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

[Gyan Mishra <[e-mail]>]

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*