Re: BGP autodiscovery design team

--===============1387145547550881910==
Content-Type: multipart/alternative; boundary="000000000000e5c46d0598fd3c25"

--000000000000e5c46d0598fd3c25
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> 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 <[email protected]> wrote:

> > I agree with Roberts=E2=80=99 point. Prior to crafting or selecting a d=
raft 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/idr
>

--000000000000e5c46d0598fd3c25
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div>&gt; imiho, if we agreed to constrain solut=
ions to the absolute minimal<div>&gt;=C2=A0mechanism, we might be able to c=
over a significant subset of clos,=C2=A0</div><div>&gt; ibgp, inter-provide=
r, and ixp.=C2=A0=C2=A0<br></div><div><br></div><div>We have a very differe=
nt set of possible tools and solutions to setup BGP peering in Clos fabric =
as compared with BGP neighbor discovery for IBGP mesh or IXP.=C2=A0</div><d=
iv><br></div><div>With that perhaps we could consider if for nothing else t=
hen for simplicity to separate those two quite orthogonal tasks.=C2=A0</div=
><div><br></div><div>As noted for the latter we do have a pretty mature can=
didate solution on the table. For the former I think there is a lot of expe=
rience=C2=A0we could leverage=C2=A0from IGPs.=C2=A0<br></div><div><br></div=
><div>I am not aware that there is a requirement=C2=A0to automate Inter-pro=
vider=C2=A0peering in any dimension.=C2=A0 =C2=A0<br></div><div><br></div><=
div>Many thx.</div><div>Robert.</div><div><br></div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Dec 5, 2019 at =
11:43 PM Randy Bush &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; =
I agree with Roberts=E2=80=99 point. Prior to crafting or selecting a draft=
 as<br>
&gt; the basis for a proposal the design team should clearly articulate the=
<br>
&gt; scope, use cases and requirements that need to be addressed. IMO<br>
&gt; stating that in an informational RFC is a good way to ensure that all<=
br>
&gt; stakeholders are in agreement as to what the eventual<br>
&gt; specification/draft addresses, and as important does not address.<br>
<br>
while i am tempted to agree with you, i see it from a different vector.<br>
<br>
imiho, if we agreed to constrain solutions to the absolute minimal<br>
mechanism, we might be able to cover a significant subset of clos, ibgp,<br=
>
inter-provider, and ixp.<br>
<br>
if we do not constrain to the minimial mechanism, we will make a complex<br=
>
and disgusting mess of boiling the ocean on {pick any one of the above}.<br=
>
<br>
i think it was tony hoare who said something such as<br>
<br>
=C2=A0 =C2=A0there are two kinds of standards,<br>
=C2=A0 =C2=A0 =C2=A0- the intersection of what everybody *must* have<br>
=C2=A0 =C2=A0 =C2=A0- the union of what everybody thinks they could want<br=
>
<br>
randy<br>
<br>
_______________________________________________<br>
Idr mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/idr" rel=3D"noreferrer" ta=
rget=3D"_blank">https://www.ietf.org/mailman/listinfo/idr</a><br>
</blockquote></div>

--000000000000e5c46d0598fd3c25--


--===============1387145547550881910==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr

--===============1387145547550881910==--