Subject: 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

From: Stewart Bryant <[email-masked]>
Date: Thu, 01 Sep 2011 16:40:16 +0100

On 01/09/2011 15:37, Yaakov Stein wrote:
>
> Stewart
>
> Was this email meant to address my email to the IETF discussion list 
> (from Tues 16 Aug)
>
> or just the discussion on MPLS and PWE lists ?
>
> It does to SOME extent, as it leaves open the possibility of the GAL 
> not being at BoS;
>
> but it does not rule out that possibility either.
>
Indeed, but a draft would need to make the case for it to be anywhere
other than BOS. The only case that I can think of at the moment is
where a FAT label is being used, but that is out of scope in this draft and
would need to be resolved in the draft describing the co-existance
of the two labels.
>
> 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.

> (My email also identified a wording issue and what I consider to be a 
> completely inaccurate
>
> explanation of what the draft is trying to accomplish.)
>

"architectures appropriate"

Seems to have the word "as" missing. I will add an editors note.

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.

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.

You second case cannot happen because a GAL is a reserved label and
a reserved label can never be a legitimate PW label.

Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 5 Sep 2011 11:47:31 +0000

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 <[email-masked]><mailto:[email-masked]>

Reply-To:

[email-masked]<mailto:[email-masked]>

To:

Yaakov Stein <[email-masked]><mailto:[email-masked]>

CC:

[email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

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

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

You say:

[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:

flooded with garbage."

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

[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.

---

From: Luca Martini <[email-masked]>
Date: Tue, 13 Sep 2011 09:04:21 -0600

> However, please be aware that this simply postpones the true discussion.
This is correct. This document was not meant to have a discussion about OAM.
Thanks Yaakov.

Luca

> *Subject: *
> Re: FW: [PWE3] Last Call: (Using the Generic Associated Channel Label
> for Pseudowire in MPLS-TP) to Proposed Standard
>
> *Date: *
>
> 	
>
> *From: *
> Stewart Bryant <[email-masked]> <mailto:[email-masked]>
>
> *Reply-To: *
>
> 	
>
> [email-masked] <mailto:[email-masked]>
>
> *To: *
>
> 	
>
> Yaakov Stein <[email-masked]> <mailto:[email-masked]>
>
> *CC: *
>
> 	
>
> [email-masked] <mailto:[email-masked]> <[email-masked]>
> <mailto:[email-masked]>
>
> …
>
> …
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf