Skip to main content

BGP Link-State Extensions for Seamless BFD
draft-ietf-idr-bgp-ls-sbfd-extensions-10

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

Alvaro Retana Yes

Andrew Alston No Objection

Comment (2022-05-05 for -09)
Thanks to the authors for this specification.  I found the document to be clear concise and easy to understand - and had no issues adding this into our own LS implementation based on the document text.

Erik Kline No Objection

Francesca Palombini No Objection

John Scudder No Objection

Comment (2022-05-03 for -08)
Like Lars, I also found the author list to be fairly remarkable, almost one author per page. Many hands make light work, they say.

There is one sentence in the Security Considerations section that I think overpromises:

                                                  The IGP instances
   originating this information are assumed to support any required
   security and authentication mechanisms (as described in [RFC7883] and
   [RFC7883]) to prevent any security issues when propagating the
   information into BGP-LS.

"To prevent *any* security issues" is quite a promise! I'm sure it's not what you mean, I expect you mean something more like "and therefore the security properties of those underlying mechanisms are assumed". Probably if you just dropped everything from there on, so just ended with "[RFC7883])" the text would be complete and accurate.

Lars Eggert No Objection

Comment (2022-05-02 for -08)
The document has six authors, which exceeds the recommended author limit. Has
the sponsoring AD agreed that this is appropriate? (Especially since this
document is very short.)

-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3, paragraph 7
-       of 4 octets for each additional discriminator.
-       ^^
+       by 4 octets for each additional discriminator.
+       ^^

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

Martin Duke No Objection

Comment (2022-05-02 for -08)
Please expand NLRI on first use.

Murray Kucherawy No Objection

Comment (2022-05-04 for -09)
I have the same question about the size of the author list as others have raised.

A very minor suggestion: The current Section 1.1 really belongs as 2.1, IMHO.

Paul Wouters No Objection

Comment (2022-05-03 for -08)
Note that two styles of tables are used in the document. One uses:

          +------------+--------------------------+---------------+

The other uses:

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The authors should pick whichever one they prefer. If no strong preference, I encourage you to pick the first style :)

Note that the note about early code point should probably be removed.

Robert Wilton No Objection

Comment (2022-05-05 for -09)
Hi,

My only comment doesn't directly relate to the content in the document, but I would like to check whether any new YANG data nodes are required to configure, enable, or manage this extension and if so that they are being tracked by the WG chairs, or via another document so that they don't get forgotten.

And a +1 on 6 authors on a 7 page document seeming excessive.

Regards,
Rob

Roman Danyliw No Objection

Comment (2022-05-03 for -08)
** Section 6.

The TLV introduced in this document is used to propagate IGP defined
   information ([RFC7883] and [RFC7883]).  The TLV represents
   information used to set up S-BFD sessions.  The IGP instances
   originating this information are assumed to support any required
   security and authentication mechanisms (as described in [RFC7883] and
   [RFC7883]) to prevent any security issues when propagating the
   information into BGP-LS.

-- I also share John Scudder’s reservation about this text.  In addition to his assessment that the second part of the last sentence over-promises, I believe the first part needs refinement as well.  I think were primarily talking about RFC5304 and RFC5310 so let’s also be precise about the security properties in question.  Perhaps:
NEW
The IGP instances originating this information are assumed to support the authentication mechanisms described in [RFC7883].

-- Editorial.  Why is [RFC7883] cited as “[RFC7883] and [RFC7883]”?

Warren Kumari No Objection

Comment (2022-05-04 for -09)
Thank you for this document -- I found it clear and easy to read. 

Also, much thanks to Dan for the great OpsDir review - https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ls-sbfd-extensions-07-opsdir-lc-romascanu-2022-04-20/

Zaheduzzaman Sarker No Objection

Comment (2022-05-03 for -08)
Thanks for working on this specification.

I will have to agree with some of the fellow ADs that number of authors is overwhelmingly large for such an small specification which clearly goes beyond the recommendation on the # of authors.

Éric Vyncke No Objection