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

From: John Scudder <[email-masked]>
Date: Tue, 8 Sep 2020 19:11:47 +0000

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

---

From: Randy Bush <[email-masked]>
Date: Tue, 08 Sep 2020 13:03:43 -0700

i think we have multiple flavors of signaling.  i am not sure there is a
crisp taxonomy, but some of the spaces could be describes as

  o hard core routing data, bgp classic

  o state signals, please chill out i am gonna sleep/restart/die

  o conditions, the circuit's bandwidth, color, delay, flavor

  o policies, prefix limits, code flavor, ...

and we're trying to squeeze them all into some funny containers, bgp
tlvs, capabilities, bgp-ls, ...; most of which were designed for other
purposes.

as you point out, draft-ietf-idr-operational-message is another
container which kinda tried to hold some of these.  it could certainly
deal with the proposal at hand.

but it sure would be nice if we had a little archetectural structure
and regularity here.

randy

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 9 Sep 2020 01:39:25 +0000

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 <[email-masked]> On Behalf Of John Scudder
Sent: Tuesday, September 8, 2020 12:12 PM
To: IDR List <[email-masked]>
Cc: Donatas Abraitis <[email-masked]>
Subject: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Hi All,

Thanks,

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

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 9 Sep 2020 09:22:34 +0100

> and version for each neighbor.

yeah, this would be useful.  Would there be value in splitting the host 
stack name from the version name?

Nick

---

From: Donatas Abraitis <[email-masked]>
Date: Wed, 9 Sep 2020 12:05:15 +0300

Would there be value in splitting the host stack name from the version name?

I'll just double-check: what do you mean host stack name in this context?

-- 

*Donatas Abraitis*
*Systems Engineer*
@: [email-masked]
W: www.hostinger.com

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 9 Sep 2020 10:29:14 +0100

> I'll just double-check: what do you mean host stack name in this context?

e.g. in the case of "FRRouting 7.2-dev-MyOwnFRRVersion-gc68bb14"

host stack: "FRRouting"
version: "7.2-dev-MyOwnFRRVersion-gc68bb14"

Nick

---

From: tom petch <[email-masked]>
Date: Wed, 9 Sep 2020 10:19:36 +0000

From: Idr <[email-masked]> on behalf of Nick Hilliard <[email-masked]>
Sent: 09 September 2020 09:22

<tp>
and then do we want a FCFS register of host stack name to try and reduce the minor quirks that people introduce when referring to a host?  It would increase the cost but also add value IMHO.
In a similar vein, should there be guidelines on version?  The NETMOD WG is wading into this minefield with draft-ietf-netmod-yang-module-versioning which seeks to nail down revisions with a precision that I think will be too much effort ever to be kept up-to-date but again some guidelines could add value.

SMI I found good at this but NETMOD does not seem to have kept it up.

Either way, this should be an object in the BGP YANG model at some point.

In passing, IANA Considerations are not quite right.  The Capability Codes registry is in the BGP Parameters Group.

Tom Petch
Nick

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 9 Sep 2020 16:00:10 +0100

tom petch wrote on 09/09/2020 11:19:
> and then do we want a FCFS register of host stack name to try and
> reduce the minor quirks that people introduce when referring to a
> host?

I like the idea, but not where it leads to.  E.g. how would you handle 
foundry -> brocade -> {extreme,ruckus}?  Also brand identity tends to be 
owned by marketing departments, and I'm not sure that opening a registry 
up like this to the whims of a marketing department would do anyone's 
sanity any good. E.g. "JunOS", "JUNOS", "Junos OS", "junOS" - which one 
is it?  Or would it make any sense to refer to TimOS when that name was 
externally retired years ago, even if it's still visible internally?

Nick

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 9 Sep 2020 15:32:21 +0000

No.

This is a simple feature to allow an operator to get a quick idea
with "show bgp neighbors" what he is looking at.
Let's not boil this too much.

Regards,
Jakob.

