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.
> 
> 	Theory and practice are very different when it comes
> to data plane diagnostics vs. control plane. Hoping that it is easier 
> and ensuring that it actually works %100 of the time are two quite 
> different things.
NH=> If we have a p2p or p2mp connections then all facets of
traffic/fault/performance management are definable and tractable.  This
is not the case with mp2p merging constructs as these don't satisfy
connection requirements.   This is just a fact.  Are you saying this is
not true or something?

>  Also, as someone who
> works at a network operator, you surely can appreciate the 
> advantages of using a single mechanism for fault-detection 
> and trouble-shooting, especially if it is widely deployed and 
> available.
NH=> True, I also appreciate how much easier and cost-effective it is to
operate technologies that respect arch requirements (for their mode) and
come originally well-defined functionally (technologies that are either
significantly functionally deficient or over-engineered are bad).   Not
all technologies are equal when it comes to Opex considerations.

regards, Neil
> 
> 	--Tom
> 
> 
> > 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