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"
On Apr 11, 2006, at 11:48 AM, <neil.2.harrison@bt.com> wrote: >> 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, tracing in a co-ps mode technology that respects connection > requirements should be a whole lot easier than in one than does > not. So > I would argue that you can re-use the same diagnostic tools in T-MPLS. Theory and practice are very different when it comes to data plane diagnostics vs. control plane. Hoping that it is easier and ensuring that it actually works %100 of the time are two quite different things. Also, as someone who works at a network operator, you surely can appreciate the advantages of using a single mechanism for fault-detection and trouble-shooting, especially if it is widely deployed and available. --Tom > BTW - We really should start with a definition of defects including > entry/exit criteria...everything else builds on this baseline. Unless > one has a proper connection however, I really don't see how this is > possible. > > regards, Neil >> >> --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 >> _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|