The MPLS WG Archive

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

I too got a mail-fail indicate on this ('too many recipients') so
re-posting just to the MPLS folks.

 
> Tom,
> 
> A couple of observations on your remarks:
> 
> (i)	I agree with you that some clarity is required on 
> specific reserved label ranges and their uses.  However, I'd 
> say it's bigger than just the label ranges and should also 
> include how all the header fields (ie S, EXP, TTL) are to be 
> used in T-MPLS (I noted you don't think this 'T-MPLS' name is 
> good, but I'll stick with it here).  Why?  Well, folks need 
> to consider the various client/server relationships that 
> could exist between the various spins of MPLS as-is and 
> T-MPLS....and especially misconnectivity between them....so 
> how is this going to be handled?
> 
> (ii)	I'd urge you not to be so hard on Y.1711.  This is a 
> simple defect detection/handling OAM solution for ANY co-ps 
> mode network based on label-swapping that respects the 
> architectural requirement of what defines a connection (ie 
> single source, connectivity=1).  Any form of MPLS that has 
> merging (so that is LDP and/or PHP) violates the rules for a 
> connection.....this is just a fact.....and so Y.1711 is not 
> appropriate (but then attempting to apply any sort of 
> determinism across any aspect of traffic/fault/performance 
> management is fraught with problems when the rules for 
> connections are broken).
> 
> regards, Neil
> 
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> > Sent: 10 April 2006 16:15
> > To: Greg Jones(ITU-T SG 15)
> > Cc: mpls@lists.ietf.org; mark.jones@sprint.com; 
> > maeda@ansl.ntt.co.jp; info@mfaforum.org; 
> > Ghani.Abbas@marconi.com; Scott Brim W; Bill (E-mail) Fenner; 
> > statements@ietf.org; Ross Callon; betts01@nortel.com
> > Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented 
> > Recommendations" 
> > 
> > 
> > 
> > 	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
> > > 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