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

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 6 Apr 2006 19:08:14 +0200

Greg and all,
In your message to the MPLS WG you jave stated state that reservation of
labels 
16 to 31 was seen as not leading to any interoperability issues between MPLS
and 
T-MPLS because 

<quote>
	the label allocation on a link is defined in IETF RFCs 
	as a local matter for any MPLS device
<end quote>

Please note that Section 3.14 of RFC 3031 "Multiprotocol Label Switching 
Architecture" defines at least two types of label spaces in a LSR:

- per-interface
- per-platform.

(Other types of label spaces are not precluded by RFC 3031.)

To the best of my knowledge, both types of label spaces are widely used
in the MPLS networks already deployed. In certain cases (e.g., when
dealing with MPLS Pseudo-Wire labels), usage of per-platform label
space is MANDATORY.
(See
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-17.txt
which has been already approvde for publication as a Standards Track RFC.)

Please note also that encoding of the MPLS Shim header as defined in RFC
3032
does not distinguish between these two types of label spaces.

I am hence concerned that reservation of additional labels may cause
interoperability
issues between T-MPLS and existing LSRs using per-platform label allocation.
At the very least it seems that your analysis of the possible
interoperability use cases
does not consider the situation when per-platform label space is used and
includes
labels reserved for T-MPLS.

Regards,
			Sasha

> -----Original Message-----
> From: Greg Jones [mailto:[email-masked]]
> Sent: Sunday, April 02, 2006 9:59 PM
> To: George Swallow; Loa Andersson
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: [mpls] New Liaison Statement, "T-MPLS Consented
> Recommendations" 
> 
> 
> 
> 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

---

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

