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

Hi Linda

Yes, RFC 7606 provides complete revision of error handling as opposed to
peer reset which was the error handling with RFC 4271.

See section 2 and 3.

All BGP implementations including Open BGP implementations should support
RFC 7606.

The main benefit for the versioning is in case the BGP peer capabilities
exchange is in a one way state and not bidirectional and in that case
having the version number would help troubleshoot if the AFI/SAFi,
code-point or parameter is supported or not.

Kind Regards

Gyan

On Fri, Jan 13, 2023 at 4:52 PM Linda Dunbar <linda.dunbar@futurewei.com>
wrote:

> With so many BGP flavors and versions, is it possible to configure a
> router to ignore the capabilities that it doesn’t support? But still keep
> the BGP session going?
>
>
>
> Linda
>
>
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of * Gyan Mishra
> *Sent:* Thursday, January 12, 2023 3:15 PM
> *To:* Robert Raszuk <robert@raszuk.net>
> *Cc:* idr@ietf.org
> *Subject:* Re: [Idr] WG adoption call for
> draft-abraitis-bgp-version-capability-08, to end September 25
>
>
>
>
>
> 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 <robert@raszuk.net> 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 <hayabusagsm@gmail.com> 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/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcontainerlab.dev%2Fmanual%2Fkinds%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cac89172b3bb141f93de808daf4e219c0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638091549180793698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VQTChAf2m6dsTnGf7yiFL8Huny9um%2BJ5fwfS29EnbbU%3D&reserved=0>
>
>
>
> 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 <robert@raszuk.net> 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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cac89172b3bb141f93de808daf4e219c0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638091549180793698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0fV62p6me7FjTEJLn177SqCIbYJbAQx1ma3ejtZy9b4%3D&reserved=0>
>
> --
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cac89172b3bb141f93de808daf4e219c0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638091549180949897%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nCMguZkcKwDcfO4Q7TZxk3lHGuqMUPvKMwqfhmqNGPk%3D&reserved=0>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> --
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cac89172b3bb141f93de808daf4e219c0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638091549180949897%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nCMguZkcKwDcfO4Q7TZxk3lHGuqMUPvKMwqfhmqNGPk%3D&reserved=0>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*