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

[Gyan Mishra <[e-mail]>]

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

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

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

      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?


      Which node is RR1 and which is Rn and are they both 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.


      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


      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?


      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.

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

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.

BGP-LS consumer has decide RR1 and Rn

BGP-LS producer has device RRm

BGP-LS propagator

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


So the BGP-LS propagator is the Route Reflector ?

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.

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*