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"
Why do you think T-MPLS is a completely different mechanism than MPLS? Also why should the OAM for T-MPLS that is not using PHP, ECMP and merging satisfy the general OAM requirements as specified in RFC4377? -Shahram > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Tuesday, April 11, 2006 10:34 AM > To: Shahram Davari > Cc: mpls@lists.ietf.org > Subject: Re: [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? > > See inline marked with "TOM:" > > > 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? > > The OAM as specified in the T-MPLS document is not a subset of > MPLS; it is a completely different mechanism from what is specified > at the IETF to meet the requirements in RFC4377. As described, y1711 > acts on a sub-set of MPLS (lets forget about the label range), but > does not meet all of the requirements as specified in RFC4377, > even for this subset of MPLS. > > --Tom > > > > > > > > > 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 > > TOM: Read above. > > >>> 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 > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|