[Lsr] I-D Action: draft-ietf-lsr-isis-spine-leaf-ext-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : IS-IS Routing for Spine-Leaf Topology Authors : Naiming Shen Les Ginsberg Sanjay Thyamagundalu Filename: draft-ietf-lsr-isis-spine-leaf-ext-01.txt Pages : 17 Date: 2019-03-08 Abstract: This document describes a mechanism for routers and switches in a Spine-Leaf type topology to have non-reciprocal Intermediate System to Intermediate System (IS-IS) routing relationships between the leafs and spines. The leaf nodes do not need to have the topology information of other nodes and exact prefixes in the network. This extension also has application in the Internet of Things (IoT). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-spine-leaf-ext/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-isis-spine-leaf-ext-01 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-spine-leaf-ext-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-spine-leaf-ext-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] IS-IS lite (an aside)..
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. Tony Przygienda writes: 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 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) 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 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 signature.asc Description: PGP signature ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] IS-IS lite (an aside)..
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 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) 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 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
Re: [Lsr] IS-IS lite (an aside)..
FWIW, this use of IS-IS was not adopted by homenet, which is why we now have babel wg. Thanks, Chris. Acee Lindem (acee) writes: On 3/8/19, 7:22 AM, "Lsr on behalf of Christian Hopps" wrote: tony...@tony.li writes: >Robert Raszuk 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 signature.asc Description: PGP signature ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] IS-IS lite (an aside)..
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) wrote: > > > 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 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
Re: [Lsr] IS-IS lite (an aside)..
On 3/8/19, 7:22 AM, "Lsr on behalf of Christian Hopps" wrote: tony...@tony.li writes: >Robert Raszuk 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] IS-IS lite (an aside)..
tony...@tony.li writes: Robert Raszuk 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. signature.asc Description: PGP signature ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
