Re: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

Tony Przygienda <[email protected]> Thu, 15 Feb 2018 09:28:45 -0800
Newsgroups gmane.ietf.isis
Message-ID <CA+wi2hO2fzTRt7k9xDFiBhpw5wUo2N5WOUUGS0HeECf9Gh96pQ__32634.2473774732$1518715710$gmane$org@mail.gmail.com>
--===============8740133459261056897==
Content-Type: multipart/alternative; boundary="f403045c0d18bb58030565439185"

--f403045c0d18bb58030565439185
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 15, 2018 at 9:20 AM, Greg Shepherd <[email protected]> wrote:

> On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda <[email protected]>
> wrote:
>
>>
>>
>> On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd <[email protected]> wrote:
>>
>>> For the record, there is no SR Registry. There is only an IGP Algo Type
>>> Registry as defined in draft-ietf-ospr-segment-routing-extensions-24
>>> section 8.5
>>>
>>
>> So is that a good idea, having multiple drafts in flight with fields
>> expecting to have magic couplings to each other while leaving e'thing
>> "unspecified" to "publish RFCs" while we "decide things later"?
>>
>
> That was a pivot, but still; there is no reference, there is no coupling.
>
> Tangental: draft-ietf-ospr-segment-routing-extensions-24 has been around
> for a while, and the IGP Algo registry will be tied to this draft and it's
> fate. If anyone is expecting to use this registry outside of the scope of
> this draft, it would be in their best interest to pull the registry
> description out into a separate draft.
>
>
OK, and I agree that if such a registry is pulled and under a clear charter
of mandating multiple technologies within an independent body then a
discussion starts to make sense and what the size of that should be given
that mandates algorithms over multiple technologies (SR, unicast, mcast,
whatever) and implies a "God's eye view" of all the elements of all the
technologies (and if a computation touches elements from two technologies
they become [optionally] coupled).  We are not talking IGP registry or
multicast computation registry or SR registry then but a "wider scope
registry". Yes, that is an intriguing thought with its own validity but
outside the scope of charter we're under as BIER.  Personally, I consider
multiple, if needed loosely coupled registries for each technology a less
centralized and hence "more Internet like" solution but I see how opinions
on such a thing can diverge ...

thanks

--- tony


>
>

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Feb 15, 2018 at 9:20 AM, Greg Shepherd <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Thu, Feb =
15, 2018 at 8:53 AM, Tony Przygienda <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:[email protected]" target=3D"_blank">[email protected]</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote"><span>On Thu, Feb 15, 2018 =
at 8:38 AM, Greg Shepherd <span dir=3D"ltr">&lt;<a href=3D"mailto:gjshep@gm=
ail.com" target=3D"_blank">[email protected]</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr">For the record, there is no SR Re=
gistry. There is only an IGP Algo Type Registry as defined in draft-ietf-os=
pr-segment-routin<wbr>g-extensions-24 section 8.5</div></blockquote><div><b=
r></div></span><div>So is that a good idea, having multiple drafts in fligh=
t with fields expecting to have magic couplings to each other while leaving=
 e&#39;thing &quot;unspecified&quot; to &quot;publish RFCs&quot; while we &=
quot;decide things later&quot;?=C2=A0</div></div></div></div></blockquote><=
div><br></div></span><div>That was a pivot, but still; there is no referenc=
e, there is no coupling.=C2=A0</div><div><br></div><div>Tangental: draft-ie=
tf-ospr-segment-routin<wbr>g-extensions-24 has been around for a while, and=
 the IGP Algo registry will be tied to this draft and it&#39;s fate. If any=
one is expecting to use this registry outside of the scope of this draft, i=
t would be in their best interest to pull the registry description out into=
 a separate draft.</div><span class=3D""><div><br></div></span></div></div>=
</div></blockquote><div><br></div><div>OK, and I agree that if such a regis=
try is pulled and under a clear charter of mandating multiple technologies =
within an independent body then a discussion starts to make sense and what =
the size of that should be given that mandates algorithms over multiple tec=
hnologies (SR, unicast, mcast, whatever) and implies a &quot;God&#39;s eye =
view&quot; of all the elements of all the technologies (and if a computatio=
n touches elements from two technologies they become [optionally] coupled).=
=C2=A0 We are not talking IGP registry or multicast computation registry or=
 SR registry then but a &quot;wider scope registry&quot;. Yes, that is an i=
ntriguing thought with its own validity but outside the scope of charter we=
&#39;re under as BIER.=C2=A0 Personally, I consider multiple, if needed loo=
sely coupled registries for each technology a less centralized and hence &q=
uot;more Internet like&quot; solution but I see how opinions on such a thin=
g can diverge ... <br></div><div><br></div><div>thanks<br></div><div><br></=
div><div>--- tony <br></div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div class=3D"gmail_extra"><br></div></div>
</blockquote></div><br></div></div>

--f403045c0d18bb58030565439185--


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

_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg

--===============8740133459261056897==--