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

--===============0708455107185921300==
Content-Type: multipart/alternative; boundary="f403045c7fa87cd1b10565a802fb"

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

>
> From an architectural view, the idea of having the IGP/routing layer have
> to understand
> BIER specifics seems an undesirable coupling.
>

very much so, in stark terms one could say that IGP is BIER signalling
while the fact that we use SPF to perform BIER nexthop calculations is a
convenient first artifact. The architecture RFC does not separate that
clearly IMO but is rather an "example" of practical BIER architecture
embodiment ;-) I do absolutely prefer it that way from practical
standpoint, abstract architectures with all degrees of flexibility written
first are hard to understand and slow to build. BIER delivered on a real
problem but after this first delivery needs the flexibility to spread its
wings into fields where IGP unicast may not be enough IMO and in any case,
IGP unicast computation coupling to BIER specific elements is unnecessary
and undesirable unless one believes e'thing is better off centralized. It
would be _highly_ unfortunate and immense waste of resources if we ended up
building another signalling just so we can perform non unicast IGP
computations.

Could someone walk me through how this would be supported in each of the
> different options?
>
> For Option D, where there is a sub-TLV and that sub-TLV can supply the
> additional non-BIER
> constraints, I understand it.
>
> For Option B - which some folks are preferring, I do not see understand
> how it would work.
>

BAR = 0 SPF, subtype can be FlexAlgo, any other IGP metric or constraint or
even an IGP registry value, this is a unicast computation
BAR = 1 SPF without BIER routers, subtype can be FlexAlgo, any other IGP
metric or constraint specification, this is a unicast computation
BAR = X (some unicast computation type)  same as 0/1

BAR = Y (multicast specific computation that IGP cnanot perform), subtype
can be anything

What is important to observe that SPF with additional constraints is as
efficient as SPF without those constraints (as long we're talking certain
convex properties AFAIR but I don't want to bore anyone with math, most of
the stuff we use today like max. BW, min. delay has this property).



> For Option A, I do not understand how it would work.
>

replace subtype with a sub-TLV so it's basically option D). I explained in
my +1/+2 my reasoning why option B) is more preferrable if you are
concerned about backwards compatibility but it's nothing architecturally
important. IGPs were muddling for years without clear distinction between
mandatory/optional TLVs are IDR has and we lived to tell the tale ;-) ...


>
> Obviously, this is going far out on a design limb - where flex-algo does
> not yet have any IETF
> support or adoption, but since it is clear that people's perspectives are
> being strongly influenced
> by what that might morph into, I think this is important for the whole WG
> to understand.
>
>
 AFAIU we have BIER RFCs that form a solid foundation to deliver now.
Things to be done in the future can obviously morph into many directions
and claim to cover any problem presented to them without much risk ...

thanks

--- tony

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Fro=
m an architectural view, the idea of having the IGP/routing layer have to u=
nderstand</div><div>BIER specifics seems an undesirable coupling.=C2=A0</di=
v></blockquote><div><br></div>very much so, in stark terms one could say th=
at IGP is BIER signalling while the fact that we use SPF to perform BIER ne=
xthop calculations is a convenient first artifact. The architecture RFC doe=
s not separate that clearly IMO but is rather an &quot;example&quot; of pra=
ctical BIER architecture embodiment ;-) I do absolutely prefer it that way =
from practical standpoint, abstract architectures with all degrees of flexi=
bility written first are hard to understand and slow to build. BIER deliver=
ed on a real problem but after this first delivery needs the flexibility to=
 spread its wings into fields where IGP unicast may not be enough IMO and i=
n any case, IGP unicast computation coupling to BIER specific elements is u=
nnecessary and undesirable unless one believes e&#39;thing is better off ce=
ntralized. It would be _highly_ unfortunate and immense waste of resources =
if we ended up building another signalling just so we can perform non unica=
st IGP computations. <br><div><br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Could som=
eone walk me through how this would be supported in each of the different o=
ptions?</div><div><br></div><div>For Option D, where there is a sub-TLV and=
 that sub-TLV can supply the additional non-BIER</div><div>constraints, I u=
nderstand it.=C2=A0</div><div><br></div><div>For Option B - which some folk=
s are preferring, I do not see understand how it would work.</div></div></b=
lockquote><div><br></div><div>BAR =3D 0 SPF, subtype can be FlexAlgo, any o=
ther IGP metric or constraint or even an IGP registry value, this is a unic=
ast computation <br></div><div>BAR =3D 1 SPF without BIER routers, subtype =
can be FlexAlgo, any other IGP metric or constraint specification, this is =
a unicast computation <br></div><div>BAR =3D X (some unicast computation ty=
pe)=C2=A0 same as 0/1<br><br></div><div>BAR =3D Y (multicast specific compu=
tation that IGP cnanot perform), subtype can be anything <br></div><div><br=
></div><div>What is important to observe that SPF with additional constrain=
ts is as efficient as SPF without those constraints (as long we&#39;re talk=
ing certain convex properties AFAIR but I don&#39;t want to bore anyone wit=
h math, most of the stuff we use today like max. BW, min. delay has this pr=
operty). <br></div><div><br>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div>For Option A, I do not understand how it would work.</div=
></div></blockquote><div><br></div><div>replace subtype with a sub-TLV so i=
t&#39;s basically option D). I explained in my +1/+2 my reasoning why optio=
n B) is more preferrable if you are concerned about backwards compatibility=
 but it&#39;s nothing architecturally important. IGPs were muddling for yea=
rs without clear distinction between mandatory/optional TLVs are IDR has an=
d we lived to tell the tale ;-) ...<br></div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>Obviously, this is g=
oing far out on a design limb - where flex-algo does not yet have any IETF<=
/div><div>support or adoption, but since it is clear that people&#39;s pers=
pectives are being strongly influenced</div><div>by what that might morph i=
nto, I think this is important for the whole WG to understand.</div><br></d=
iv></blockquote><div><br></div><div>=C2=A0AFAIU we have BIER RFCs that form=
 a solid foundation to deliver now.=C2=A0 Things to be done in the future c=
an obviously morph into many directions and claim to cover any problem pres=
ented to them without much risk ... <br><br></div><div>thanks <br><br></div=
><div>--- tony <br></div></div></div></div></div>

--f403045c7fa87cd1b10565a802fb--


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

--===============0708455107185921300==--