datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

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

Submission Date: 2010-05-06
From: ITU-T SG 15 (Greg Jones)
To: IETF MPLS WG (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.