June 2020 - NANOG - lists.nanog.org

Re: [c-nsp] LDPv6 Census Check
by Mark Tinka 11 Jun '20

11 Jun '20

On 11/Jun/20 17:32, David Sinn wrote: > Respectfully, that is deployment dependent. In a traditional SP topology that focuses on large do everything boxes, where the topology is fairly point-to-point and you only have a small handful of nodes at a PoP, labels can be fast, cheap and easy. Given the lack of ECMP/WECMP, they remain fairly efficient within the hardware. > > However if you move away from large multi-chip systems, which hide internal links which can only be debugged and monitored if you know the the obscure, often different ways in which they are partially exposed to the operator, and to a system of fixed form-factor, single chip systems, labels fall apart at scale with high ECMP. I'm curious about this statement - have you hit practical ECMP issues with label switching at scale? We have ECMP'ed label switch paths with multiple paths for a single FEC all over the place, and those work fine both on Cisco and Junos (of all sizes), both for IPv4 and IPv6 FEC's. Have done for years. Unless I misunderstand your concern. Mark.

1 0

RE: [c-nsp] LDPv6 Census Check
by adamv0025＠netconsultings.com 11 Jun '20

11 Jun '20

> From: David Sinn > Sent: Thursday, June 11, 2020 4:32 PM > > However if you move away from large multi-chip systems, > to a system of fixed form-factor, single chip systems, labels fall > apart at scale with high ECMP. Needing to enumerate every possible path > within the network or having to have a super-deep label stack removes all of > the perceived benefits of cheap and simple. > Looks like the deployments you describe are large DC Clos/Benes fabric, then the potentially deep label imposition would be done by the VMs right? On transit nodes the 64x ECMP or super-deep labels is no problem for NPU/lookup process as it's always just top label lookup and resolving to a single egress interface. adam

1 0

Re: [c-nsp] LDPv6 Census Check
by Saku Ytti 11 Jun '20

11 Jun '20

On Thu, 11 Jun 2020 at 21:04, David Sinn <dsinn(a)dsinn.com> wrote: > You've made my point for me. If you are building the core of your network out of MX's, to turn a phrase, in a past life "I fully support my competitors to do so". Large numbers of small boxes, as they have already shown in the data-center, have major cost, control and operational advantages over a small number of large ones. They also expose the inherent problems of label-switching and where IP has it's merits. Except this implementation does not exist, but we can argue that is missing feature. We can argue we should be able to tell the lookup engine this CIDR is on-chip and it's host routes only. This is certainly doable, and would make IP tunnels like MPLS tunnels for lookup cost, just larger lookup key, which is not significant cost. But even if we had this (we don't, we have for MPLS) IP would be still inferior, it is more tunneling overhead, i.e. I need more overspeed. Technically MPLS is just better tunneling header. I can understand sentimental arguments for IPv4 and market seems to appreciate those arguments particularly well. -- ++ytti

1 0

Re: [c-nsp] LDPv6 Census Check
by Saku Ytti 11 Jun '20

11 Jun '20

On Thu, 11 Jun 2020 at 18:32, David Sinn <dsinn(a)dsinn.com> wrote: > However if you move away from large multi-chip systems, which hide internal links which can only be debugged and monitored if you know the the obscure, often different ways in which they are partially exposed to the operator, and to a system of fixed form-factor, single chip systems, labels fall apart at scale with high ECMP. Needing to enumerate every possible path within the network or having to have a super-deep label stack removes all of the perceived benefits of cheap and simple. The arguments about IP lookups being slow is one best left to the 1990's when it was true. Fixed pipeline systems have proven this to be false. It continues to be very much true. IP lookups require external memory, which takes SERDES, which could be used for revenue otherwise. IP lookups are slow, expensive and complex, fundamentally, no amount of advancement will change this fundamental nature. Sure we can come up with all kind of implementations which bridge the gap, but the gap is there. If we take say JNPR MX, your lookup speed isn't limited by the instruction count on the PPE, the PPE spends most of its time sleeping, when the platform is fully PPS congested, the PPE is waiting for the memory to return! -- ++ytti

1 0

Re: [c-nsp] LDPv6 Census Check
by Mark Tinka 11 Jun '20

11 Jun '20

On 11/Jun/20 14:43, Gert Doering wrote: > > Not "in addition to" but "to throw out the IPv4 part" :-) That's another view-point, yes. There are plenty of networks that can't afford to keep buying IPv4 on the open market. They want to go single-stack IPv6. Today, you would need to build a 6PE network if you want MPLS support in your IPv6-only network, which still requires IPv4. Private IPv4 address space works, but some people like it, some don't, and more importantly, you still carry around IPv4. You could try the SRv6 gravy, but now you probably need new kit. What's the SRv6 business-case? Well, one would say you save millions of $$ not buying IPv4, but now you've spent money supporting SRv6. LDPv6 can be supported by any platform that supports MPLS today. No money out the door. Cisco would need to develop code for both LDPv6 and SRv6 anyway, so no harm done on that side. As we used to say in Vladivostok, "It's simple physics :-)". > (If I had LDPv6 today, I wouldn't actually change the existing network > today. But for the next round of rebuilding things, it would be something > to consider...) Give your favorite Cisco AM a shout-out. I promise, they are probably too young to remember your 6500/7600 tickets :-). Mark.

