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

[Alvaro Retana <[e-mail]>]

On February 15, 2021 at 10:55:53 AM, Acee Lindem wrote:

Acee:

Hi!

I started looking at the latest version (-18).

Instead of going through this whole message and the diffs, I think it
might be better for everyone to send out bite-size comments/answers.
Here's the first one (it only covers the items you highlighted for WG
discussion).

Thanks!

Alvaro.




> Thank you for your extensive review and comments. Now that the document
> is back in the WG, we have couple things to discuss in the WG:

I didn't see much discussion in the WG.  I'm making some comments here
in case anyone looks...



> 1. NLRI packing - Well it is almost implied, I think we need to
> limit a BGP Update to a single NLRI and BGP-LS Attribute.

>From §5.1.1 (BGP-LS-SPF NLRI TLVs):

   Given that there is a single BGP-LS Attribute for all the BGP-LS-SPF
   NLRI in a BGP Update, Section 3.3, [RFC7752], a BGP Update will
   normally contain a single BGP-LS-SPF NLRI since advertising multiple
   NLRI would imply identical attributes.

This is not a limit, as you suggested above.  FWIW, it seems to me
that the reasoning implies that setting a limit is not necessary
because it will happen naturally.



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



> 3. NEXT_HOP requiremeent - We now say we are following RFC 4760.
> However, we need to be sure we are consistent throughout.

I'll keep an eye out for that.



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