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"><<a= href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>>= ;</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"><<a href=3D"mailt= o:[email protected]" target=3D"_blank">[email protected]</a>></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"><<a href=3D"mailto:gjshep@gm= ail.com" target=3D"_blank">[email protected]</a>></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'thing "unspecified" to "publish RFCs" while we &= quot;decide things later"?=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'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 "God's eye = view" 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 "wider scope registry". Yes, that is an i= ntriguing thought with its own validity but outside the scope of charter we= '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" 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==--