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

From: Alvaro Retana <[email-masked]>
Date: Mon, 11 Apr 2022 07:45:47 -0700

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]

---

From: Ketan Talaulikar <[email-masked]>
Date: Fri, 15 Apr 2022 11:59:09 +0530

Hi Alvaro,

Thanks for your detailed review and please check inline below for the
responses to your comments.

We've also posted an update based on the discussion below:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-app-specific-attr-09

> commented inline about other instances but may not have caught them

KT> I agree that the draft should not be carrying normative text or
describing consumer behavior. We've fixed the text referencing of BGP-LS
consumers.

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

KT> Ack. We have simplified the introduction.

>    in [RFC8920] and [RFC8919].

KT> Ack. We will refer to RFC8920 (OSPF) which is identical to BGP-LS TLV.

> indicate where the information comes from:

KT> Where the information comes from is covered in the procedures section
given the differences between the IGP encodings and the need to normalize
them before advertisement into BGP-LS.

> point at the existing documents.

KT> Ack and please also see responses to previous comments.

> [major] Same comment as above...

KT> Ack

> [major] Same comment as above...

KT> Ack

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

KT> Ack

> information.  This is outside the scope of BGP-LS.

KT> Ack - rephrased.

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

KT> Ack. This paragraph is removed.

> what to do.  Please use "are expected" instead.

KT> These are guidelines and hence not using normative language. Rephrased.

> different applications" nor how it should be "used only by a specific

KT> The text has been rephrased and hope it is clear now.

> [minor] s/that have/that can have

KT> Ack

> see more comments there.]

KT> The BGP-LS TLVs that go into the ASLA TLV as sub-TLVs need to be
identified similar to how it has been done in RFC8919 and RFC8920 for the
IGPs.

>
>
> 233
> +---------------+-------------------------------+-------------------+
> 236
> +---------------+-------------------------------+-------------------+
> 242        |               | Delay                         |
>     |
> 244        |               | Variation                     |
>     |
> 247        |               | Bandwidth                     |
>     |
> 249        |               | Bandwidth                     |
>     |
> 251        |               | Bandwidth                     |
>     |
> 253
> +---------------+-------------------------------+-------------------+
>

KT> Ack

> by recommending, the text is conditioning the application of those

KT> Ack. This needs to be a REQUIREMENT for backward compatibility.

> explained anywhere -- and rfc7752 doesn't talk about top-level at all.

KT> Ack. We have described what is meant by "top-level" in the introduction.

> "application-specific"?  Why is it recommended and not required?

KT> The bullet points earlier in the section provide guideline to help
determine which link attributes need to be classified as
application-specific. The same applies to IGPs as well. We've moved the
related text just after the bullet points and rephrased it for clarity.

> that mean that it can't be used as a top-level TLV?

KT> Yes. For new link attributes, it would be good to determine, depending
on whether or not the attribute is app-specific, one or the other but not
both.

> it can also be used as a top-level TLV.  Is that true?

KT> It should not be included in the ASLA TLV and if included by error, it
should be ignored.

> new attributes as "application-specific".  Not doing it would result

KT> The BGP-LS encoding rules guide the decision-making for the consumers.
Here we are specifying the encoding rules. E.g., the inclusion of some
random sub-TLV under the ASLA would need to be ignored. The flexibility is
for the BGP-LS speakers while propagating the topology information as they
do not perform semantic validation.

> sentence just adds confusion.

KT> We have removed the first sentence.

> Note also that it is still not clear to

KT> New link attributes need to be defined as application-specific when
introduced. Table 1 does that for the existing TLVs. The two bullet points
earlier in this section 3 provide guidance to determine whether an
attribute has application-specific semantics. This would of course need to
be consistent with how they are specified in the underlying IGPs.

> instructions to the consumer about what to do with the BGL-LS

KT> Consumers are also receivers, but this is more of an encoding
specification. Similar to when we say, undefined flags MUST be set to 0 on
transmission and MUST be ignored on reception.

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

KT> Same as the previous comment. We are describing the encoding mechanism.

> the operator, right?  Please say so.

KT> We have removed this paragraph since it is not really necessary.

> [major] "or from the local node..."   See the comment in §2 about

KT> Ack. Removed that part.

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

