Skip to main content

Liaison statement
LS173 - Comments on draft-ietf-mpls-tp-data-plane-02 [Ref # 030.02]

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2010-05-06
From Group ITU-T-SG-15
From Contact Hiroshi Ota
To Group mpls
To Contacts swallow@cisco.com
loa@pi.nu
Cc paf@cisco.com
stbryant@cisco.com
adrian.farrel@huawei.com
rcallon@juniper.net
mpls@ietf.org
yoichi.maeda@ntt-at.co.jp
steve.trowbridge@alcatel-lucent.com
Response Contact tsbsg15@itu.int
greg.jones@itu.int
hiroshi.ota@itu.int
Technical Contact malcolm.betts@zte.com.cn
Purpose For action
Deadline 2010-05-28 Action Taken
Attachments LS173 - Comments on draft-ietf-mpls-tp-data-plane-02 [Ref # 030.02] - pdf body
Body
Thank you for your liaison statement (Ref # 030.01) requesting a review by the
ITU-T of the MPLS-TP data plane draft. The experts of Q.12/15 have reviewed
draft-ietf-mpls-tp-data-plane-01 by correspondence and request that the
following changes are made before the IETF approves the draft.

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.

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.