Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

[Gyan Mishra <[e-mail]>]

So I think the crux of the issue is with so many open BGP flavors and
versions and running into possibilities of feature support issues, I think
it would be very helpful to be able to see the compute nodes bgp version
from the TOR for troubleshooting.  In case their are known bugs with
certain versions.

So if you were able to do a “show BGP summary” and are able to see the
versions would be helpful.

Kind Regards

Gyan

On Thu, Jan 12, 2023 at 12:07 PM Robert Raszuk <[e-mail]> wrote:

> Gyan,
>
> > I can see a lot of value in this draft
>
> So imagine you are a TOR.
>
> Could you provide some examples on what would you do differently to
> compute
> nodes speaking to you from BIRD BGP vs from exaBGP vs home grown
> Python BGP ?
>
> Many thx,
> R.
>
>
>
>
>
>
>
> On Thu, Jan 12, 2023 at 5:53 PM Gyan Mishra <[e-mail]> wrote:
>
>>
>> I support the draft and agree this is very useful for cloud native
>> environments.
>>
>> I think the main use of this feature is for DC fabric extension to
>> compute nodes and now as well Kubernetes microservices cloud native
>> containerization or router in a container.
>>
>> Just about every router vendor and ONF disaggregation vendor has a
>> container version of router such as Cisco’s XRD, Juniper cRPD, SONiC,
>> Nokia, Arista etc which gives you both control plane and data plane to
>> front and provide CNI networking for K8 Kubernetes microservices.
>>
>> As well as you have all the Open BGP versions FRR, BIRD, Quagga, ExaBGP
>> etc that  give you the BGP control plane to advertise routes using Linux
>> data plane.
>>
>> https://containerlab.dev/manual/kinds/
>>
>> So this version feature is really for cloud native compute layer NFV -
>> VNF, CNF,  and not really for PNF  physical hardware based internet routers
>> or switches.
>>
>> I can see a lot of value in this draft and I support making a WG document
>> versus independent stream based on the massive proliferation of distributed
>> cloud native edge computing software based environments.
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Wed, Jan 11, 2023 at 2:20 PM Robert Raszuk <[e-mail]> wrote:
>>
>>>
>>> > a feature that is useful from an operational standpoint
>>>
>>> So let's put all the encoding aside. Your email made me curious why
>>> router A needs to know BGP release number, OS version and vendor name of
>>> router B ?
>>>
>>> Are we doing such a bad job in IDR that BGP no longer interoperates at
>>> the protocol level ?
>>>
>>> The original problem was presented as 1000s of computes reporting their
>>> BGP versions to TORs. But those 1000s of computes are already managed by
>>> orchestration which does have this information. Why should BGP TOR care ?
>>>
>>> Or why IXP Route Server should care that customer X is connecting with
>>> Junos vs with Huawei vs with Arrcus to it or to other IX fabric members ?
>>>
>>> Kind regards,
>>> R.
>>>
>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>> --
>>
>> <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*