1 0

Re: [c-nsp] LDPv6 Census Check
by Mark Tinka 11 Jun '20

11 Jun '20

On 11/Jun/20 13:03, Drikus Brits wrote: > We're deploying some new POPs with a mix of IOS-XR as borders, BNG and > PEs and IOS-XE for LNSs. LDPv6 would be awesome to have availabke on > IOS-XE alongside LDPv4. We're being pushed by Cisco to go one flavour > or another of SR as well by Cisco, but i'd much prefer to have LDPv4 & > LDPv6 right now. > > We have some buying power with Cisco at the moment, so let me know how > I can help from the land 'down under'. Thanks, Drikus. If you can get your AM to get in touch with the ASR920 and ASR1000 BU's to ask for LDPv6, that will help a great deal. Cisco are saying "no one" is asking for LDPv6, forgetting that it's more about IPv6, than other lower/higher-level services it can support, LDPv6 included. As with you, they are trying to shove SRv6 down our throats, which can only come on an NCS540 for the moment, which is odd since that runs IOS XR, which supports LDPv6. So basically, swap out tons of boxes to get a feature that can easily be coded for in existing hardware... makes you wonder about the thought-process; It's been a crazy two weeks with our Cisco AM's and the platform TME's on heated calls about this that it's almost old testament biblical :-). It's at the stage where it's going up the chain to the BU's who will make the final call. So if they can get some noise from you as well, it certainly won't hurt. You don't need new hardware features on the ASR920 or ASR1000 to support LDPv6. You might do for SRv6. Either way, both platforms would need both features developed in code, and I think it's safe to assume which one will be practically easier to build and roll-out to the entire MPLS customer base, today. Mark.

1 0

Re: [c-nsp] LDPv6 Census Check
by Saku Ytti 11 Jun '20

11 Jun '20

On Thu, 11 Jun 2020 at 12:57, Robert Raszuk <robert(a)raszuk.net> wrote: > Nope that was not the main reason. > > Main reason was the belief that labels MUST be locally significant - and not domain wide unique. Just look at Juniper's SRm6 or now SRH ... they keep this notion of locally significant SIDs. It is deep in their DNA ... still. Seems weird, because neither LDP or SR implies globally significant labels, implementation choice. What SR does imply is a continuous block of labels of equal size in domain. > Now to your runt that MPLS is great because of exact match perhaps you missed it but number of solutions on the table (including RbR[**] I recently proposed) use exact match 4B locator based lookup in the v6 packets to get from segment end to segment end. Which is making a simple thing a complex thing. > On the other hand your comments about greatness of MPLS ... simplified data plane and depending on the hardware difference in jitter (in sub ms ranges - if that even matters) comes up with a lot of control plane complexity when you want to build a network across all continents, yet keep it scoped from IGP to areas or levels. No summarization in MPLS in FECs is something we should not sweep under the carpet. MPLS complexity is trivial in control-plane and forwarding-plane compared to IPV6 or SRv6 or RbR[**]. I'm not saying we can't do better than MPLS, but the proposal here is blatantly worse. -- ++ytti

1 0

Re: [c-nsp] LDPv6 Census Check
by Mark Tinka 11 Jun '20

11 Jun '20

