- Test - lists.nanog.org

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 11 Jun '20

11 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

Outsourced NOC Solutions
by Rod Beck 10 Jun '20

10 Jun '20

Hi, My colleague and I may be running a new dark fiber network in the Northeast. We need an outsourced NOC to monitor for fiber cuts and serve as a contact point for customers. Am I wrong in believing that there should be a way of lighting a single pair in the cable and then monitoring it for signal disruption? It is not a perfect solution, but arguably better than learning that the cable has been damaged from an irate customer. Best to take any replies off the message board. Thanks. Regards, Roderick. Roderick Beck VP of Business Development United Cable Company www.unitedcablecompany.com<http://www.unitedcablecompany.com> New York City & Budapest rod.beck(a)unitedcablecompany.com Budapest: 36-70-605-5144 NJ: 908-452-8183 [1467221477350_image005.png]

15 24

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

10 Jun '20

On 10/Jun/20 21:20, Gert Doering wrote: > Oh. Indeed, sorry for being unclear here. > > SR/MPLS sounds like a good idea (reducing label state). > > SR/IPv6 does not sound convincing. +1. 2010 - 2019 has been a decade of "pushing stuff". 2020 is the year of deciding what snake oil no longer deserves energy, the Coronavirus notwithstanding. Mark.

1 0

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

10 Jun '20

On 10/Jun/20 21:17, Gert Doering wrote: > > We do have IOS XEs today (ASR920), and based on that, we're not going > to buy new IOS XE devices any time soon. > > The amount of... strangeness... that this BU considers acceptable > is... not. It's been a week of trying to get them to see reason. Tough for their "unified" case with the IOS XR team are delivering the goods. Mark.

1 0

infrapedia June 2020
by Mehmet Akcin 10 Jun '20

10 Jun '20

hey there, today we have interviewed Vint Cerf and asked him some questions about the internet, development after covid19, if you are interested in watching this interview, check it out - https://www.youtube.com/watch?v=hL3nV5x4fHc&feature=youtu.be if you have suggestions on who you would like to see interviewed also let me know, I am working on a couple of interesting people focusing on internet stability and reliability. (offlist please) we have also thought it would be a good idea to give international telecoms, ixps, datacenters, subsea cable companies an award as they work very hard, if you are interested in voting you can do that https://www.infrapedia.com/app as always source code for infrapedia is available https://github.com/infrapedia and please feel free to join and contribute to the project. last but not least... Join our slack here! https://join.slack.com/t/infrapedia/shared_invite/zt-em3btj80-jj0iGlG7jkAjP… Mehmet

1 0

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

10 Jun '20

On 10/Jun/20 20:10, Gert Doering wrote: > To be honest, I do not think we're going to buy any IOS XE gear in the > foreseeable future. But if we did, LDPv6 would be nice to have - to get > rid of IPv4 in the backbone network. We have LDPv6 working beautifully between IOS XR (6.4.2) and Junos (17.4). But we can't make the core BGPv6-free because downstream ASR1000's and ASR920's don't have it. So if you don't have IOS XE today, but have the others, then you're good to go :-). Nobody is going to demand LDPv6, because it's not about LDPv6... it's about IPv6, and wanting IPv4 parity. But, guess that doesn't much a business case write. > > We do not intend to run SRv6 any time soon. As I thought :-). Mark.

1 0

ACX5448
by JASON BOTHE 09 Jun '20

09 Jun '20

Hi all Just curious if anyone on is using the ACX5448 and what their thoughts are on it. Thanks J~

4 5

Re: Partial vs Full tables
by William Herrin 09 Jun '20

09 Jun '20

On Mon, Jun 8, 2020 at 10:52 AM <ljwobker(a)gmail.com> wrote: > Every "fast" FIB implementation I'm aware of takes a set of prefixes, stores them in some sort of data structure, which can perform a longest-prefix lookup on the destination address and eventually get to an actual physical interface for forwarding that packet. Exactly how those prefixes are stored and exactly how load-balancing is performed is *very* platform specific, and has tons of variability. I've worked on at least a dozen different hardware based forwarding planes, and not a single pair of them used the same set of data structures and design tradeoffs. Howdy, AFAIK, there are two basic approaches: TCAM and Trie. You can get off in to the weeds fast dealing with how you manage that TCAM or Trie and the Trie-based implementations have all manner of caching strategies to speed them up but the basics go back to TCAM and Trie. TCAM (ternary content addressable memory) is a sort of tri-state SRAM with a special read function. It's organized in rows and each bit in a row is set to 0, 1 or Don't-Care. You organize the routes in that memory in order from most to least specific with the netmask expressed as don't-care bits. You feed the address you want to match in to the TCAM. It's evaluated against every row in parallel during that clock cycle. The TCAM spits out the first matching row. A Trie is a tree data structure organized by bits in the address. Ordinary memory and CPU. Log-nish traversal down to the most specific route. What you expect from a tree. Or have I missed one? Regards, Bill Herrin -- William Herrin bill(a)herrin.us https://bill.herrin.us/

4 3

Re: Partial vs Full tables
by Jakob Heitz (jheitz) 08 Jun '20

08 Jun '20

These are the first steps to optimization. Hysteresis is another. They work in ideal cases. However, when coding, we need to consider all cases. How do you set the timer? The timer has to anticipate the future. It's like an automatic transmission. It can't anticipate the future. However, the worst that can happen if the automatic transmission anticipates incorrectly is that it hunts. Regards, Jakob. -----Original Message----- Date: Mon, 8 Jun 2020 10:14:17 +0200 From: Baldur Norddahl <baldur.norddahl(a)gmail.com> On 08.06.2020 07.56, Jakob Heitz (jheitz) via NANOG wrote: > FIB compression comes with some risks. > When routes churn, there are certain cases when you have to decompress the FIB. > Then, the FIB must have the space, or else OOPS. > If a set of compressed routes has to change to decompress some and compress a > different set to improve overall compression, there is a lot of FIB > programming going on. This can cause very long convergence times. > The easy solution is to introduce some delay before programming the FIB. Or even process RIB updates as a separate thread, such that the FIB update thread does not try to program every step the RIB might go through. Instead the FIB update thread would take a snapshot of where we are now and where do we want to be and only program the diff. Given the concept is a smaller FIB size, this might actually end up being less FIB programming. Regards, Baldur

1 0