Liaison Statement Submission Date: 2006-09-13 From: Loa Andersson (IETF Liaison to ITU-T, MPLS; IETF MPLS WG Chair; loa@pi.se) Scott Bradner (IETF Liaison to ITU-T, sob@harvard.edu) Deborah Brungard (IETF CCAMP WG Chair, dbrungard@att.com) Stewart Bryant (IETF PWE3 WG Chair, stbryant@cisco.com) Adrian Farrel (IETF Liaison to SG15, CCAMP WG Chair, adrian@olddog.co.uk) Danny McPherson (IETF PWE3 WG Chair, danny@arbor.net) George Swallow (IETF MPLS WG Chair, swallow@cisco.com) To: ITU-T Study Group 15; Greg Jones (greg.jones@itu.int) CC: IESG (iesg@ietf.org) IAB (iab@ietf.org) Steve Trowbridge (sjtrowbridge@lucent.com) Malcolm Betts (betts01@nortel.com) Yoichi Maeda (maeda@ansl.ntt.co.jp) Ghani Abbas (ghani.abbas@marconi.com) Houlin Zhao (houlin.zhao@itu.int) CCAMP mailing list (ccamp@ops.ietf.org) MPLS mailing list (mpls@lists.ietf.org) PWE3 mailing list (pwe3@ietf.org) Re: T-MPLS use of the MPLS Ethertypes Response Contact: George Swallow Technical Contact: George Swallow Purpose: For action Deadline: 2006-10-13 We would like to thank you for your response to our liaison. We feel that through the liaison activity and the Ottawa meeting we have entered into a productive and useful dialogue. We are particularly pleased by your positive reaction to most of our concerns. We do, however, once again, request documentation of the problem that T-MPLS solves. We feel that this documentation is fundamental to a proper review of the T-MPLS architecture, protocol requirements, and any future solutions, and we advise the ITU-T not to present any T-MPLS Recommendations for consent until work on a T-MPLS problem statement is well advanced. Further, a full reference diagram of the interfaces and services of the T-MPLS network would be most useful. We understand that the direct adaptation of an IP/MPLS client over a T-MPLS server is still at a very preliminary stage. However, some understanding of the client/server relationship is necessary in order to adequately evaluate architectural decisions currently being made in G.8110.1. The most immediate concern is the proposed use of the MPLS Ethertypes. First we would like to call your attention to the fact that we are in the process of modifying the semantics of the two Ethertypes used by MPLS. Currently their designations are "MPLS Unicast" (8847) and "MPLS Multicast" (8848). The new semantics will be "Downstream Assigned" (8847) and "Upstream Assigned" (8848)". On a practical level, they will still be used for Unicast and Multicast respectively, however the change has been made to clarify which Label Switch Router (LSR) controls each label space. Each of these label spaces is shared by all MPLS applications. Each space is managed by a label-manager which is responsible for label allocation and reclamation. When a packet is received at the downstream LSR with Ethertype 8847 it is looked up in a table managed by the downstream router. Conversely when a packet is received at the downstream LSR with Ethertype 8848 it is looked up in a table managed by the upstream router. In your liaison to the MFA Forum dated 19-23 June 2006 you say, T-MPLS is intended to be a separate layer network with respect to MPLS. However, T- MPLS will use the same data-link protocol ID (e.g. EtherType), frame format and forwarding semantics for as those defined for MPLS frames. T-MPLS and MPLS cannot coexist on the same "interface" (for example they could not coexist on a single Ethernet VLAN, however they could be multiplexed on to a common Ethernet PHY using separate VLANs). On the face of it, this statement implies that MPLS and T-MPLS are two different things, but that you wish to identify them both using the same Ethertype. The Ethertype is the primary means for multiplexing and distinguishing protocols over Ethernet. The Ethertype identifies the protocol entity that will receive a packet at the layer above. VLANs on the other hand are primarily intended as a service level interface, allowing multiple virtual LANs over a single bridged domain. . If T-MPLS cannot co-exist with MPLS over Ethernet, and T-MPLS is in fact a separate layer network, then it should be identified by its own Ethertype(s), Clear and unambiguous identification is in the best interest of all involved. In particular, if T- MPLS is being architected in such a way that would prevent it from acquiring labels by interacting with a shared label manager, then separate Ethertypes would guarantee that there is no confusion as to which label spaces belong to T-MPLS. Note further that if T-MPLS is being architected in such a way that it can (or could) interact with a shared label manager and could co-exist over the same interface sharing the MPLS label spaces with other MPLS applications, then we would welcome use of the MPLS Ethertypes. We believe that a decision to use the MPLS Ethertypes to point to a label space other than as defined by the MPLS RFCs to be architecturally unsound and ultimately will prove to be limiting to the deployment options available in networks which employ both MPLS and T-MPLS. Sincerely, Loa Andersson Scott Bradner Deborah Brungard Stewart Bryant Adrian Farrel Danny McPherson George Swallow