On 11/Jun/20 11:57, Robert Raszuk wrote: > > Nope that was not the main reason. > > Main reason was the belief that labels MUST be locally significant - > and not domain wide unique. Just look at Juniper's SRm6 or now SRH ... > they keep this notion of locally significant SIDs. It is deep in their > DNA ... still. > > We argued about it a lot in cisco back in TDP days - and we lost. I get this for VLAN's, being only 4,096 per broadcast domain and all. But are we struggling with scaling label space? Just my 1+1, since I may be over-simplifying the issue. > > - - - > > Now to your runt that MPLS is great because of exact match perhaps you > missed it but number of solutions on the table (including RbR[**] I > recently proposed) use exact match 4B locator based lookup in the v6 > packets to get from segment end to segment end. > > On the other hand your comments about greatness of MPLS ... simplified > data plane and depending on the hardware difference in jitter (in sub > ms ranges - if that even matters) comes up with a lot of control plane > complexity when you want to build a network across all continents, yet > keep it scoped from IGP to areas or levels. No summarization in MPLS > in FECs is something we should not sweep under the carpet. I found multi-level IS-IS to be useless in an MPLS network because you still need to leak routes between L2 and L1 in order to form MPLS FEC's. So you simplify the network by having a single L2 (or just Area 0 in OSPF), because today's control planes can handle it. And yes, some are brave enough to run RFC 3107 if it becomes a problem, but if you can afford to string a network together across all continents, I doubt an x86-based control plane with 64GB of RAM is topping the list of your problems. Mark.

1 0

Re: [c-nsp] LDPv6 Census Check
by Mark Tinka 11 Jun '20

11 Jun '20

On 11/Jun/20 09:58, Radu-Adrian FEURDEAN wrote: > Well, given their (Cisco's) braindead policy regarding non-implementation of LDPv6 on XE, no wonder people are looking for alternatives, and SRv6 is one of them. Which doesn't track because there are a number of IOS XE boxes that do not support SRv6, and probably never will. Meanwhile, no issue with those boxes supporting LDPv6, as they already support LDPv4. > And don't forget SRv6 is also heavily associated (marketing-wise) with 5G.... Well, we all know the farce that is 5G. Also, not all of us run mobile networks, and even for those that do, there are probably a few that don't buy into the snake oil, especially those that offer native IPv6 to their mobile customers :-). > Back to our friends and their policy: It happens that in certain regions of the world, if you want to be an ISP other than the "establishment" (== incumbent + "first alternatives" that started 20-25 years ago), you MUST have LNS (if you want to stay in business). If like many, you are kind of stuck with Cisco because it's Cisco, the only decent solution to have LNS is ASR1K (running XE). Also add ASR920 which has a number of uses. Also, in order to stay in business, you may want to offer L3VPN services, which brings you to doing MPLS. You say MPLS, you say LDP, and there you go, your backbone remains v4-based for the next eternity. Which I would understand if Cisco's strategy, as a company, was anti-LDP. But when you have the IOS XR team actively supporting LDP and adding new features with each major release, the split brain is obvious. You can't come to me under a "unified" organizational banner, and then tell me you are a-thousand companies internally. If you choose to fork code into IOS, IOS XE, IOS XR, NX OS, or whatever new flavour of the decade, don't make that my problem. Customers don't buy code; they buy boxes that are built for the task. The code that comes with it is the code that comes with it. Moreover, IOS XE also has its own split BU's. So getting IOS XE fixed for the ASR920 doesn't necessarily mean you get it fixed for the ASR1000. I mean, how much more complicated does a business have to be? > > There also seems to be a lack of global vision. Tyry to ask your favourite vendor what do you need in order to be able to offer IPv4-L3VPN, IPv6-L3VPN and L2VPN (mainly point-to-point - NO MAC learning) over a backbone that does NOT use any single IPv4 address (backbone-side). Because you can do it on a backbone that does not use any single IPv*6* address, but you may want to go forwards, not backwards. Add a LNS in the mix (the v4 addresses for the LNS go in VRFs - that's not backbone). Add a money, rack space and power needed constraints in the mix. This exercise looks challenging with other vendors too, but with Cisco it's just impossible. That's because it's not about l3vpn6 or l2vpn6; it's about IPv6. And you can't business-case IPv6. Some vendors fail to understand that IPv6 is not the money-maker. IPv6 is what attracts the customer to the network so that the money can flow. It's a means to an end, not the end in itself. > > Of course, Cisco says there is no demand for one simple reason : the people talking with Cisco account managers (or whatever they are called) are only rarely those that care about technical stuff. They may want some features on the CPEs (like "ui uant SDWAN"), but for anything else (including backbone equipment) they only want lower prices. You end up with everybody having to deal with a specific platform in real life to dream about a specific feature, yet the vendor to consider that "nobody wants it". One of the reasons I've never been keen on working for a vendor is tunnel vision becomes easy. As an operator, you have a much wider view of what's happening in the real world. When a vendor decides to home-in on EoMPLS and VPLS being better signaled by LDP vs. BGP, you end up with situations where they track user-demand through the number of TAC cases the feature caused. The fewer the TAC cases, the lower the demand. Very scientific. Nobody is going to demand LDPv6 because the over-arching problem is a lack of IPv6 deployment at global scale. If folk don't deploy IPv6, they will not think about LDPv6, RSVPv6, e.t.c. But to make it worse, if the vendors keep encouraging the "big-spending" mobile operators to maintain IPv4 by selling CGN licenses, it's kind of back-to-front, isn't it? No operator unwilling to deploy IPv6 but favours CGN is ever going to ask a vendor about LDPv6, especially if the vendor is in charge of building and operating that backbone as a "professional, managed service". Ultimately, we are not asking for an ASIC re-spin. We are not asking for a doubling of forwarding capacity. We are not asking for a greener chassis. We are not asking for 100Gbps ports. All of which are physically impossible. We are asking for LDP to extended to support IPv6. Really, how hard is that? Mark.

