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

[Ketan Talaulikar <[e-mail]>]

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*
>
>