Re: [Idr] BGP autodiscovery design team

> imiho, if we agreed to constrain solutions to the absolute minimal
> mechanism, we might be able to cover a significant subset of clos,
> ibgp, inter-provider, and ixp.

We have a very different set of possible tools and solutions to setup BGP
peering in Clos fabric as compared with BGP neighbor discovery for IBGP
mesh or IXP.

With that perhaps we could consider if for nothing else then for simplicity
to separate those two quite orthogonal tasks.

As noted for the latter we do have a pretty mature candidate solution on
the table. For the former I think there is a lot of experience we could
leverage from IGPs.

I am not aware that there is a requirement to automate
Inter-provider peering in any dimension.

Many thx.
Robert.

On Thu, Dec 5, 2019 at 11:43 PM Randy Bush <randy@psg.com> wrote:

> > I agree with Roberts’ point. Prior to crafting or selecting a draft as
> > the basis for a proposal the design team should clearly articulate the
> > scope, use cases and requirements that need to be addressed. IMO
> > stating that in an informational RFC is a good way to ensure that all
> > stakeholders are in agreement as to what the eventual
> > specification/draft addresses, and as important does not address.
>
> while i am tempted to agree with you, i see it from a different vector.
>
> imiho, if we agreed to constrain solutions to the absolute minimal
> mechanism, we might be able to cover a significant subset of clos, ibgp,
> inter-provider, and ixp.
>
> if we do not constrain to the minimial mechanism, we will make a complex
> and disgusting mess of boiling the ocean on {pick any one of the above}.
>
> i think it was tony hoare who said something such as
>
>    there are two kinds of standards,
>      - the intersection of what everybody *must* have
>      - the union of what everybody thinks they could want
>
> randy
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>