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

Jeff Tantsura <[email protected]> Sat, 17 Feb 2018 09:31:12 -0800
Newsgroups gmane.ietf.isis
Message-ID <792530F3-9AAC-431C-934F-29F77FE1B9DD__14006.7369946793$1518888588$gmane$org@gmail.com>
--===============8121981252913074635==
Content-Type: multipart/alternative;
 boundary=Apple-Mail-07D98455-F3CD-4B26-B1BE-C55006F2A6D4
Content-Transfer-Encoding: 7bit


--Apple-Mail-07D98455-F3CD-4B26-B1BE-C55006F2A6D4
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1

Regards,
Jeff

> On Feb 16, 2018, at 18:18, Dolganow, Andrew (Nokia - SG/Singapore) <andrew=
[email protected]> wrote:
>=20
> Agree, what Eric has is starting to look like a compromise. Let=E2=80=99s g=
et the final text (wip) on the list asap.
> =20
> Andrew
> =20
> From: "Les Ginsberg (ginsberg)" <[email protected]>
> Date: Friday, February 16, 2018 at 11:08 PM
> To: Eric Rosen <[email protected]>, Andrew Dolganow <andrew.dolganow@noki=
a.com>, "(Ice) IJsbrand Wijnands" <[email protected]>
> Cc: Greg Shepherd <[email protected]>, "[email protected]" <[email protected]>, "is=
[email protected]" <[email protected]>, Xiejingrong <[email protected]>, Ar=
kadiy Gulko <[email protected]>
> Subject: RE: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-extensions-07.tx=
t
> =20
> Eric -
> =20
> From: Eric C Rosen [mailto:[email protected]]=20
> Sent: Friday, February 16, 2018 6:45 AM
> To: Les Ginsberg (ginsberg) <[email protected]>; Dolganow, Andrew (Nokia -=
 SG/Singapore) <[email protected]>; IJsbrand Wijnands <[email protected]=
>
> Cc: Greg Shepherd <[email protected]>; [email protected]; [email protected]; Xie=
jingrong <[email protected]>; [email protected]
> Subject: Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-extensions-07.tx=
t
> =20
> Perhaps the following would be a good compromise (or perhaps not).
>=20
> Have an eight-bit field whose values are taken from the "IGP Algorithms" R=
egistry.
>=20
> Have another eight-bit field whose values are taken from a new BIER-specif=
ic registry.  I don't know, maybe call it the "BIER Underlay Algorithm Modif=
ier" registry.  The way the underlay paths are computed for a given BIER sub=
-domain is determined by the pair of codepoints: <IGP Algorithms codepoint, B=
IER Underlay Algorithm Modifier codepoint>.
>=20
>=20
>=20
> [Les:] Makes sense =E2=80=93 except I would think only when the BUAM =3D=3D=
 0 do the values come from IGP registry. Other values for BUAM would require=
 a different set of definitions for the algorithm value.
>=20
>    Les
>=20
>=20
> The default value for the "BIER Underlay Algorithm Modifier" field would b=
e zero.   The value zero in this field would mean "just use the IGP Algorith=
ms field to figure out how the underlay paths are computed."  Non-zero value=
s could be used to add additional nuance.  Existing drafts can say "the use o=
f non-zero values in this field is outside the scope of this document".=20
>=20
> The registration policy for the new registry could save about  half the va=
lues for "standards action", and about half for FCFS.  And a few for Experim=
ental.  (This would be a good policy for the IGP Algorithms registry as well=
, imho.)
>=20
> This seems to have minimal impact on existing implementations, and leaves r=
oom for further development of BIER while avoiding entanglements (or peceive=
d entanglements) with other technologies that might be considered controvers=
ial.
>=20
> Now perhaps the WG can proceed to the really important issues, such as how=
 to best design the T-shirts.  (Though frankly I'd rather get a few more hom=
e-brewed beers than a T-shirt.)
>=20
>=20
>=20
>=20
> On 2/16/2018 12:51 AM, Les Ginsberg (ginsberg) wrote:
> Andrew =E2=80=93
> =20
> There is no change being considered to the size of the algorithm field for=
 Segment Routing.  That is 8 bits =E2=80=93 there are mature SR documents an=
d multiple implementations that use that encoding. There is also the IGP reg=
istry defined in an SR document (though not necessarily exclusively for SR u=
se) which defines 8 bit values.
> =20
> The only thing which is being discussed here is whether BIER should use an=
 8 bit or 16 bit algorithm field. Also, even if it is decided BIER should us=
e a 16 bit algorithm, it is conceivable that the values defined in the IGP a=
lgorithm registry may still be of use to BIER.
> =20
>    Les
> =20
> From: BIER [mailto:[email protected]] On Behalf Of Dolganow, Andrew (N=
okia - SG/Singapore)
> Sent: Thursday, February 15, 2018 7:39 PM
> To: IJsbrand Wijnands <[email protected]>
> Cc: Greg Shepherd <[email protected]>; [email protected]; [email protected]; Xie=
jingrong <[email protected]>; [email protected]; Eric C R=
osen <[email protected]>
> Subject: Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-extensions-07.tx=
t
> =20
> Well,
> =20
> Now, there are multiple treads being discussed here under one topic:
> =20
> - how big should the the field be?
> - should there be common registry for all technologies?
> - where should it be defined and which WG should standardize it?
> =20
> To me the first question is totally dependent on the answer to the last tw=
o, since the use case pointed out suggests a common registry.=20
> =20
> Now there may be different opinions (I believe there are from this exchang=
e) whether we should or should not have a common registry, how complicated w=
ould it be and whether it would tax all groups trying to use that. But even b=
efore we go there, the basic question has to be answered:=20
> - which WG would own that registry. It is not in a charter of BIER to own i=
t nor it is in a charter of SR nor it is in a charter of ISIS. Do none of th=
em should own and mandate use. We are chartering LSR now - should we add reg=
istry for all IGP algorithms, we have routing WG, others?  Would like to hea=
r AD=E2=80=99s opinion. Note that although LSR appears obvious, the algorith=
ms to compute BIER may be controller-based that do bot require LSR (same app=
lies to SR).=20
> =20
> - if we do agree to have a common registry, I would assume we all then tax=
 everyone to signal that the same way. That would mean changes to SR and cha=
nges to BIER.=20
> =20
> This seems a lot. We have implementations of both technologies, so are cha=
nges to those warranted or is it too late and we should pursue independent  a=
lg definition and registry as it has been set-up in the existing drafts. And=
 we are talking only of those two but more WG will come and want to define t=
hings for them as well.=20
> =20
>=20
> Andrew
> =20
> Sent from my iPhone
>=20
> On Feb 16, 2018, at 2:51 AM, IJsbrand Wijnands <[email protected]> wrote:
>=20
> I think its clear from the discussion there are different opinions on the m=
atter on how to make BIER use the BAR field. The reason for me to support 16=
 bits is that everybody seemed ok go move forward with an 8bits BAR without a=
 registry, a 16bits BAR does not change anything, its just a bigger field. B=
ut at least with 16bits, we can split in Type, Value, and support different u=
se-cases. IMO, pointing to whatever the Unicast underlay is providing is the=
 main use-case, but it allows other ways to do things.
> =20
> One thing is clear, with just 8bits, it will be very hard to reach an agre=
ement what the registry would look like. If we make it 16bits, we know we ca=
n solve multiple  use-cases. The main question (I think) is whether we docum=
ent how a 16bit BAR is carved up now, or we defer that to later. And as I sa=
id, since everybody seemed ok with 8bit BAR without a registry, I don=E2=80=99=
t see why its now different for 16bits. It gives us time to workout exactly h=
ow to use it and get input from the WGs.
> =20
> And, of course, the goal is to create a registry for the 16 bits through a=
 new draft!
> =20
> Thx,
> =20
> Ice.
> =20
>=20
>=20
>=20
>=20
> On 15 Feb 2018, at 18:28, Tony Przygienda <[email protected]> wrote:
>=20
>=20
>=20
> 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]> wro=
te:
>=20
>=20
> 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 Re=
gistry as defined in draft-ietf-ospr-segment-routing-extensions-24 section 8=
.5
>=20
> So is that a good idea, having multiple drafts in flight with fields expec=
ting to have magic couplings to each other while leaving e'thing "unspecifie=
d" to "publish RFCs" while we "decide things later"?=20
>=20
> That was a pivot, but still; there is no reference, there is no coupling.=20=

