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

"Malis, Andrew G. (Andy)" <andrew.g.malis@verizon.com> Thu, 11 December 2008 20:56 UTC

Return-Path: <mpls-interop-bounces@ietf.org>
X-Original-To: mpls-interop-archive@ietf.org
Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B183A67D6; Thu, 11 Dec 2008 12:56:17 -0800 (PST)
X-Original-To: mpls-interop@core3.amsl.com
Delivered-To: mpls-interop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981FB3A67D6 for <mpls-interop@core3.amsl.com>; Thu, 11 Dec 2008 12:56:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.444
X-Spam-Level:
X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UITBLAx3tkRS for <mpls-interop@core3.amsl.com>; Thu, 11 Dec 2008 12:56:12 -0800 (PST)
Received: from tpamail2.verizon.com (tpamail2.verizon.com [192.76.82.136]) by core3.amsl.com (Postfix) with ESMTP id 1A0B53A67BD for <mpls-interop@ietf.org>; Thu, 11 Dec 2008 12:56:12 -0800 (PST)
Received: from smtpftw3.verizon.com (smtpftw3.verizon.com [138.83.140.92]) by tpamail2.verizon.com (8.13.3/8.13.3) with ESMTP id mBBKr28h002219; Thu, 11 Dec 2008 15:53:02 -0500 (EST)
Received: from ftwccout01.verizon.com (ftwccout01.verizon.com [138.83.131.134]) by smtpftw3.verizon.com (8.13.3/8.13.3) with ESMTP id mBBKr23H024986; Thu, 11 Dec 2008 15:53:02 -0500 (EST)
Received: from ftwccout01.verizon.com (unknown [127.0.0.1]) by ftwccout01.verizon.com (Symantec Mail Security) with ESMTP id DE0A352800A; Thu, 11 Dec 2008 15:52:57 -0500 (EST)
X-AuditID: 8a538386-ac500bb0000063b1-69-49417da96316
Received: from smtpftw3.verizon.com (unknown [138.83.140.92]) by ftwccout01.verizon.com (EMF) with ESMTP id A65D14E4004; Thu, 11 Dec 2008 15:52:57 -0500 (EST)
Received: from FHDP1CCMXCG01.us.one.verizon.com ([166.68.240.33]) by smtpftw3.verizon.com (8.13.3/8.13.3) with ESMTP id mBBKqqOM024615; Thu, 11 Dec 2008 15:52:56 -0500 (EST)
Received: from FHDP1LUMXCV24.us.one.verizon.com ([166.68.125.53]) by FHDP1CCMXCG01.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 15:52:54 -0500
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 11 Dec 2008 15:52:50 -0500
Message-ID: <01F652C8CDBE7D4EB7ED860698C6D97332DB3A@FHDP1LUMXCV24.us.one.verizon.com>
In-reply-to: <6535C9CED6F87446B41D20EF170F23621BDC45@mamxm01.ciena.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-topic: [Mpls-interop] MPLS over MPLS-TP
Thread-index: AclbfJC1yxFkbGGYTbuRnPmiqs13rQAFWwLwAARXiwcAADH0oAAJ1yjTAAASToAAAOIaEAAAPgpAAAAeHAAAAFAxcA==
References: <01F652C8CDBE7D4EB7ED860698C6D97332DA7F@FHDP1LUMXCV24.us.one.verizon.com><C5672281.F3E7%benjamin.niven-jenkins@bt.com> <01F652C8CDBE7D4EB7ED860698C6D97332DB1A@FHDP1LUMXCV24.us.one.verizon.com> <6535C9CED6F87446B41D20EF170F23621BDC42@mamxm01.ciena.com> <01F652C8CDBE7D4EB7ED860698C6D97332DB2D@FHDP1LUMXCV24.us.one.verizon.com> <6535C9CED6F87446B41D20EF170F23621BDC45@mamxm01.ciena.com>
From: "Malis, Andrew G. (Andy)" <andrew.g.malis@verizon.com>
To: "Shah, Himanshu" <hshah@ciena.com>, "Ben Niven-Jenkins" <benjamin.niven-jenkins@bt.com>, "Adrian Farrel" <adrian@olddog.co.uk>, "Drake, John E" <John.E.Drake2@boeing.com>, <mpls-interop@ietf.org>
X-OriginalArrivalTime: 11 Dec 2008 20:52:54.0065 (UTC) FILETIME=[70368210:01C95BD2]
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [Mpls-interop] MPLS over MPLS-TP
X-BeenThere: mpls-interop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF MPLS Interoperability Design Team <mpls-interop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-interop>, <mailto:mpls-interop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mpls-interop>
List-Post: <mailto:mpls-interop@ietf.org>
List-Help: <mailto:mpls-interop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-interop>, <mailto:mpls-interop-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mpls-interop-bounces@ietf.org
Errors-To: mpls-interop-bounces@ietf.org

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