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

[Acee Lindem <[e-mail]>]

Hi Alvaro, 

Keyur and I discussed your comments and most have been addressed in the -19 version. 

> On Feb 8, 2023, at 8:00 AM, Alvaro Retana <[e-mail]> wrote:
> 
> 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.

We changed the wording to indicate one NLRI per BGP Update.


    Given that there is a single BGP-LS Attribute for all the BGP-LS-SPF
    NLRI in a BGP Update, Section 3.3, [I-D.ietf-idr-rfc7752bis], a BGP
    Update for BGP-LS-SPF SAFI SHALL contain a single BGP-LS-SPF NLRI.
    It is unlikely that multiple NLRI would have identical attributes so,
    for simplicity, 
> 
> 
> 
>> 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. 




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

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.


Thanks,
Acee