Re: [Idr] John Scudder's Discuss on draft-ietf-idr-rfc7752bis-14: (with DISCUSS and COMMENT)

[John Scudder <[e-mail]>]

Hi Ketan,

I’ve reviewed your replies and change set, looks good to me for the large part. A few replies are in line below (I’ve trimmed the agreed points for brevity).

—John

## COMMENTS

> On Feb 17, 2023, at 6:20 AM, Ketan Talaulikar <[e-mail]> wrote:
...
> ### Section 4
> 
> You set up, but do not resolve, a conflict, in your first two paragraphs:
> 
> ```
>    The origination and propagation of IGP link-state information via BGP
>    needs to provide a consistent and true view of the topology of the
>    IGP domain.
> ```
> and,
> 
> ```
>    The link-state information advertised in BGP-LS from the IGPs is
>    derived from the IGP LSDB built using the OSPF Link State
>    Advertisements (LSAs) or the IS-IS Link State Packets (LSPs).
>    However, it does not serve as a true reflection of the originating
>    router's LSDB.
> ```
> What's a reader to think when they encounter this contradiction, between "needs
> to provide... a true view" and "does not serve as a true reflection"? I guess
> the former talks about the *topology* and the latter talks about the *LSDB*,
> but if you intend to make something of this subtle difference, it's escaped me.
> 
> KT> Yes, that is indeed the difference and it was not meant to be subtle. Because this is important for the reader to grasp. Any suggestions to improve would be most helpful.
>  
> I presume that having set up this dichotomy, you have some resolution in mind
> for it -- please don't leave it as a conundrum to be solved by the reader.
> 
> KT> There is no dichotomy here to be resolved. It is just a factual statement.

Maybe I should have said “superficial dichotomy”, but the repetition of “true” makes it hard for me not to see it that way. A simple change that could mitigate this would be changing the second “true” to “verbatim”. And now that I’m thinking about it, even the first “true” could probably use an edit. After all, what is truth? Especially in a protocol with eventual-consistency semantics? I joke, but only partly — we probably don’t want to get into metaphysics in the IETF stream RFCs (we can leave that for the April 1 series). Is there any problem with removing “and true” from the first quoted use? With those two edits, we’d have:

OLD:
   The origination and propagation of IGP link-state information via BGP
   needs to provide a consistent and true view of the topology of the
   IGP domain.  BGP-LS provides an abstraction of the IGP specifics and
   BGP-LS Consumers may be varied types of applications.

   The link-state information advertised in BGP-LS from the IGPs is
   derived from the IGP LSDB built using the OSPF Link State
   Advertisements (LSAs) or the IS-IS Link State Packets (LSPs).
   However, it does not serve as a true reflection of the originating
   router's LSDB.

NEW:
   The origination and propagation of IGP link-state information via BGP
   needs to provide a consistent view of the topology of the
   IGP domain.  BGP-LS provides an abstraction of the IGP specifics and
   BGP-LS Consumers may be varied types of applications.

   The link-state information advertised in BGP-LS from the IGPs is
   derived from the IGP LSDB built using the OSPF Link State
   Advertisements (LSAs) or the IS-IS Link State Packets (LSPs).
   However, it does not serve as a verbatim reflection of the originating
   router's LSDB.

(Or if you miss the first “and true”, perhaps change to “and accurate”?)

[…]

> ### Section 5.3, limiting the size of the BGP-LS Attribute
> 
> Thanks for this discussion. One of the points you raise is:
> 
> ```
>          BGP-LS Producers MUST
>    ensure that they limit the TLVs included in the BGP-LS Attribute to
>    ensure that a BGP UPDATE message for a single Link-State NLRI does
>    not cross the maximum limit for a BGP message.  The determination of
>    the types of TLVs to be included may be made by the BGP-LS Producer
>    based on the BGP-LS Consumer applications requirement and is outside
>    the scope of this document.
> ```
> In other words, it's a policy decision. But that means that in this scenario
> such policy filtering of TLVs would be expected on a per-producer basis -- does
> this motivate any concern that inconsistent policy being applied at different
> BGP-LS Producers could lead to redundant but non-comparable information being
> propagated into BGP-LS? If so, is this worth noting?
> 
> KT> Ack. Added text to that effect.

You’ve added “(in a consistent manner)” and changed “the BGP-LS Producer” to “all the BGP-LS Producers”. This does indeed address my point, although it does so in kind of a minimal and easy-to-ignore way. For example, an implementor could hardcode such a filtering policy and either ignore the “in a consistent manner” text since it’s thrown in parenthetically and non-normatively, or if they paused to consider it they might decide “oh well my implementation will behave completely consistently with itself”. But, if deployed in a mixed-vendor or even mixed-version network, there might still be inconsistent policies applied, and it would be even worse if the policies were hardcoded rather than configured by the operator.

Given that overrunning the update size is arguably a case of “the network is already broken” I’m not going to elevate this to a DISCUSS or insist that you make any particular change — but please give one more careful thought to whether anything more helpful can go here. Options I can think of include adding a paragraph of text describing potential consequences if the guidance isn’t followed and inconsistent filtering is done, strengthening the guidance from the very soft lower-case “may” to a SHOULD or MUST, or even some more drastic mitigation like requiring the session to drop if the NLRI would exceed the maximum PDU size.

In reviewing this again I also notice that (as mentioned above) the text is exceedingly deferential: "The determination of the types of TLVs to be included may be made (in a consistent manner) by all the BGP-LS Producer Producers based on the BGP-LS Consumer applications requirement and is outside the scope of this document.” The “may” is pretty odd there. I guess I should put out at least some straw man replacement text to spur discussion. Here’s an attempt,

NEW:
If the NLRI would cause the BGP message size limit to be exceeded, implementations will have to take some steps to avoid doing so, otherwise, a protocol error would ensue. The exact mitigation to be used is implementation-specific and beyond the scope of this specification. However, if the implementation chooses to mitigate the problem by excluding some TLVs from the NLRI, this exclusion MUST be done consistently by all routers within a given BGP-LS domain. Because of this requirement for consistency, it would be better for the exclusion policy to be configurable, but in any case, it must be documented. If different routers in a given BGP-LS domain do inconsistently exclude TLVs, the result would be redundant, non-comparable information being propagated into BGP-LS.

[…]

## NITS

“copes” -> “copies”

“value..” -> “value”