-----Original Message-----
From: Nick Hilliard <[email-masked]> 
Sent: Wednesday, September 9, 2020 1:23 AM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: John Scudder <[email-masked]>; IDR List <[email-masked]>; Donatas Abraitis <[email-masked]>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Nick

---

From: john heasley <[email-masked]>
Date: Wed, 9 Sep 2020 17:02:29 +0000

> stack name from the version name?

was randy suggesting that this is unnecessary, that such a message could
instead be placed in BGP SMS^Wrfc8203?

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 9 Sep 2020 19:15:40 +0200

Jakob,

I know you love simple features easy to implement. We all to pick like low
hanging fruits.

But I support Randy in his opinion expressed on this thread that we should
look at the bigger picture here instead of troughing ASCII or UTF strings
at random places into current BGP protocol just because this is "easy to
do".

Thx,
R.

On Wed, Sep 9, 2020 at 5:32 PM Jakob Heitz (jheitz) <jheitz=
[email-masked]> wrote:

> Cc: John Scudder <[email-masked]>; IDR List <[email-masked]>; Donatas
> Abraitis <[email-masked]>
> Subject: Re: [Idr] WG adoption call for
> draft-abraitis-bgp-version-capability-08, to end September 25
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 09 Sep 2020 10:20:44 -0700

> instead be placed in BGP SMS^Wrfc8203?

dns!

---

From: Donatas Abraitis <[email-masked]>
Date: Wed, 9 Sep 2020 20:28:27 +0300

Robert, I fully understand you, but these times BGP is used not in telcos mainly. 

 It's happening in services. Even MySQL HA can be achieved with help of BGP protocol. 

Kubernetes, Openshift, containers, etc., changed a shape how processes are running these days actually. But that's not about that.

Imagine a cluster of 1000 containers each running a specific version of BGP daemon. With such setup I would need another 1000 containers running lldpd and exposing information about the versions. Even this won't work because of network namespaces.

Implementing huge rfcs take time, and this is very trivial to implement for any existing daemons. I'm not referring big vendors here, but more about software vendors.

Sent from my iPhone

> On 2020-09-09, at 20:16, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Jakob,
> 
> I know you love simple features easy to implement. We all to pick like low hanging fruits. 
> 
> But I support Randy in his opinion expressed on this thread that we should look at the bigger picture here instead of troughing ASCII or UTF strings at random places into current BGP protocol just because this is "easy to do". 
> 
> Thx,
> R.
> 
> 
> 
> 
> 
> 
> 
> 
>> On Wed, Sep 9, 2020 at 5:32 PM Jakob Heitz (jheitz) <jheitz=[email-masked]> wrote:
>> No.
>>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 9 Sep 2020 17:41:21 +0000

Yeah, because I actually have to implement them.
And if the value/effort ratio is too low, it won't get done.

Regards,
Jakob.

From: Robert Raszuk <[email-masked]>
Sent: Wednesday, September 9, 2020 10:16 AM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: Nick Hilliard <[email-masked]>; Donatas Abraitis <[email-masked]>; IDR List <[email-masked]>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Jakob,

Thx,
R.

On Wed, Sep 9, 2020 at 5:32 PM Jakob Heitz (jheitz) <jheitz=[email-masked]<mailto:[email-masked]>> wrote:
No.

Regards,
Jakob.

-----Original Message-----
From: Nick Hilliard <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 9, 2020 1:23 AM
To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>
Cc: John Scudder <[email-masked]<mailto:[email-masked]>>; IDR List <[email-masked]<mailto:[email-masked]>>; Donatas Abraitis <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Nick
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: John Scudder <[email-masked]>
Date: Wed, 9 Sep 2020 17:51:10 +0000

(Individual contributor hat)

On Sep 9, 2020, at 1:02 PM, john heasley <[email-masked]<mailto:[email-masked]>> wrote:

It doesn’t fit in RFC 8203, that sits inside the NOTIFICATION message and is inherently destructive to the session. It’s sort of morally related, since both of them just bung a string into the message.

—John

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 9 Sep 2020 20:19:08 +0200

> these times BGP is used not in telcos mainly.

Great ! Thanks for this valuable insight.

Well last time I checked BGP is rather needed for the Internet. And this is
major focus here to keep The Internet running.

If we start throwing one off stones into it - it can still hold ... till
the time when it no longer can. And then what ? Do we have backoff plan ?
What if someone takes 128 bytes of capabilities tomorrow ?

I proposed splitting BGP into telco/Internet BGP and all other use cases
many year ago. All you enumerated fit perfectly into the latter.

- - -

Donatas,

Said all of the above - I do like your suggestion to augment BGP with this
extra information. It may be useful. I would actually still like to know
who is behind an RR as far as BGP implementation is concerned though.

What if we define new message (we can call it operational message) and for
now just have one TLV there carrying OS version of BGP between connected
peers ?

What do you think ? Would you add this to FRR ?

Many thx,
Robert.

On Wed, Sep 9, 2020 at 7:28 PM Donatas Abraitis <
[email-masked]> wrote:

> Kubernetes, Openshift, containers, etc., changed a shape how processes are
> running these days actually. But that's not about that.
>
> Imagine a cluster of 1000 containers each running a specific version of
> BGP daemon. With such setup I would need another 1000 containers running
> lldpd and exposing information about the versions. Even this won't work
> because of network namespaces.
>
> Implementing huge rfcs take time, and this is very trivial to implement
> for any existing daemons. I'm not referring big vendors here, but more
> about software vendors.
>
>
> Sent from my iPhone
>

---

From: John Scudder <[email-masked]>
Date: Wed, 9 Sep 2020 19:04:45 +0000

(Co-chair hat)

On Sep 9, 2020, at 2:19 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Well last time I checked BGP is rather needed for the Internet. And this is major focus here to keep The Internet running.

I just went and checked our charter, because I was convinced that this point was explicitly part of it. It’s not. "The main objective of the working group is to support the use of BGP-4 by IP version 4 and IP version 6 networks.”

Nonetheless, I think it would be hard to find someone who thinks it’s OK to break the Internet. I don’t think evidence has been presented that this proposal would do that, but it’s completely fair to ask that the question be thought through.

—John

---

From: EXT - heas <[email-masked]>
Date: Wed, 9 Sep 2020 22:04:45 +0000

> It doesn’t fit in RFC 8203, that sits inside the NOTIFICATION message and is inherently destructive to the session. It’s sort of morally related, since both of them just bung a string into the mess…

Ach, I forgot that this was tied to the notification subcode.  shame it could not
be shared.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 Sep 2020 00:53:04 +0200

John,

Just to clarify one important point. I am not stating that this extension
will break BGP today.

However I am stating that Tragedy of Commons is not an imaginary paradigm
but real danger. It is not this extension which I would be afraid of to add
into BGP capabilities. It is the number of extensions like this one
acting together (which IDR may never observe if we take extension by
extension approach) which may lead to making the Internet weaker.

Any way I am not against this add on - in fact I think it has some limited
use case (like described by author to find which LXCs demons are talking
from compute to my BGP TOR), but let's just please package it nicely.

For example would putting this in large community along with lXC next hop
as a prefix would not be sufficient ? Sounds pretty harmless to me yet will
serve the intended purpose.

Best,
R.

On Wed, Sep 9, 2020 at 9:04 PM John Scudder <[email-masked]> wrote:

> (Co-chair hat)
>
> On Sep 9, 2020, at 2:19 PM, Robert Raszuk <[email-masked]> wrote:
>
> Well last time I checked BGP is rather needed for the Internet. And this
> is major focus here to keep The Internet running.
>
>
> I just went and checked our charter, because I was convinced that this
> point was explicitly part of it. It’s not. "The main objective of the
> working group is to support the use of BGP-4 by IP version 4 and IP version
> 6 networks.”
>
> Nonetheless, I think it would be hard to find someone who thinks it’s OK
> to break the Internet. I don’t think evidence has been presented that this
> proposal would do that, but it’s completely fair to ask that the question
> be thought through.
>
> —John
>

