Subject: [Pals] Mail regarding draft-ietf-pwe3-vccv-for-gal

From: Gregory Mirsky <[email-masked]>
Date: Fri, 24 Oct 2014 01:30:48 +0000

Dear Authors, Editors, et. al,
thank you for your work on this document that is very important to PW OAM. Please kindly consider my comments below:

*         Abstract

o   "This document describes a unified mode of operation for Virtual Circuit Connectivity Verification (VCCV) ..." IMHO, agreement of WG discussion in Paris was to limit document scope to introduction of Control Channel Type 4 for PW VCCV and address unified operation of CC VCCV in RFC 5085bis.

o   "It describes new rules requiring this mode to be used as the default/mandatory mode of operation for VCCV." I think this statement is over-reaching. Use of Control Channel Type 4 may be suggested as preferred in some scenarios, such as CW not being used, SS-PW or e2e MS-PW. I think that the strongest statement could be "New implementations of PW VCCV SHOULD support CC Type 4."

o   "The older types will remain optional." IMHO, the WG agreed to obsolete Type 2 CC PW VCCV.

*         Requirements Language and Terminology.
These acronyms are not used in the document: AVP, L2SS, LCCE, PW-ACH

*         Introduction

o   "... the ITU-T and IETF have set out to enhance MPLS to make it suitable as an optical transport protocol ..." Perhaps should be "packet transport".

o   "In order to support VCCV when an MPLS-TP PSN is in use, the GAL-ACH had to be created ..." G-ACh was created for MPLS-TP LSP, not PW. PW VCCV when PSN is MPLS-TP can use any of described in RFC 5085 control channel types. And RFC 5586 explicitly excluded GAL from being used on PWs in the first sentence of Section 4.2.

o   "This document defines two modes of operation of VCCV ..." Where the document leaves CC Type 3? Isn't it valid mode of PW VCCV operation that the PWE3 WG decided to keep? I believe that only Type 3 can be used in MS-PW to address S-PE whether CW  being used or not.

o   "In either case, it will be mandatory to implement and use that mode under that scenario." Again, this conclusion is not in sync with what was agreed at PWE3 WG meeting in Paris.

*         Section 2
"... Associated Channel Types of 21, 07, or 57 are allowed" Firstly, it should be "0x0021, 0x007, or 0x0057". Secondly, why 0x000A, 0x000B, 0x000C, 0x000D, 0x000E, 0x0022, 0x0023, 0x0024, 0x0025, 0x0026, 0x0027, and 0x0058 would not be listed as valid ACH types?

*         Section 3
"In the case of multi-segment pseudo-wires, the PW Label TTL MUST be set to the correct value to reach the intended destination PE as described in [RFC6073]" And that would be the case of VCCV CC Type 3 used in combination with CC Type 4. I think it must be so noted that VCCV CC Type 3 and CC Type 4 can be used in combination since Section 5.1.3 of RFC 5085 explicitly allows combination of PW VCCV Control Channels Type 1 and Type 3.

*         Section 4
"The first nibble of the next field is set to 0001b ..." Perhaps "the first nibble of the next octet ...". And does that imply that GAL MUST be BoS label and thus S=1? Should that be explicitly stated?

*         Section 5

o   "If the c-bit is set, indicating the use of the control word, type 1 MUST be advertised and type 4 MUST NOT be advertised." MUST in connection to Type 1 implicitly requires support of CC Type 1. I think that this is too strong statement and propose change it to "Type 1 MUST be advertised if supported" or just "Type 1 MAY be advertised".

o   "If the c-bit is not set, indicating that the control word is not in use, type 4 MUST be advertised, and type 1 MUST NOT be advertised." As in previous comment, MUST in connection to CC Type 4 is too strong and implies it being supported. Similar change suggested.

Regards,
                Greg

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 24 Oct 2014 05:34:16 +0000

​Greg,

Lots of thanks for a very careful review of the document.

All your comments look valid to me and, IMO, should be addressed in the next revision of the draft.

