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

[Gyan Mishra <[e-mail]>]

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 <[e-mail]>
wrote:

> 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:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Jakob
> Heitz (jheitz)
> *Sent:* Friday, October 30, 2020 6:18 AM
> *To:* Robert Raszuk <[e-mail]>; Jeffrey Haas <[e-mail]>
> *Cc:* John Scudder <jgs=[e-mail]>; IDR List <
> [e-mail]>; Donatas Abraitis <[e-mail]>
> *Subject:* Re: [Idr] WG adoption call for
> draft-abraitis-bgp-version-capability-08, to end September 25
>
>
>
> Hey Robert,
>
>
>
> That's a super cool idea. I like it.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Idr <[e-mail]> *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, October 29, 2020 4:31 AM
> *To:* Jeffrey Haas <[e-mail]>
> *Cc:* John Scudder <jgs=[e-mail]>; IDR List <
> [e-mail]>; Donatas Abraitis <[e-mail]>
> *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 <[e-mail]> wrote:
>
> Robert,
>
> On Thu, Oct 29, 2020 at 09:22:29AM +0100, Robert Raszuk wrote:
> > > - 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.
> >
> > 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 ?
>
> 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".
>
> > 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.
>
> 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
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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