KT> Ack. Removed that part.

> Normative pointer), or it would have to Update the process itself.

KT> I am not sure if the BGP-LS document introducing a new app-specific
link attribute needs to carry an "updates" tag for this document. I guess
the same question applies to the underlying IGPs as well. This document is
giving guidelines and does not define the process. I hope that the updated
text clarifies that.

> SLA TLV.  That requirement contradicts the requirement in this step.

KT> Updated the text to carve out this exception.

> be clearer if Normative language is used?

KT> Ack. Fixed with the use of normative language.

> (given the preceding sentences) is what is throwing me off.

KT> The "also" is needed.

> bullet into 2 or 3 different paragraphs to improve clarity.

KT> The "note" is unnecessary and hence removed.

> described procedure doesn't seem to contemplate the "both" part.

KT> Rephrased to avoid any confusion.

> addresses be ordered somehow (for easier comparison in the next step)?

KT> SRLGs are 32-bit values and not addresses. When it comes to SRLGs,
there is no requirement for either ensuring that there are no duplicates or
for any order to be followed. That said, the use of "merge" is perhaps not
the right one here and we have replaced it with "collate".

> independently advertised.

KT> Yes

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

KT> Ack. Carved out an exception for this.

> requiring how the consumer handles the information it receives.
KT> Same as previous comments. These are encoding rules and not
instructions for consumers.

> also contradicts the requirement in step 2.

KT> Ack. Carved out the exception.

> [major] Giving instructions to the consumer...

KT> Rephrased.

> the collection of the data through BGP-LS.

KT> Ack. Removed the text in this section. Please also check the next
comment.

> Instead of this section, just point at the Deployment Considerations

KT> Ack. Have renamed this section to "Deployment Considerations" instead
and pointed to the IGP specs for the major part.

> case where the consumer doesn't support this specification?

KT> Then it would not be able to leverage the application-specific link
attributes and would continue to use the top-level TLV info advertised
prior to this specification for existing applications but not for newer
ones like Flexalgo. Have clarified this in the text.

> better if it wasn't Normatively recommended.

KT> Ack. Removed the normative language use.

>    registry does not require any value and should be left empty.

KT> Ack

>
>
> 465
> +------------+------------------------------------------+----------+
> 467
> +------------+------------------------------------------+----------+
> 469
> +------------+------------------------------------------+----------+
>

KT> Ack

> rfc7752 is enough.  IOW, pointing as rfc4271, rfc4272, and rfc6952 is

KT> Ack

>    of tampering is similarly limited in scope.

KT> We've incorporated this text.

> 603                   August 2021, <
> https://www.rfc-editor.org/info/rfc9104>.
>

KT> Ack

Thanks,
Ketan

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 15 Apr 2022 11:26:23 -0700

On April 15, 2022 at 2:29:21 AM, Ketan Talaulikar wrote:

Ketan:

Hi!

Please see a few comments in-line.  My two biggest issues remaining
have to do with using Table 1 as a Normative reference and backwards
compatibility.  However, I think that I figured out what was missing
-- see below.  There are still some consumer-specific instructions
left.

Thanks!

Alvaro.

...
> KT> Ack. We will refer to RFC8920 (OSPF) which is identical to BGP-LS TLV.

For the Bit Masks, refer to rfc8919 instead: that is where the bits
are allocated and rfc8920 points to it too.

...
> > information. This is outside the scope of BGP-LS.

Even after removing the normative language, the text still talks about
the meaning of the fields...which is already specified in rfc8920 (the
text now says that) and is out of scope for BGP-LS.

...
> KT> Yes. For new link attributes, it would be good to determine, depending on
> whether or not the attribute is app-specific, one or the other but not both.

The application-specific nature depends on the IGP: of the IGPs define
application-specific information then it should become
application-specific in BGP-LS -- but if not, then no.  Is this true?

If so, how about this:

   BGP-LS Attribute TLVs corresponding to Link NLRI that are identified as
   application-specific are REQUIRED to be encoded within an ASLA TLV.

This seems to match well with then (new) next paragraph:

   Link attributes that do not have application-specific semantics MUST
   NOT be advertised within the ASLA TLV.  Receivers MUST ignore any
   non-application-specific attribute sub-TLVs within the ASLA TLV.

