Re: [Idr] Opsdir last call review of draft-ietf-idr-rfc7752bis-13

[Ketan Talaulikar <[e-mail]>]

Hi Gyan,

I am trimming to only retain the open points below. Please check inline
with KT2.

On Wed, Nov 16, 2022 at 8:33 AM Gyan Mishra <[e-mail]> wrote:

>
>>> I don’t think this is mentioned in the draft but I think it’s important
>>> related
>>> to the number of BGP-LS NBI peers necessary and the two options where
>>> the NBI
>>> could be to a controller or multiple controllers within the same AS for
>>> redundancy as well as the NBI could be a dedicated PCE router SBI that
>>> also
>>> share the NBI and having redundancy for router or controller and at
>>> least two
>>> peerings.  As well as mention that it is not necessary for the NBI exist
>>> to all
>>> PEs and only one NBI to one PE in the AS at a minimum but better to have
>>> at
>>> least 2 for redundancy.  As well as the NBI can be setup iBGP and the RR
>>> can
>>> double up as PCE/BGP-LS node SBI & NBI or you can have the controller or
>>> router
>>> SBI/NBI sitting in a separate AS and eBGP multihop to two PEs NBI
>>> session for
>>> redundancy.
>>>
>>
>> KT> I am not sure that I understand what exactly is meant by NBI here.
>> The document only talks about BGP. The interface/API between a BGP Speaker
>> and (consumer) applications is out of scope - whether it be an "external"
>> northbound API (e.g., via REST) or something "internal" IPC within a
>> router/system.
>>
>>
>      Gyan> I was referring to the NBI as the SDN / PCE controller or
> router which in the draft is the consumer peering to the PE being the
> producer.
>

KT2> I am sorry, but your use of the term NBI is still not clear to me and
there is no such term in the document. The discussion would be a lot easier
if you were to use the terms in the documents. For now, I will assume that
whenever you say "consumer" you are referring to the BGP-LS Consumer as
defined in Sec 3 of the document. If this is not your intention, then is it
possible for you to rephrase your comment?


> So I am referring to the producer to consumer peering
>

KT2> BGP-LS Consumer is not a BGP Speaker and the interface to such
consumer is outside the scope of this document.


> but the producer side of the peering and how to configure the producer
> side I think should be in scope as far as redundancy and having at least 2
> producers PE nodes peering to the consumer as a best practice.  Also that
> each PE producer  does not need to peer to the consumer but at least 2 for
> redundancy.  I am referring to the BGP peering consumer design aspects and
> not the application consumer which is out of scope - agreed.  Please review
> above related to BGP Consumer which is relevant as their are a bunch of
> ways to configure the BGP consumer colocated on the RR or dedicated router
> in the domain or could be setup a consumer node that eBGP connects to the
> domain and so sits in a separate AS and could be eBGP multihop peering to
> remote producer PE or direct eBGP peeing to the producer PE.
>

KT2> If your point is to capture redundancy aspects of the BGP-LS
deployment design, we can perhaps add the following text in Sec 8.1.1.

   It is RECOMMENDED that operators deploying BGP-LS enable at least two

   or more BGP-LS Producers in each IGP flooding domain to achieve

   redundancy in the origination of link-state information into BGP-LS.

   It is also RECOMMENDED that operators ensure BGP peering designs that

   ensure redundancy in the BGP update propagation paths (e.g., using at

   least a pair of route reflectors) and ensuring that BGP-LS Consumers are

   receiving the topology information from at least two BGP-LS Speakers.



>
>>> In cases of migration where you have full overlay any permutations of
>>> MPLS,
>>> SR-MPLS, SRv6 and the core is dual stacked and not single protocol and
>>> so you
>>> have a dual plane or multi plane core the caveats related to the NBI
>>> BGP-LS
>>> peering and that you should for redundancy 2 NBI peers per plane for
>>> example
>>> IPv4 peer for SR-MPLS IPv4 plane NabI and IPv6 peer for SRv6 plane NBI.
>>>
>>
>> KT> Please see my previous response clarifying the AFI for BGP-LS. As
>> such, I don't see how MPLS/SR-MPLS/SRv6 makes any difference here.
>>
>
>     Gyan> Agreed.  Here  I was trying to give an example of a migration
> scenario where you have multiple planes, ships in the night and how best to
> configure the BGP LS peering producer to BGP consumer which is in scope.
> So I think this can be a very relevant scenario that should be included in
> the draft.
>

KT2> The choice of IPv4 or IPv6 for BGP-LS sessions has no impact on the
topology information that is being carried in BGP-LS updates.

Thanks,
Ketan