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