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

New version:
https://datatracker.ietf.org/doc/html/draft-abraitis-bgp-version-capability-11

TL;DR; Switched back to BGP Capability. Why? Because if the implementation
does not support BGP OPEN Optional Parameters, the session resets. Also,
added RFC9072 as a requirement to avoid exceeding 255 bytes of optional
parameters length.

On Tue, Jan 17, 2023 at 7:05 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> At the top of RFC 4271 section 4.5 this is what I am reading that if any
> open or update message with error sub code is received the session is
> reset.
>
> 4.5 <https://www.rfc-editor.org/rfc/rfc4271#section-4.5>.  NOTIFICATION Message Format
>
>    A NOTIFICATION message is sent when an error condition is detected.
>    The BGP connection is closed immediately after it is sent.
>
>
>
> That goes for all of the sub codes
>
>
> OPEN Message Error subcodes:
>
>                1 - Unsupported Version Number.
>                2 - Bad Peer AS.
>                3 - Bad BGP Identifier.
>                4 - Unsupported Optional Parameter.
>                5 - [Deprecated - see Appendix A <https://www.rfc-editor.org/rfc/rfc4271#appendix-A>].
>                6 - Unacceptable Hold Time.
>
>       UPDATE Message Error subcodes:
>
>                1 - Malformed Attribute List.
>                2 - Unrecognized Well-known Attribute.
>                3 - Missing Well-known Attribute.
>                4 - Attribute Flags Error.
>                5 - Attribute Length Error.
>                6 - Invalid ORIGIN Attribute.
>                7 - [Deprecated - see Appendix A <https://www.rfc-editor.org/rfc/rfc4271#appendix-A>].
>                8 - Invalid NEXT_HOP Attribute.
>                9 - Optional Attribute Error.
>               10 - Invalid Network Field.
>               11 - Malformed AS_PATH.
>
>
>
>
>
> On Mon, Jan 16, 2023 at 8:21 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>>
>> RFC 4271 section 4.5 states the session is reset for any open or update
>> notification code.
>>
>> RFC 7606 only updates error handling for update messages.  So the
>> unsupported version number will cause the peer to reset.
>>
>> Jakub mentioned this regarding the version capability draft which I agree
>> is a good option below:
>>
>> I can agree to using a new BGP OPEN Optional Parameter.
>>
>>
>>
>> I would add that if after receiving the OPEN message, the BGP neighbor
>> closes the session
>>
>> with “Unsupported Optional Parameters”, that the sender of that OPEN
>> message try
>>
>> opening the session again without the version parameter.
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Mon, Jan 16, 2023 at 1:54 PM Linda Dunbar <linda.dunbar@futurewei.com>
>> wrote:
>>
>>> 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 <hayabusagsm@gmail.com>
>>> *Sent:* Saturday, January 14, 2023 12:01 AM
>>> *To:* Linda Dunbar <linda.dunbar@futurewei.com>
>>> *Cc:* Robert Raszuk <robert@raszuk.net>; idr@ietf.org
>>> *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 <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%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 <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%7C877a543e7c434aeecc9d08daf5f4adb6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638092728500492184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=prCWQdJRG0gHXfMDlKGnqMLADRUCIhJsvpRA1Hr17zA%3D&reserved=0>
>>>
>>> --
>>>
>>>
>>> <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 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%7C877a543e7c434aeecc9d08daf5f4adb6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638092728500492184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=B5mXvFpqA4yiWAvx6Uszwt4T8ku5Wfud3feAGlawHuo%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%7C877a543e7c434aeecc9d08daf5f4adb6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638092728500492184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=B5mXvFpqA4yiWAvx6Uszwt4T8ku5Wfud3feAGlawHuo%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*
>>
>> --
>
> <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*
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

-- 
Donatas