[Idr] AD Review of draft-ietf-idr-bgp-ls-app-specific-attr-08

[Alvaro Retana <[e-mail]>]

Dear authors:

I just finished reading this document.  Thank you for the work!


I've had the pleasure of processing all the BGP-LS extensions to date.
A constant throughout has been the concept that BGP-LS provides
transport; what to do with the information and any error checking
(beyond basic checks) is left to the consumer and out of scope.
However, this document includes a good number of instructions for the
consumer; for example:

   ...the link attributes advertised within an ASLA TLV with such a
   zero-length application bit mask MUST NOT be considered by BGP-LS
   consumers for those applications for which at least one instance
   of ASLA TLV is present in the same advertisement with their specific
   application bit set.

   A BGP-LS consumer that supports this specification SHOULD prefer
   the application-specific attribute value received via sub-TLVs within
   the ASLA TLV over the value received via the top-level TLVs.


These are two examples in which the document directly specifies what
the consumer is to do with the information.  Again, these types of
statements have been considered out of scope.  Please remove them.  I
commented inline about other instances but may not have caught them
all.


I will wait for my comments to be addressed before moving the document forward.

Thanks!

Alvaro.


[Line numbers from idnits.]


...
78	1.  Introduction

[] I appreciate the background, but the objective of this document is
to define a way to carry the IGP-derived information.  The
justification for the IGPs to carry the information and its potential
use should have already been justified in [RFC8920] and [RFC8919].  It
concerns me that adding this much background will raise unnecessary
questions.

I strongly recommend that you focus on the objective of this document
and keep it simple:

   [RFC8920] and [RFC8919] define extensions to carry application specific
   attributes.

   This document specifies how this information is carried in BGP-LS.

Ok, maybe a few more words would be good.  You get the idea.


...
131	2.  Application Specific Link Attributes TLV
...

[major] For all the fields below, I made the same comment: the
information comes from the IGPs.  Instead of describing the fields
independently, perhaps consider a statement like this:

   The semantics and values of the fields in the TLV are described
   in [RFC8920] and [RFC8919].


167	   o  SABM Length : Standard Application Identifier Bit Mask Length in
168	      octets.  The values MUST be 0, 4, or 8.  If the Standard
169	      Application Identifier Bit Mask is not present, the value MUST be
170	      set to 0.

[major] BGP-LS is just the carrier of the information, the validation
or use of the data by the consumer is out of scope.  All the
information is taken from the IGPs.  The descriptions should then
indicate where the information comes from:

   SABM Length: Standard Application Identifier Bit Mask Length as defined
   in [rfc8919] and [rfc8920].



172	   o  UDABM Length : User-Defined Application Identifier Bit Mask Length
173	      in octets.  The values MUST be 0, 4, or 8.  If the User-Defined
174	      Application Identifier Bit Mask is not present, the value MUST be
175	      set to 0.

[major] Same comment as above.  Note that the specifications in
rfc8919/rfc8920 are not the same, which is another reason to simple
point at the existing documents.


177	   o  Standard Application Identifier Bit Mask : of size 0, 4, or 8
178	      octets as indicated by the SABML.  An optional set of bits, where
179	      each bit represents a single standard application.  The bits are
180	      defined in the IANA "IGP Parameters" registries under the "Link
181	      Attribute Applications" registry [RFC8919].

[major] Same comment as above...


183	   o  User-Defined Application Identifier Bit Mask : of size 0, 4, or 8
184	      octets as indicated by the UDABML.  An optional set of bits, where
185	      each bit represents a single user-defined application.  The bits
186	      are not managed or assigned by IANA or any other standards body
187	      and definition is left to the implementation.

[major] Same comment as above...


189	   o  sub-TLVs : BGP-LS Attribute TLVs corresponding to the Link NLRI
190	      that are application-specific (as specified in Section 3) are
191	      included as sub-TLVs of the ASLA TLV.

[minor] s/sub-TLVs :/Link Attribute sub-TLVs :


193	   An ASLA TLV with both the SABM and UDABM lengths set to 0 (i.e.
194	   without any application identifier bit masks) indicates that the link
195	   attribute sub-TLVs that it encloses are applicable for all
196	   applications.  However, the link attributes advertised within an ASLA
197	   TLV with such a zero-length application bit mask MUST NOT be
198	   considered by BGP-LS consumers for those applications for which at
199	   least one instance of ASLA TLV is present in the same advertisement
200	   with their specific application bit set.

