Skip to main content

IS-IS Path Control and Reservation
draft-ietf-isis-pcr-05

Yes

(Alia Atlas)

No Objection

(Alissa Cooper)
(Ben Campbell)
(Brian Haberman)
(Joel Jaeggli)
(Kathleen Moriarty)
(Martin Stiemerling)

Note: This ballot was opened for revision 04 and is now closed.

Alia Atlas Former IESG member
Yes
Yes (for -04) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2016-01-05 for -04) Unknown
This is a well written document.  I have a couple of major comments that should be addressed before publication (and some minor ones/nits below).

1. In Section 6.1. (Topology sub-TLV) I think there's a small RFC2119 conflict. "The variable length Topology sub-TLV MUST be used to describe an explicit tree.  The Topology sub-TLV MAY be also used for describing a…GADAG".  That text says that the sub-TLV has to always (MUST) be used to describe an ET, and that it can also describe a GADAG.  I think that clearly it is one or the other.  Suggestion:
     NEW>
     The variable length Topology sub-TLV is used to describe an
     explicit tree.  The Topology sub-TLV may be also used for 
     describing a Generalized Almost Directed Acyclic Graph (
     GADAG).

2. Section 7. (MRT-FRR Application) talks about the specific use of I-D.ietf-rtgwg-mrt-frr-algorithm.  However, the description doesn't match the Default MRT Profile as specified in draft-ietf-rtgwg-mrt-frr-architecture — please include in this document a description of the MRT Profile used.


Minor/Nits:

1. It is nice that you put references in Section 3. (Terminology and Definitions) for each entry.  However, the definitions are not exactly the same as the source — for example, the definitions in this document and in I-D.ietf-rtgwg-mrt-frr-architecture are similar, but not the same. I'm sure some of the differences are just word choices, but I find that it may be confusing.

2. In Section 2. (Conventions Used in This Document) I found the second paragraph ("The lowercase forms with an initial capital…") interesting, but then couldn't find any cases where the words were used.  Did I miss them?  If they're not used I would delete the paragraph to avoid confusion.

3. Section 4. (Explicit Trees)
* "An ET MUST NOT contain Cycles."  I'm guessing that "Cycles" refers to loops, right?  I just wanted to clarify because you used a capital C — nothing wrong with that, just that it might be a special term.  BTW, the fact that an ET is defined as loop-free should cover this anyway.
* s/Unidirectional Utilized Bandwidth/Unidirectional Bandwidth Utilization

4. Section 8. (Summary) is superfluous.
Barry Leiba Former IESG member
No Objection
No Objection (2016-01-06 for -04) Unknown
I was going to ask to discuss this:

   The lowercase forms with an initial capital "Must", "Must Not",
   "Shall", "Shall Not", "Should", "Should Not", "May", and "Optional"
   in this document are to be interpreted in the sense defined in
   [RFC2119], but are used where the normative behavior is defined in
   documents published by SDOs other than the IETF.

...because I think this is a too-subtle distinction that would be confusing to many readers.  But you don't appear to actually have any such terms in the document.  Please remove that paragraph.
Ben Campbell Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (2016-01-07 for -04) Unknown
As mentioned by the Linda Dunbar in her OPS-DIR review:
Minor issues:

Why the Bandwidth Constraint sub-TLV is not same as the Bandwidth Sub-TLV defined by 
https://tools.ietf.org/html/draft-ietf-isis-te-metric-extensions-07#page-10?

Need to make sure that the Bandwidth Sub-TLV (unidirectional available bandwidth, unidirectional utilized bandwidth sub-TLV, etc), of draft-ietf-isis-te-metric-extensions is consistent. 

Regards, Benoit
Brian Haberman Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2016-01-07 for -04) Unknown
This comment from Suresh Krishnan's Gen-ART review seems relevant:

There is no reference for the format of the Bandwidth fields in Sections 6.3 
and 6.4. I am assuming this refers to the Single Precision format (binary32) 
from IEEE 754. If so, please add an explicit reference to this.
Joel Jaeggli Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -04) Unknown