OSPF Graceful Link Shutdown
draft-ietf-ospf-link-overload-16

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

(Alia Atlas) Yes

Deborah Brungard (was Discuss, No Objection) No Objection

Comment (2018-02-05)
No email
send info
Thanks for addressing my Discuss and comment.

(Ben Campbell) No Objection

Comment (2018-01-23 for -13)
No email
send info
-8: It would be helpful to see a few sentences about how the security considerations in 2328 and 5340 apply to the mechanisms in this draft, rather than just a "no new considerations" assertion.

(Benoît Claise) No Objection

Comment (2018-01-25 for -14)
No email
send info
As mentioned by Tim, part of the OPS DIR review. It's the authors and responsible AD to decide whether to act on those comments.

I believe the document is Ready for publication.  I have only three minor
comments below, which the authors may choose to act on.

Overall the document reads reasonably well. Not being overly familiar with the
material, I needed to read it through end-to-end more than once to better
understand its scope and intent. My first comment would be that perhaps the
introduction section could be better written; the abstract seemed clear on the
purpose of the draft, while the introduction felt a little muddled.  Sections
2, 3 and 4, which detail the motivations and extensions, were much clearer.

Secondly, there are some minor typographic errors throughout the document,
generally missing (in)definite articles.  While the RFC Editor would pick these
up, it would be nice for the authors to have a final pass and fix those before
submission.

Thirdly, the document does not give any advice on the timing of using the
extensions - how far in advance is it recommended to use the extensions? - or
on the return to 'normal' state once the maintenance is completed.  So perhaps
consider adding a short section on this, maybe in Section 5.

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Suresh Krishnan) No Objection

Warren Kumari No Objection

(Mirja Kühlewind) No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

(Eric Rescorla) No Objection

Comment (2018-01-18 for -12)
No email
send info
I think this document would be clearer if the example in S 7.1 were
in the intro. I was scratching my head a bit at the beginning and
then got to 7.1 and it made more sense.

Alvaro Retana No Objection

Comment (2018-01-24 for -13)
No email
send info
I debated about filing my first comment as a DISCUSS [1], but decided against it because it should be very easy to solve.  The rest are non-blocking comments.

(1) The following should be Normative references: rfc2119 and rfc6987 -- this last one because MaxLinkMetric (which is defined there) is extensively used (as a MUST) throughout the document.

(2) Section 3. (Flooding Scope) provides information about the flooding scope, but only references for OSPFv2.  It would be nice if the references for OSPFv3 were included there as well.

(3) Section 4.5. mentions that a "new TLV called Graceful-Link-Shutdown is defined" for BGP-LS, but there are no details on the format, etc.  The IANA Considerations section suggests a value, not for a TLV but for an NLRI Type!  

(4) Section 5: "The node that has the link to be taken out of service SHOULD advertise the Graceful-Link-Shutdown sub-TLV..."  When would the node not advertise the sub-TLV?  IOW, why is "MUST" not used?

(5) In 5.1: "MAX-TE-METRIC is a constant defined by this draft and set to 0xfffffffe."  Assuming that the intent is to define a new architectural constant... I would rather see this constant defined separately (in it's own section/sub-section with a formal definition) instead of "in passing" while describing how to use it (a la MaxLinkMetric in rfc6987).

(6) 5.1 says that the metrics "MUST be set to MaxLinkMetric...and SHOULD be set to MAX-TE-METRIC".  Why is there a difference?

(7) s/MAX_METRIC/MaxLinkMetric

[1] https://www.ietf.org/iesg/statement/discuss-criteria.html

(Adam Roach) No Objection