Re: [PWE3] Mail regarding draft-ietf-pwe3-vccv-for-gal

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:
>
> 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.
>
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.
>
> These acronyms are not used in the document: AVP, L2SS, LCCE, PW-ACH
>
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
> pwe3@ietf.org
> 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