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

[Gyan Mishra <[e-mail]>]

Hi Ketan

You are very welcome!

One final suggestion related to the use of RR versus the variety of ways
you can setup the BGP-LS AFI/SAFI peering to collect the link state from
the BGP-LS producer PEs, and BGP-LS can be very memory and CPU intensive
with messaging on the RR.  My thoughts are maybe a sentence on an possible
optimization  is to decouple the BGP-LS producer function off the RR and
put it on a dedicated stub RS separate AS eBGP multihop loop to loop
peering to two producers per core AS.  This way there heavy processing
overhead does not impact the production RRs.

In Figure 1 it shows BGP-LS producer with peering directly to BGP-LS
consumer application.  Is that in cases where an RR is not utilized?  If so
maybe some wording to explain that direct peering to BGP-LS consumer.

Many Thanks

Gyan

On Fri, Nov 18, 2022 at 7:54 AM Ketan Talaulikar <[e-mail]>
wrote:

> Hi Gyan,
>
> Thanks for your suggestions and the discussion. I've posted an update with
> the changes as discussed:
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc7752bis-14
>
> Thanks
> Ketan
>
>
> On Fri, Nov 18, 2022 at 6:44 AM Gyan Mishra <[e-mail]> wrote:
>
>>
>> Hi Ketan
>>
>> See in-line Gyan3
>>
>> I am all set.  The document is ready for publication.
>>
>> Excellent work!
>>
>> Gyan
>>
>> On Thu, Nov 17, 2022 at 10:00 AM Ketan Talaulikar <[e-mail]>
>> wrote:
>>
>>> 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.
>>>
>>
>>     Gyan3> Yes it addresses all set here
>>
>>>
>>>
>>>
>>>>   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.
>>>
>>>
>>      Gyan3> Understood
>>
>>>
>>>>
>>>> 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.
>>>
>>>
>>     Gyan> Understood
>>
>>>
>>>>       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.
>>>
>>>
>>     Gyan3>That’s what I thought
>>
>>>
>>>>       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).
>>>
>>
>>    Gyan3> Got it.  All set
>>
>>>
>>>
>>>>
>>>>       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.
>>>
>>>
>>     Gyan3> Got it now thanks
>>
>>>
>>>>       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.
>>>
>>>
>>     Gyan3> Understood.
>>
>>>
>>>> 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.
>>>
>>>
>>     Gyan> Understood
>>
>>> 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.
>>>
>>>
>>     Gyan> Understood
>>
>>>
>>>> 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.
>>>
>>>
>>     Gyan> In the diagram is it possible to label the role names
>>
>>>
>>>> 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.
>>>
>>
>>     Gyan> I was trying to map the node name to role name  - if you can
>> add the roles to figure 1 would help
>>
>>>
>>>
>>>
>>>> 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*
>>>>
>>>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email [e-mail] <[e-mail]>*
>>
>>
>>
>> *M 301 502-1347*
>>
>> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*