Re: [Idr] AD Review of draft-ietf-idr-rfc7752bis-10

[Alvaro Retana <[e-mail]>]

On November 7, 2022 at 5:49:13 AM, Ketan Talaulikar wrote:

Ketan:

Hi!

...
> > While I still have issues that I would like to see resolved, I am
> > starting the IETF LC. Given that we are close to IETF 115, the LC
> > will end afterwards. Maybe we can find a time there to talk about any
> > remaining issues.
>
> KT2> I am attending IETF 115 remotely and I hope we can still find time to
> meet virtually for any points that need further discussions.

I still have a couple of issues that we should maybe talk about.

Last week was too busy to find a time, but perhaps we can find
something tomorrow:  https://fantastical.app/aretana-tJ8Q/open-time

[Besides the times there, I could also talk at 11:15am UTC if that helps.]

See comments inline.


Thanks!

Alvaro.


...
> > > > 854 A BGP-LS Producer MAY suppress the advertisement of a Link NLRI,
> > > > 855 corresponding to a half link, from a link-state IGP unless it has
> > > > 856 verified that the link is being reported in the IS-IS LSP or OSPF
> > > > 857 Router LSA by both the nodes connected by that link. This 'two-way
> > > > 858 connectivity check' is performed by link-state IGPs during their
> > > > 859 computation and may be leveraged before passing information for any
> > > > 860 half-link that is reported from these IGPs into BGP-LS. This ensures
> > > > 861 that only those Link State IGP adjacencies which are established get
> > > > 862 reported via Link NLRIs. Such a 'two-way connectivity check' may be
> > > > 863 also required in certain cases (e.g. with OSPF) to obtain the proper
> > > > 864 link identifiers of the remote node.
> > ...
> > > > [major] "A BGP-LS Producer MAY suppress the advertisement of a...half
> > > > link...unless it has verified that the link is being reported [in the
> > > > IGP] by both the nodes connected by that link."
> > > >
> > > > Another way of looking at this option is to require the converse
> > > > behavior: "the BGP-LS Producer MUST NOT suppress...if the two-way
> > > > connectivity has been advertised on the IGP".
> > > >
> > > > I both cases we would be requiring the BGP-LS Producer to perform the
> > > > two-way connectivity check using the IGP information. That seems to
> > > > me to be way outside the scope of BGP (or BGP-LS).
> > > >
> > > > As far as I can tell, the two-way connectivity check is done by the
> > > > IGPs when running SPF, so that result wouldn't be available in the
> > > > LSBD.
> > >
> > > KT> Whether the result of 2-way connectivity check is stored/available in
> > > the LSDB is implementation specific. It is not so that information from
> > > LSAs/LSPs can be simply plucked from a LSDB built from raw IGP PDUs and
> > > advertised into BGP-LS. Information from multiple LSAs/LSPs can
> > > contribute to a single link-state object. This requires additional
> > > processing in the form of collating information into some form of a
> > > topology database (nodes, links, prefixes). Ultimately, it is up to the
> > > implementation how it realizes the LSDB.
> >
> > It looks like we're saying the same thing: the 2-way connectivity
> > information may not be immediately available to BGP-LS. Right?
>
> KT2> It can be available - it depends on how the interface between IGP and
> BGP is implemented. Note that the text does not say "BGP or BGP-LS" but the
> "BGP-LS Producer" - the intention here is reference to the "router" and not
> to a specific protocol component.

What?!   According to §3, the BGP-LS Producer *is* a BGP speaker...


