Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
> > On Jun 19, 2020, at 08:06, Mark Tinka wrote: > >> On 19/Jun/20 14:50, Tim Durack wrote: >> >> If y'all can deal with the BU, the Cat9k family is looking >> half-decent: MPLS PE/P, BGP L3VPN, BGP EVPN (VXLAN dataplane not MPLS) >> etc. >> UADP programmable pipeline ASIC, FIB ~200k, E-LLW, mandatory DNA >> license now covers software support... >> >> Of course you do have to deal with a BU that lives in a parallel >> universe (SDA, LISP, NEAT etc) - but the hardware is the right >> price-perf, and IOS-XE is tolerable. >> >> No large FIB today, but Cisco appears to be headed towards "Silicon >> One" for all of their platforms: RTC ASIC strapped over some HBM. The >> strategy is interesting: sell it as a chip, sell it whitebox, sell it >> fully packaged. >> >> YMMV > > I'd like to hear what Gert thinks, though. I'm sure he has a special > place for the word "Catalyst" :-). > > Oddly, if Silicon One is Cisco's future, that means IOS XE may be headed > for the guillotine, in which case investing any further into an IOS XE > platform could be dicey at best, egg-face at worst. > > I could be wrong... never underestimate the desire of product managers and engineering teams to have their own petri dishes to swim around in. -- steve ulrich (sulrich@botwerks.*)
Re: Segment Routing
On Tue, May 22, 2018 at 9:59 AM Saku Ytti <s...@ytti.fi> wrote: > On 22 May 2018 at 17:43, steve ulrich <sulr...@botwerks.org> wrote: > > Hey, > > > sorry, yes. i was referring to SRTE wrt the pop operation. > > Yup RSVP=>SR is more ambiguous and debatable than LDP=>SR which is > unambiguous win. > > > not labels but they are encoded as labels. i hope operators have the > option > > to configure common/consistent label ranges, but i don't necessarily > assume > > it. tooling to resolve this will be required just as in the LDP world. > > I've not had this tooling in LDP world, and not anticipating to need > it in SR world. But maybe I'm missing something, what kind of > information do you need in LDP world which you need to develop tooling > for, and how does the problem+solution translate to SR world? > in the day's of yore, i know a few folks who built tooling to validate and/or detect failure to sync between the IGP and LDP or detect data plane black holing behaviors caused by resolution in the RIB w/no complementary label allocation (or LDP convergence lagging significantly). implementations have come a long way since then. but yeah, IGP-LDP sync lag has been a thing for some folks. in a world of anycast/prefix-SIDs some of this doesn't necessarily go away, it just looks kind of different. though to be fair, this alignment improves (the IGP/LDP convergence sync case goes away) for all the reasons you've cited previously in this thread. -- steve ulrich (sulrich@botwerks.*)
Re: Segment Routing
sorry, yes. i was referring to SRTE wrt the pop operation. in most of the implementations i've poked at, there is the ability to specify a consistent label range, but it's not always the case. SIDs are not labels but they are encoded as labels. i hope operators have the option to configure common/consistent label ranges, but i don't necessarily assume it. tooling to resolve this will be required just as in the LDP world. On Tue, May 22, 2018 at 9:19 AM Saku Ytti <s...@ytti.fi> wrote: > Hey Steve, > > > the data plane behavior on LDP is swap oriented, while the data plane on > SR > > is pop oriented. depending on the hardware capabilities in use this may > > have (subtle) traffic engineering or diagnostic implications at a > minimum. > > folks will likely have to build tooling to address this. > > I think you're thinking of SR-TE, SR in normal LDP-like use case would be > single > egress label with swap on LSRs. > > Ingress PE would figure out label by using egress PE index as an > offset to next-hop > P's label range. > Nexthop P would swap the label determining out label using same mechanism. > > I practice operators would configure same label range in every box, so > swap would be > from same label to same label. But that is purely due to operator > configuration, and > it's still swap. > > -- > ++ytti > -- steve ulrich (sulrich@botwerks.*)
Re: Segment Routing
fwiw - there's a potentially significant loss of visibility w/SR from a traffic management perspective depending on how it's deployed. though, i doubt the OP is really driving at this point. the data plane behavior on LDP is swap oriented, while the data plane on SR is pop oriented. depending on the hardware capabilities in use this may have (subtle) traffic engineering or diagnostic implications at a minimum. folks will likely have to build tooling to address this. we're pushing the bubble of complexity around. On Tue, May 22, 2018 at 8:47 AM Saku Ytti <s...@ytti.fi> wrote: > On 22 May 2018 at 11:19, Matt Geary <matt.ge...@gmail.com> wrote: > > > really seeing the value of SR to replace LDP on my backbone. With some > > scripting and lots of software tools I can make it just like LDP, but > why? > > So break the ease of LDP just to get label switching on my hub core not > > really seeing it, unless someone has done it and they are seeing the > value. > > Can you elaborate what scripting and software tools are needed? If you'd > talk > about RSVP particularly AutoBW and SR, then yeah, but SR on itself should > be less of a chore than LDP. > > SR is what MPLS was intended to be day1, it just wasn't very marketable > idea > to sell MPLS and sell need for changing all the IGPs as well. > LDP is added state, added signalling, added complexity with reduced > visibility. > SR is like full-mesh LDP (everyone has everyone's label POV), while also > removing one protocol entirely. > > -- > ++ytti > -- steve ulrich (sulrich@botwerks.*)
Re: in defense of lisp (was: Anybody can participate in the IETF)
On Wed, Jul 13, 2011 at 10:07 AM, Cameron Byrne cb.li...@gmail.com wrote: On Jul 13, 2011 7:39 AM, Scott Brim scott.b...@gmail.com wrote: On Wed, Jul 13, 2011 at 10:09, Randy Bush ra...@psg.com wrote: btw, a litte birdie told me to take another look at 6296 IPv6-to-IPv6 Network Prefix Translation. M. Wasserman, F. Baker. June 2011. (Format: TXT=73700 bytes) (Status: EXPERIMENTAL) which also could be considered to be in the loc/id space randy No, that's a misuse of loc/id since no identification is involved, even at the network layer -- but it is in the reduce issues in global routing and local renumbering space (that's part of what LISP does). Cameron: As for ILNP, it's going to be difficult to get from where things are now to a world where ILNP is not just useless overhead. When you finally do, considering what it gives you, will the journey have been worth it? LISP apparently has more benefits, and NPT6 is so much easier -- particularly if you have rapid adaptation to apparent address changes, which many apps have and all mobile devices need already -- sorry but I don't think ILNP is going to make it. You can't just say the IETF should pay more attention. I've invited people to promote it and nobody stepped up. Difficult depends on your time horizon. Ipv6 is/was difficult. Sctp is difficult, but I remain bullish on its value. ILNP may be more difficult, but i believe it is strategically correct. We can disagree on merits of competing RESEARCH topics. I am just providing ops feedback , to bring this thread full circle. Lastly, we must make sure that LISP does not become the next 6to4 where good intentions for RESEARCH become a quantifiable network nightmare. i would agree that LISP hasn't necessarily improved the root problem posed. however, on this front nor it hasn't done any harm. the intriguing elements with LISP for me personally, are in all of the adjunct capabilities that a L/I split enables. there are some very valid and interesting applications that this enables and some novel technology capabilities that are exercised. (useful endpoint mobility, novel load balancing, encap data plane liveness, etc.) researching and getting our hands dirty as an industry with these technologies has considerable value. without actually poking at running code and pushing bits over these interfaces we run the risk of letting the perfect be the enemy of the good. i like the fact that this research let's us gauge how far from perfect the current state of the art is. fwiw - while there are folks that see LISP as an impending ops nightmare (if you don't like it, don't use it.) there are a number of folks for whom it provides compelling solutions to real problems that they have and they're keen on using it to solve those problems or explore the solution space. to that end i don't know that we need to make sure that LISP doesn't become anything. we need to find solutions to problems and rationally explore those solutions and incrementally enhance them. yes. i participate in the LISP research test bed in my (very) small way. -- steve ulrich (sulrich@botwerks.*)
Re: IPv6 Addressing Help
i believe this is recently trod NANOG ground. i've seen a number of folks exploring techniques very similar to this from an addressing plan perspective. it's simple, intuitive and if you don't like it, well, you are free to craft your own. in either event it's a practical discussion of some of the considerations. http://nanog.org/meetings/nanog46/abstracts.php?pt=MTM3MyZuYW5vZzQ2nm=nanog46 On Fri, Aug 14, 2009 at 10:59 AM, Celeste Andersonceles...@usc.edu wrote: Sounds like an excellent topic for a tutorial/talk/panel at the next NANOG. --celeste. - Original Message - From: Chris Gotstein ch...@uplogon.com Date: Friday, August 14, 2009 8:04 am Subject: IPv6 Addressing Help To: Nanog nanog@nanog.org We are a small ISP that is in the process of setting up IPv6 on our network. We already have the ARIN allocation and i have a couple routers and servers running dual stack. Wondering if someone out there would be willing to give me a few pointers on setting up my addressing scheme? I've been mulling over how to do it, and i think i'm making it more complicated than it needs to be. You can hit me offlist if you wish to help. Thanks. -- steve ulrich (sulr...@botwerks.*)
