RE: Re: FW: [PWE3] Last Call: <draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt> (Using the Generic Associated Channel Label for Pseudowire in MPLS-TP) to Proposed Standard

[Yaakov Stein <yaakov_s@xxxxxxx>]

Stewart

 

I will answer your specific questions below.

 

I have no specific objection to the new text that you proposed on the PWE3 list :

   In MPLS-TP, the GAL MUST be used with packets on a G-ACh on

   LSPs, Concatenated Segments of LSPs, and with Sections, and

   MAY be used with PWs. The presence of a GAL indicates that

   an ACH immediately follows the MPLS label stack.  

as it has become so generic (does not explain where the GAL is placed) as to be noncontroversial.

However, please be aware that this simply postpones the true discussion.

 

I would still like the wording

   According to the MPLS-TP requirement document [RFC5654], it is

   necessary that MPLS-TP mechanisms and capabilities be able to

   interoperate with the existing IETF MPLS [RFC3031] and IETF PWE3

   [RFC3985] architectures appropriate.

to be removed, as I believe that it does not correctly describe the purpose of this draft.

It should be replaced with the text that appears further on

   The inconsistency between the usage of the GAL with MPLS PWs and

   MPLS-TP PWs may cause unnecessary implementation differences and is

   in disagreement with the MPLS-TP requirements.

 

Please see a few more remarks interleaved below.

 

Y(J)S

 

-------- Original Message --------

Subject:	Re: FW: [PWE3] Last Call: (Using the Generic Associated Channel Label for Pseudowire in MPLS-TP) to Proposed Standard
Date:	Thu, 01 Sep 2011 16:40:16 +0100
From:	Stewart Bryant <stbryant@xxxxxxxxx>
Reply-To:	stbryant@xxxxxxxxx
To:	Yaakov Stein <yaakov_s@xxxxxxx>
CC:	ietf@xxxxxxxx <ietf@xxxxxxxx>

…

However, you did not address my other final comment that a PW that starts in an MPLS-TP domain,

can easily leak into a non-TP domain.

What does one do then ?

That is a general issue rather than a TP issue.
When you get to the PW label and you would find that it was not BOS.
If you you are not running FAT that that is a detectable.
If you are running FAT the presence of the GAL (which is not an
allowed FAT label) is also a detectable.

[YJS] I believe the simultaneous use of FAT and GAL is ruled out by the TP framework document.

…

You say:

"Bottom of stack has been the label position of the PW label for many years,

and this position is mandated by multiple RFCs, e.g. 3985 and 4447

   Note that the PW label must always

   be at the bottom of the packet's label stack."

That is no longer true with the introduction of FAT.

[YJS] 

As you know I proposed an alternative mechanism,

however, in any case the FAT case is different from the GAL.

Each load balanced flow label is actually a "partial-PW' and thus the flow label is a type of PW label,

albeit a PW carrying only a subset of the user flows that exist in the original PW.

On the other hand the GAL is a modifier, meaning that the rest of the payload has a different format. 

Then you say:

"Present PW implementations receiving the PW label with stack bit cleared,

and a GAL at the bottom position will choke and, at best, discard the packet.

At worst, the GAL may coincide with a legitimate PW label, and the customer will be

flooded with garbage."

Your first case is sort of correct - the packet should be silently

discarded as it was clearly not intended for that PW - but it had 

better not choke as this would be an attack vector.

[YJS] By "choke" I meant either discard or flood the impersonated PW with what it believes to be VCCV packets. 

You second case cannot happen because a GAL is a reserved label and

a reserved label can never be a legitimate PW label.

[YJS]

My second case CAN happen (I expected this question).

Please remember that before MS-PWs were proposed, PW labels were never considered "real" MPLS labels,

and many implementations did not religiously apply the MPLS restrictions to them.

Stewart

[YJS]

I DO have a proposal that is completely consistent with the goals of this draft AND the PWE RFCs.

 

The GAL can be placed in one of 2 positions

1)      ABOVE the PW label (just as the router alert is placed above the PW label in VCCV Type 2)

2)      INSTEAD of the PW label (thus making a single "OAM PW", reducing the OAM load)

Note 1 – this is essentially the same as using the GAL for the MPLS tunnel into which the PWs are placed.

Note 2 – this is close to my original proposal for PW OAM, that was abandoned when VCCV "per-PW OAM" won out.

 

 

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf