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

[John Scudder <[e-mail]>]

Hi All,

As a reminder, this adoption call ends this Friday.

As of now, I would be hard-pressed to say I saw consensus either for, or against. I’d once again like to encourage you to take up the question in two parts:

- Does the WG want to put work into fixing the problem, of sending version information to a peer? I think if the question were limited to that, the consensus would probably be “yes”.
- Does the WG like this approach? So far the responses I’ve seen divide into a “pragmatic” camp (it’s quick and easy, let’s just do it), and an “architectural” camp (let’s have a more general solution with fewer corner cases). I’m not sure it will be possible to reach consensus between these two views, but I don’t think we’ve tried very hard yet.

I have a lot of sympathy for keeping it simple, but as Einstein may or may not have said, “everything should be made as simple as possible… but no simpler”. We are asked to decide whether the current draft is “as simple as possible” or even simpler. From that point of view, if you think it’s too simplistic, it would be helpful for you to explain what specific harm its excessive simplicity causes, and what you’d prefer as a “simple as possible, but no simpler” alternative.

Thanks,

—John

> On Sep 8, 2020, at 3:11 PM, John Scudder <jgs=[e-mail]> wrote:
> 
> 
> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-abraitis-bgp-version-capability-08__;!!NEt6yMaO-gk!WoDk_v2eZvQXLUQzQJ6wuGJfnX3PrXgjTEuSzOrPZemMeRV2jticFxEkbOH_dg$ .
> 
> This begins the usual two-week discussion period. Please send your support, opposition, comments, discussion, before September 25.
> 
> The recent thread is here: https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/idr/q4pUI7jKnYEL_5Cr0mUfoHopY74/__;!!NEt6yMaO-gk!WoDk_v2eZvQXLUQzQJ6wuGJfnX3PrXgjTEuSzOrPZemMeRV2jticFxGnDkHeFQ$  and an earlier thread, when Donatas first brought the subject up on the list, is here: https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/idr/zHNioWl24mdTthQA0O4OatZ2uy4/__;!!NEt6yMaO-gk!WoDk_v2eZvQXLUQzQJ6wuGJfnX3PrXgjTEuSzOrPZemMeRV2jticFxG1g7uXDA$
> 
> 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