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

[Robert Raszuk <[e-mail]>]

Dear Adrian, All,

I think there is a significant difference between documenting that some
extension is useful from stating this is useful and MUST be done this way.

Also I am not sure what Alvaro expects IDR and chairs to do here. To adopt
the draft which insists on using BGP Capabilities to carry a free form text
when there may not be rough consensus to do so ?

Or maybe to take a problem at hand and work together to produce a solution
which may not use BGP Capabilities at all ?

Network audit tools are really cool to have, but just like some recent
attempts to turn BGP into config push is BGP a good protocol to exchange
OS/BGP code version information between peers ? And as I asked and no one
answered what if the problem is caused by 1 session away ?

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

In my books the document is stable for some time and waiting for
implementations.

It seems rather a norm that some documents take 10+ years to get processed
here. Hint: pls just look at the history of BGP Optimal Route Reflection
document history. So 8 years seems still pretty nominal to me ;)

Cheers,
R.

PS. As to the use of "bypass" term I did not mean to say that this has been
hidden in any form or shape ... quite contrary. WG says this is not good
solution then going around WG is what I call a bypass.









On Fri, Aug 21, 2020 at 11:14 PM RFC ISE (Adrian Farrel) <
[e-mail]> wrote:

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