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

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

Why do you think T-MPLS is a completely different mechanism than MPLS?
Also why should the OAM for T-MPLS that is not using PHP, ECMP and merging satisfy the
general OAM requirements as specified in RFC4377?

-Shahram

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Tuesday, April 11, 2006 10:34 AM
> To: Shahram Davari
> Cc: [email-masked]
> 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:[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
> 
> 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
> >>> [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
> 

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 11 Apr 2006 11:09:24 -0400

> Why do you think T-MPLS is a completely different mechanism than MPLS?

	I didn't say that; please re-read what I posted.
I said it is essentially a subset of functionality (sans the reserved
label range and Y.1711).

> general OAM requirements as specified in RFC4377?

	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