Re: [Mpls-interop] MPLS over MPLS-TP

inline 

>-----Original Message-----
>From: Shah, Himanshu [mailto:hshah@ciena.com] 
>Sent: Thursday, December 11, 2008 9:06 AM
>To: Drake, John E; Malis, Andrew G. (Andy); Adrian Farrel; Ben 
>Niven-Jenkins; mpls-interop@ietf.org
>Subject: RE: [Mpls-interop] MPLS over MPLS-TP
>
>...inline 
>
>
>
>-----Original Message-----
>From: Drake, John E [mailto:John.E.Drake2@boeing.com]
>Sent: Thursday, December 11, 2008 11:45 AM
>To: Shah, Himanshu; Malis, Andrew G. (Andy); Adrian Farrel; 
>Ben Niven-Jenkins; mpls-interop@ietf.org
>Subject: RE: [Mpls-interop] MPLS over MPLS-TP
>
> 
>
>>-----Original Message-----
>>From: Shah, Himanshu [mailto:hshah@ciena.com]
>>Sent: Thursday, December 11, 2008 8:23 AM
>>To: Malis, Andrew G. (Andy); Drake, John E; Adrian Farrel; Ben 
>>Niven-Jenkins; mpls-interop@ietf.org
>>Subject: RE: [Mpls-interop] MPLS over MPLS-TP
>>
>>Andy,
>>
>>I am of the opinion that PW provides the better demarcation than 
>>mapping client MPLS or IP packets directly over the MPLS-TP 
>tunnel. The
>
>>generalized useage comes by virtue of being able to map 
>different kinds
>
>>of PWs over MPLS-TP tunnels.
>
>JD:  I'm sure everyone has a different opinion.  By saying 
>that MPLS TP is payload agnostic, we allow each service 
>provider to make their own decision wrt service demarcation.
>
>>
>>Now, MPLS-PWoverMPLS-TP vs client-MPLSoverMPLS-TP are virtually 
>>indistiguishable at the LSRs, but atleast PW labels have 
>provider label
>
>>contexts at the LSEs.
>
>JD:  What is so much more appealing about having provider 
>label context via a PW label rather than an MPLS Label?  
>
>
>himanshu> Several. traditional ones.
>himanshu> 1. LSEs do not have to participate in client MPLS

JD:  In neither case, MPLS TP/PW/MPLS nor MPLS TP/MPLS, does the
provider participate in client MPLS.  Please see my response to Nurit.

> 2. 
>PW label 
>himanshu> can be followed by control word, giving more
>separation, less confusion for LSRs

JD:  This sounds like an assertion.

>himanshu> 3. Given provider may chose custom label range for PWs and
>MPLS in his network, giving further separation etc etc

JD:  A given provider is free to use custom label ranges in his network
in both the MPLS TP/PW/MPLS and the MPLS TP/MPLS cases.  As noted above,
in either case, the service provider only deals with his label stack and
has no visibility or awareness of the customer label stack.

>
>/himanshu
>
>
>
>
>
>
>>Not sure if
>>erroneous label pop changing the trajectory is a solvable problem in 
>>MPLS (especially for stacked labels).
>>
>>/himanshu
>>
>>
>>
>>-----Original Message-----
>>From: mpls-interop-bounces@ietf.org
>>[mailto:mpls-interop-bounces@ietf.org] On Behalf Of Malis, Andrew G.
>>(Andy)
>>Sent: Thursday, December 11, 2008 10:33 AM
>>To: Drake, John E; Adrian Farrel; Ben Niven-Jenkins; 
>>mpls-interop@ietf.org
>>Subject: Re: [Mpls-interop] MPLS over MPLS-TP
>>
>>John,
>>
>>Exactly.
>>
>>Cheers,
>>Andy
>>
>>-----Original Message-----
>>From: Drake, John E [mailto:John.E.Drake2@boeing.com]
>>Sent: Thursday, December 11, 2008 10:28 AM
>>To: Malis, Andrew G. (Andy); Adrian Farrel; Ben Niven-Jenkins; 
>>mpls-interop@ietf.org
>>Subject: RE: [Mpls-interop] MPLS over MPLS-TP
>>
>>Andy,
>>
>>Great.  So, it is up to the client endpoints of the MPLS TP LSP to 
>>understand the payload contents and we could have as payloads, for 
>>example, MPLS packets with their own label stack, IP packets, or 
>>ethernet PW packets which in turn contain, for example, MPLS 
>packets or
>
>>IP packets.
>>
>>Thanks,
>>
>>John
>>
>>>-----Original Message-----
>>>From: Malis, Andrew G. (Andy) [mailto:andrew.g.malis@verizon.com]
>>>Sent: Thursday, December 11, 2008 7:19 AM
>>>To: Drake, John E; Adrian Farrel; Ben Niven-Jenkins; 
>>>mpls-interop@ietf.org
>>>Subject: RE: [Mpls-interop] MPLS over MPLS-TP
>>>
>>>John,
>>>
>>>JD:  I agree with your point about PW labels, but doesn't the same 
>>>point apply to the label stack with two EOS bits?  Viz,
>>having the EOS
>>>bit set will not prevent an implementation from messing up
>>the stack in
>>
>>>arbitrary and capricious ways.
>>>
>>>Isn't another alternative to just have the MPLS TP network be 
>>>completely agnostic to the contents of its payloads, as a
>>server layer
>>>is supposed to be?
>>>In that case, the payload could in fact be an MPLS payload
>>with its own
>>
>>>stack.
>>>
>>>AM> I must not have been clear enough, because that was my
>>>intention. We
>>>are in agreement here. The payload would not have to be another MPLS 
>>>stack, but it could be, and that was the context of the original 
>>>discussion between Ben and Adrian.
>>>
>>>Cheers,
>>>Andy
>>>
>>>
>>_______________________________________________
>>Mpls-interop mailing list
>>Mpls-interop@ietf.org
>>https://www.ietf.org/mailman/listinfo/mpls-interop
>>
>>
>
>
_______________________________________________
Mpls-interop mailing list
Mpls-interop@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-interop