In addition, please see below a couple of comments of my own:

  1.  GAL vs. Flow Label:
     *   The draft refers to RFC 5586 for the definition of GAL, and this document states that GAL MUST be BoS.
     *   At the same time, RFC 6391 has defined the Flow Label for flow-aware (a.k.a. "fat") PWs, and specified that it MUST be BoS.
     *   It is not clear to me whether GAL and Flow Label can be combined, since they cannot both be BoS. I'd like to remind the authors that this issue has been raised at the very early stages of discussion of VCCV Type 4 (even before it has become a WG document), but it remains unresolved until now.
  2.  TTL in the PW LSE:
     *   The draft contains some Editor remarks regarding this issue, but eventually suggests setting TTL=1 in the PW LSE for SS-PWs
     *   To the best of my recollection original Martini drafts have set the PW LSE TTL to 2, and many implementations follow this, even if the PW RFCs have relaxed that to any suitable value
     *   In any case, setting TTL in the PW LSE to 1 would cause many implementations to trap all PW packets to the CP due to TTL expiration; so this looks an error to me,

Hopefully these comments will be useful.

Regards,

Sasha

________________________________
From: pwe3 <[email-masked]> on behalf of Gregory Mirsky <[email-masked]>
Sent: Friday, October 24, 2014 4:30 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [PWE3] Mail regarding draft-ietf-pwe3-vccv-for-gal

•         Abstract

o   “It describes new rules requiring this mode to be used as the default/mandatory mode of operation for VCCV.” I think this statement is over-reaching. Use of Control Channel Type 4 may be suggested as preferred in some scenarios, such as CW not being used, SS-PW or e2e MS-PW. I think that the strongest statement could be “New implementations of PW VCCV SHOULD support CC Type 4.”

•         Requirements Language and Terminology.
These acronyms are not used in the document: AVP, L2SS, LCCE, PW-ACH

•         Introduction

•         Section 2

•         Section 3

•         Section 4
"The first nibble of the next field is set to 0001b ..." Perhaps “the first nibble of the next octet …”. And does that imply that GAL MUST be BoS label and thus S=1? Should that be explicitly stated?

•         Section 5

o   “If the c-bit is set, indicating the use of the control word, type 1 MUST be advertised and type 4 MUST NOT be advertised.” MUST in connection to Type 1 implicitly requires support of CC Type 1. I think that this is too strong statement and propose change it to “Type 1 MUST be advertised if supported” or just “Type 1 MAY be advertised”.

Regards,
                Greg

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 24 Oct 2014 23:44:27 +0100

Greg

Thanks for the comments. It is a bit close to the deadline to be certain 
to get a new version out by the cutoff on Monday.

What I propose is that we work through the comments on here and 
depending where I get to either request a late submission or place the a 
draft in some public place.

Either way I have proposed to the existing PWE3 chairs that I take a 
slot to get feedback on the proposed resolution and if there is some 
uncertainly on how to go forward use some WG time to work through the 
issues.

Please see inline.

On 24/10/2014 02:30, Gregory Mirsky wrote:
> thank you for your work on this document that is very important to PW 
> OAM. Please kindly consider my comments below:
>
> ·Abstract
>
> o"This document describes a unified mode of operation for Virtual 
> Circuit Connectivity Verification (VCCV) ..." IMHO, agreement of WG 
> discussion in Paris was to limit document scope to introduction of 
> Control Channel Type 4 for PW VCCV and address unified operation of CC 
> VCCV in RFC 5085bis.
>
> o"It describes new rules requiring this mode to be used as the 
> default/mandatory mode of operation for VCCV." I think this statement 
> is over-reaching. Use of Control Channel Type 4 may be suggested as 
> preferred in some scenarios, such as CW not being used, SS-PW or e2e 
> MS-PW. I think that the strongest statement could be "New 
> implementations of PW VCCV SHOULD support CC Type 4."
>
> o"The older types will remain optional." IMHO, the WG agreed to 
> obsolete Type 2 CC PW VCCV.
>
I will tone that down some.

