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

--===============2733032658483542125==
Content-Type: multipart/alternative; boundary="94eb2c0da4127181b60565a90720"

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

On Tue, Feb 20, 2018 at 10:25 AM, IJsbrand Wijnands <[email protected]> wrote:

> Tony,
>
> > Now, what BAR registry would give us is a "layering of constraints" if
> you want, i.e.  BAR=3D1 (since this is a very tanglible example, another =
one
> would be max. degree of fanout or things like max-label-depth e.g.)  woul=
d
> take care of the BIER specific constraints without IGP knowing about it i=
n
> architectural terms.  On top of that IGP applies its constraints (BW,
> delay, whatever) but it's really not  BIER problem, we are just happy
> riders on coattails of the hard IGP work ;-)
>
> If you want to build a table for BIER, you need to have a way to
> associate/signal the different constraints that need to be used. In my
> mind, this is not coming from the IGP, but needs to be signalled in the
> context BIER. Like how you signal BIER-ONLY as algorithm. Or, statically
> configured as part of the Sub-Domain. Obviously what is required here is =
a
> architecture draft that explains how this all should work.
>

yes, staticially configured BIER computaton constraints could work but then
routers cannot detect mismatch. A very heavy disadvantage ...

Architecture is something we can talk in London if you see value in that,
sure. For the record, I however vastly prefered the direction (mainly)
you/Eric gave from start on which was "enough architecture to get important
first application done", hence I was never pushing some some grand
cathedral building scheme. Maybe after this is in place we should have this
in London, it's the call of the day one core group that carried the banner
where there was nothing but first hill to take ;-)

My suggestion is, let us work out either option B) or Eric's proposal as
flexible and orthogonal scheme to ground the IGPs and then fall out the
rest over it ...  As you observed, I'm big believer in maybe overbuilding a
tad in flexibility or size in control plane to have architectural wiggle
room while in forwarding path one has to be extremely frugal to get the
silicon @ cost ...


>
> >
> > To address the "efficienty" constraint one has to be very deeply steepe=
d
> into IGP SPF computations but the result is that an implementation can
> easily incorporate constraints of all layers into a single computation (S=
PF
> practically speaking) unless they lead to NP complete combinations (so
> .e.g. having something that is max-bw @ guaranteed delay is far from
> simple) ...
> >
> > So let's say we put the IGP signalling under a new cool IGP  (eeeh, I'm
> building one ;-)  and we do not want to shake their whole IGP standard
> saying "hey, you know, we have this BIER Stuff you must encode on your IG=
P
> elements (beside us being a subTLV) and put in your registries to do the
> right thing", if we have BAR we can just tell them, ok, encoding wise, js=
ut
> give us your SPF-on-steroids registry and we use that as subtype,
> underneath that we plug in BAR in our encoding, i.e. we just use them as
> signalling channel while constraining the SPF. We're done.  Obviously the
> SPF has to be modified to respect the union of all constraints but the
> alternative is worse, i.e. I have to be running multiple passes prunning
> things (which are practically far less desirable since we are loosing ver=
y
> cool stuff like LFA which I'm sure we could solve as well but get for fre=
e
> if we just prune the SPF @ runtime)
> >
> > I do hope that parses and I  make sense. I tried to be as terse as I
> managed and I know I am bad at that =E2=80=A6
>
> You lost me, sorry=E2=80=A6
>

sorry, email is limited ... Not sure how to deal with that ...

--- tony

--94eb2c0da4127181b60565a90720
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 Tue, Feb 20, 2018 at 10:25 AM, IJsbrand Wijnands <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">Tony,<br>
<span class=3D""><br>
&gt; Now, what BAR registry would give us is a &quot;layering of constraint=
s&quot; if you want, i.e.=C2=A0 BAR=3D1 (since this is a very tanglible exa=
mple, another one would be max. degree of fanout or things like max-label-d=
epth e.g.)=C2=A0 would take care of the BIER specific constraints without I=
GP knowing about it in architectural terms.=C2=A0 On top of that IGP applie=
s its constraints (BW, delay, whatever) but it&#39;s really not=C2=A0 BIER =
problem, we are just happy riders on coattails of the hard IGP work ;-)<br>
<br>
</span>If you want to build a table for BIER, you need to have a way to ass=
ociate/signal the different constraints that need to be used. In my mind, t=
his is not coming from the IGP, but needs to be signalled in the context BI=
ER. Like how you signal BIER-ONLY as algorithm. Or, statically configured a=
s part of the Sub-Domain. Obviously what is required here is a architecture=
 draft that explains how this all should work.<br></blockquote><div><br></d=
iv><div>yes, staticially configured BIER computaton constraints could work =
but then routers cannot detect mismatch. A very heavy disadvantage ... <br>=
<br></div><div>Architecture is something we can talk in London if you see v=
alue in that, sure. For the record, I however vastly prefered the direction=
 (mainly) you/Eric gave from start on which was &quot;enough architecture t=
o get important first application done&quot;, hence I was never pushing som=
e some grand cathedral building scheme. Maybe after this is in place we sho=
uld have this in London, it&#39;s the call of the day one core group that c=
arried the banner where there was nothing but first hill to take ;-)<br><br=
></div><div>My suggestion is, let us work out either option B) or Eric&#39;=
s proposal as flexible and orthogonal scheme to ground the IGPs and then fa=
ll out the rest over it ...=C2=A0 As you observed, I&#39;m big believer in =
maybe overbuilding a tad in flexibility or size in control plane to have ar=
chitectural wiggle room while in forwarding path one has to be extremely fr=
ugal to get the silicon @ cost ... <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">
<span class=3D""><br>
&gt;<br>
&gt; To address the &quot;efficienty&quot; constraint one has to be very de=
eply steeped into IGP SPF computations but the result is that an implementa=
tion can easily incorporate constraints of all layers into a single computa=
tion (SPF practically speaking) unless they lead to NP complete combination=
s (so .e.g. having something that is max-bw @ guaranteed delay is far from =
simple) ...<br>
&gt;<br>
&gt; So let&#39;s say we put the IGP signalling under a new cool IGP=C2=A0 =
(eeeh, I&#39;m building one ;-)=C2=A0 and we do not want to shake their who=
le IGP standard saying &quot;hey, you know, we have this BIER Stuff you mus=
t encode on your IGP elements (beside us being a subTLV) and put in your re=
gistries to do the right thing&quot;, if we have BAR we can just tell them,=
 ok, encoding wise, jsut give us your SPF-on-steroids registry and we use t=
hat as subtype, underneath that we plug in BAR in our encoding, i.e. we jus=
t use them as signalling channel while constraining the SPF. We&#39;re done=
.=C2=A0 Obviously the SPF has to be modified to respect the union of all co=
nstraints but the alternative is worse, i.e. I have to be running multiple =
passes prunning things (which are practically far less desirable since we a=
re loosing very cool stuff like LFA which I&#39;m sure we could solve as we=
ll but get for free if we just prune the SPF @ runtime)<br>
&gt;<br>
</span>&gt; I do hope that parses and I=C2=A0 make sense. I tried to be as =
terse as I managed and I know I am bad at that =E2=80=A6<br>
<br>
You lost me, sorry=E2=80=A6<br></blockquote><div><br></div><div>sorry, emai=
l is limited ... Not sure how to deal with that ... <br><br></div><div>--- =
tony <br></div></div></div></div>

--94eb2c0da4127181b60565a90720--


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

--===============2733032658483542125==--