The MPLS WG Archive

[<neil.2.harrison@bt.com>]

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

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