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

[Alvaro Retana <[e-mail]>]

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.


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


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

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.



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



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


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



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


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



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


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



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


...
> > [EoR -08]