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"
Hi Tom, 1) Reading the T-MPLS specs I didn't see any specific label range restriction. Where have you seen this? 2) The OAM specified is for T-MPLS, which as you said is a subset of MPLS. Specifically T-MPLS doesn't include PHP, merging and ECMP as indicated by the Liaison. So why should an OAM that is going to be used for T-MPLS support those functions? Regards, -Shahram > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Tuesday, April 11, 2006 9:25 AM > To: mpls@lists.ietf.org > Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented > Recommendations" > > > [Resending to mpls list as I got a warning from the mailer > that there was a suspicious number of recipients, so I am not > sure it was delivered.] > > Hi, > > A few things in the ITU T-MPLS document concern me: > > 1) The document itself constitutes what is essentially > two things: an protocol specification > and an implementation guideline. > > For this reason, I first suggest that this document > needs to be split into two: one that specifies > the label range allocation (as well as requests > it from the IETF), and a second that specifies > the implementation guideline. I also suggest > removal of "MPLS" from the name. This is very > confusing, and implies that this document is > some new standard for MPLS, whereas what it > really specifies (sans the label range allocation > and the OAM) is a subset of MPLS functionality. > > 2) With regard to the label range reservation, I am > troubled by this because MPLS has been widely deployed > without the said reserved label range. Deployment > of LSRs that suddenly use this special label > range will most likely lead to interoperability > issues. I am also troubled by the lack of > definition of what the reserved labels should > be used for. If in the future, these labels are > defined in a manner that is incompatible with > existing LSRs, this will pose a significant > hurdle to deployments. Again, a separate document that > requests the label range, as well as specifies > what they are to be used for is appropriate. > > 3) The OAM as specified does not meet the IETF's > requirements for OAM specified in RFC4377. > Y.1711 is not suitable for environments where PHP is > enabled, and it also has other deficiencies such as a > lack of tracing functionality, and cannot handle Equal > Cost Multi-Path (ECMP) LSPs. In particular, section > 4.3 of RFC4377 stipulates that path characterization > functions must be able to work in these cases: > > 4.3. Path Characterization > > The path characterization function is the ability to > reveal details > of LSR forwarding operations. These details can then be compared > during subsequent testing relevant to OAM functionality. This > includes but is not limited to: > > - consistent use of pipe or uniform time to live > (TTL) models by > an LSR [RFC3443]. > > - sufficient details that allow the test origin to > exercise all > path permutations related to load spreading (e.g., ECMP). > > - stack operations performed by the LSR, such as pushes, pops, > and TTL propagation at penultimate hop LSRs. > > I suggest replacing the reference to Y.1711 with a reference > to rfc4377, rfc4378, and rfc4379. > > --Tom > > > > > 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 > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|