>=20
> Tangental: draft-ietf-ospr-segment-routing-extensions-24 has been around f=
or a while, and the IGP Algo registry will be tied to this draft and it's fa=
te. 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 o=
ut into a separate draft.
>=20
>=20
> OK, and I agree that if such a registry is pulled and under a clear charte=
r of mandating multiple technologies within an independent body then a discu=
ssion starts to make sense and what the size of that should be given that ma=
ndates algorithms over multiple technologies (SR, unicast, mcast, whatever) a=
nd implies a "God's eye view" of all the elements of all the technologies (a=
nd if a computation touches elements from two technologies they become [opti=
onally] coupled).  We are not talking IGP registry or multicast computation r=
egistry or SR registry then but a "wider scope registry". Yes, that is an in=
triguing thought with its own validity but outside the scope of charter we'r=
e under as BIER.  Personally, I consider multiple, if needed loosely coupled=
 registries for each technology a less centralized and hence "more Internet l=
ike" solution but I see how opinions on such a thing can diverge ...=20
>=20
> thanks
>=20
> --- tony=20
> =20
>=20
>=20
> _______________________________________________
> BIER mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/bier
> =20
> <PastedGraphic-6.png>
> =20
> _______________________________________________
> Isis-wg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/isis-wg
> =20
> _______________________________________________
> BIER mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/bier

--Apple-Mail-07D98455-F3CD-4B26-B1BE-C55006F2A6D4
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto">+1<br><br><div id=3D"AppleMailSignature">Re=
gards,<div>Jeff</div></div><div><br>On Feb 16, 2018, at 18:18, Dolganow, And=
rew (Nokia - SG/Singapore) &lt;<a href=3D"mailto:[email protected]">=
[email protected]</a>&gt; wrote:<br><br></div><blockquote type=3D"ci=
te"><div>

<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
	{mso-style-name:msonormal;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;
	color:black;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri",sans-serif;
	color:#1F497D;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri",sans-serif;
	color:#1F497D;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style>


<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-f=
amily:&quot;Calibri&quot;,sans-serif;color:windowtext;mso-fareast-language:E=
N-US">Agree, what Eric has is starting to look like a compromise. Let=E2=80=99=
s get the final text (wip) on the list asap.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-f=
amily:&quot;Calibri&quot;,sans-serif;color:windowtext;mso-fareast-language:E=
N-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-f=
amily:&quot;Calibri&quot;,sans-serif;color:windowtext;mso-fareast-language:E=
N-US">Andrew<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-f=
amily:&quot;Calibri&quot;,sans-serif;color:windowtext;mso-fareast-language:E=
N-US"><o:p>&nbsp;</o:p></span></p>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0=
cm 0cm">
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><b>From: </b>"Les Ginsbe=
rg (ginsberg)" &lt;<a href=3D"mailto:[email protected]">[email protected]<=
/a>&gt;<br>
<b>Date: </b>Friday, February 16, 2018 at 11:08 PM<br>
<b>To: </b>Eric Rosen &lt;<a href=3D"mailto:[email protected]">erosen@junip=
er.net</a>&gt;, Andrew Dolganow &lt;<a href=3D"mailto:andrew.dolganow@nokia.=
com">[email protected]</a>&gt;, "(Ice) IJsbrand Wijnands" &lt;<a hre=
f=3D"mailto:[email protected]">[email protected]</a>&gt;<br>
<b>Cc: </b>Greg Shepherd &lt;<a href=3D"mailto:[email protected]">gjshep@gmai=
l.com</a>&gt;, "<a href=3D"mailto:[email protected]">[email protected]</a>" &lt;<a h=
ref=3D"mailto:[email protected]">[email protected]</a>&gt;, "<a href=3D"mailto:isis-=
[email protected]">[email protected]</a>" &lt;<a href=3D"mailto:[email protected]">i=
[email protected]</a>&gt;, Xiejingrong &lt;<a href=3D"mailto:xiejingrong@huawe=
i.com">[email protected]</a>&gt;, Arkadiy Gulko &lt;<a href=3D"mailto:a=
[email protected]">[email protected]</a>&gt;<br=
>
<b>Subject: </b>RE: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-extensions-=
07.txt<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"font-size=
:11.0pt;color:windowtext"><o:p>&nbsp;</o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><a name=3D"_MailOriginal=
Body"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-s=
erif;color:#1F497D">Eric -</span><o:p></o:p></a></p>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,sans-serif;color:#1F497D">&nbsp;</span><o:p></o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4=
.0pt">
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0=
cm 0cm">
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody"><b><span style=3D"font-size:11.0pt;font-family:&quot;=
Calibri&quot;,sans-serif;color:windowtext">From:</span></b></span><span styl=
e=3D"mso-bookmark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-fa=
mily:&quot;Calibri&quot;,sans-serif;color:windowtext">
 Eric C Rosen [<a href=3D"mailto:[email protected]">mailto:[email protected]=
et</a>] <br>
<b>Sent:</b> Friday, February 16, 2018 6:45 AM<br>
<b>To:</b> Les Ginsberg (ginsberg) &lt;<a href=3D"mailto:[email protected]"=
>[email protected]</a>&gt;; Dolganow, Andrew (Nokia - SG/Singapore) &lt;<a h=
ref=3D"mailto:[email protected]">[email protected]</a>&gt;; I=
Jsbrand Wijnands &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt;<=
br>
<b>Cc:</b> Greg Shepherd &lt;<a href=3D"mailto:[email protected]">gjshep@gmai=
l.com</a>&gt;; <a href=3D"mailto:[email protected]">[email protected]</a>; <a href=3D=
"mailto:[email protected]">[email protected]</a>; Xiejingrong &lt;<a href=3D"m=
ailto:[email protected]">[email protected]</a>&gt;; <a href=3D"mai=
lto:[email protected]">[email protected]</a><b=
r>
<b>Subject:</b> Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-extensions-=
07.txt</span><o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0cm;margin-right:0cm;marg=
in-bottom:12.0pt;margin-left:36.0pt">
<span style=3D"mso-bookmark:_MailOriginalBody">Perhaps the following would b=
e a good compromise (or perhaps not).<br>
<br>
Have an eight-bit field whose values are taken from the "IGP Algorithms" Reg=
istry.<br>
<br>
Have another eight-bit field whose values are taken from a new BIER-specific=
 registry.&nbsp; I don't know, maybe call it the "BIER Underlay Algorithm Mo=
difier" registry.&nbsp; The way the underlay paths are computed for a given B=
IER sub-domain is determined by the pair
 of codepoints: &lt;IGP Algorithms codepoint, BIER Underlay Algorithm Modifi=
er codepoint&gt;.<br>
<br>
<br>
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0cm;margin-right:0cm;marg=
in-bottom:12.0pt;margin-left:36.0pt">
<span style=3D"mso-bookmark:_MailOriginalBody"><b><i><span style=3D"font-siz=
e:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;color:#1F497D">[Les:] Ma=
kes sense =E2=80=93 except I would think only when the BUAM =3D=3D 0 do the v=
alues come from IGP registry. Other values for BUAM would
 require a different set of definitions for the algorithm value.</span></i><=
/b><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0cm;margin-right:0cm;marg=
in-bottom:12.0pt;margin-left:36.0pt">
<span style=3D"mso-bookmark:_MailOriginalBody"><b><i><span style=3D"font-siz=
e:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;color:#1F497D">&nbsp;&nb=
sp; Les</span></i></b><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0cm;margin-right:0cm;marg=
in-bottom:12.0pt;margin-left:36.0pt">
<span style=3D"mso-bookmark:_MailOriginalBody"><br>
The default value for the "BIER Underlay Algorithm Modifier" field would be z=
ero.&nbsp;&nbsp; The value zero in this field would mean "just use the IGP A=
lgorithms field to figure out how the underlay paths are computed."&nbsp; No=
n-zero values could be used to add additional
 nuance.&nbsp; Existing drafts can say "the use of non-zero values in this f=
ield is outside the scope of this document".
<br>
<br>
The registration policy for the new registry could save about&nbsp; half the=
 values for "standards action", and about half for FCFS.&nbsp; And a few for=
 Experimental.&nbsp; (This would be a good policy for the IGP Algorithms reg=
istry as well, imho.)<br>
<br>
This seems to have minimal impact on existing implementations, and leaves ro=
om for further development of BIER while avoiding entanglements (or peceived=
 entanglements) with other technologies that might be considered controversi=
al.<br>
<br>
Now perhaps the WG can proceed to the really important issues, such as how t=
o best design the T-shirts.&nbsp; (Though frankly I'd rather get a few more h=
ome-brewed beers than a T-shirt.)<br>
<br>
<br>
<br>
<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">On 2/16/2018 12:51 AM, Les Ginsberg (ginsberg) wrote:=
<o:p></o:p></span></p>
</div>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,sans-serif;color:#1F497D">Andrew =E2=80=93</span><o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,sans-serif;color:#1F497D">&nbsp;</span><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,sans-serif;color:#1F497D">There is no change being considered to t=
he size of the algorithm field for Segment Routing.&nbsp;
 That is 8 bits =E2=80=93 there are mature SR documents and multiple impleme=
ntations that use that encoding. There is also the IGP registry defined in a=
n SR document (though not necessarily exclusively for SR use) which defines 8=
 bit values.</span><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,sans-serif;color:#1F497D">&nbsp;</span><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,sans-serif;color:#1F497D">The only thing which is being discussed=
 here is whether BIER should use an 8 bit or 16
 bit algorithm field. Also, even if it is decided BIER should use a 16 bit a=
lgorithm, it is conceivable that the values defined in the IGP algorithm reg=
istry may still be of use to BIER.</span><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,sans-serif;color:#1F497D">&nbsp;</span><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,sans-serif;color:#1F497D">&nbsp;&nbsp; Les</span><o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,sans-serif;color:#1F497D">&nbsp;</span><o:p></o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4=
.0pt">
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0=
cm 0cm">
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody"><b><span style=3D"font-size:11.0pt;font-family:&quot;=
Calibri&quot;,sans-serif">From:</span></b></span><span style=3D"mso-bookmark=
:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-family:&quot;Calibr=
i&quot;,sans-serif">
 BIER [</span></span><a href=3D"mailto:[email protected]"><span style=3D=
"mso-bookmark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-family=
:&quot;Calibri&quot;,sans-serif">mailto:[email protected]</span></span><=
span style=3D"mso-bookmark:_MailOriginalBody"></span></a><span style=3D"mso-=
bookmark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-family:&quo=
t;Calibri&quot;,sans-serif">]
<b>On Behalf Of </b>Dolganow, Andrew (Nokia - SG/Singapore)<br>
<b>Sent:</b> Thursday, February 15, 2018 7:39 PM<br>
<b>To:</b> IJsbrand Wijnands </span></span><a href=3D"mailto:[email protected]">=
<span style=3D"mso-bookmark:_MailOriginalBody"><span style=3D"font-size:11.0=
pt;font-family:&quot;Calibri&quot;,sans-serif">&lt;[email protected]&gt;</span><=
/span><span style=3D"mso-bookmark:_MailOriginalBody"></span></a><span style=3D=
"mso-bookmark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-family=
:&quot;Calibri&quot;,sans-serif"><br>
<b>Cc:</b> Greg Shepherd </span></span><a href=3D"mailto:[email protected]"><=
span style=3D"mso-bookmark:_MailOriginalBody"><span style=3D"font-size:11.0p=
t;font-family:&quot;Calibri&quot;,sans-serif">&lt;[email protected]&gt;</span=
></span><span style=3D"mso-bookmark:_MailOriginalBody"></span></a><span styl=
e=3D"mso-bookmark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-fa=
mily:&quot;Calibri&quot;,sans-serif">;
</span></span><a href=3D"mailto:[email protected]"><span style=3D"mso-bookmark:_=
MailOriginalBody"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&=
quot;,sans-serif">[email protected]</span></span><span style=3D"mso-bookmark:_Ma=
ilOriginalBody"></span></a><span style=3D"mso-bookmark:_MailOriginalBody"><s=
pan style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif">;
</span></span><a href=3D"mailto:[email protected]"><span style=3D"mso-bookmar=
k:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-family:&quot;Calib=
ri&quot;,sans-serif">[email protected]</span></span><span style=3D"mso-bookma=
rk:_MailOriginalBody"></span></a><span style=3D"mso-bookmark:_MailOriginalBo=
dy"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-ser=
if">;
 Xiejingrong </span></span><a href=3D"mailto:[email protected]"><span s=
tyle=3D"mso-bookmark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font=
-family:&quot;Calibri&quot;,sans-serif">&lt;[email protected]&gt;</span=
></span><span style=3D"mso-bookmark:_MailOriginalBody"></span></a><span styl=
e=3D"mso-bookmark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-fa=
mily:&quot;Calibri&quot;,sans-serif">;
</span></span><a href=3D"mailto:[email protected]"><span styl=
e=3D"mso-bookmark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-fa=
mily:&quot;Calibri&quot;,sans-serif">[email protected]</span>=
</span><span style=3D"mso-bookmark:_MailOriginalBody"></span></a><span style=
=3D"mso-bookmark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-fam=
ily:&quot;Calibri&quot;,sans-serif">;
 Eric C Rosen </span></span><a href=3D"mailto:[email protected]"><span styl=
e=3D"mso-bookmark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-fa=
mily:&quot;Calibri&quot;,sans-serif">&lt;[email protected]&gt;</span></span=
><span style=3D"mso-bookmark:_MailOriginalBody"></span></a><span style=3D"ms=
o-bookmark:_MailOriginalBody"><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif"><br>
<b>Subject:</b> Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-extensions-=
07.txt</span><o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">Well,
<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">Now, there are multiple treads being discussed here u=
nder one topic:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">- how big should the the field be?<o:p></o:p></span><=
/p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">- should there be common registry for all technologie=
s?<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">- where should it be defined and which WG should stan=
dardize it?<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">To me the first question is totally dependent on the a=
nswer to the last two, since the use case pointed out suggests a common regi=
stry.&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">Now there may be different opinions (I believe there a=
re from this exchange) whether we should or should not have a common registr=
y, how complicated would it be and
 whether it would tax all groups trying to use that. But even before we go t=
here, the basic question has to be answered:&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">- which WG would own that registry. It is not in a ch=
arter of BIER to own it nor it is in a charter of SR nor it is in a charter o=
f ISIS. Do none of them should own
 and mandate use. We are chartering LSR now - should we add registry for all=
 IGP algorithms, we have routing WG, others? &nbsp;Would like to hear AD=E2=80=
=99s opinion. Note that although LSR appears obvious, the algorithms to comp=
ute BIER may be controller-based that do
 bot require LSR (same applies to SR).&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">- if we do agree to have a common registry, I would a=
ssume we all then tax everyone to signal that the same way. That would mean c=
hanges to SR and changes to BIER.&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">This seems a lot. We have implementations of both tec=
hnologies, so are changes to those warranted or is it too late and we should=
 pursue independent &nbsp;alg definition
 and registry as it has been set-up in the existing drafts. And we are talki=
ng only of those two but more WG will come and want to define things for the=
m as well.&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0cm;margin-right:0cm;marg=
in-bottom:12.0pt;margin-left:36.0pt">
<span style=3D"mso-bookmark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
<div id=3D"AppleMailSignature">
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">Andrew
<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">Sent from my iPhone<o:p></o:p></span></p>
</div>
</div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0cm;margin-right:0cm;marg=
in-bottom:12.0pt;margin-left:36.0pt">
<span style=3D"mso-bookmark:_MailOriginalBody"><br>
On Feb 16, 2018, at 2:51 AM, IJsbrand Wijnands &lt;</span><a href=3D"mailto:=
[email protected]"><span style=3D"mso-bookmark:_MailOriginalBody">[email protected]<=
/span><span style=3D"mso-bookmark:_MailOriginalBody"></span></a><span style=3D=
"mso-bookmark:_MailOriginalBody">&gt; wrote:<o:p></o:p></span></p>
</div>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">I think its clear from the discussion there are diffe=
rent opinions on the matter on how to make BIER use the BAR field. The reaso=
n for me to support 16 bits is that
 everybody seemed ok go move forward with an 8bits BAR without a registry, a=
 16bits BAR does not change anything, its just a bigger field. But at least w=
ith 16bits, we can split in Type, Value, and support different use-cases. IM=
O, pointing to whatever the
 Unicast underlay is providing is the main use-case, but it allows other way=
s to do things.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">One thing is clear, with just 8bits, it will be very h=
ard to reach an agreement what the registry would look like. If we make it 1=
6bits, we know we can solve multiple
 use-cases. The main question (I think) is whether we document how a 16bit B=
AR is carved up now, or we defer that to later. And as I said, since everybo=
dy seemed ok with 8bit BAR without a registry, I don=E2=80=99t see why its n=
ow different for 16bits. It gives us
 time to workout exactly how to use it and get input from the WGs.<o:p></o:p=
></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">And, of course, the goal is to create a registry for t=
he 16 bits through a new draft!<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">Thx,<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">Ice.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody"><br>
<br>
<br>
<br>
<o:p></o:p></span></p>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">On 15 Feb 2018, at 18:28, Tony Przygienda &lt;</span>=
<a href=3D"mailto:[email protected]"><span style=3D"mso-bookmark:_MailOrig=
inalBody">[email protected]</span><span style=3D"mso-bookmark:_MailOrigina=
lBody"></span></a><span style=3D"mso-bookmark:_MailOriginalBody">&gt;
 wrote:<br>
<br>
<br>
<br>
On Thu, Feb 15, 2018 at 9:20 AM, Greg Shepherd&nbsp;&lt;</span><a href=3D"ma=
ilto:[email protected]"><span style=3D"mso-bookmark:_MailOriginalBody">gjshep=
@gmail.com</span><span style=3D"mso-bookmark:_MailOriginalBody"></span></a><=
span style=3D"mso-bookmark:_MailOriginalBody">&gt;&nbsp;wrote:<br>
On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda&nbsp;&lt;</span><a href=3D"=
mailto:[email protected]"><span style=3D"mso-bookmark:_MailOriginalBody">t=
[email protected]</span><span style=3D"mso-bookmark:_MailOriginalBody"></sp=
an></a><span style=3D"mso-bookmark:_MailOriginalBody">&gt;&nbsp;wrote:<br>
<br>
<br>
On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd&nbsp;&lt;</span><a href=3D"ma=
ilto:[email protected]"><span style=3D"mso-bookmark:_MailOriginalBody">gjshep=
@gmail.com</span><span style=3D"mso-bookmark:_MailOriginalBody"></span></a><=
span style=3D"mso-bookmark:_MailOriginalBody">&gt;&nbsp;wrote:<br>
For the record, there is no SR Registry. There is only an IGP Algo Type Regi=
stry as defined in draft-ietf-ospr-segment-routing-extensions-24 section 8.5=
<br>
<br>
So is that a good idea, having multiple drafts in flight with fields expecti=
ng to have magic couplings to each other&nbsp;while leaving e'thing "unspeci=
fied" to "publish RFCs" while we "decide things later"?&nbsp;<br>
<br>
That was a pivot, but still; there is no reference, there is no coupling.&nb=
sp;<br>
<br>
Tangental: draft-ietf-ospr-segment-routing-extensions-24 has been around for=
 a while, and the IGP Algo registry will be&nbsp;tied to this draft and it's=
 fate. If anyone is expecting to use this registry outside of the scope of t=
his draft, it would&nbsp;be in their best
 interest to pull the registry description out into a separate draft.<br>
<br>
<br>
OK, and I agree that if such a registry is pulled and under a clear charter o=
f mandating multiple technologies within an&nbsp;independent body then a dis=
cussion starts to make sense and what the size of that should be given that m=
andates algorithms&nbsp;over multiple
 technologies (SR, unicast, mcast, whatever) and implies a "God's eye view" o=
f all the elements of all the&nbsp;technologies (and if a computation touche=
s elements from two technologies they become [optionally] coupled). &nbsp;We=
 are not&nbsp;talking IGP registry or multicast
 computation registry or SR registry then but a "wider scope registry". Yes,=
 that is an&nbsp;intriguing thought with its own validity but outside the sc=
ope of charter we're under as BIER. &nbsp;Personally, I consider&nbsp;multip=
le, if needed loosely coupled registries for
 each technology a less centralized and hence "more Internet like"&nbsp;solu=
tion but I see how opinions on such a thing can diverge ...&nbsp;<br>
<br>
thanks<br>
<br>
--- tony&nbsp;<br>
&nbsp;<br>
<br>
<br>
_______________________________________________<br>
BIER mailing list<br>
</span><a href=3D"mailto:[email protected]"><span style=3D"mso-bookmark:_MailOri=
ginalBody">[email protected]</span><span style=3D"mso-bookmark:_MailOriginalBody=
"></span></a><span style=3D"mso-bookmark:_MailOriginalBody"><br>
</span><a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www=
.ietf.org_mailman_listinfo_bier&amp;d=3DDwMGaQ&amp;c=3DHAkYuh63rsuhr6Scbfh0U=
jBXeMK-ndb3voDTXcWzoCI&amp;r=3D-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&a=
mp;m=3D6OA-v6Lzq8oR77r5sobl4BRPQbtAOImezBFZ2ljFIHA&amp;s=3DvxlvDI3ihNiRYhMD9=
FOOhdgHsUytgoyTrVRAkLXqc5U&amp;e=3D"><span style=3D"mso-bookmark:_MailOrigin=
alBody">https://www.ietf.org/mailman/listinfo/bier</span><span style=3D"mso-=
bookmark:_MailOriginalBody"></span></a><span style=3D"mso-bookmark:_MailOrig=
inalBody"><o:p></o:p></span></p>
</blockquote>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&lt;PastedGraphic-6.png&gt;<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">_______________________________________________<br>
Isis-wg mailing list<br>
</span><a href=3D"mailto:[email protected]"><span style=3D"mso-bookmark:_Mail=
OriginalBody">[email protected]</span><span style=3D"mso-bookmark:_MailOrigin=
alBody"></span></a><span style=3D"mso-bookmark:_MailOriginalBody"><br>
</span><a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www=
.ietf.org_mailman_listinfo_isis-2Dwg&amp;d=3DDwMGaQ&amp;c=3DHAkYuh63rsuhr6Sc=
bfh0UjBXeMK-ndb3voDTXcWzoCI&amp;r=3D-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0=
VNo&amp;m=3D6OA-v6Lzq8oR77r5sobl4BRPQbtAOImezBFZ2ljFIHA&amp;s=3DgRpwwZhHBYgy=
3mRmJHvKkTmqciLemxC0YhCk0qAATNg&amp;e=3D"><span style=3D"mso-bookmark:_MailO=
riginalBody">https://www.ietf.org/mailman/listinfo/isis-wg</span><span style=
=3D"mso-bookmark:_MailOriginalBody"></span></a><span style=3D"mso-bookmark:_=
MailOriginalBody"><o:p></o:p></span></p>
</div>
</blockquote>
</div>
</div>
</blockquote>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"mso-bookm=
ark:_MailOriginalBody">&nbsp;<o:p></o:p></span></p>
</div>
</div>


</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>BIER mailing list</span><br><spa=
n><a href=3D"mailto:[email protected]">[email protected]</a></span><br><span><a href=
=3D"https://www.ietf.org/mailman/listinfo/bier">https://www.ietf.org/mailman=
/listinfo/bier</a></span><br></div></blockquote></body></html>=

--Apple-Mail-07D98455-F3CD-4B26-B1BE-C55006F2A6D4--


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

--===============8121981252913074635==--