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

From: Donatas Abraitis <[email-masked]>
Date: Mon, 26 Oct 2020 15:31:46 +0200

So, as I understand, we can forget this idea, right?

On Mon, Sep 28, 2020 at 9:18 PM John Scudder <[email-masked]> wrote:

> 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
>
> > 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$
> .
> >
> > 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
> > _______________________________________________
> > Idr mailing list
> > [email-masked]
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!WoDk_v2eZvQXLUQzQJ6wuGJfnX3PrXgjTEuSzOrPZemMeRV2jticFxHntHgWMA$
>
>

-- 

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

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 28 Oct 2020 17:53:14 -0400

Adding in a comment as I clear my backlog:

On Mon, Sep 28, 2020 at 06:18:21PM +0000, John Scudder wrote:
> 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.

I have general concerns about this feature.  But let me offer related
observations why my opinion is "not a fan, but of potential use":

- This capability is advertised prior to session establishment.  
  RFC 8203 got a bit of jutification for putting in text during a
  NOTIFICATION where the session is going down anyway.  Having this at
  session start means less chance for damange than if we're exchanging stuff a
  bit more interactively in something like the operational message.
- I think requiring extended optional params is a good idea for this.  It
  mitigates the necessity for having to do do the math to squeeze stuff in
  or not.

I would qualify the feature as "mostly harmless" and "useful in some
circumstancs".  Use in BGP fabrics is one I find a compelling use case.

I'm strongly supportive of the concerns with using this feature for general
ISP eBGP use cases.  I will, however, offer the related observation that an
ISP may like knowing what version of software their customers are running.
It may ease situations where service providers may want to signal a customer
to upgrade a vulnerable stack.

Consider me weakly supportive of adoption and fast WGLC.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 29 Oct 2020 09:22:29 +0100

>   mitigates the necessity for having to do do the math to squeeze stuff in

How about we would just carry a fixed size URL reference to this
effectively static and opaque to the bgp protocol information instead of
actual text string ?

IMO anything which is static and is not needed for protocol operations,
best path selection etc ... should be passed as a pointer.

Fetching such string could be done in spare CPU times well before need to
locally present it or at the run time when someone executes a show cmd or
other form of query api.

Note that till one day dynamic capabilities are in place - the above would
also cover ISSU/NSR where one would like to do software upgrade without BGP
session reset.

Thx,
R.

On Wed, Oct 28, 2020 at 10:38 PM Jeffrey Haas <[email-masked]> wrote:

> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 29 Oct 2020 07:33:16 -0400

Robert,

> effectively static and opaque to the bgp protocol information instead of

I think this is problematic in a few senses:
- Sure, you could take this idea to the extreme that we'll just have a
  single four-byte field with a FCFS registry that everyone uses and has
  private space for a local registry.  And people would hate that.  You're
  devolving to pre-registration for something that may change frequently.
- Sure, you could just reserve char version[64] in the structure, but domain
  names may vary in length.  And when you move to punycode i18n domains,
  this could be even messier.  See prior issues with RFC 8203.
- I strongly expect that some operators will want to stick in their own
  strings here.  "Role" potentially in combination with "version".

> locally present it or at the run time when someone executes a show cmd or

Which is really a lot of typing to say "we're not exchanging this out of
band ... why?"  Which is still a legitimate argument.  It's why I think the
use case, although slightly helpful, has a lot of weaknesses.  

The one slight boost I give the core use case that we're regularly seeing in
data center cases is protocol stacks are being spun up with very little
additional components. This provides a push to consolidate channels for
sending critical information.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 29 Oct 2020 12:31:16 +0100

Just to clarify one point ... I was not seeing a need to use domain names.
Just either IP address of bgp peer or implicitely use bgp peer's address.

https url would be actually pretty short ... just the path to the opaque
text.

I am more interesting on your view of how to do NSR/ISSU with current
proposal.

Cheers,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 29 Oct 2020 08:25:00 -0400

> Just to clarify one point ... I was not seeing a need to use domain names.

You did type URL, which generally implies a domain name. 

> https url would be actually pretty short ... just the path to the opaque

Taking this one step further into some of the discussions I'd had with
people such as Elliot Lear, this likely ties a bit more into proposals for
pointing to software manifests for products.  A URL would be sufficient -
and quite possibly not what some people would want to use this feature for.