---

From: tom petch <[email-masked]>
Date: Thu, 10 Sep 2020 09:34:11 +0000

From: Idr <[email-masked]> on behalf of John Scudder <jgs=[email-masked]>
Sent: 09 September 2020 20:04

(Co-chair hat)

<tp>
A charter that calls for us to produce a MIB-2 for BGP4, no mention of a YANG model:-)

I think that since that charter was written much has been added to BGP and, like Robert, I have a concern that one day we may add the straw that breaks the camel's back.  When the WG was asked, some time ago, whether or not yet another feature should be added to BGP, I was against it, for that reason, but in the rough.  Many, if not most problems, come from change and while most changes are fault-free, there is always a slight risk in adding something that this one will not be.  I see it as benefit versus risk and am ambivalent about this; some benefit, some risk.

But when Alvaro reviewed this for the IESG as an ISE submission, I got the sense that the IESG would not hinder publication so I expect to see this being published, hopefully without mishap, whether or not the IDR WG agrees.  Adoption means more review so I suppose adoption is a good thing.

Tom Petch

—John

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 11 Sep 2020 02:10:53 +0000

Hi, 

Here are some comments from my side:

1. I agree with Randy and Robert to take a look at this feature from a more structural point of view.

2. It says “the capability is designed more to non-production environments...”. Does this imply it will not be seen in production networks? If so, perhaps the capability code reserved for experimental use would be sufficient?

3. It mentions LLDP etc. can provide this information, while information exchange between different processes is hard not recommended in some environments. Currently this WG has a design team on BGP autoconf , in which we are exploring the possibility of using some other protocol to facilitate the setup of BGP peering. This presumption may be related to the BGP autoconf discussion. 

Best regards,
Jie

> From: Idr [mailto:[email-masked]] On Behalf Of John Scudder
> Sent: Wednesday, September 9, 2020 3:12 AM
> 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-0
> 8.
> 
> 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/zHNioWl24mdTthQA0O4OatZ2uy
> 4/
> 
> 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.
>

---

From: John Scudder <[email-masked]>
Date: Wed, 23 Sep 2020 19:04:14 +0000

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=[email-masked]> 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$ .
> 
> 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$
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 23 Sep 2020 21:59:47 +0200

Hi John,

> - 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”.
>

Even that question is a bit loaded IMO

Say yes maybe I see the value of sending this between 100s of virtual peers
and a TOR. But is BGP main used this application ?

On the other hand I see limited value to just send it between client and RR
... I would rather like to see passed between clients.

> - 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.
>

Frankly I have not seen much support except from Jakob for encoding it in
capabilities. And that support comes mainly from the fact that "it is easy
to do".

Thx.
R.

PS1. And on the other hand if it is not adopted here it will likely get
published as an RFC anyway in the ISE track. So honestly I have no idea
what's best for BGP. If it would be my call in such a situation I would
perhaps recommend to adopt it and repackage in a different encoding
envelope. But who will work on it if authors would not be interested to
change the draft once it becomes a WG doc ?

PS2. Assume this goes on as ISE RFC. And perhaps magic happens and IDR
defines a different encoding for exactly the same information down the
road. Would IDR or GROW have power to move ISE RFC to historic or obsolete
status at that point ?

> 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
>
> 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.
> >
> 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
> 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.
> >

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 23 Sep 2020 22:18:07 +0000

I support it, because it provides value.

I can see it actually getting done (and not wasting everyone's time), because it's easy to do.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Wednesday, September 23, 2020 1:00 PM
To: John Scudder <jgs=[email-masked]>
Cc: IDR List <[email-masked]>; Donatas Abraitis <[email-masked]>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Frankly I have not seen much support except from Jakob for encoding it in capabilities. And that support comes mainly from the fact that "it is easy to do".

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 24 Sep 2020 00:24:32 +0200

Hey Jakob,

I never said this does not provide value.

But there is much more operational messages which I hope many will agree
that they also provide value.

With that said do you want to put all of this into capabilities, just
because it is easy to do ?

Cheers,
R.

On Thu, Sep 24, 2020 at 12:18 AM Jakob Heitz (jheitz) <[email-masked]>
wrote:

> *From:* Idr <[email-masked]> *On Behalf Of * Robert Raszuk
> *Sent:* Wednesday, September 23, 2020 1:00 PM
> *To:* John Scudder <jgs=[email-masked]>
> *Cc:* IDR List <[email-masked]>; Donatas Abraitis <
> [email-masked]>
> *Subject:* Re: [Idr] WG adoption call for

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 23 Sep 2020 22:50:23 +0000

Robert,

I don't remember, why did the operational message not move forward?

Regards,
Jakob.

From: Robert Raszuk <[email-masked]>
Sent: Wednesday, September 23, 2020 3:25 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: John Scudder <jgs=[email-masked]>; IDR List <[email-masked]>; Donatas Abraitis <[email-masked]>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Hey Jakob,

But there is much more operational messages which I hope many will agree that they also provide value.

With that said do you want to put all of this into capabilities, just because it is easy to do ?

Cheers,
R.

On Thu, Sep 24, 2020 at 12:18 AM Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
I support it, because it provides value.

Regards,
Jakob.

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Wednesday, September 23, 2020 1:00 PM
To: John Scudder <jgs=[email-masked]<mailto:[email-masked]>>
Cc: IDR List <[email-masked]<mailto:[email-masked]>>; Donatas Abraitis <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 24 Sep 2020 00:54:41 +0200

Hi Jakob,

It was getting very good community support. Just lack of implementations by
vendors as required by IDR to progress it.

Willing to hello with that one from yr side ?

Thx,
R.

On Thu, Sep 24, 2020 at 12:50 AM Jakob Heitz (jheitz) <[email-masked]>
wrote:

> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Wednesday, September 23, 2020 3:25 PM
> *To:* Jakob Heitz (jheitz) <[email-masked]>
> *Cc:* John Scudder <jgs=[email-masked]>; IDR List <
> [email-masked]>; Donatas Abraitis <[email-masked]>
> *From:* Idr <[email-masked]> *On Behalf Of *Robert Raszuk

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 24 Sep 2020 00:19:14 +0000

I just took a look at it.
It was 8 years ago, before my time at Cisco.
It is a muddle of TLVs and I so hate coding up endless sets of TLVs. and then debugging them.
The world has moved on. Can we use a layer 6 protocol, like JSON or google protobufs now?
Also, it has request/reply messages. That's no longer operational messages.
That makes it a protocol. It makes the receiving party do work.
BGP is used to message between devices belonging to different entities.
Entities do not like doing free work for other entities.

If we were to reincarnate operational messages, could we modernize it and remove the request/reply?

Regards,
Jakob.

Sent: Wednesday, September 23, 2020 3:55 PM

Hi Jakob,

It was getting very good community support. Just lack of implementations by vendors as required by IDR to progress it.

Thx,
R.

On Thu, Sep 24, 2020 at 12:50 AM Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Regards,
Jakob.

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 23, 2020 3:25 PM
To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>
Cc: John Scudder <jgs=[email-masked]<mailto:[email-masked]>>; IDR List <[email-masked]<mailto:[email-masked]>>; Donatas Abraitis <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Hey Jakob,

Cheers,
R.

Regards,
Jakob.

---

From: John Scudder <[email-masked]>
Date: Thu, 24 Sep 2020 18:25:31 +0000

On Sep 23, 2020, at 3:59 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

PS1. And on the other hand if it is not adopted here it will likely get published as an RFC anyway in the ISE track. So honestly I have no idea what's best for BGP. If it would be my call

It is your call — well, what I mean is that this is exactly the kind of issue that should be discussed during this adoption call. So thanks for bringing it up.

in such a situation I would perhaps recommend to adopt it and repackage in a different encoding envelope.

That’s certainly an option that can be on the table, and if others are interested in the same way forward, they should follow up. It would probably help to discuss what that “different encoding envelope” might be, at least in general terms.

But who will work on it if authors would not be interested to change the draft once it becomes a WG doc ?

Indeed that’s a key question. For that matter it is for every draft we adopt: not only “do you think it’s a good idea” but “are you willing to put effort into it” (including contributing, reviewing, etc). I think it’s a good idea that everyone should have a pony, but I’m not willing to put effort into it :-).

But, in this case it seems like the ’not be interested’ part is getting a little ahead of ourselves. Donatas is in the cc after all, we shouldn’t need to speculate about his preferences. Donatas, as the author, what’s your reaction to Robert’s proposal? (It is OK to say “I would need to know something more specific an just ‘different encoding envelope’.”)

PS2. Assume this goes on as ISE RFC. And perhaps magic happens and IDR defines a different encoding for exactly the same information down the road. Would IDR or GROW have power to move ISE RFC to historic or obsolete status at that point ?

My guess is that the answer is “no”. Historic is — as far as I know — a designation specific to the IETF standards process. The ISE is — as far as I understand it — not part of the IETF standards process. Figure 1 of RFC 6635, "RFC Editor Model”, seems to confirm this. I’ll see if I can get an authoritative answer.

—John

---

From: Donatas Abraitis <[email-masked]>
Date: Thu, 24 Sep 2020 21:40:22 +0300

Hello, guys,

>> But who will work on it if authors would not be interested to change the draft once it becomes a WG doc ? 
Not sure, what is "change the draft" in this context, but I'm ready to do changes if needed.

Sent from my iPhone

> On 2020-09-24, at 21:25, John Scudder <[email-masked]> wrote:
> 
>  On Sep 23, 2020, at 3:59 PM, Robert Raszuk <[email-masked]> wrote:
>>

---

From: John Scudder <[email-masked]>
Date: Thu, 24 Sep 2020 18:50:18 +0000

On Sep 24, 2020, at 2:25 PM, John Scudder <[email-masked]<mailto:[email-masked]>> wrote:

I checked with Adrian (the ISE Editor) and the practical answer is “yes”, as long as the AD and the ISE Editor can come to agreement (which I hope they generally would).

—John

---

From: John Scudder <[email-masked]>
Date: Thu, 24 Sep 2020 18:52:42 +0000

Hi Donatas,

On Sep 24, 2020, at 2:40 PM, Donatas Abraitis <[email-masked]<mailto:[email-masked]>> wrote:

I hope Robert will provide his own elaboration, but from context what I think he meant is something along the lines of “maybe the transport for the information doesn’t end up being a Capability, but <foo>”. As far as I know the one concrete suggestion for <foo> so far has been the proposed (but never implemented) Operational message.

Thanks,

—John

---

From: Randy Bush <[email-masked]>
Date: Thu, 24 Sep 2020 12:44:41 -0700

> I hope Robert will provide his own elaboration, but from context what
> I think he meant is something along the lines of “maybe the transport
> for the information doesn’t end up being a Capability, but <foo>”.

and we could try to organize the philosophy (he said, trying to avoid
the term 'architicture') of which of the half dozen hack transports
are used for what kind of purpose.

randy

---

From: John Scudder <[email-masked]>
Date: Mon, 28 Sep 2020 18:18:21 +0000

Hi Folks,

It seems to me that the discussion hasn’t concluded and we are still having productive discussion. Hence, I would like to extend the period for discussion by another week, now to conclude on October 2.

Thanks,

—John

> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!WoDk_v2eZvQXLUQzQJ6wuGJfnX3PrXgjTEuSzOrPZemMeRV2jticFxHntHgWMA$