I think that it might be better to split this problem into two. Firstly 
get this draft out with the changes needed to support the GAL, and write 
a separate draft deprecating  Type 2 and doing any clean up on VCCV. Or 
maybe doing this in three stages (GAL then Dep Type 2 then cleanup). 
That way each text is focused.

> ·Requirements Language and Terminology.
>
Will look at that
>
> ·Introduction
>
> o"... the ITU-T and IETF have set out to enhance MPLS to make it 
> suitable as an optical transport protocol ..." Perhaps should be 
> "packet transport".
>
Yes
>
> o"In order to support VCCV when an MPLS-TP PSN is in use, the GAL-ACH 
> had to be created ..." G-ACh was created for MPLS-TP LSP, not PW. PW 
> VCCV when PSN is MPLS-TP can use any of described in RFC 5085 control 
> channel types. And RFC 5586 explicitly excluded GAL from being used on 
> PWs in the first sentence of Section 4.2.
>
Yes
>
> o"This document defines two modes of operation of VCCV ..." Where the 
> document leaves CC Type 3? Isn't it valid mode of PW VCCV operation 
> that the PWE3 WG decided to keep? I believe that only Type 3 can be 
> used in MS-PW to address S-PE whether CW  being used or not.
>
> o"In either case, it will be mandatory to implement and use that mode 
> under that scenario." Again, this conclusion is not in sync with what 
> was agreed at PWE3 WG meeting in Paris.
>
> ·Section 2
>
> "... Associated Channel Types of 21, 07, or 57 are allowed" Firstly, 
> it should be "0x0021, 0x007, or 0x0057". Secondly, why 0x000A, 0x000B, 
> 0x000C, 0x000D, 0x000E, 0x0022, 0x0023, 0x0024, 0x0025, 0x0026, 
> 0x0027, and 0x0058 would not be listed as valid ACH types?
>
I will look at that text - this draft should not repeat the registry!
>
> ·Section 3
>
> "In the case of multi-segment pseudo-wires, the PW Label TTL MUST be 
> set to the correct value to reach the intended destination PE as 
> described in [RFC6073]" And that would be the case of VCCV CC Type 3 
> used in combination with CC Type 4. I think it must be so noted that 
> VCCV CC Type 3 and CC Type 4 can be used in combination since Section 
> 5.1.3 of RFC 5085 explicitly allows combination of PW VCCV Control 
> Channels Type 1 and Type 3.
>
Let's see if that makes sense when I get there
>
> ·Section 4
>
> "The first nibble of the next field is set to 0001b ..." Perhaps "the 
> first nibble of the next octet ...". And does that imply that GAL MUST 
> be BoS label and thus S=1? Should that be explicitly stated?
>
Will think about this some more when I look at Sasha's comments
>
> ·Section 5
>
> o"If the c-bit is set, indicating the use of the control word, type 1 
> MUST be advertised and type 4 MUST NOT be advertised." MUST in 
> connection to Type 1 implicitly requires support of CC Type 1. I think 
> that this is too strong statement and propose change it to "Type 1 
> MUST be advertised if supported" or just "Type 1 MAY be advertised".
>
> o"If the c-bit is not set, indicating that the control word is not in 
> use, type 4 MUST be advertised, and type 1 MUST NOT be advertised." As 
> in previous comment, MUST in connection to CC Type 4 is too strong and 
> implies it being supported. Similar change suggested.
>
Again will look at that.

Expect a follow up response with the text actions

Stewart
>
> Regards,
>
> Greg
>
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

-- 
For corporate legal information go to:

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

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 25 Oct 2014 00:33:04 +0100

On 24/10/2014 06:34, Alexander Vainshtein wrote:
> Greg,