...
> earlier in this section 3 provide guidance to determine whether an attribute
> has application-specific semantics. This would of course need to be
> consistent with how they are specified in the underlying IGPs.

Yes!  To me this is the most important part: BGP-LS inherits stuff
from the IGPs, if the IGPs decide that something is
application-specific (even if it doesn't match the guidelines in this
document) then it is application-specific.  The same should be true
the other way around: BGP-LS shouldn't change the characteristics of a
non-application-specific piece of information just because it fits the
guidelines here.

This leads me to think that the text earlier in Section 3 may only add
to the confusion, and that should be taken out.

> transmission and MUST be ignored on reception.

No, it's not the same thing.  In this care you are going significantly
beyond comparing bits.

Also, are there other types of "receivers" that are not consumers for
which it would be relevant to ignore the sub-TLVs?  If ignored they
would still be propagated...eventually to the consumer.   So we're
back at telling the consumer what to do.

> KT> Same as the previous comment. We are describing the encoding mechanism.

No.  Encoding is how the information is represented (put them at the
top-level, for example).  Here you're talking about what to do with
the data: "take precedence" implies that the receiver/consumer will do
something with it.

...
> KT> I am not sure if the BGP-LS document introducing a new app-specific link
> attribute needs to carry an "updates" tag for this document. I guess the same
> question applies to the underlying IGPs as well. This document is giving
> guidelines and does not define the process. I hope that the updated text
> clarifies that.

[You didn't change the text in #1 -- maybe you meant some other text.]

Again, my problem with this step is that it says: "MUST be encoded
using...TLVs listed in Table 1."  It is specifically pointing at Table
1.  It doesn't say (something like) "the corresponding BGL-LS TLV for
the IGP attribute", it is specific about Table 1.   The only way the
requirement can be satisfied is if the "TLVs listed in Table 1" are
used.

As I read this again, you wrote "using existing RSVP-TE/GMPLS
encodings".  What do you mean by that?  If these are the existing
advertisements, then this first bullet is what rfc7752, rfc8571, and
rfc9104 already specify.  Yes??

I think this ties things together with what I was missing about being
backwards compatible.

...
> KT> Updated the text to carve out this exception.

OLD>
   2.  Application-specific link attributes received from an OSPF node
       using ASLA sub-TLV or from an IS-IS node (except for (3)(F) and
       (3)(G) below) using either ASLA sub-TLV or ASLA SRLG TLV MUST be
       encoded in the BGP-LS ASLA TLV as sub-TLVs.

NEW>
   2.  Application-specific link attributes received from an OSPF node
       using ASLA sub-TLV or from an IS-IS node using either the ASLA
       sub-TLV or ASLA SRLG TLV MUST be encoded in the BGP-LS ASLA TLV
       as sub-TLVs.  Exceptions to this rule are specified in (3)(F)
       and (3)(G) below.

...
...
> KT> Same as previous comments. These are encoding rules and not instructions
> for consumers.

"receiver MUST ignore" sounds exactly like an instruction.

...
> > [major] Giving instructions to the consumer...

Similar comment to one above...  The only receiver of BGP-LS
information that would do something with the information and where any
type of preference would apply is a consumer.

...
...
> KT> Ack. Have renamed this section to "Deployment Considerations" instead and
> pointed to the IGP specs for the major part.

This is the new paragraph:

   BGP-LS sources the link-state topology information (including the
   extensions introduced by this document) from the underlying link-
   state IGP protocols.  The various deployment aspects related to the
   advertisement and use of application-specific link attributes are
   discussed in the Deployment Considerations sections of [RFC8920] and
   [RFC8919].  The IGP backward compatibility aspects described in those
   documents associated with application-specific link attributes along
   with the BGP-LS procedures specified in this document enable backward
   compatibility in deployments of existing applications such as RSVP-
   TE, SR Policy, and LFA.

This is related to the comment above associated with Table 1.
Backwards compatible with what??  This is the first document that
talks about application-specific attributes.

I believe you mean backwards compatible with rfc7752, rfc8571, and
rfc9104.  However, this document doesn't clearly explain that the
non-application-specific BGP-LS specifications are those.

...