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. |