Re: [Lsvr] AD Review of draft-ietf-lsvr-bgp-spf-11.txt

[Alvaro Retana <[e-mail]>]

On February 15, 2023 at 2:41:08 PM, Acee Lindem wrote:


Acee:

Hi!


...
> >> 2. Initial synchronization - we need to discuss this in the draft
> >> and potentially add an option to require this, such as the IS-IS
> >> suppress adjacency option. I don't think we'd want to require
> >> this as it would limit deployment.
> >
> > I didn't find anything about this in -18.
> >
> > Thinking out loud. The End-of-RIB marker from rfc4724 could be used
> > as a default behavior in BGP SPF (for this specific SAFI) without a
> > Capability. I know that Graceful Restart is not supported -- the
> > suggestion is to only use the End-of-RIB marker part of rfc4724.
>
> We added requiring EoR synchronization as an option. This change impacted
> mainly section 4 but other sections were modified as well.

It seemed weird to me that the EoR was introduced there (BGP Peering
Models), in a mostly informative section and not as a general option.
It looks like using the EoR is an option in all cases -- and then
there's §10.1.2 which has general applicability (but still says
"depending on the peering model").

It would be better if you specified (Normative language) things only
one.  The use of of "MAY be required" is confusing because a
requirement is a MUST...

Here's a suggestion for text in §10.1.2:

OLD>
   10.1.2. Adjacency End-of-RIB (EOR) Marker Requirement

   Depending of the peering model, topology, and convergence
   requirements, an End-of-RIB (EoR) Marker marker [RFC4724] for the
   BGP-LS-SPF SAFI MAY be required from the peer prior to advertising a
   BGP-LS Link NLRI for the peer. If configuration is supported, this
   SHOULD be configurable at the BGP SPF instance level and SHOULD be
   configured consistently throughout the BGP SPF routing domain.


NEW>
   10.1.2. Adjacency End-of-RIB (EOR) Marker

   An End-of-RIB (EoR) Marker [RFC4724] for the BGP-LS-SPF SAFI MAY be
   expected prior to advertising any BGP-LS NLRI received from the peer.
   This option SHOULD be configurable at the BGP SPF instance level and
   should be enabled consistently throughout the BGP SPF routing domain.

   A failure to consistently configure the use of the EoR marker can
   result in transient micro-loops and dropped traffic due to incomplete
   forwarding state.


You should be able to remove the related text from the other sections.

The new text in §4.3 (without the EoR-related example) is:

   The controller MAY use constraints to determine when to advertise
   BGP-LS-SPF NLRI for BGP-LS peers. These constraints are outside the
   scope of this document and, since they are internal to the controller,
   need not be standardized.

s/MAY/may  : the constraints are out of scope, so we can't Normatively
point at them.



BTW, the title of §4 should be "BGP SPF Peering Models" (not "BGP
Peering Models").



...
> >> 4. Single session requirement for BGP-LS. Right now we don't
> >> prevent this.
> >
> > As with BGP-LS, it would be nice if you (at least) RECOMMENDED it.
> > Given the peering models and that they don't map to "normal" BGP
> > deployments, it would be nice to have that separation.
> >
> > This is the related text from rfc7752bis (especially the last sentence):
> >
> > Distribution of the BGP-LS NLRIs SHOULD be handled by dedicated route
> > reflectors in most deployments providing a level of isolation and
> > fault containment between different BGP address families. In the
> > event of dedicated route reflectors not being available, other
> > alternate mechanisms like separation of BGP instances or separate BGP
> > sessions (e.g. using different addresses for peering) for Link-State
> > information distribution SHOULD be used.
> >
> > As you mention, any peering configuration is ok, nothing is prevented.
> >
> > BTW, I noticed that you borrowed the "AFI/SAFI disable" text from
> > rfc7752bis; §7.2 now reads:
> >
> > ...
> > such malformed NLRIs as 'Treat-as-withdraw'. In other cases, where
> > the error in the NLRI encoding results in the inability to process
> > the BGP update message (e.g., length related encoding errors), then
> > the router SHOULD handle such malformed NLRIs as 'AFI/SAFI disable'
> > when other AFI/SAFI besides BGP-LS are being advertised over the same
> > session. Alternately, the router MUST perform 'session reset' when
> > the session is only being used for BGP-LS-SPF or when its 'AFI/SAFI
> > disable' action is not possible.
> >
> > The recommendation above (for a separate BGP-LS-SPF session) would be
> > a good follow up to this too.
>
> Added this to section 4.2:
>
> However, since there are BGP sessions between every directly-connected node
> in the BGP SPF routing domain, there is only a reduction in BGP sessions when
> there are parallel links between nodes. Hence, this peering model is
> RECOMMENDED over the single-hop peering model Section 4.1.

This is fine, but we're talking about different things:

- the new text in §4.2 talks about a single session between routers,
which is good.

- I'm talking about a BGP session carrying ONLY BGP-LS-SPF routes.
Nothing else.  This avoids an error in a different AFI/SAFI that may
result in a session reset affecting BGP SPF...and vice versa.  That is
what the text above (from rfc7752bis) says.


Thanks!

Alvaro.