The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns"
Greg and all, In your message to the MPLS WG you jave stated state that reservation of labels 16 to 31 was seen as not leading to any interoperability issues between MPLS and T-MPLS because <quote> the label allocation on a link is defined in IETF RFCs as a local matter for any MPLS device <end quote> Please note that Section 3.14 of RFC 3031 "Multiprotocol Label Switching Architecture" defines at least two types of label spaces in a LSR: - per-interface - per-platform. (Other types of label spaces are not precluded by RFC 3031.) To the best of my knowledge, both types of label spaces are widely used in the MPLS networks already deployed. In certain cases (e.g., when dealing with MPLS Pseudo-Wire labels), usage of per-platform label space is MANDATORY. (See http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-17.txt which has been already approvde for publication as a Standards Track RFC.) Please note also that encoding of the MPLS Shim header as defined in RFC 3032 does not distinguish between these two types of label spaces. I am hence concerned that reservation of additional labels may cause interoperability issues between T-MPLS and existing LSRs using per-platform label allocation. At the very least it seems that your analysis of the possible interoperability use cases does not consider the situation when per-platform label space is used and includes labels reserved for T-MPLS. Regards, Sasha > -----Original Message----- > From: Greg Jones [mailto:tsbsg15@itu.int] > Sent: Sunday, April 02, 2006 9:59 PM > To: George Swallow; Loa Andersson > Cc: mpls@lists.ietf.org; mark.jones@sprint.com; maeda@ansl.ntt.co.jp; > info@mfaforum.org; Ghani.Abbas@marconi.com; sbrim@cisco.com; > fenner@research.att.com; statements@ietf.org; rcallon@juniper.net; > tsbsg15@itu.int; betts01@nortel.com > Subject: [mpls] New Liaison Statement, "T-MPLS Consented > Recommendations" > > > > Title: T-MPLS Consented Recommendations > Submission Date: 2006-04-02 > URL of the IETF Web page: > https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=207 > Please reply by 2006-04-17 > > From: Greg Jones(ITU-T SG 15) <tsbsg15@itu.int> > To: IETF MPLS WG, CC: MFA Forum(George Swallow > <swallow@cisco.com>, Loa Andersson <loa@pi.se>) > Cc: info@mfaforum.org > maeda@ansl.ntt.co.jp > sjtrowbridge@lucent.com > rcallon@juniper.net > fenner@research.att.com > sob@harvard.edu > sbrim@cisco.com > mpls@lists.ietf.org > Reponse Contact: tsbsg15@itu.int > Technical Contact: Ghani.Abbas@marconi.com > mark.jones@sprint.com > betts01@nortel.com > Purpose: For action > Body: We apologize for not having sent a liaison regarding > three consented Recommendations related to > T-MPLS. The intent of these Recommendations is not to change > MPLS but rather to identify a > subset of existing MPLS necessary and sufficient to provide > connection-oriented packet transport. > The approach to the work was to make a profile of the MPLS > data plane functionalities defined in > IETF RFCs using the description of MPLS provided in G.8110 > (which was approved last year). > The intended application of this profile is to provide a > connection-oriented packet transport > network. > The focus of the three new recommendations is on the data > plane aspects of T-MPLS. Control plane > aspects are currently for further study and the work on this > subject is starting. > According to our work methodology the T-MPLS definitions are > split into the three main > Recommendations that have been consented in February 2006: > * G.8110.1 dealing with the T-MPLS Architecture > * G.8112 dealing with T-MPLS interface specification > * G.8121 dealing with T-MPLS equipment functional specification > A brief high-level introduction of the essential features and > selected options for Transport MPLS > can be found in section 6/G.8110.1. > The objective of the work done by ITU-T SG15 was to define a > way to use MPLS as a connection- > oriented packet-based transport solution for packet aware > transport networks that can support both > packet and circuit (e.g. SDH, OTH or WDM) switching > technologies under a common operation, > control and management paradigm. For this purpose T-MPLS > deploys the MPLS frame format, > Client to MPLS mapping and MPLS to MPLS multiplexing and > complements this with transport > network OAM (Y.1711), nested connection monitoring requiring > the labels to be present up to the > final node in the network, protection switching > (Y.1720/G.8131), transport network based control > and management planes, maintaining frame ordering and a > restricted number of classes of > service/queues. > * MPLS has many applications and it is desirable to > identify a subset of MPLS technology that > provides the necessary and sufficient functionality for > transport applications. > We have indicated below some of the options we have selected :- > * In IETF RFCs the usage of PHP is optional. We decided > not to use it in order to simplify OAM > procedures > * In IETF RFCs the usage of merging is optional. We > decided not to use it in order to simplify > OAM procedures and also because the relative lower number of > LSPs to be supported is not > considered a major scaling issue > * The usage of ECMP is optional. We decided not to use it > in order to simplify OAM procedures > * Leaving labels 16-31 for further study was seen as a no > change because the label allocation on a > link is defined in IETF RFCs as a local matter for any MPLS device. > We are not expecting that the current version of the > specification is going to create any > interoperability issue. We envisage two possible cases of > interoperability: > 1. Interoperability between a T-MPLS box and an existing > full-featured and fully configurable > MPLS box can be solved by configuring the MPLS box to use the > same options selected by T- > MPLS (T-MPLS being a profile of MPLS this should be > possible). In this case the link between > the two boxes is a T-MPLS link and in the scope of our > Recommendations. > 2. Interoperability between a transport platform > supporting T-MPLS and an existing MPLS box > that uses a different option selection than T-MPLS, should be > solved by the transport platform. > In this case the link between the transport platform and the > MPLS box is not a T-MPLS link and > therefore it is outside the scope of T-MPLS recommendations. > We are looking for cooperation > with IETF to develop the detailed specification of this case. > Please find attached the text of the consented > Recommendations. Please note that some minor > modifications may be made to these draft Recommendations as a > result of comments made during > the approval process > We will appreciate your comments and suggestions in relation > to the initial scope of T-MPLS as a > packet transport network technology. > We are planning to review your comments during the next > meeting that is planned in Kobe (Japan) > on 22-27 April 2006. Results of the comments will be included > into our future work (e.g. corrigenda > or amendments) on T-MPLS Recommendations. Amendments of > T-MPLS Recommendations are > already in our plan for the next SG15 plenary meeting in > November 2006.We are looking forward > for future cooperation with you in T-MPLS data plane and > control plane evolution. > > Attachments: Consented Text of G.8110.1, G.8112, G.8121 > Attachment(s): > Consented Text of G.8110.1 (https://datatracker.ietf.org/documents/LIAISON/file288.zip) Consented Text of G.8112 (https://datatracker.ietf.org/documents/LIAISON/file289.zip) Consented Text of G.8121 (https://datatracker.ietf.org/documents/LIAISON/file290.zip) _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls |
|