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 <cho...@chopps.org> wrote:

>
> FWIW, this use of IS-IS was not adopted by homenet, which is why we now
> have babel wg.
>
> Thanks,
> Chris.
>
> Acee Lindem (acee) <a...@cisco.com> writes:
>
> > On 3/8/19, 7:22 AM, "Lsr on behalf of Christian Hopps" <
> lsr-boun...@ietf.org on behalf of cho...@chopps.org> wrote:
> >
> >
> >     tony...@tony.li writes:
> >     >Robert Raszuk <rob...@raszuk.net> 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
> >
> > 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
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to