Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations"

From: <[email-masked]>
Date: Tue, 11 Apr 2006 15:26:25 +0100

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:[email-masked]]
> > Sent: 10 April 2006 16:15
> > To: Greg Jones(ITU-T SG 15)
> > Cc: [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]; 
> > [email-masked]; Scott Brim W; Bill (E-mail) Fenner; 
> > [email-masked]; Ross Callon; [email-masked]
> > 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) <[email-masked]>
> > > To: IETF MPLS WG, CC: MFA Forum(George Swallow 
> <[email-masked]>, 
> > > Loa Andersson <[email-masked]>)
> > > Cc: [email-masked]
> > > [email-masked]
> > > [email-masked]
> > > [email-masked]
> > > [email-masked]
> > > [email-masked]
> > > [email-masked]
> > > [email-masked]
> > > Reponse Contact: [email-masked]
> > > Technical Contact: [email-masked] [email-masked]
> > > [email-masked]
> > > 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
> > > [email-masked] https://www1.ietf.org/mailman/listinfo/mpls
> > 
> > _______________________________________________
> > mpls mailing list
> > [email-masked] https://www1.ietf.org/mailman/listinfo/mpls
> > 
> 

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: George Swallow <[email-masked]>
Date: Tue, 11 Apr 2006 11:25:19 -0400

Neil -

> include how all the header fields (ie S, EXP, TTL) are to be 

Could you enlighten us as to what you are considering here.  Prima
facia, it would appear that you are diverting further from MPLS than the
liaised material would indicate....

> how is this going to be handled?

We handle such relationships for ATM, SONET, Ethernet without calling
any of those MPLS.  I see no argument here for including MPLS in the
name of your transport technology.

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719