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

[Ketan Talaulikar <[e-mail]>]

Hi Alvaro,

Thanks for your response and suggestions. I've posted an update that
includes text changes for your comments (as also for Joel's and IANA
comments):
https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc7752bis-13

Please let me know if this addresses your comments.

Thanks,
Ketan


On Mon, Nov 14, 2022 at 9:53 PM Alvaro Retana <[e-mail]>
wrote:

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