Distribution of Traffic Engineering Extended Administrative Groups Using the Border Gateway Protocol - Link State (BGP-LS)
draft-ietf-idr-eag-distribution-19

In Section 2, "MUST be multiple of 4" is missing an "a".

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?

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) ?

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.

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"?

Thanks for addressing my discuss.