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? I didn't say that; please re-read what I posted. I said it is essentially a subset of functionality (sans the reserved label range and Y.1711). > 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? How do you trace the LSP using Y.1711 or is that not an important function for OAM for T-MPLS? Also, from the IETF's perspective, we have already defined a tool set that satisfies all of the requirements of ping and trace (tree and path) in a single tool, which is now on the standards track, is widely deployed, and thus should be the tool specified herein. --Tom > -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 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|