> > My issue with the text above is that it is Normative ("BGP-LS Producer
> > MAY suppress"). The only way to do that is to either expect that the
> > LSDB will provide the information, or to have BGP-LS figure it out. I
> > think we're both saying that neither option is feasible. So, how can
> > the Normative statement be satisfied?
>
> KT2> Please see my previous response and the next one.
>
> >
> > Suggestion: s/MAY/may and add a statement about the mechanism itself
> > to figure out the 2WCC being out of scope.
>
> KT2> The text describes a mechanism - i.e., use/leverage the check performed
> by the IGPs. However, added text in the new section 4 introduced to clarify
> this a bit further.

No, the text doesn't describe anything, it just suggests using
whatever the IGP does, but the interaction is also left out of scope.
We can't have it both ways: normatively depend on a behavior *and*
leave it out of scope.

The test in this section (§5.2.2, quoted above) is not specific about
the mechanism:

   A BGP-LS Producer MAY suppress the advertisement of a Link NLRI,
   corresponding to a half-link, from a link-state IGP unless it has
   verified that the link is being reported in the IS-IS LSP or OSPF
   Router LSA by both the nodes connected by that link.  This 'two-way
   connectivity check' is performed by link-state IGPs during their
   computation and may be leveraged before passing information for any
   half-link that is reported from these IGPs into BGP-LS.  ...

Note that the text implies that the BGP-LS Producer is responsible for
the action (advertisement and verification: "BGP-LS Producer MAY
suppress the advertisement...unless it has verified..."), but also
points at the 2WCC being done by the IGPs ("'two-way connectivity
check' is performed by link-state IGPs").

The new §4 leaves the ability to use/leverage whatever the IGP does
out of scope.

   The design of the interface between IGPs and BGP for the
   advertisement of link-state information is outside the scope of this
   document.  In some cases, the information derived from IGP processing
   (e.g., combination of link-state object from across multiple LSAs/
   LSPs, leveraging reachability and two-way connectivity checks, etc.)
   may be required for advertisement of link-state information into BGP-
   LS.

As I said above, we can't normatively depend on a behavior *and* leave
it out of scope.


Back to the top: as I mentioned, what bothers me the most is the
initial "MAY", so s/MAY/may would solve this issue for me (without
changing the meaning of the rest of the text).  I probably should have
started with this -- the more I read it (and the additional text), the
more I now think that the "MAY" is stating a fact, not a normative
option, which also takes me back to s/MAY/may.



...
> > > > 2358 When a BGP Speaker receives an update message with Link-State NLRI(s)
> > > > 2359 in the MP_REACH_NLRI but without the BGP-LS Attribute, it is most
> > > > 2360 likely an indication that a BGP Speaker preceding it has performed
> > > > 2361 the 'Attribute Discard' fault handling. An implementation SHOULD
> > > > 2362 preserve and propagate the Link-State NLRIs in such an update message
> > > > 2363 so that the BGP-LS Consumers can detect the loss of link-state
> > > > 2364 information for that object and not assume its deletion/withdraw.
> > > > 2365 This also makes it possible for a network operator to trace back to
> > > > 2366 the BGP-LS Propagator that detected the fault with the BGP-LS
> > > > 2367 Attribute.
> > > >
> > > > [major] "SHOULD preserve and propagate"
> > > >
> > > > This is a very useful signal that something went wrong. Why is it
> > > > recommended and not required? When is it ok to not preserve and
> > > > propagate.
> > >
> > > KT> Good point. There is a flip side here. Assume that there were two
> > > BGP-LS Producers for the same link-state object. For some reason, one of
> > > them generated a malformed TLV in the BGP-LS attribute while the other
> > > did not. If we do "treat as withdraw" then that malformed update is gone
> > > and the other will go through. However, if we were to retain with
> > > "attribute discard" then there is no guarantee which of the two updates
> > > would go through.
> >
> > I still don't understand. When is it ok to not "preserve and
> > propagate the Link-State NLRIs" (after another node used "attribute
> > discard")? I'm not sure if you're arguing for "MAY preserve and
> > propagate".
>
> KT2> The discard (or absence) of BGP-LS Attribute does not affect its
> eligibility for best path selection. Hence, it would get propagated further
> w/o the BGP-LS attribute. Please also see my next response - this was just
> for discussion and no change to text is proposed.

Right...so you're saying that propagating the route (after removing
the BGP-LS Attribute) is a good thing.

The question is: why is that behavior not required?  If it is only
recommended, when is it ok to decide not to propagate?