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

From: Shahram Davari <[email-masked]>
Date: Tue, 11 Apr 2006 07:16:56 -0700

Hi Tom,

1) Reading the T-MPLS specs I didn't see any specific label range restriction. Where have you seen this?

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?

Regards,
-Shahram

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Tuesday, April 11, 2006 9:25 AM
> To: [email-masked]
> 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) <[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: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 11 Apr 2006 10:34:25 -0400

> 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

>>> because the label allocation on a

TOM: Read above.

---

From: Scott W Brim <[email-masked]>
Date: Tue, 11 Apr 2006 10:55:01 -0400

> 1) Reading the T-MPLS specs I didn't see any specific label range restriction. Where have you seen this?

It's in G.8112.