> I am more interesting on your view of how to do NSR/ISSU with current

I don't pretend that it solves this problem.  It's not my feature. :-)

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 29 Oct 2020 22:17:58 +0000

Hey Robert,

That's a super cool idea. I like it.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Thursday, October 29, 2020 4:31 AM
To: Jeffrey Haas <[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

Just to clarify one point ... I was not seeing a need to use domain names. Just either IP address of bgp peer or implicitely use bgp peer's address.

https url would be actually pretty short ... just the path to the opaque text.

I am more interesting on your view of how to do NSR/ISSU with current proposal.

Cheers,
R.

On Thu, Oct 29, 2020, 12:18 Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

-- Jeff

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 30 Oct 2020 12:00:56 +0800

Putting the pointer for the static information for further diagnosis into the capability code is better than putting the static information themselves.

The peer just want to know something about the other peer, let it achieve this by the information pointer.

Best Regards

Aijun Wang

China Telecom 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
Sent: Friday, October 30, 2020 6:18 AM
To: Robert Raszuk <[email-masked]>; Jeffrey Haas <[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 Robert,

Regards,

Jakob.

From: Idr <[email-masked] <mailto:[email-masked]> > On Behalf Of Robert Raszuk
Sent: Thursday, October 29, 2020 4:31 AM
To: Jeffrey Haas <[email-masked] <mailto:[email-masked]> >
Cc: John Scudder <jgs=[email-masked] <mailto:jgs=[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

Cheers,

R.

On Thu, Oct 29, 2020, 12:18 Jeffrey Haas <[email-masked] <mailto:[email-masked]> > wrote:

Robert,

-- Jeff

---

From: <[email-masked]>
Date: Fri, 30 Oct 2020 10:00:17 +0000

Now could this be a static pointer?
e.g., standardized OID, well-known URI [1], standardized yang model?

That would probably still require an RFC, but no change to the BGP protocol, nor eating space in the capability, no mandatory 2 implementations…

Bruno

PS: Not that I care for the feature ; either way. N
[1] +IP address of the peer. Possibly with some access control restriction (source IP of the configured peer, AS of the configured peer, TTL hack, possibly TCP-AO like for BGP although at this point I’m well beyond ultracrepidarian [2] )
[2] https://dictionary.cambridge.org/fr/dictionnaire/anglais/ultracrepidarian?q=ultracrepidarian (for non-native speakers like me)

From: Idr [mailto:[email-masked]] On Behalf Of Aijun Wang
Sent: Friday, October 30, 2020 5:01 AM
To: 'Jakob Heitz (jheitz)' <jheitz=[email-masked]>; 'Robert Raszuk' <[email-masked]>; 'Jeffrey Haas' <[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

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
Sent: Friday, October 30, 2020 6:18 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Jeffrey Haas <[email-masked]<mailto:[email-masked]>>
Cc: John Scudder <jgs=[email-masked]<mailto:jgs=[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 Robert,

Regards,
Jakob.

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Thursday, October 29, 2020 4:31 AM
To: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>
Cc: John Scudder <jgs=[email-masked]<mailto:jgs=[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

Cheers,
R.

-- Jeff

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 30 Oct 2020 14:53:43 +0100

Hi Bruno,

Yes it could be well known pointer indeed. So all would be required in such
a case is a one bit flag (perhaps indicating that such info is here and
waiting for collection. That's sort of ultimate compression :)

We could also generalize it a bit and have such pointer to a json file.
Such file may in turn contain number of nested objects one of them
perhaps defined in the subject draft could describe BGP-OS related info.
Some other extension could add local GPS coordinates of the BGP speaker etc
...

Moreover fetching such information could happen either inbound of already
established TCP session for BGP or out of band by different TCP session. In
the former case as a bonus all security related concerns go away :)  We
could also allow both methods such that mgmt station could fetch such
information directly outside of the routing protocol channel.

Thx,
R.

On Fri, Oct 30, 2020 at 11:00 AM <[email-masked]> wrote:

> That would probably still require an RFC, but no change to the BGP
> protocol, nor eating space in the capability, no mandatory 2
> implementations…
>
>
>
> Bruno
>
>
>
> [1] +IP address of the peer. Possibly with some access control restriction
> (source IP of the configured peer, AS of the configured peer, TTL hack,
> possibly TCP-AO like for BGP although at this point I’m well beyond
> ultracrepidarian [2] )
>
> [2]
> https://dictionary.cambridge.org/fr/dictionnaire/anglais/ultracrepidarian?q=ultracrepidarian
> (for non-native speakers like me)
>
>
>
>
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Aijun Wang
> *Sent:* Friday, October 30, 2020 5:01 AM
> *To:* 'Jakob Heitz (jheitz)' <jheitz=[email-masked]>; 'Robert
> Raszuk' <[email-masked]>; 'Jeffrey Haas' <[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
>
>
>
> Putting the pointer for the static information for further diagnosis into
> the capability code is better than putting the static information
> themselves.
>
> *From:* [email-masked] [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Jakob Heitz (jheitz)
> *Sent:* Friday, October 30, 2020 6:18 AM
> *To:* Robert Raszuk <[email-masked]>; Jeffrey Haas <[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 Robert,
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, October 29, 2020 4:31 AM
> *To:* Jeffrey Haas <[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
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 30 Oct 2020 10:42:32 -0400

Good point on using a pointer and not static information.

>From reviewing this thread it sounds like we have made a lot of progress
and are looking at the solutions aspects of how to best encode the
versioning.  Seems we have a somewhat rough consensus.

This is a very interesting and important topic for the internet community
at large in the context of RFC 3392 and update in 5492 major change to BGP
error handing that allows the peer to ignore newly introduced capabilities
if not supported and not sent a notification to reset peer.

https://tools.ietf.org/html/rfc5492

   If a BGP speaker receives from its peer a capability that it does not
   itself support or recognize, it MUST ignore that capability.  In
   particular, the Unsupported Capability NOTIFICATION message MUST NOT
   be generated and the BGP session MUST NOT be terminated in response
   to reception of a capability that is not supported by the local
   speaker.

Traditionally BGP was run on internet routers only,

but now with appliances, lb, firewalls along s service chain or now
containers running BGP the issue with having to troubleshoot
capability exchange

issues pre RFC 5492 would come up but I believe any vendor running BGP
now would be supporting RFC 5492 and you

should not run into issues that existed pre RFC 5492 where the BGP
session is terminated due to a capability

exchange mismatch.

So that being said I as it seems we all seem to have rough consensus
that adding this feature

should be simple enough and not break existing and has value in
troubleshooting BGP peer establishment.

I would like to bring up that short of adding this feature other
simple means of troubleshooting is doing a “show BGP Neigjhbor xxx”
shows all the BGP AFI / SAFI capability exchange

in send / receive state negotiated and those that are in send or
receive and not both.  Also most vendors have built in wireshark tools
to run quick capture on the BGP capability exchange and all BGP
parameters being exchanged

and which parameter is breaking the peering.

Along these same lines of this draft and maybe something that also
could be included is by default there are a number of parameters that
are exchanged automatically other

then AFI/SAFI which in the AFI/SAFI case the peer will not come up
without the match so the notification is required.

For other BGP parameters not configured on a peer or not being used
for the peering session

but are in the “default” BGP list of capabilities in the BGP open
message would it make sense to

only explicitly add BGP parameters via configuration then have the
parameters be exchanged automatically.  An example would be RFC 5549
next hop encoding which is not always used but is in the open message.
Another example would be 4 bytes AS.  I can see why

4 byte AS should be automatic but maybe not RFC 5549 next hop
encoding.  Although

there are two sides to this and I think as Software is upgraded even
on internet routers,

from an operators POV it makes sense to send all the latest parameters
and capabilities available

then having to explicitly configure as necessary.  There are still
some that require configuration

like graceful restart and others but overall it

makes sense I think with code upgrades to send all the capabilities
you have and then per RFC 5492 even of their is a parameters mismatch
the peer still comes

up after a code upgrade.

So this version feature I can see the value of having the information,
but I wonder how the encoding would happen of the versioning.

I agree a pointer to a URL and not having static information makes sense.

On Fri, Oct 30, 2020 at 12:01 AM Aijun Wang <[email-masked]>
wrote:

> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Jakob
> Heitz (jheitz)
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD