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

How is it any better for a PW? You still have a label at the top of the
stack. There are two scenarios:

1. A label is popped at the MPLS-TP layer that shouldn't have been

That's either going to expose another label at that layer that won't be
have the proper context, or the start of an IP packet that'll be
misinterpreted as a label (since MPLS-TP switches presumably won't know
how to forward IP, at least in the fast path). In either case, if
there's a matching label allocation to the 20 bits in the header, then
it'll be forwarded out a random interface, or dropped if there's no
match.

2. An MPLS-TP label wasn't popped that should have been

That'll expose (probably) the bottom-most MPLS-TP label to the IP/MPLS
client router. Again, what happens next depends on how that label is
interpreted by the router.

Either way, how are things any better if you use a PW label?

Cheers,
Andy

-----Original Message-----
From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] 
Sent: Thursday, December 11, 2008 3:03 PM
To: Malis, Andrew G. (Andy); Adrian Farrel; Drake, John E;
mpls-interop@ietf.org
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Andy,

On 11/12/2008 15:31, "Malis, Andrew G. (Andy)"
<andrew.g.malis@verizon.com>
wrote:
> AM> The intention would be that the MPLS-TP EOS bit would only be
> encountered at boundary the MPLS-TP network, and the payload would
> delivered to the client to do with as it desires (and expects),
whether
> it's IP to forward, MPLS to switch using router-allocated labels, PW
> contents, or something else entirely. To the client, there should be
no
> difference (at some layer of abstraction above the interface details)
> between using MPLS-TP for transport and POS or GFP encapsulation for
> transport.

Yes, but my concern is that IP & MPLS may well be 'recognised' in the
network core and if something happened (e.g. Erroneous label pop) to
expose
them they could be forwarded natively in error.  Other traffic types are
unlikely to have this happen as the network core is unlikely to support
natively forwarding them.

Ben

_______________________________________________
Mpls-interop mailing list
Mpls-interop@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-interop