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

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

...and hence the second point applies.

There is only limited to none things that you can do
in MPLS if an LSR misbehaves. PW gives you limited protection,
MPLSoMPLS-TP provides none protection. Ample room to break things
based on how bad the behavior is

/himanshu



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

Himanshu,

If things are misconfigured that badly, why couldn't the PW control word
be misinterpreted as a label if too many labels were popped at the
MPLS-TP layer?

Cheers,
Andy

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

Control word after the PW label prevents identifying the packet as IP
packet at an LSR.
As I said earlier, misdirection due to erroneous label operation yields
unpredictable results. There are a limited things one can do (some of
which was mentioned in my previous email (like label range separation,
control word insertion, etc etc))

/himanshu 



-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Malis, Andrew G.
(Andy)
Sent: Thursday, December 11, 2008 3:11 PM
To: Ben Niven-Jenkins; Adrian Farrel; Drake, John E;
[e-mail]
Subject: 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:[e-mail]]
Sent: Thursday, December 11, 2008 3:03 PM
To: Malis, Andrew G. (Andy); Adrian Farrel; Drake, John E;
[e-mail]
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Andy,


On 11/12/2008 15:31, "Malis, Andrew G. (Andy)"
<[e-mail]>
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
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-interop


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