Re: [Idr] Review of draft-abraitis-bgp-version-capability-07

["RFC ISE (Adrian Farrel)" <[e-mail]>]

I think I object to the idea that this is  bypass of IDR.

It is *still* not too late for IDR to pick up this work if they want to
(but it is very close to too late). What I would need to hear (and I
presume Alvaro as the responsible AD) is a clear statement that the WG
*does* want to work on this.

Robert, I read your email as saying that "I want roughly this function,
but I would not do it that way." (Please say if I misread you). That is
certainly possible, and the WG is never expected to approve work without
review and editing, but it is hard for an author who fails to get any
traction to be told much later that there is finally traction but only if
they discard their approach and start again.

Perhaps one of the perils of a FCFS registry is that codepoints are
relatively freely available and without WG control. But it isn't as though
the author did not put this up for review from IDR on several occasions.

Wrt draft-ietf-idr-operational-message, I note that this expired a few
days less than eight years ago. I think it is reasonable to assume that
the WG is not pursuing that idea.

Best,
Adrian

Robert Raszuk wrote:
>>
>> Not only iBGP. It's up to the administration scope. If that's a clos
>> topology of leaves and spines, most likely there will be eBGP used. >>
Or even especially routing on the host, or more complicated
>> Kubernetes/Docker deployments.
>>
>
> Sure not just iBGP but the draft says this: "This capability is NOT
> RECOMMENDED for eBGP use."  I realize what you meant to say was that
> the  draft is "NOT RECOMMENDED" to be used between different
> operational domains.
>
> - - -
>
> In any case this is an interesting case of IDR bypass. If this is
> approved I can already see a line of other proposals. Where will it
> bring BGP time will tell.
>
> My intention is however just to point out that this is a protocol
> extension which IDR compliant implementations will need to be aware
> of.
>
> The document uses a very soft language in a number of places. Example:
> The Capability Length SHOULD be no greater than 64.
>
> Bottom line is that there is a lot of people in IDR and/or GROW who
> think that we need to exchange such information between BGP peers. I
> am one of them. In the past I wrote BGP diagnostic message draft then
> we merged it with Advisory Message into BGP Operational Message which
> was in fact adopted as IDR WG document
> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00
>
> I think BGP (well really OS) version is a useful information, but I do
> not think this should be part of BGP Capabilities as an opaque text.
>
> My recommendation here is to add a new message to BGP Operational
> Message document and move forward with that more general solution to
> the problem. If FRR can support BGP Operational Message we can
> document it and move one step closer to IDR LC.

-- 
Adrian Farrel (ISE),
[e-mail]