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

[Acee Lindem <[e-mail]>]

Hi Alvaro, Co-Authors, 

Version -20 includes the updates below. 

Thanks,
Acee

> On Feb 17, 2023, at 12:14 PM, Acee Lindem <[e-mail]> wrote:
> 
> 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.
>