2 2

Update your ARIN IRR data access methods (was: Fwd: [arin-announce] New Internet Routing Registry Release)
by John Curran 10 Jun '20

10 Jun '20

NANOGers - ARIN has released its updated IRR system - if you are relying on ARIN’s IRR data, please refer to details below and update access methods accordingly. Thanks! /John John Curran President and CEO American Registry for Internet Numbers Begin forwarded message: From: ARIN <info(a)arin.net<mailto:info@arin.net>> Subject: [arin-announce] New Internet Routing Registry Release Date: 10 June 2020 at 2:34:55 PM EDT To: <arin-announce(a)arin.net<mailto:arin-announce@arin.net>> ARIN is pleased to announce the release of new and updated Internet Routing Registry (IRR) features. Full release notes are included below this message. ARIN systems are operating normally. If you have questions, comments, or issues, please submit an Ask ARIN ticket using your ARIN Online account, or contact the Registration Services Help Desk by phone Monday through Friday, 7:00 AM to 7:00 PM ET at +1.703.227.0660. Regards, Mark Kosters Chief Technology Officer American Registry for Internet Numbers (ARIN) Release Notes This release consists of IRR additions and improvements. The following information is provided to assist you in using ARIN’s IRR. Obtaining Routing Information from ARIN’s IRR Using FTP ARIN’s IRR information can be obtained from ftp://ftp.arin.net/pub/rr/. The FTP site provides two sources that have been migrated from ARIN’s IRR: one for authorized objects and one for nonauthorized objects. Authorized objects have been verified that the organization is authorized to create the record and that the registration associated with the object is under an (L)RSA. What do I need to change after this IRR deployment to use FTP? * If you are obtaining IRR information via FTP, to get all ARIN objects, you’ll need to access two separate sources: ARIN (arin.db.gz) and ARIN-NONAUTH (arin-nonauth.db.gz). Note that the source files are in a new, zipped format (.gz). Using Near Real-Time Monitoring (NRTM) ARIN provides two NRTM streams: ARIN (which contains authorized objects, as previously described) and ARIN-NONAUTH (which contains nonauthorized objects). What do I need to change after this IRR deployment to use NRTM? * Add the new NONAUTH stream to your monitoring. The serial number for this stream is found at https://ftp.arin.net/pub/rr/ARIN-NONAUTH.CURRENTSERIAL * Update the current ARIN (authorized) stream serial number; this number is found at https://ftp.arin.net/pub/rr/ARIN.CURRENTSERIAL Whois Port 43: You can access ARIN’s IRR database for both ARIN and ARIN-NONAUTH sources (which is running IRR Daemon, or IRRd) by entering commands from a terminal window. There are no changes to this functionality after the deployment. Managing Routing Information in ARIN’s IRR ARIN now provides a new method to manage IRR data directly in ARIN Online by selecting IRR Object Records from the main navigation menu. Organizations who currently use ARIN’s email-template based system (IRR-email) can continue to use that system, but no new organizations will be added to the IRR-email system. Your data from the IRR-email system has been migrated and is available for viewing in ARIN Online, but migrated IRR objects cannot be modified in ARIN Online. (Only IRR objects created in ARIN Online can be modified in ARIN Online.) What do I need to do as a result of these changes? - If you are currently using IRR-email and you want to continue to use that system, no action is needed. (You cannot use both IRR-email and ARIN Online to manage your IRR data.) - If you are currently using IRR-email and you want to start using ARIN Online to manage your IRR data, upon your first use of IRR in ARIN Online, you’ll be asked to confirm that you want to switch to ARIN Online to manage your IRR data. You’ll have to agree to this change before proceeding. If you start using IRR-online, you will no longer have access to IRR-email. _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce(a)arin.net<mailto:ARIN-announce@arin.net>). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-announce Please contact info(a)arin.net if you experience any issues.

3 2