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

["Jakob Heitz (jheitz)" <[e-mail]>]

I support this draft.
You reserve a capability code, so the document should be standards track.

To address other comments:

It is quite correct that it is better to use an NMS to get the full network
picture and precise versions of every router including all its software
patches.

With some routers, if you wanted to put the full vendor and version name
and list of patches, you would overflow the capabilities length with
just this capability alone. So, put a sensibly shortened version.

Capabilities length is known at configuration time, before the BGP session
even comes up. It is trivial to reject a configuration if it is determined
to cause a capabilities overflow.

With ISSU, it is possible to upgrade the BGP software version without
bouncing the session.

Of course, if this capability is on by default, there are security/privacy
concerns. So don't send it by default.

Nevertheless, even with all these possible issues, I think it would
be super handy to run "show bgp neighbors" and see the software vendor
and version for each neighbor.

This draft does not harm anyone and is not difficult to code up.

Regards,
Jakob.

-----Original Message-----
From: Idr <[e-mail]> On Behalf Of John Scudder
Sent: Tuesday, September 8, 2020 12:12 PM
To: IDR List <[e-mail]>
Cc: Donatas Abraitis <[e-mail]>
Subject: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Hi All,

You may recall that we had a recent discussion about draft-abraitis-bgp-version-capability-07, which was on the ISE track. After some discussion both on and off list, the author has updated the document and requested WG adoption of https://datatracker.ietf.org/doc/html/draft-abraitis-bgp-version-capability-08.

This begins the usual two-week discussion period. Please send your support, opposition, comments, discussion, before September 25. 

The recent thread is here: https://mailarchive.ietf.org/arch/msg/idr/q4pUI7jKnYEL_5Cr0mUfoHopY74/ and an earlier thread, when Donatas first brought the subject up on the list, is here: https://mailarchive.ietf.org/arch/msg/idr/zHNioWl24mdTthQA0O4OatZ2uy4/

It’s my impression from these two threads that there’s potentially interest from the WG in tackling the problem; it’s less clear to me that the WG supports the particular design outlined in the current draft. It would be helpful if you’d address both of these when commenting, and keep in mind that as usual WG adoption of the draft wouldn't mean “this is the exact solution”, it would mean “this is a good starting point.” Finally, as a result of the recent discussion, there’s been some renewed interest in draft-ietf-idr-operational-message. One suggestion (which I can’t put my finger on in the archives right now, sorry) was to turn draft-ietf-idr-operational-message into a pure framework document, i.e. define no TLVs in it, just the transport. If done, IMO that might open the door to more easily allowing a draft like the present one to adopt it as a transport.

The floor is open for your comments!

Thanks,

—John
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr