Subject: [RTG-DIR] RtgDir: Early Review of draft-ietf-pce-pcep-flowspec-05.txt - "PCEP Extension for Flow Specification"

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 22 Oct 2019 17:27:59 +0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see ​

  http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Early Review/Last Call  comments that you receive, and strive to
resolve them through discussion or by updating the draft.

Document: draft-ietf-pce-pcep-flowspec-05.txt
Reviewer: Acee Lindem
Review Date: 10/22/2019
IETF LC End Date: N/A
Intended Status: Standards Track

Summary:
This document is basically ready for further discussion and WG Last Call,
but has nits that should be considered prior to publication.

Comments:

 The draft is extremely easy to read and understand. This is an early
 review yet the document is in better shape than most documents I review
 during Working Group Last Call. I don't even follow the PCE Working
 Group but believe I could consume the entire draft with only a
 rudimentary understanding of the PCE protocol and having read and
 followed RFC 5575.

Major Issues: None

Minor Issues: None

Nits:

  I have a question and a few suggestions:

    1. For the multicast flow filter TLVs, is there some reason why
       the S-bit and G-bit respectively indicate that the fields are
       NOT used? In most protocol encodings, a Set bit indicates that
       a field is used and a Clear bit indicates that it is not used.
       Also, all zeros has also been used a wildcard specification
       but I guess you preferred something explicit.

    2. For IGPs, we always hyphenate Bit definitions. However, in this
       specification, the Bit definitions are not hyphenated other
       than in the IANA section. Being the LSR chair, I'd prefer
       consistency with the IGP specifications.

    3. In most IETF specifications, "headend" is a single compound
       word.

    4. In section 9, could you indicate that the only change is adding
       the <flowspec-list>? This seems to be the case but it would be
       good to state it explicitly.

    5. I have attached an RFCDIFF of suggested editorial changes.

Thanks,
Acee

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 22 Oct 2019 19:05:54 +0100

Hi Acee,

Thanks for the review and the kind words.
I believe this document is in WG last call at the moment, so this is not quite so early as an “Early Review” might normally be.

>       but I guess you preferred something explicit.

No particular reason for the bit settings that I can remember. It makes the bits fit nicely with the "Reserved" field, but that is not a very telling point. We could change this if there is a good reason to do so.

IIRC the setting of all zeros has a specific meaning in this case and so a different wildcard value was needed.

>       consistency with the IGP specifications.

I just checked back with RFC 5440 (the PCEP base specification) and there hyphenation is not used.

I have no strong opinion and will let the PCE chairs tell me what to do.

>    3. In most IETF specifications, "headend" is a single compound

Oooh, I hate that 😊
Can we leave it to the RPC to fix as a matter of house style?

>       good to state it explicitly.

In my working copy.

>   5. I have attached an RFCDIFF of suggested editorial changes.

That was unusually thorough of you. Thanks! All of those nits were spot on and are in my working copy (modulo one s/am/an/).

Best,
Adrian

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 22 Oct 2019 18:24:48 +0000

Hi Adrian,

On 10/22/19, 2:06 PM, "Adrian Farrel" <[email-masked]> wrote:

    Hi Acee,

    

I'm fine with it - especially if the document is already in Working Group Last Call (WGLC) and the WG is used to this encoding. I wouldn't have put it in the Nits if I really thought it were important. 

    

It is probably more important to be aligned with the base specification. There was one instance of R-bit in the IANA specifications that could be changed to be consistent. 

    Oooh, I hate that 😊

I don't have that strong an opinion. At least "head end" is used consistently. 

    In my working copy.

Thanks - this was an unusually easy Routing Directorate review!
Acee
    
    Best,
    Adrian