Skip to main content

Distribution of Traffic Engineering Extended Administrative Groups Using the Border Gateway Protocol - Link State (BGP-LS)
RFC 9104

Yes

Alvaro Retana

No Objection

Erik Kline
Martin Duke
(Martin Vigoureux)

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

Alvaro Retana Yes

John Scudder Yes

Comment (2021-05-06 for -16)
Thanks for the clear and short document! Below are a couple minor editorial comments. 

1. Abstract 

   Administrative groups are link attributes advertised used for traffic

Advertised, or used, pick one. (Probably keep used and delete advertised.)

2. Section 2

   This document defines an extension that enable BGP-LS speakers to

s/enable/enables/

Erik Kline No Objection

Lars Eggert No Objection

Comment (2021-05-10 for -16)
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, so there will likely be some false positives. There is no need
to let me know what you did with these suggestions.

"Abstract", paragraph 1, nit:
>    Administrative groups are link attributes advertised used for traffic

"advertised used" - pick one?

Section 2, paragraph 2, nit:
-    This document defines an extension that enable BGP-LS speakers to
+    This document defines an extension that enables BGP-LS speakers to
+                                                  +

"D", paragraph 4, nit:
> s an extension to BGP-LS for advertisement of extended administrative groups
>                              ^^^^^^^^^^^^^^^^
The usual collocation for "advertisement" is "for", not "of". Did you mean
"advertisement for"?

Section 1, paragraph 2, nit:
>  OSPFv3 [RFC5340]. The BGP-LS advertisement of the originally defined (non- e
>                               ^^^^^^^^^^^^^^^^
The usual collocation for "advertisement" is "for", not "of". Did you mean
"advertisement for"?

Section 1, paragraph 3, nit:
> fies an extension to BGP-LS for advertisement of the extended administrative
>                                 ^^^^^^^^^^^^^^^^
The usual collocation for "advertisement" is "for", not "of". Did you mean
"advertisement for"?

Section 4, paragraph 2, nit:
> g the TLVs into BGP-LS. The advertisement of the link attribute information
>                             ^^^^^^^^^^^^^^^^
The usual collocation for "advertisement" is "for", not "of". Did you mean
"advertisement for"?

Martin Duke No Objection

Murray Kucherawy No Objection

Comment (2021-05-17 for -16)
In Section 2, "MUST be multiple of 4" is missing an "a".

Robert Wilton (was Discuss) No Objection

Comment (2021-05-19 for -17)
Thanks for addressing my discuss.

Roman Danyliw No Objection

Comment (2021-05-18 for -16)
Per Section 4 (Security Considerations), 

It is assumed that the IGP instances originating this TLV
   will support all the required security (as described in [RFC7308]) in
   order to prevent any security issues when propagating the TLVs into
   BGP-LS. 

The Security Considerations (Section 3) of RFC7308 reads "This extension adds no new security considerations."  What guidance is this sentence providing?

Éric Vyncke No Objection

Comment (2021-05-10 for -16)
Thank you for the document.

Please find below some non-blocking comments.

Regards

-éric

-- Abstract --
I cannot parse/understand " attributes advertised used "


-- Section 2 --
"TLV MUST be considered malformed" but then what actions need to be taken ? Ignored (I guess) ?

(Benjamin Kaduk; former steering group member) No Objection

No Objection (2021-05-18 for -17)
Section 4

[Roman already covered the question about what the "required security"
from 7308 is, so I won't duplicate that]

         The advertisement of the link attribute information defined
   in this document presents no significant additional risk beyond that
   associated with the existing link attribute information already
   supported in [RFC7752].

This seems like the key point to make in this section, and might be
promoted to appear first.

I do think there is some additional risk (perhaps not significant,
though) in going from original AG to EAG, mostly in the form of the
repeated information in the first 32 bits and risk of skew between them.
It seems that the IESG comments on RFC 7038
(https://datatracker.ietf.org/doc/rfc7308/ballot/) included some useful
suggestions for security considerations, but they were not acted on at
that time.  We could still choose to incorporate them now, since the
considerations are basically identical for BGP-LS as for the IGPs that
7038 covered.

(Martin Vigoureux; former steering group member) No Objection

No Objection (for -17)