>  1. *GAL vs. Flow Label*:
>       * The draft refers to RFC 5586 for the definition of GAL, and
>         this document states that GAL MUST be BoS.
>       * At the same time, RFC 6391 has defined the Flow Label for
>         flow-aware (a.k.a. "fat") PWs, and specified that it MUST be BoS.
>       * It is not clear to me whether GAL and Flow Label can be
>         combined, since they cannot both be BoS. I'd like to remind
>         the authors that this issue has been raised at the very early
>         stages of discussion of VCCV Type 4 (even before it has become
>         a WG document), but it remains unresolved until now.
>
Thanks for pointing out the conflict.

In the original PW design the PW label was always the bottom label.
The FAT label was after the PW label for two reasons firstly because you 
needed the context of the PW label to know to pop it and secondly it had 
more entropy and so putting it at the bottom seemed like the best place 
because you expect entropy to increase as you get closer to the bottom 
of the stack.

Now as I recall the GAL says that the ACH is after the bottom of stack, 
which means it could actually be anywhere although it was convenient to 
put it at BOS.

Probably the right things - with suitable update notes is 
PW/FAT/GAL/ACH. The PW handler then know to discard the FAT and the GAL 
says look for the ACH.

We have no choice but to include the FAT since it is a property of the 
PW and the handler always expects it. We could remove it when the GAL is 
present but is a lot more complex.

What is annoying and hopefully people realize this is that when the GAL 
is that the ECMP path is likely to change - something we carefully 
avoided with the CW design (which is why we did it like that in the 
first place.

This then takes me to wonder if we should restrict the GAL solely to the 
case of a point to point LSP such as we get with RSVP-TE and MPLS-TP, in 
which case FAT would never be present.

I need some WG input on this.

> 1.
>
>
>  2. *TTL in the PW LSE*:
>       * The draft contains some Editor remarks regarding this issue,
>         but eventually suggests setting TTL=1 in the PW LSE for SS-PWs
>       * To the best of my recollection original Martini drafts have
>         set the PW LSE TTL to 2, and many implementations follow this,
>         even if the PW RFCs have relaxed that to any suitable value
>       * In any case, setting TTL in the PW LSE to 1 would cause many
>         implementations to trap all PW packets to the CP due to TTL
>         expiration; so this looks an error to me,
>
Yes I remember that. It's an implementation issue in some older h/w that 
is unlikely to do this. However it's probably OK to maintain the old 
value as the packet is not going to go very far.

Let me go back and look at the framework RFCs and see if there is 
anything I am missing.

We should discuss this at the next WG meeting to make sure we are all on 
the same page.

- Stewart
> 1.
> ------------------------------------------------------------------------
> *From:* pwe3 <[email-masked]> on behalf of Gregory Mirsky 
> <[email-masked]>
> *Sent:* Friday, October 24, 2014 4:30 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* [PWE3] Mail regarding draft-ietf-pwe3-vccv-for-gal
>

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 24 Oct 2014 23:48:13 +0000

Hi Stewart,
you’ve said “…when the GAL is that the ECMP path is likely to change …”.
I think that is the case for legacy nodes that do not support Entropy Label and RFC 6790 as it states that reserved, a.k.a. special purpose and extended special purpose, labels MUST NOT be used as keys for load-balancing by transit LSRs.

                Regards,
                                Greg

From: Stewart Bryant [mailto:[email-masked]]
Sent: Friday, October 24, 2014 4:33 PM
To: Alexander Vainshtein; Gregory Mirsky; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] Mail regarding draft-ietf-pwe3-vccv-for-gal

​Greg,

  1.  GAL vs. Flow Label:

In the original PW design the PW label was always the bottom label.
The FAT label was after the PW label for two reasons firstly because you needed the context of the PW label to know to pop it and secondly it had more entropy and so putting it at the bottom seemed like the best place because you expect entropy to increase as you get closer to the bottom of the stack.

Now as I recall the GAL says that the ACH is after the bottom of stack, which means it could actually be anywhere although it was convenient to put it at BOS.

Probably the right things - with suitable update notes is PW/FAT/GAL/ACH. The PW handler then know to discard the FAT and the GAL says look for the ACH.

We have no choice but to include the FAT since it is a property of the PW and the handler always expects it. We could remove it when the GAL is present but is a lot more complex.

