Subject: [Lsr] IS-IS lite (an aside)..

From: Christian Hopps <[email-masked]>
Date: Fri, 08 Mar 2019 07:22:06 -0500

[email-masked] writes:
>Robert Raszuk <[email-masked]> writes:
>>
>> See TORs are one case .. but there are ideas to run dynamic protocols to the hosts too. I have heard there was even a volunteer to write ISIS-lite to be used on hosts :)
>
> I would…. discourage that concept.

Perhaps Robert is referring to when homenet was considering using IS-IS instead of a brand new protocol (babel) for use in the homenet. The proposed solution for very simple devices (e.g. thermostats or anything w/o much ram etc) was to use the overload bit. This wasn't just for hosts though, but for very small devices that could still serve as simple router for a network behind them.

    https://www.ietf.org/archive/id/draft-mrw-homenet-rtg-comparison-02.txt

Christian Franke coded up "tinyisis" in 1500 lines of C code. :)

    https://git-us.netdef.org/projects/OSR/repos/tinyisis/browse/tinyisis.c

Thanks,
Chris.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 8 Mar 2019 12:29:40 +0000

On 3/8/19, 7:22 AM, "Lsr on behalf of Christian Hopps" <[email-masked] on behalf of [email-masked]> wrote:

    

We have " IS-IS Routing for Spine-Leaf Topology" to address resources on a TOR while still having multiple northbound links. At least in the context of flooding reduction, I don’t think we need anything IS-IS lite. 

Thanks,
Acee

    Thanks,
    Chris.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 8 Mar 2019 14:28:30 +0100

Well I was actually not talking about homenet efforts, but any small/mid
size compute clusters.

See today it is very common for hosts to participate in dynamic routing -
simply due to a fact that VMs or PODs want to be dynamically IP reachable
when they are created by orchestration.

Moreover it is not that uncommon to see flat routing requirement too in
today's DC deployments. Systems folks just do not like the additional
protocol layers :)

So what options do we have - well BGP between TOR and compute seems to be
the only option. Then in fabric there is link state or oversold BGP.

Then in the former case you have to redistribute BGP to your underlay and
if have requirement to separate reachability then at best you need to map
communities to ISIS tags at redistribution. Of course for multi-tenancy
there is zoo of other hierarchical options.

That just brings an observation that if we are spending some effort to get
link state operate lighter in densely meshed environments perhaps it does
make sense to make it work end to end too. Not that hosts need to know
entire topology so they can be happily treated as stubs, but still single
protocol operation is a big OPEX advantage.

r.

On Fri, Mar 8, 2019 at 1:30 PM Acee Lindem (acee) <[email-masked]> wrote:

>
>
> On 3/8/19, 7:22 AM, "Lsr on behalf of Christian Hopps" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>     [email-masked] writes:
>     >> See TORs are one case .. but there are ideas to run dynamic
> protocols to the hosts too. I have heard there was even a volunteer to
> write ISIS-lite to be used on hosts :)
>     >
>     Perhaps Robert is referring to when homenet was considering using
> IS-IS instead of a brand new protocol (babel) for use in the homenet. The
> proposed solution for very simple devices (e.g. thermostats or anything w/o
> much ram etc) was to use the overload bit. This wasn't just for hosts
> though, but for very small devices that could still serve as simple router
> for a network behind them.
>
>
> We have " IS-IS Routing for Spine-Leaf Topology" to address resources on a
> TOR while still having multiple northbound links. At least in the context
> of flooding reduction, I don’t think we need anything IS-IS lite.
>
> Thanks,
> Acee
>
>
>     Thanks,
>     Chris.
>
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: Christian Hopps <[email-masked]>
Date: Fri, 08 Mar 2019 08:36:31 -0500

FWIW, this use of IS-IS was not adopted by homenet, which is why we now have babel wg.

Thanks,
Chris.

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 8 Mar 2019 09:21:51 -0800

Somewhat Apple & Kiwi comparisons all over the place here a bit IMO.
Assuming we seem to be talking about ROTH in IP fabrics mainly ...

a) Babel was solving wireless mesh problem, extremely different from wired
fabrics and Babel as solution was IMO fully justified and superior to
suggested ISIS stuff (simplicity, convergence @ high link failure rates,
use of inherent wireless broadcast and so on, inherent, simple
source-routing possible) to anything else based on e.g. Battle-Mesh
comparisons. RPL could probably have done the job as well but no'one seemed
to have looked there ;-) MANET did a decent job as well but a link-state
will be always much "fatter" for "simple" stuff than DV (observe I'm
talking RIP variety, not the differential update path vector like BGP),
just nature of even basic flooding and LSDB maintainance code unless you
want to skip retransmissions, CSNPs and all the other good stuff  ... And
BTW, almost anything can be written in 1000 lines of code if you cut enough
corners, make the lines long enough and hard-code wire formats in byte
arrays but those things are not really what I'd call "reasonable solutions"
often ;-) You can even make an art out of it if you look @
https://www.ioccc.org/ . I digress as usual ...
b) getting default route into the host and host address out has a million
possiblities, even DHCP hacks will do ;-) The fun starts when servers
multi-home and when the first links fail and hosts start to blackhole
merrily or when hosts start to seriously move things around or bring tons
addresses up/down for e.g. service scaling ... Yes, in a somewhat limited
fashion Naiming's & Les's ISIS bolts can deal with the issue @ cost of high
configuration necessity (I give Naiming that he seemed to have been the
first to start thinking about the issues and tinker around ;-), scale
limitations (which can be somewhat dealt with by using RFC7356 but is that
'old-ISIS' anymore even?) and very interesting behavior if you happen to be
less than super-human and miswire your fabric here and there ;-)
c) if you think through more problems involved in this deeper and want to
properly tackle them long-term you problably know by now what the real
answer is I pursuit ;-)

--- tony

On Fri, Mar 8, 2019 at 5:36 AM Christian Hopps <[email-masked]> wrote:

> > We have " IS-IS Routing for Spine-Leaf Topology" to address resources on
> a TOR while still having multiple northbound links. At least in the context

---

From: Christian Hopps <[email-masked]>
Date: Fri, 08 Mar 2019 14:00:08 -0500

I think my email is being taken way too seriously. Please note it was "an aside"

Also I feel the need to defend Christian's code here. Did you check the code prior to the comments? I don't see a lot of obfuscation, in fact I see code for printing data for user consumption (e.g., id2str, etc), DIS election, and it even includes jittered timers, which must means it's at least half-way serious, right?. :)

For a proof-of-concept project, I'd say good job.

Thanks,
Chris.

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 8 Mar 2019 13:22:33 -0800

On Fri, Mar 8, 2019 at 11:00 AM Christian Hopps <[email-masked]> wrote:

> Also I feel the need to defend Christian's code here. Did you check the
> code prior to the comments? I don't see a lot of obfuscation, in fact I see
> code for printing data for user consumption (e.g., id2str, etc), DIS
> election, and it even includes jittered timers, which must means it's at
> least half-way serious, right?. :)
>
ack, you made me curious and I looked @ it. Yeah, I admit it's readable,
quite clean code albeit AFAIS e'thing (obviously) massively hardcoded, one
fragment, no CSNP, no PSNP processing or sending (and how does that work I
was wondering or is he leaving the neighbor retransmitting forever ?) Even
with that 1.5KLOC is very small ...

interesting datapoint in itself and sorry if I was bit flipant, mea culpa
...

--- t