[major] This paragraph talks about what a consumer should do with the
information.  This is outside the scope of BGP-LS.


...
208	   When the node is not running any of the IGPs but running a protocol
209	   like BGP, then the link attributes for the node's local links MAY be
210	   originated as part of the BGP-LS Attribute using the ASLA TLV and its
211	   sub-TLVs within the Link NLRI corresponding to the local node.

[major] The subject of including non-IGP information, BGP
specifically, has come up in other BGP-LS-related drafts.  The
conclusion has been that the process is currently not specified and
that draft-ietf-idr-bgp-ls-bgp-only-fabric may be the best place to do
that -- at least that was the conclusion the last time we discussed it
[1].  Has anything changed?  If not, then please remove the paragraph
above.

[1] https://mailarchive.ietf.org/arch/msg/idr/7nNtfqJ6OyktdP4QETX2xHSHbTw/


213	3.  Application-Specific Link Attributes

215	   Several BGP-LS Attribute TLVs corresponding to the Link NLRI are
216	   defined in BGP-LS and more may be added in the future.  The following
217	   types of link attributes are required to be considered application-
218	   specific.

[major] "are required"

The wording sounds like it may need to be a Normative statement ("are
REQUIRED"), but that would then be an indication to the consumer of
what to do.  Please use "are expected" instead.


220	   o  those that have different values for different applications e.g.,
221	      a different TE metric value used for RSVP-TE than for SR Policy

223	   o  those that apply to multiple applications but need to be used only
224	      by a specific application e.g., certain Shared Risk Link Group
225	      (SRLG) values are configured on a node for LFA but the same do not
226	      need to be used for RSVP-TE

[major] This text doesn't describe "types of link attributes", but
*uses* of the attributes.  For example, 1096 (SRLG is used as an
example) is not already defined to indicate "different values for
different applications" nor how it should be "used only by a specific
application".


228	   The following table lists the currently defined BGP-LS Attributes
229	   TLVs corresponding to Link NLRI that have application-specific
230	   semantics.  These were originally defined with semantics for RSVP-TE
231	   and GMPLS applications.

[minor] s/that have/that can have


[] What's the value of identifying these TLVs?  More specifically:
given that it is up to the consumer (not BGP-LS) to decide what is
appropriate, what is the importance of this information?  If a TLV
that is not listed (1089, for example) is included, then what?  [I
know there are Normative statements about that in the next section --
see more comments there.]


233	   +---------------+-------------------------------+-------------------+
234	   |    TLV Code   | Description                   | Reference         |
235	   |     Point     |                               | Document          |
236	   +---------------+-------------------------------+-------------------+
237	   |      1088     | Administrative group (color)  | [RFC7752]         |
238	   |      1092     | TE Default Metric             | [RFC7752]         |
239	   |      1096     | Shared Risk Link Group        | [RFC7752]         |
240	   |      1114     | Unidirectional Link Delay     | [RFC8571]         |
241	   |      1115     | Min/Max Unidirectional Link   | [RFC8571]         |
242	   |               | Delay                         |                   |
243	   |      1116     | Unidirectional Delay          | [RFC8571]         |
244	   |               | Variation                     |                   |
245	   |      1117     | Unidirectional Link Loss      | [RFC8571]         |
246	   |      1118     | Unidirectional Residual       | [RFC8571]         |
247	   |               | Bandwidth                     |                   |
248	   |      1119     | Unidirectional Available      | [RFC8571]         |
249	   |               | Bandwidth                     |                   |
250	   |      1120     | Unidirectional Utilized       | [RFC8571]         |
251	   |               | Bandwidth                     |                   |
252	   |      1173     | Extended Administrative Group | [RFC9104]         |
253	   +---------------+-------------------------------+-------------------+

255	     Table 1: BGP-LS Attribute TLVs also used as sub-TLVs of ASLA TLV

257	   All the BGP-LS Attribute TLVs defined in the table above are
258	   RECOMMENDED to continue to be advertised at the top-level in the BGP-
259	   LS Attribute for carrying attributes specific to RSVP-TE without the
260	   use of the ASLA TLV.

[nit] s/RECOMMENDED to continue to be advertised/RECOMMENDED to be advertised


[major] When is it ok to not advertise these TLVs at the top-level?
Assuming that the reason is backward compatibility (?), why isn't it a
requirement?  The propagation of those TLVs was defined elsewhere --
by recommending, the text is conditioning the application of those
other RFCs.


[major] What is the "top-level"?  I guess you mean "not as a sub-TLV
of the Application-Specific Link Attributes TLV", but that is not
explained anywhere -- and rfc7752 doesn't talk about top-level at all.


262	   When a new link attribute is introduced, it may be thought of as
263	   being specific to only a single application.  However, subsequently,
264	   it may be also shared by other applications and/or require
265	   application-specific values.  In such cases, it is RECOMMENDED to err
266	   on the side of caution and define such attributes as application-
267	   specific to ensure flexibility in the future.

[major] "new link attribute...may...require application-specific
values.  In such cases, it is RECOMMENDED to...define such attributes
as application-specific..."

What does "to...define...as application-specific" mean?  The
attributes listed above were not defined as "application-specific";
the ASLA TLV provides the application-specific context.  Is that
(ability to include the attribute as a sub-TLV) that you mean, or are
you expecting something more?  At least, you need to be more specific
on what is expected.

When would it be ok not to define a new attribute as
"application-specific"?  Why is it recommended and not required?


269	   BGP-LS Attribute TLVs corresponding to Link NLRI that are defined in
270	   the future MUST specify if they are application-specific and hence
271	   are REQUIRED to be encoded within an ASLA TLV.

[major] This paragraph provides more insight into what you might mean.

Let me see if I understand.  If a new link attribute is specified as
"application-specific" it then MUST be included in the ASLA TLV.  Does
that mean that it can't be used as a top-level TLV?

I'm assuming that if a new link attribute is not specified as
"application-specific" it still can be included in the ASLA TLV, and
it can also be used as a top-level TLV.  Is that true?

Given that the consumer decides what to do with the information
received, there doesn't seem to be a strong incentive to specifying
new attributes as "application-specific".  Not doing it would result
in maximum flexibility.


273	   Only application-specific link attributes need to be advertised
274	   within the ASLA TLV.  Link attributes that do not have application-
275	   specific semantics MUST NOT be advertised within the ASLA TLV.
276	   Receivers MUST ignore any non-application-specific attribute sub-TLVs
277	   within the ASLA TLV.

[major] Given the requirement in the second sentence, the first
sentence just adds confusion.  Note also that it is still not clear to
me how one can tell if an attribute has "application-specific
semantics" or not.


[major] "Receivers MUST ignore..."   Since when is it ok to give
instructions to the consumer about what to do with the BGL-LS
information?


279	   When the same application-specific link attributes are advertised
280	   both within the ASLA TLV and as top-level TLVs in the BGP-LS
281	   Attribute, the attributes advertised within the ASLA TLV take
282	   precedence for the applications indicated in the ASLA TLV encoding.

[major] Again, isn't this an action that the consumer decides?


284	4.  Procedures

286	   The procedures described in this section apply to networks where all
287	   BGP-LS originators and consumers support this specification.  The
288	   backward compatibility aspects and operations in deployments where
289	   there are some BGP-LS originators or consumers that do not support
290	   this specification are described further in Section 6.

[major] How can it be confirmed that "all BGP-LS originators and
consumers support this specification"?  I'm sure that it is left to
the operator, right?  Please say so.


292	   The BGP-LS originator learns of the association of an application-
293	   specific attribute to one or more applications from either the
294	   underlying IGP protocol LSA/LSPs from which it is advertising the
295	   topology information or from the local node configuration when
296	   advertising attributes for the local node only.

[major] "or from the local node..."   See the comment in §2 about
non-IGP information.


298	   The association of an application-specific link attribute with a
299	   specific application context when advertising attributes for the
300	   local node only (e.g., when running BGP as the only routing protocol)
301	   is an implementation-specific matter and outside the scope of this
302	   document.

[major] See the comment in §2 about non-IGP information.


...
310	   A BGP-LS originator node that is advertising link-state information
311	   from the underlying IGP determines the protocol encoding of
312	   application-specific link attributes based on the following rules:

314	   1.  Application-specific link attributes received from an IGP node
315	       using existing RSVP-TE/GMPLS encodings MUST be encoded using the
316	       respective BGP-LS top-level TLVs listed in Table 1.

[major] "MUST be encoded using...Table 1."

What about a new application-specific attribute?  By definition it
won't be listed in Table 1.  My concern is that this document is
defining the general process, so a new attribute would have to Update
this document to include the new attribute in Table 1 (because of the
Normative pointer), or it would have to Update the process itself.

The complication is that later (step F, for example) this document
requires that, even if some IGP information is encoded in the
corresponding TLV, the information not be encoded in the ASLA TLV.
This makes the generalization beyond "Table 1" complicated. <sigh>


318	   2.  Application-specific link attributes received from an OSPF node
319	       using ASLA sub-TLV or from an IS-IS node using either ASLA sub-
320	       TLV or ASLA SRLG TLV MUST be encoded in the BGP-LS ASLA TLV as
321	       sub-TLVs.

[major] "MUST be encoded in the BGP-LS ASLA TLV"

Step F requires that the Maximum Link Bandwidth NOT be encoded in the
SLA TLV.  That requirement contradicts the requirement in this step.


323	   3.  In the case of IS-IS, the following specific procedures are to be
324	       followed:

326	       A.  When application-specific link attributes are received from a
327	           node with the L bit set in the ASLA sub-TLV and application
328	           bits other than RSVP-TE are set in the application bit masks
329	           then the application-specific link attributes advertised in
330	           the corresponding legacy IS-IS TLVs/sub-TLVs MUST be encoded
331	           within the BGP-LS ASLA TLV as sub-TLVs with the application
332	           bits, other than the RSVP-TE bit, copied from the IS-IS ASLA
333	           sub-TLV.  The link attributes advertised in the legacy IS-IS
334	           TLVs/sub-TLVs are also advertised in BGP-LS top-level TLVs
335	           listed in Table 1.  Note that this is true regardless of
336	           whether the RSVP-TE bit was set in the IS-IS ASLA TLV/sub-
337	           TLV.  The same procedure also applies for the advertisement
338	           of the SRLG values from the IS-IS ASLA SRLG TLV within the
339	           BGP-LS SRLG TLV (1096) both at the top-level and within the
340	           BGP-LS ASLA TLV.

[major] Using the ASLA TLV is required ("MUST be encoded within the
BGP-LS ASLA TLV"), but announcing the information from "the legacy
IS-IS TLVs/sub-TLVs" is not ("link attributes advertised in the legacy
IS-IS TLVs/sub-TLVs are also advertised in BGP-LS top-level TLVs").

Why is there a difference in the treatment?  Is the intent that the
second action should be required or just a recommendation?  Would it
be clearer if Normative language is used?

Also, it is not clear to me if the "link attributes advertised in the
legacy IS-IS TLVs/sub-TLVs" should be advertised *only* in the
top-level, or both in the top-level and the ASLA TLV.  The "also" part
(given the preceding sentences) is what is throwing me off.


[major] "Note that this is true regardless of whether the RSVP-TE bit
was set in the IS-IS ASLA TLV/sub-TLV."

I find this part confusing.  I guess that by "this" you mean the part
about legacy TLVs/sub-TLVs, and not the initial part that explicitly
says that the RSVP-TE bit is not set.  Perhaps divide the text in this
bullet into 2 or 3 different paragraphs to improve clarity.


[major] "The same procedure also applies for the advertisement of the
SRLG values from the IS-IS ASLA SRLG TLV within the BGP-LS SRLG TLV
(1096) both at the top-level and within the BGP-LS ASLA TLV."

My reading of that "same procedure" is that the information in the
IS-IS ASLA sub-TLV "MUST be encoded within the BGP-LS ASLA TLV as
sub-TLVs" -- that's it.  But the text in this last sentence goes on to
say "both at the top-level and within the BGP-LS ASLA TLV."  IOW, the
described procedure doesn't seem to contemplate the "both" part.


...
349	       C.  A merge of the SRLG values advertised in IS-IS SRLG ASLA TLVs
350	           and the other link attributes advertised in IS-IS ASLA sub-
351	           TLVs, on a per-application basis, is REQUIRED for all
352	           applications that have their bit set in the SABM/UDABM in at
353	           least one of the aforementioned TLV types.  When performing
354	           this merge, only the TLVs with the application's bit set in
355	           SABM/UDABM MUST be used when such TLVs are available from
356	           either TLV types.  If the bit for an application is set in
357	           the SABM/UDABM of only one of the TLV types, then the
358	           attributes from the other TLV type with zero-length
359	           application bit mask MUST be also selected for that
360	           application, if such TLV is available.  Such merged link
361	           attributes are advertised in a per application instance of
362	           the BGP-LS ASLA TLV.

[major] "A merge of the SRLG values...is REQUIRED..."

How is that "merge" performed?  Should the router advertise all the
addresses?  Should it make sure there are no duplicates?  Should the
addresses be ordered somehow (for easier comparison in the next step)?
 Please be explicit.


364	       D.  If the resulting set of merged link attributes and SRLG
365	           values is common across multiple applications, they MAY be
366	           advertised in a common BGP-LS ASLA TLV instance where the
367	           bits for all such applications would be set in the
368	           application bit mask.

370	       E.  Both the SRLG values from IS-IS ASLA SRLG TLVs and the link
371	           attributes from IS-IS ASLA sub-TLVs, with the zero-length
372	           application bit mask, MUST be advertised into a BGP-LS ASLA
373	           TLV with a zero-length application bit mask, independent of
374	           the merging described above.

[] I think this means that the SRLG information will be merged *and*
independently advertised.


376	       F.  [RFC8919] allows the advertisement of the Maximum Link
377	           Bandwidth within an ASLA sub-TLV even though it is not an
378	           application-specific attribute.  However, when originating
379	           the Maximum Link Bandwidth into BGP-LS, the attribute MUST be
380	           encoded only in the top-level BGP-LS Maximum Link Bandwidth
381	           TLV (1089) and the receiver MUST ignore them when advertised
382	           within the BGP-LS ASLA TLV.

[] "MUST be encoded only in the top-level"  See the comment in step 2.


[major] "the receiver MUST ignore them..."  This statement is
requiring how the consumer handles the information it receives.


384	       G.  [RFC8919] also allows the advertisement of the Maximum
385	           Reservable Link Bandwidth and the Unreserved Bandwidth within
386	           an ASLA sub-TLV even though these attributes are specific to
387	           RSVP-TE application.  However, when originating the Maximum
388	           Reservable Link Bandwidth and Unreserved Bandwidth into BGP-
389	           LS, these attributes MUST be encoded only in the BGP-LS top-
390	           level Maximum Reservable Link Bandwidth TLV (1090) and
391	           Unreserved Bandwidth TLV (1091) respectively and not within
392	           the BGP-LS ASLA TLV.

[] "MUST be encoded only in the BGP-LS top-level..."  This statement
also contradicts the requirement in step 2.


...
401	   A BGP-LS consumer node would normally receive all the application-
402	   specific link attributes corresponding to RSVP-TE and GMPLS
403	   applications as existing top-level BGP-LS TLVs while for other
404	   applications they are encoded in ASLA TLV(s) with appropriate
405	   applicable bit mask setting.  A BGP-LS consumer that supports this
406	   specification SHOULD prefer the application-specific attribute value
407	   received via sub-TLVs within the ASLA TLV over the value received via
408	   the top-level TLVs.

[major] Giving instructions to the consumer...


410	5.  Deployment Considerations

[major] This section doesn't belong in this document.  These
considerations are on the deployment of attributes by the IGPs, not
the collection of the data through BGP-LS.


...
430	6.  Backward Compatibility

432	   The backward compatibility aspects for BGP-LS are associated with the
433	   originators (i.e., nodes) and consumers (e.g., PCE, controllers,
434	   applications, etc.) of the topology information.  BGP-LS
435	   implementations have been originating link attributes and consuming
436	   them without any application-specific scoping prior to the extensions
437	   specified in this document.

439	   IGP backward compatibility aspects associated with application-
440	   specific link attributes for RSVP-TE, SR Policy, and LFA applications
441	   are discussed in the Backward Compatibility sections of [RFC8920] and
442	   [RFC8919].  While those backward compatibility aspects ensure
443	   compatibility of IGP advertisements, they also serve to ensure the
444	   backward compatibility of the BGP-LS advertisements used by BGP-LS
445	   consumers.  In deployments where the BGP-LS originators or consumers
446	   do not support the extensions specified in this document, the IGPs
447	   need to continue to advertise link attributes intended for use by SR
448	   Policy and LFA applications using the RSVP-TE/GMPLS encodings.  This
449	   allows BGP-LS advertisements to be consistent with the behavior prior
450	   to the extensions defined in this document

[major] This section basically says that these extensions are not
backwards compatible.  The text is then misleading by saying that the
IGP backwards compatibility aspects "ensure the backward compatibility
of the BGP-LS advertisements used by BGP-LS consumers".  Neither one
is backwards compatible!!

Instead of this section, just point at the Deployment Considerations
of the IGP RFCs.


452	   It is RECOMMENDED that nodes that support this specification are
453	   selected as originators of BGP-LS information when advertising the
454	   link-state information from the IGPs.

[major] "RECOMMENDED that nodes that support this specification are
selected as originators of BGP-LS"

In general, this seems like a fine recommendation, but what about the
case where the consumer doesn't support this specification?

That seems to be the caveat of why the action is recommended and not
required.  Please be explicit about that case.  In fact, it would be
better if it wasn't Normatively recommended.


456	7.  IANA Considerations

458	   This document requests assignment of code-points from the registry
459	   "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
460	   Attribute TLVs" based on the table below which reflects the values
461	   assigned via the early allocation process.  The column "IS-IS TLV/
462	   Sub-TLV" defined in the registry does not require any value and
463	   should be left empty.

[] NEW>
   IANA has assigned (early allocation) the following code point from
   the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
   Attribute TLVs" registry.  This document requests that the allocation
   be made permanent.  The column "IS-IS TLV/Sub-TLV" defined in the
   registry does not require any value and should be left empty.


465	   +------------+------------------------------------------+----------+
466	   | Code Point |         Description                      | Length   |
467	   +------------+------------------------------------------+----------+
468	   |   1122     | Application-Specific Link Attributes TLV | variable |
469	   +------------+------------------------------------------+----------+

[nit] Please add a Table number/name.


...
486	9.  Security Considerations

488	   The procedures and protocol extensions defined in this document do
489	   not affect the BGP security model.  See the "Security Considerations"
490	   section of [RFC4271] for a discussion of BGP security.  Also, refer
491	   to [RFC4272] and [RFC6952] for analyses of security issues for BGP.
492	   Security considerations for acquiring and distributing BGP-LS
493	   information are discussed in [RFC7752].  The TLVs introduced in this
494	   document are used to propagate the application-specific link
495	   attributes IGP extensions defined in [RFC8919] and [RFC8920].  It is
496	   assumed that the IGP instances originating these TLVs will support
497	   all the required security (as described in [RFC8919] and [RFC8920])
498	   in order to prevent any security issues when propagating the TLVs
499	   into BGP-LS.  The advertisement of the link attribute information
500	   defined in this document presents no significant additional risk
501	   beyond that associated with the existing link attribute information
502	   already supported in [RFC7752].

[minor] I think that pointing at the security considerations of
rfc7752 is enough.  IOW, pointing as rfc4271, rfc4272, and rfc6952 is
not necessary.


[?] Is the attack surface increased my putting this information in
BGP-LS?  What can a rogue node do with this additional information?
We should carry forward similar text to the one in the IGP RFCs.

Suggestion>
   This document defines a new way to advertise link attributes.
   Tampering with the information defined in this document may
   have an effect on applications using it, including impacting
   traffic engineering, which uses various link attributes for
   its path computation.  As the advertisements defined in this
   document limit the scope to specific applications, the impact
   of tampering is similarly limited in scope.


...
539	11.2.  Informative References
...
593	   [RFC8571]  Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
594	              C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
595	              IGP Traffic Engineering Performance Metric Extensions",
596	              RFC 8571, DOI 10.17487/RFC8571, March 2019,
597	              <https://www.rfc-editor.org/info/rfc8571>.

599	   [RFC9104]  Tantsura, J., Wang, Z., Wu, Q., and K. Talaulikar,
600	              "Distribution of Traffic Engineering Extended
601	              Administrative Groups Using the Border Gateway Protocol -
602	              Link State (BGP-LS)", RFC 9104, DOI 10.17487/RFC9104,
603	              August 2021, <https://www.rfc-editor.org/info/rfc9104>.

[major] These last two references should be Normative: you are using
Normative language to refer to the contents of Table 1, where these
references are used.


[EoR -08]