> From: George Swallow [mailto:[email-masked]]
> Sent: Tuesday, April 11, 2006 11:25 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented
> Recommendations" 
> 
> 
> Neil -
> 
> > (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 
> 
> 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....
> 
> > 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?
> 
> 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.

But none of them uses MPLS packet format: MPLS label, TTL, EXP, and switch based on
the 20-bit label, and use EXP-bit to identify the CoS/DP, and use TTL for loop detection. MPLS, by Design, consists of two distinct planes: data-plane and control-plane. If the control-plane nails down only one specific path for an LSP, using say RSVP-TE, then there is no ECMP and merging. Additinally since PHP is optional, there is no mandate to support it. So are you saying a technology that uses MPLS data-plane, but its control-plane doesn't support ECMP, merging or PHP is not MPLS?

-Shahram

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

---

From: Shahram Davari <[email-masked]>
Date: Tue, 11 Apr 2006 08:57:49 -0700

Ok, now I go it. I think this should be corrected, specially when there is no use for it. 

-Shahram

> From: Scott W Brim [mailto:[email-masked]]
> Sent: Tuesday, April 11, 2006 11:43 AM
> To: Shahram Davari
> Cc: [email-masked]; 'Thomas D. Nadeau'
> Recommendatio ns"
> On 04/11/2006 11:07 AM, Shahram Davari allegedly wrote:
> > Hi Scott,
> > 
> > The tabel in G.8112 diesn't show any restriction on label range. It
> > is in-line with RFC-3032. It just repeats which of the 32 reserved
> > labels are already in use, and which are for FFS. It also mentions
> > that all the remaining 2^20-32 labels could be used for T-MPLS. What
> > restriction do you see in that?
> > 
> > -Shahram
> 
> In 3032, labels 0-3 have special use and 4-15 are reserved.  G.8112
> (table 6-7) extends this by saying: "16-31 For further 
> study".  Existing
> implementations use these labels by default -- some cannot be 
> configured
> not to.
> 
> Cisco put in a comment suggesting this be modified to "16-31  For
> further study in consultation with the IETF".  The editor responded
> suggesting "16-31 Not used in T-MPLS" and a note: "Labels 
> 16-31 are, by
> convention, not used in T-MPLS. If used in the future, they 
> will be used
> in the context of label pop, push or swap as defined in RFC3031 and
> RFC3032."  I have trouble seeing the difference.
>

---

From: <[email-masked]>
Date: Tue, 11 Apr 2006 17:46:01 +0100

> >> 	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
> >>>
> >>>> From: Thomas D. Nadeau [mailto:[email-masked]]
> >>>> Sent: Tuesday, April 11, 2006 10:34 AM
> >>>> To: Shahram Davari
> >>>> Cc: [email-masked]
> >>>>> 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
> >>>>>
> >>>>>> From: Thomas D. Nadeau [mailto:[email-masked]]
> >>>>>> Sent: Tuesday, April 11, 2006 9:25 AM
> >>>>>> To: [email-masked]
> >>>>>> [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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> URL of the IETF Web page: https://datatracker.ietf.org/public/
> >>>>>>> liaison_detail.cgi?detail_id=207
> >>>>>>> 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
> >>>>>>> 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 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
> >>>>>>> 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-
> >> 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
> >>>>>>> *	MPLS has many applications and it is desirable
> >> to identify a
> >>>>>>> subset of MPLS technology that
> >> transport
> >>>>>>> applications.
> >>>>>>> OAM procedures and also because the relative lower
> >> number of LSPs
> >>>>>>> to be supported is not considered a major scaling issue
> >>>>>>> *	Leaving labels 16-31 for further study was seen
> >> as a no change
> >>>>>>> because the label allocation on a
> >>>>
> >>>> TOM: Read above.
> >>>>
> >> 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
> >>>>>>> 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
> >>>>>>> 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
> >>>>>>> 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
> >>>>>>> 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.
> >>>>>>>
> >>>>>>>      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)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> [email-masked] https://www1.ietf.org/mailman/listinfo/mpls
> >>>>>>
> >>>>>
> >>>>> [email-masked] https://www1.ietf.org/mailman/listinfo/mpls
> >>>>
> >>>
> >>> [email-masked] https://www1.ietf.org/mailman/listinfo/mpls
> >>
> >> [email-masked] https://www1.ietf.org/mailman/listinfo/mpls
> >>
>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 11 Apr 2006 13:28:26 -0400

> > Tom,
> > 
> > A couple of observations on your remarks:
> > 
> > (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).

Neil, Tom,

Just curious: you both say that Y.1711 does not work in conjunction with PHP. Why is that? The CV frames have a TTSI vlaue that can be used to identify the source even when because of PHP (and Label Merge) the LSP context is lost.

Peter

[snipped]

---

From: "Mack-Crane, T. Benjamin" <[email-masked]>
Date: Tue, 11 Apr 2006 17:24:44 -0500

Hi Adrian,

I agree that the requirements do not seem to be clear to everyone
participating in this discussion.  G.8110.1 does state "Transport MPLS
is a connection-oriented packet switched transport layer network
technology based on MPLS technology" which says a lot to folks familiar
with transport network architectures and functional modeling of layer
networks.  I understand this may not be clear to others however.

Perhaps one good way to think about T-MPLS is as an alternative to TDM
transport.  An LSR will relate to a T-MPLS transport device in a manner
similar to the way it relates to a SONET or SDH transport device, and
T-MPLS will provide transport services similar to those provided by
SONET/SDH.  From this perspective it may be easier to understand the
functional subset selected for T-MPLS.

Regards,
Ben

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Tuesday, April 11, 2006 12:42 PM
> To: Shahram Davari; 'Ash, Gerald R (Jerry), ALABS'; Thomas D. Nadeau;
> [email-masked]
Recommendatio
> ns"
> 
> Shahram,
> 
> Jerry asked about Y.1713 and you said...
> 
> > My guess: because it is not needed for T-MPLS, since T-MPLS doesn't
> support label merging (aka LDP).
> 
> This is really hard for us.
> We cannot hope to guess what is or is not needed for T-MPLS becuase
no-one
> has seen fit to explain the requirements to us.
> No: none of the three documents liaised has any discussion of
> requirements. It all launches straight into feature sets.
> 
> But one thing the documents *do* say is that protocols are out of
scope.
> So it is entirely possible that LDP would be used in T-MPLS (although
I
> thinik that would be a bad idea!)
> 
> You should note very clearly that LDP is not synonymous with label
> merging.
> 
> Adrian
> 
> 
> 
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================