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

[Linda Dunbar <[e-mail]>]

Gyan,

RFC4271 states that if the version number is not supported, an error message should be sent. But RFC4271 didn't say if the BGP Open session should be failed.
I am just curious if BGP session can be started even if the  version number is not supported?

Linda

From: Gyan Mishra <[e-mail]>
Sent: Saturday, January 14, 2023 12:01 AM
To: Linda Dunbar <[e-mail]>
Cc: Robert Raszuk <[e-mail]>; [e-mail]
Subject: 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Gyan Mishra
Sent: Thursday, January 12, 2023 3:15 PM
To: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[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]<mailto:[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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcontainerlab.dev%2Fmanual%2Fkinds%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C877a543e7c434aeecc9d08daf5f4adb6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638092728500492184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nOLWrbrNMQILNzVFclXgLiQZ4LQY8iUpJsOdqKozTQ8%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 <[e-mail]<mailto:[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]<mailto:[e-mail]>
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%7C877a543e7c434aeecc9d08daf5f4adb6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638092728500492184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=prCWQdJRG0gHXfMDlKGnqMLADRUCIhJsvpRA1Hr17zA%3D&reserved=0>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C877a543e7c434aeecc9d08daf5f4adb6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638092728500492184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=B5mXvFpqA4yiWAvx6Uszwt4T8ku5Wfud3feAGlawHuo%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C877a543e7c434aeecc9d08daf5f4adb6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638092728500492184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=B5mXvFpqA4yiWAvx6Uszwt4T8ku5Wfud3feAGlawHuo%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C877a543e7c434aeecc9d08daf5f4adb6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638092728500492184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=B5mXvFpqA4yiWAvx6Uszwt4T8ku5Wfud3feAGlawHuo%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347