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

Andy,

We are shifting gears. We were talking about protection against
misbehaving
LSR. Now we are discussing end to end protection/fault detection/fault
propagation, etc.

Also, I believe, we were discussing what suits best over MPLS-TP;
MPLS-PWoMPLS-TP or MPLSoMPLS-TP.

Without doubt, MPLS-TP based e-e OAM is available for both models.
In addition, for PWoMPLS-TP, you have PW based OAM.
For MPLSoMPLS-TP, PE is actually an LSR in hierarchical tunnel.

/himanshu

-----Original Message-----
From: Malis, Andrew G. (Andy) [mailto:andrew.g.malis@verizon.com] 
Sent: Thursday, December 11, 2008 3:53 PM
To: Shah, Himanshu; Ben Niven-Jenkins; Adrian Farrel; Drake, John E;
mpls-interop@ietf.org
Subject: RE: [Mpls-interop] MPLS over MPLS-TP

Himanshu,

I still don't get what protection the PW gives you over not having the
PW.

To me, the major difference between whether you have a PW or not is what
OAM is used end-to-end at the top of the transport layer (think of ATM
F5 OAM). This will either be MPLS-TP OAM or pseudowire OAM. As an
operator, I would want the former, not the latter.

Cheers,
Andy

-----Original Message-----
From: Shah, Himanshu [mailto:hshah@ciena.com]
Sent: Thursday, December 11, 2008 3:44 PM
To: Malis, Andrew G. (Andy); Ben Niven-Jenkins; Adrian Farrel; Drake,
John E; mpls-interop@ietf.org
Subject: RE: [Mpls-interop] MPLS over MPLS-TP

...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:andrew.g.malis@verizon.com]
Sent: Thursday, December 11, 2008 3:39 PM
To: Shah, Himanshu; Ben Niven-Jenkins; Adrian Farrel; Drake, John E;
mpls-interop@ietf.org
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:hshah@ciena.com]
Sent: Thursday, December 11, 2008 3:34 PM
To: Malis, Andrew G. (Andy); Ben Niven-Jenkins; Adrian Farrel; Drake,
John E; mpls-interop@ietf.org
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: mpls-interop-bounces@ietf.org
[mailto:mpls-interop-bounces@ietf.org] On Behalf Of Malis, Andrew G.
(Andy)
Sent: Thursday, December 11, 2008 3:11 PM
To: Ben Niven-Jenkins; Adrian Farrel; Drake, John E;
mpls-interop@ietf.org
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: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

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