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.

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. 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