Re: [Pals] [Gen-art] Gen-ART review of draft-ietf-pals-vccv-for-gal-05

On 17/09/2015 14:25, Jari Arkko wrote:
> Thanks for your excellent review, Dan. Andrew, will you be issuing a new version based on the comments?

Yes, there will be a -06 when the resolution of all comments are agreed.

>
> Jari
>
> On 04 Sep 2015, at 08:00, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:
>
>> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
>>
>> Document: draft-ietf-pals-vccv-for-gal-05
>> Reviewer: Dan Romascanu
>> Review Date: 9/4/15
>> IETF LC End Date:
>> IESG Telechat date:
>>
>> Summary: this document is ready with minor issues
>>
>> Major issues:
>>
>> None
>>
>> Minor issues:
>>
>> 1.       Section 3 includes the following text:
>>
>>     When the PW CW is not used, the Type 4 MPLS VCCV Control Channel (CC)
>>     type defined in this section MAY be used.  This is referred to as
>>     VCCV CC Type4 throughout the rest of this of this document.  VCCV
>>     Type 4 uses the encapsulation shown in Figure 1 in which the presence
>>     of a GAL at the end of the MPLS label stack indicates that the packet
>>     carries a VCCV message.
>>
>> Two issues here:
>> -          Line 3 includes a disturbing typo as the type is referred to in the rest of the document as ‘VCCV CC Type 4’ (with a space)
Term corrected.
>> -          I understand the MAY in the second line to be directed to the implementers and this is fine. However, what about the operators who own network devices that have implemented this option? From reading the first section I indirectly get that the operators SHOULD activate this option. Maybe a separate paragraph can include this recommendation.
The WG never went as far as to say that an operator SHOULD use this. As 
stated it recognized the advantages of the new approach, but noted that 
it was impossible to mandate the approach given the deployed equipment.

I am copying this to the WG, in case there are strong opinions either way.

>>
>> 2.       Manageability Considerations – is there a requirement for all devices in a given network to activate the new type support, or a mix of routers supporting and not-supporting this option does not cause a problem?
Only the peering PEs need to support this mode and then only for the 
particular PW. It is completely mix and match. This allows us to 
introduce this to the network without for example re-writing the whole 
of the config for existing PEs. It is not a requirement to update any 
other nodes in the network (modulo the issue of S-PEs carrying the PW 
needing to support this as well as the T-PEs.) and this position is 
mandated by the concerns stated in the introduction about currently 
deployed PEs.
>> 3.       Section 9.1 – I assume that at publication Bit X (0x0Y) is supposed to be changed to Bit 3 (0x08)
Yes.

- Stewart
>>
>> Regards,
>>
>> Dan
>>
>> _______________________________________________
>> Gen-art mailing list
>> Gen-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art

-- 
For corporate legal information go to:

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