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

[Ketan Talaulikar <[e-mail]>]

Hi John,

Thanks for your feedback and further comments/responses. Please check
inline below with KT2 for my responses.

I have also posted an update with the changes as discussed below:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc7752bis-16


On Mon, Feb 20, 2023 at 11:19 PM John Scudder <[e-mail]> wrote:

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

KT2> I get your point now and your suggestions look good to me.


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

KT2> I've taken some of your suggestions above - please check if this
works. However, since we are talking about TLVs in the BGP-LS Attribute,
the inconsistency in exclusion of TLVs won't cause "redundant,
non-comparable info" - it would just result in a somewhat flaky behavior
where the consumers may get different link-state attribute information
based on the BGP decision process along the way - depending in which
producer's update goes through. So it isn't a BGP(-LS) problem per se, but
that for the consumer applications.


>
> ## NITS
>
> “copes” -> “copies”
>
> “value..” -> “value”
>

KT2> Ack to both.

Thanks,
Ketan