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

["Shah, Himanshu" <[e-mail]>]

...inline 



-----Original Message-----
From: Drake, John E [mailto:[e-mail]] 
Sent: Thursday, December 11, 2008 11:45 AM
To: Shah, Himanshu; Malis, Andrew G. (Andy); Adrian Farrel; Ben
Niven-Jenkins; [e-mail]
Subject: RE: [Mpls-interop] MPLS over MPLS-TP

 

>-----Original Message-----
>From: Shah, Himanshu [mailto:[e-mail]]
>Sent: Thursday, December 11, 2008 8:23 AM
>To: Malis, Andrew G. (Andy); Drake, John E; Adrian Farrel; Ben 
>Niven-Jenkins; [e-mail]
>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
himanshu> 2. PW label can be followed by control word, giving more
separation, less confusion for LSRs
himanshu> 3. Given provider may chose custom label range for PWs and
MPLS in his network, giving further separation
etc etc

/himanshu






>Not sure if
>erroneous label pop changing the trajectory is a solvable problem in 
>MPLS (especially for stacked labels).
>
>/himanshu
>
>
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]] On Behalf Of Malis, Andrew G.
>(Andy)
>Sent: Thursday, December 11, 2008 10:33 AM
>To: Drake, John E; Adrian Farrel; Ben Niven-Jenkins; 
>[e-mail]
>Subject: Re: [Mpls-interop] MPLS over MPLS-TP
>
>John,
>
>Exactly.
>
>Cheers,
>Andy
>
>-----Original Message-----
>From: Drake, John E [mailto:[e-mail]]
>Sent: Thursday, December 11, 2008 10:28 AM
>To: Malis, Andrew G. (Andy); Adrian Farrel; Ben Niven-Jenkins; 
>[e-mail]
>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:[e-mail]]
>>Sent: Thursday, December 11, 2008 7:19 AM
>>To: Drake, John E; Adrian Farrel; Ben Niven-Jenkins; 
>>[e-mail]
>>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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mpls-interop
>
>

_______________________________________________
Mpls-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-interop