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

[Ketan Talaulikar <[e-mail]>]

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


On Mon, Apr 11, 2022 at 8:16 PM Alvaro Retana <[e-mail]>
wrote:

> 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.
>

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.


>
>
> 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.
>

KT> Ack. We have simplified the introduction.


>
>
> ...
> 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].
>

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


>
>
> 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:
>

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.


>
>    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.
>

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


>
>
> 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...
>

KT> Ack


>
>
> 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...
>

KT> Ack


>
>
> 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 :
>

KT> Ack


>
>
> 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.
>

KT> Ack - rephrased.


>
>
> ...
> 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/


KT> Ack. This paragraph is removed.


>
>
>
> 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.
>

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


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

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


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

KT> Ack


>
>
> [] 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.]
>

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
> +---------------+-------------------------------+-------------------+
> 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
>

KT> Ack


>
>
> [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.
>

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


>
>
> [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.
>

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


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

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.


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

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.


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

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


>
> 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.
>

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.


>
>
> 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.


KT> We have removed the first sentence.


> Note also that it is still not clear to
> me how one can tell if an attribute has "application-specific
> semantics" or not.
>

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.


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

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.


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

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


>
>
> 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.
>

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


>
>
> 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.
>

KT> Ack. Removed that part.


>
>
> 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.
>

KT> Ack. Removed that part.


>
>
> ...
> 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.
>

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.


>
> 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.
>

KT> Updated the text to carve out this exception.


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

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


>
> 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.
>

KT> The "also" is needed.


>
>
> [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.
>

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


>
>
> [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.
>

KT> Rephrased to avoid any confusion.


>
>
> ...
> 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.
>

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


>
>
> 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.
>

KT> Yes


>
>
> 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.
>

KT> Ack. Carved out an exception for this.


>
>
> [major] "the receiver MUST ignore them..."  This statement is
> requiring how the consumer handles the information it receives.
>
>
KT> Same as previous comments. These are encoding rules and not
instructions for consumers.


>
> 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.
>

KT> Ack. Carved out the exception.


>
>
> ...
> 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...
>

KT> Rephrased.


>
>
> 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.
>

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


>
>
> ...
> 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.
>

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


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

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.


>
> 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.
>

KT> Ack. Removed the normative language use.


>
>
> 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.
>

KT> Ack


>
>
> 465
> +------------+------------------------------------------+----------+
> 466        | Code Point |         Description                      |
> Length   |
> 467
> +------------+------------------------------------------+----------+
> 468        |   1122     | Application-Specific Link Attributes TLV |
> variable |
> 469
> +------------+------------------------------------------+----------+
>
> [nit] Please add a Table number/name.
>

KT> Ack


>
>
> ...
> 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.
>

KT> Ack


>
>
> [?] 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.
>

KT> We've incorporated this text.


>
>
> ...
> 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.
>

KT> Ack

Thanks,
Ketan


>
>
> [EoR -08]
>