Re: BGP autodiscovery design team

--===============0455844347987493612==
Content-Type: multipart/alternative; boundary="0000000000009f98a00598f554b4"

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

Hi Job,

>  Perhaps the design team=E2=80=99s mailing list should be [email protected]

Indeed !

I do not understand why there is any need for "design team" if required
functionality is about one of the core protocol functionality. What are we
trying to achieve - if someone on IDR is not interested given mail thread
can be easily moved to trash.

Hi Jim,

Many thx for your opinion. Very much appreciated here.

Also as we see from some proposals the core DC auto peering (also called by
some as "autodiscovery") can be done with the assistance of existing L2
protocols. So I think the fundamental first question is if this work even
belongs to IDR.

Thx,
R.



On Thu, Dec 5, 2019 at 2:50 PM Job Snijders <[email protected]> wrote:

> On Thu, Dec 5, 2019 at 14:46 UTTARO, JAMES <[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 stakeholde=
rs
>> are in agreement as to what the eventual specification/draft addresses, =
and
>> as important does not address. When creating EVPN we first crafted an
>> informational RFC https://tools.ietf.org/html/rfc7209
>> <https://tools.ietf.org/html/rfc7209> that specified Active/Active
>> Multi-homing, flooding and multicast optimization etc=E2=80=A6 which for=
med the
>> basis for the RFC 7432. This focused the design team on realizing the
>> requirements articulated there.*
>>
>
> I think the above is good feedback.
>
> Also, it appears the entire working groep is interested to be part of the
> design team. Perhaps the design team=E2=80=99s mailing list should be idr=
@ietf.org?
> :-)
>
> Kind regards,
>
> Job
>

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

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div>Hi Job,</div><div><br></di=
v><div dir=3D"ltr">&gt;=C2=A0 Perhaps the design team=E2=80=99s mailing lis=
t should be <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]<=
/a>=C2=A0</div><div dir=3D"ltr"><br></div><div>Indeed !=C2=A0</div><div><br=
></div><div>I do not understand why there is any need for &quot;design team=
&quot; if required functionality is about one of the core=C2=A0protocol=C2=
=A0functionality. What are we trying to=C2=A0achieve - if someone on IDR is=
 not interested given mail thread can be easily moved to trash.=C2=A0</div>=
<div dir=3D"ltr"><br></div><div dir=3D"ltr">Hi Jim,<div><br></div><div>Many=
 thx for your opinion. Very much appreciated here.=C2=A0</div><div><br></di=
v><div>Also as we see from some proposals the core DC auto peering (also ca=
lled by some as &quot;autodiscovery&quot;) can be done with the assistance=
=C2=A0of=C2=A0existing=C2=A0L2 protocols. So I think the fundamental first =
question is if this work even belongs to IDR.=C2=A0</div><div><br></div><di=
v>Thx,<br>R.</div></div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><br></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On =
Thu, Dec 5, 2019 at 2:50 PM Job Snijders &lt;<a href=3D"mailto:[email protected]"=
>[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div>On Thu, Dec 5, 2019 at 14:46 UTTARO, JAMES &lt;<a href=3D"=
mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt; wrote:<br><=
/div><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">





<div lang=3D"EN-US">
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size:12pt;color:rgb(112,48,16=
0)">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 en=
sure that all stakeholders are in agreement as to what the eventual specifi=
cation/draft addresses, and as important does not address. When creating EV=
PN we first crafted an informational
 RFC <a href=3D"https://tools.ietf.org/html/rfc7209" target=3D"_blank">http=
s://tools.ietf.org/html/rfc7209</a> that specified Active/Active Multi-homi=
ng, flooding and multicast optimization etc=E2=80=A6 which formed the basis=
 for the RFC 7432. This focused the design team on realizing
 the requirements articulated there.</span></b></p></div></div></blockquote=
><div dir=3D"auto"><br></div><div dir=3D"auto">I think the above is good fe=
edback.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Also, it appears=
 the entire working groep is interested to be part of the design team. Perh=
aps the design team=E2=80=99s mailing list should be <a href=3D"mailto:idr@=
ietf.org" target=3D"_blank">[email protected]</a>? :-)</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">Kind regards,</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">Job</div></div></div>
</blockquote></div></div>

--0000000000009f98a00598f554b4--


--===============0455844347987493612==
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

--===============0455844347987493612==--