Liaison statement
Response to comments in LS173 - Comments on draft-ietf-mpls-tp-data-plane-02 (ref #030.03)

Thank you for your draft-ietf-mpls-tp-data-plane-02, the Internet Draft
has been updated and we have requested that it is published as a RFC
on the standards track.

The comment in the liaison is:

Section 3.1.1.  LSP Packet Encapsulation and Forwarding: Replace the
fourth paragraph:

  "Support for the Pipe and Short Pipe DiffServ tunneling and TTL
  processing models described in [RFC3270] and [RFC3443] is REQUIRED by
  the MPLS-TP.  Support for the Uniform model is OPTIONAL."

  With:

  "Support for the Pipe and Short Pipe DiffServ tunneling and TTL
  processing models described in [RFC3270] and [RFC3443] is REQUIRED by
  the MPLS-TP.  Support for the Uniform model is for REQUIRED for
  Diffserv tunnelling. The Uniform model MUST NOT be used for TTL
  processing."

  Reason for the requested change:
  The modified fourth paragraph does not fully address our comment on the
  -01 version which was intended to provide support for the PST
  application.  The uniform model must be supported to ensure that a LSP
  in a PST can be configured to have the same PHB as the LSP being
  monitored.  Also the uniform model for TTL processing must not be used
  to avoid problems with the TTL addressing of MIPs.

The response is:

We have changed the paragraph text to:

  The Uniform, Pipe and Short Pipe DiffServ tunneling and TTL processing
  models described in [RFC3270] and [RFC3443] MAY be used for MPLS-TP
  LSPs.  Note however that support for the Pipe or Short Pipe models is
  REQUIRED for typical transport applications, in which the topology and
  QoS characteristics of the MPLS-TP server layer are independent of the
  client layer.  Specific applications MAY place further requirements on
  the DiffServ tunneling and TTL processing models an LSP can use.

It is not the intent of this draft to place generalised restrictions on
implementations in advance of the requirements determined by specific
applications.


The comment in the liaison is:

  Section 6.  Security Considerations: Replace:
  2.  Any MPLS label processed at the receiving LSR, such as an LSP or PW
  label, has a label value that the receiving LSR has previously
  distributed to the peer beyond that neighbour (i.e., when it is known
  that the path from the system to which the label was distributed to the
  receiving system is via that neighbour).
  With:
  2.  Packets that arrive on an interface or, for PW or hierarchical
  LSPs, LSP with a given label value should not be forwarded unless that
  label value is assigned to an LSP or PW to be carried by the peer LSR
  or PE over that interface or LSP.
  Reason for the requested change:
  The text is confusing, the replacement text is aligned with text that
  was proposed to be added to the MPLS-TP framework draft.

The response is:

We believe that your proposed text requires an extension to the MPLS
data plane that is outside the scope of the current MPLS-TP project.
Proposed extensions to the MPLS data plane to support enhanced security
are welcome and should be submitted to the MPLS working group for
consideration via the normal IETF process.




Loa Andersson
George Swallow

MPLS Working Group co-chairs