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

[Ketan Talaulikar <[e-mail]>]

Hi Alvaro,

Thanks for your response and suggestions. Please check inline below with
KT2.

We have also posted an update with the following changes as discussed
below:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-app-specific-attr-10


On Fri, Apr 15, 2022 at 11:56 PM Alvaro Retana <[e-mail]>
wrote:

> 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.
>
>
>
> ...
> > > 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.
>
> For the Bit Masks, refer to rfc8919 instead: that is where the bits
> are allocated and rfc8920 points to it too.
>

KT2> Ack. Fixed.


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

KT2> Ack. The updated text now simply points to RFC8920.


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

KT2> Yes, it depends on the IGP definition.


>
> 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.
>
>
KT2> Ack. Updated text as suggested.


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

KT2> Removed the initial set of text in Sec 3. BGP-LS does indeed determine
based on the underlying IGP specs.


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

KT2> Removed the text about receivers since it was applicable only for
consumers and not BGP-LS speakers.


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

KT2> There is no normative text here and it is not explicitly directed
toward consumers. However, I believe it is important to clarify this.


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

KT2> Ack. Moved this out of the numbered rules. This is as per existing
BGP-LS specs and the text is updated to reflect the same.


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

KT2> Ack


>
>
>
> ...
> > > 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.
> ...
> > > [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.
>
> "receiver MUST ignore" sounds exactly like an instruction.
>

KT2> Ack. Fixed.


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

KT2> Rephrased further to indicate only the BGP-LS sender side of things.


>
>
>
> ...
> > > 430 6. Backward Compatibility
> ...
> > 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.
>

KT2> Ack. Added the references to those RFCs and rephrased the text.

Thanks,
Ketan


>
>
> ...
> > > [EoR -08]
>