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

[Robert Raszuk <[e-mail]>]

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

> 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:[e-mail]] *On Behalf Of *Aijun Wang
> *Sent:* Friday, October 30, 2020 5:01 AM
> *To:* 'Jakob Heitz (jheitz)' <jheitz=[e-mail]>; '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
>
>
>
> 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]
> <[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.
>