Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

--===============7800455575217325032==
Content-Type: multipart/alternative; boundary="089e082f6a447e81230565ae2bff"

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

>
> Future specifications may specify BART values that change the
> interpretation of the BARM octet. Those specifications must handle
> backwards
>
>
> ICE: This creates a potential dependency which I think we should avoid. I
> think there are possible use-cases where the combination of the two value=
s
> could be valuable. But since we don=E2=80=99t yet know what that is, lets=
 not
> speculate on it. Let keep both values as equal importance without
> interdependency.
>


And I happen to think that if this proposal has any merit this is precisely
the paragraph we have to keep to make sure that not every possible BART
value is being slaved to IGP Registry Algorithm a.k.a as BARM then ...
Without this section we would be mandating that BARM is always an IGP
algorithm or FA so basically it would mandate IGP Algorithm registry as the
only option to perform a calculation making BART possibly pretty much
useless ... Having a registry being mapped 1:1 into  another registry known
as identity makes them both them the same thing by another name.

So, to get anywhere close to consensus let's get bit less creative maybe
and stick to the four letters of the alphabet that the AD extended as a
wide playing field and the WG seems to converge around ... Or otherwise
stick to option F) unmodified and see who's interested in it unless you
insist on creating an option G) ...

thanks

--- tony

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div><sp=
an class=3D""><blockquote type=3D"cite">=C2=A0<br>Future specifications may=
 specify BART values that change the<br>interpretation of the BARM octet. T=
hose specifications must handle backwards<br></blockquote><div><br></div></=
span><div>ICE: This creates a potential dependency which I think we should =
avoid. I think there are possible use-cases where the combination of the=C2=
=A0two values could be valuable. But since we don=E2=80=99t yet know what t=
hat is, lets not speculate on it. Let keep both values as equal importance =
without interdependency.<br></div><span class=3D""></span></div></div></blo=
ckquote><div><br><br></div><div>And I happen to think that if this proposal=
 has any merit this is precisely the paragraph we have to keep to make sure=
 that not every possible BART value is being slaved to IGP Registry Algorit=
hm a.k.a as BARM then ... Without this section we would be mandating that B=
ARM is always an IGP algorithm or FA so basically it would mandate IGP Algo=
rithm registry as the only option to perform a calculation making BART poss=
ibly pretty much useless ... Having a registry being mapped 1:1 into=C2=A0 =
another registry known as identity makes them both them the same thing by a=
nother name. <br><br></div><div>So, to get anywhere close to consensus let&=
#39;s get bit less creative maybe and stick to the four letters of the alph=
abet that the AD extended as a wide playing field and the WG seems to conve=
rge around ... Or otherwise stick to option F) unmodified and see who&#39;s=
 interested in it unless you insist on creating an option G) ... <br><br></=
div><div>thanks <br><br></div><div>--- tony <br></div><div><br>=C2=A0<br></=
div></div></div></div>

--089e082f6a447e81230565ae2bff--


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

--===============7800455575217325032==--