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

[Acee Lindem <[e-mail]>]

Hi Alvaro, 

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

We’re fine with the text you suggest. We realize that you would have liked EoR to be mandatory
but we didn’t want to do that at this point. 




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

Agreed. 

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

Agreed. 

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

Are you talking about this text from RFC 7752BIS?  

    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.

Thanks,
Acee


> .
> 
> 
> Thanks!
> 
> Alvaro.