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

[Ketan Talaulikar <[e-mail]>]

Hi Gyan,

Please check responses inline below with KT3.

On Thu, Nov 17, 2022 at 8:37 AM Gyan Mishra <[e-mail]> wrote:

>
> Hi Ketan
>
> Responses in-line
>
> Thanks
>
> Gyan
>
> On Wed, Nov 16, 2022 at 1:59 AM Ketan Talaulikar <[e-mail]>
> wrote:
>
>> 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?
>>
>>
>    Gyan2> Let me try again with correct semantics
>
> As Alvaro mentioned we definitely need a drawing here describing the roles
> as it’s very confusing
>

KT3> There is Figure 1 which is being referred to and Alvaro's review
comments have been addressed.


>
>  I was referring to the NBI as the SDN / PCE controller or router which in
> the draft is the BGP-LS consumer peering to the PE being the BGP-LS
> producer.  So I am referring to the BGP-Las producer to BGP-LS consumer
> peering but the BGP-LS producer side of the peering and how to configure
> the BGP-LS 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 BGP-LS producer  does not need to peer to the
> BGP-LS consumer but at least 2 minimum for redundancy.
>

KT3> Doesn't the text we discussed further below to be added in Sec 8.1.1
cover all this? Those are operational guidelines.


>   I am referring to the BGP peering BGP-LS consumer design aspects and not
> the BGP-LS application consumer which is out of scope - agreed.  Please
> review above related to BGP BGP-LS Consumer which is relevant as their are
> a bunch of ways to configure the BGP BGP-LS consumer colocated on the RR or
> dedicated router in the domain or could be setup a BGP-LS 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
> BGP-LS producer PE.
>

KT3> Agreed. There are N ways to design BGP peerings. This standards track
document does not aim to capture them.


>
>
> 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.
>>
>
>    Gyan2> This paragraph is confusing as it refers to consumer as two
> different contents an BGP-LS application consumer and a BGP-LS BGP Consumer
>

KT3> You seem to be introducing two new terms for consumers which are not
there in the document.


>
>       BGP-LS Consumer: The term BGP-LS Consumer refers to a consumer
>       application/process and not a BGP Speaker.
>
>
>       Gyan2> So here we are saying application/process meaning API driven / Netconf
>
>       or SDN or BGP or other controller based mechanism?
>
>
KT3> Consumer is an application that is outside of the BGP/BGP-LS
functional block which this document specifies. So it is not part of BGP
(which is IDR WG scope) and could be anything else.


>
>       Which node is RR1 and which is Rn and are they both route reflectors
>
>
KT3> As the name and description suggest, the nodes with "RR" in their
names are route reflectors.


>
>       The BGP Speakers RR1
>       and Rn are handing off the BGP-LS information that they have
>       collected to a consumer application.
>
>
>       Gyan2> It sounds like there is a BGP component to the BGP-LS consumer and a application
>
>       Component.
>
>
KT3> No. There is no BGP peering/interface to a BGP-LS consumer (it is some
app).


>
>       Rn is the BGP-LS producer node, what is RR1, is or the BGP-LS consumer BGP implementation in scope ?
>
>
>       The BGP protocol
>       implementation and the consumer application may be on the same or
>       different nodes.
>
>
>       Gyan> So here there are 2 components a BGP component and a application component
>
>       And they can be on same node or different nodes
>
>
KT3> Yes


>
>       This document only covers the BGP
>       implementation.
>
>
>       Gyan3> So here the BGP component is in scope - you agree
>
>
>       So to reiterate the BGP-LS Consumer “BGP component” is in scope, correct?
>
>
KT3> No. Please see my previous responses.


>
>       The consumer application and the design of the
>       interface between BGP and the consumer application may be
>       implementation specific and are outside the scope of this
>       document.
>
>
>       Gyan> So only the BGP-LS Consumer “application component” is out of scope
>
>
>       The communication of information is expected to be
>       unidirectional (i.e., from a BGP Speaker to the BGP-LS Consumer
>       application) and a BGP-LS Consumer is not able to send information
>       to a BGP Speaker for origination into BGP-LS.
>
>
>              Gyan> Bundling these two together into one role makes it very
> confusing.
>

KT3> There is no such "bundling" in the text.


>
> I think BGP-LS Consumer Application should be decoupled into separate role
> so that the BGP-LS Consumer would be in scope.
>
>>
>>
>>> 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.
>>
>>
>>
>>> Gyan> perfect!
>>>>
>>>>
>
>>>>> 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.
>>
>
>     Gyan> Understood.  My point here is the redundancy aspects similar to
> every domain having two BGP-LS producers but in this case we have to plane
> so having 2 producers per plane.  Also as you pointed out I think we should
> have verbiage to state that the choice of IPv4 or IPv6 peer has no impact
> on the topology information produced will be for both plane provided by the
> IPv4 peer providing the IPv4 and IPv6 plane topology graph  and IPv6 peer
> providing the as well the same IPv4 and IPV6 topology.
>

KT3> This is already covered in sec 5.5.


> I wonder in that case within a single domain you could have 1 peer on IPv4
> and 1 peer on IPv4 and not need 2 per plane and that is sufficient
> redundancy.  That should be spelled out as that is very common for
> operators migrating from SR-MPLS to SRv6 and having the dual plane setup.
>

KT3> There is no need for this document to refer to either SR-MPLS or SRv6
since they are not relevant here.


>
> New comment
>
> The purpose of the BGP-LS propagator is very confusing and I think we
> definitely need a diagram to lay out the topology and all the device roles.
>

KT3> That is what Figure 1 is for.


>
> BGP-LS consumer has decide RR1 and Rn
>
> BGP-LS producer has device RRm
>
> BGP-LS propagator
>

KT3> Sorry, but I do not understand the statements above.


> The BGP Speaker RRm propagates the BGP-LS
> information between the BGP Speaker Rn and the BGP Speaker RR1.
>
>
KT3> Yes


>
> So the BGP-LS propagator is the Route Reflector ?
>

KT3> Yes


>
> With BGP-LS it’s just one way propagation that the producers propagate
> BGP-LS state to the BGP-LS Consumer BGP implementation in scope so why
> would there be any propagation feedback to the BGP-LS producer PE nodes.
>

KT3> That is how BGP works. A policy can be created to prevent
advertisements from propagating to BGP speakers that may not be interested
in the information.

Thanks,
Ketan


>
> I think once the drawing is created that will help tremendously.
>
>>
>> Thanks,
>> Ketan
>>
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347*
>
>