What is annoying and hopefully people realize this is that when the GAL is that the ECMP path is likely to change - something we carefully avoided with the CW design (which is why we did it like that in the first place.

This then takes me to wonder if we should restrict the GAL solely to the case of a point to point LSP such as we get with RSVP-TE and MPLS-TP, in which case FAT would never be present.

  1.
  2.  TTL in the PW LSE:
     *   The draft contains some Editor remarks regarding this issue, but eventually suggests setting TTL=1 in the PW LSE for SS-PWs
     *   To the best of my recollection original Martini drafts have set the PW LSE TTL to 2, and many implementations follow this, even if the PW RFCs have relaxed that to any suitable value
     *   In any case, setting TTL in the PW LSE to 1 would cause many implementations to trap all PW packets to the CP due to TTL expiration; so this looks an error to me,
Yes I remember that. It's an implementation issue in some older h/w that is unlikely to do this. However it's probably OK to maintain the old value as the packet is not going to go very far.

Let me go back and look at the framework RFCs and see if there is anything I am missing.

We should discuss this at the next WG meeting to make sure we are all on the same page.

- Stewart

  1.

Regards,

Sasha

________________________________
From: pwe3 <[email-masked]><mailto:[email-masked]> on behalf of Gregory Mirsky <[email-masked]><mailto:[email-masked]>
Sent: Friday, October 24, 2014 4:30 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [PWE3] Mail regarding draft-ietf-pwe3-vccv-for-gal

•         Abstract

•         Introduction

•         Section 2

•         Section 3

•         Section 4

•         Section 5

Regards,
                Greg

pwe3 mailing list

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

--

---

From: Shahram Davari <[email-masked]>
Date: Sat, 25 Oct 2014 00:02:38 +0000

Hi Greg,

Good point. We have always assumed the order is PW Label, FAT Label, GAL (BoS). This seems to be the more logical way of doing it.

Thx
Shahram

From: pwe3 [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Friday, October 24, 2014 4:48 PM
To: [email-masked]; Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] Mail regarding draft-ietf-pwe3-vccv-for-gal

Hi Stewart,

                Regards,
                                Greg

To: Alexander Vainshtein; Gregory Mirsky; [email-masked]<mailto:[email-masked]>

​Greg,

  1.  GAL vs. Flow Label:

  1.
  2.  TTL in the PW LSE:

- Stewart

  1.

Regards,

Sasha

•         Abstract

•         Introduction

•         Section 2

•         Section 3

•         Section 4

•         Section 5

Regards,
                Greg

pwe3 mailing list

--

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 25 Oct 2014 13:59:28 +0100

Greg

You can mandate new behaviour in the PEs, but not the P routers.

If a packet goes through an older P router that does not know about the 
EL, who knows what it will make of the GAL.

Stewart

On 25/10/2014 00:48, Gregory Mirsky wrote:
> I think that is the case for legacy nodes that do not support Entropy 
> Label and RFC 6790 as it states that reserved, a.k.a. special purpose 
> and extended special purpose, labels MUST NOT be used as keys for 
> load-balancing by transit LSRs.
>
> Regards,
>
> Greg
>
> *From:*Stewart Bryant [mailto:[email-masked]]
> *Sent:* Friday, October 24, 2014 4:33 PM
> *To:* Alexander Vainshtein; Gregory Mirsky; 
> [email-masked]
> *Subject:* Re: [PWE3] Mail regarding draft-ietf-pwe3-vccv-for-gal
>
> The FAT label was after the PW label for two reasons firstly because 
> you needed the context of the PW label to know to pop it and secondly 
> it had more entropy and so putting it at the bottom seemed like the 
> best place because you expect entropy to increase as you get closer to 
> the bottom of the stack.
>
> Now as I recall the GAL says that the ACH is after the bottom of 
> stack, which means it could actually be anywhere although it was 
> convenient to put it at BOS.
>
> PW/FAT/GAL/ACH. The PW handler then know to discard the FAT and the 
> GAL says look for the ACH.
>
> PW and the handler always expects it. We could remove it when the GAL 
> is present but is a lot more complex.
>
> What is annoying and hopefully people realize this is that when the 
> GAL is that the ECMP path is likely to change - something we carefully 
> This then takes me to wonder if we should restrict the GAL solely to 
> the case of a point to point LSP such as we get with RSVP-TE and 
> MPLS-TP, in which case FAT would never be present.
>
> Yes I remember that. It's an implementation issue in some older h/w 
> that is unlikely to do this. However it's probably OK to maintain the 
> old value as the packet is not going to go very far.
>
> *From:* pwe3 <[email-masked]> <mailto:[email-masked]> on 
> behalf of Gregory Mirsky <[email-masked]> 
> <mailto:[email-masked]>
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> o“It describes new rules requiring this mode to be used as the 
> default/mandatory mode of operation for VCCV.” I think this statement 
> MS-PW. I think that the strongest statement could be “New 
> implementations of PW VCCV SHOULD support CC Type 4.”
>
> "The first nibble of the next field is set to 0001b ..." Perhaps “the 
> first nibble of the next octet …”. And does that imply that GAL MUST 
> o“If the c-bit is set, indicating the use of the control word, type 1 
> MUST be advertised and type 4 MUST NOT be advertised.” MUST in 
> that this is too strong statement and propose change it to “Type 1 
> MUST be advertised if supported” or just “Type 1 MAY be advertised”.
>
> [email-masked]  <mailto:[email-masked]>

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 25 Oct 2014 14:03:26 +0100

On 25/10/2014 01:02, Shahram Davari wrote:
>
> Hi Greg,
>
> Good point. We have always assumed the order is PW Label, FAT Label, 
> GAL (BoS). This seems to be the more logical way of doing it.
>
Shahram

Isn't that what I proposed?

However I still don't see how GAL is ECMP safe given that we have no 
knowledge of the age/type of P router on the path.

Stewart
>
> Thx
> Shahram
>
> *From:*pwe3 [mailto:[email-masked]] *On Behalf Of *Gregory Mirsky
> *Sent:* Friday, October 24, 2014 4:48 PM
> *To:* [email-masked]; Alexander Vainshtein;

---

From: Shahram Davari <[email-masked]>
Date: Sat, 25 Oct 2014 14:53:59 +0000

Hi

In case of older routers one should probably use vccv1.

Regards,
Shahram

On Oct 25, 2014, at 6:04 AM, "Stewart Bryant" <[email-masked]<mailto:[email-masked]>> wrote:

However I still don't see how GAL is ECMP safe given that we have no knowledge of the age/type of P router on the path.

Stewart

Thx
Shahram

To: [email-masked]<mailto:[email-masked]>; Alexander Vainshtein; [email-masked]<mailto:[email-masked]>

Hi Stewart,

                Regards,
                                Greg

​Greg,

  1.  GAL vs. Flow Label:

  1.
  2.  TTL in the PW LSE:

- Stewart

  1.

Regards,

Sasha

•         Abstract

•         Introduction

•         Section 2

•         Section 3

•         Section 4

•         Section 5

Regards,
                Greg

pwe3 mailing list

--

_______________________________________________
Pals mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pals

---

From: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Sat, 25 Oct 2014 23:39:03 +0000

Sharanm

How do you know whether or not there are older P routers in the new?

Unless you know otherwise you have to assume that there are.

Stewart

Sent from my iPad

On 25 Oct 2014, at 07:54, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:

Hi

Regards,
Shahram

Stewart

Thx
Shahram

Hi Stewart,

                Regards,
                                Greg

​Greg,

  1.  GAL vs. Flow Label:

  1.
  2.  TTL in the PW LSE:

- Stewart

  1.

Regards,

Sasha

•         Abstract

•         Introduction

•         Section 2

•         Section 3

•         Section 4

•         Section 5

Regards,
                Greg

pwe3 mailing list

--