- NANOG - lists.nanog.org

RE: Router Suggestions
by Jared Brown 16 Jun '20

16 Jun '20

My no-effort quote from last month lists just the box at $13,000. Once you are all in the total is that 1.5 multiple Baldur mentioned compared to OP. However, if you google "mx204 price" the first hit wants very much to sell you one for <$11,000. Caveat emptor and YMMV. Jared > Yes I too looked into that. And it was not near that price.. Please send me and email off list. I would like to know where I might find that. > >> On Mon, Jun 15, 2020 at 2:58 PM Forrest Christian (List Account) <lists(a)packetflux.com> wrote: >> >> We just got a MX204 quote and it was close to 2.5x the price you're quoting, with apparently the minimum license needed for full tables, and Next Day replacement. >> So if it's really $11K, please shoot me an email off list. Or if someone has a better place to get a decent quote for a MX204, or can clarify where this quote >> might have went wrong, that would be useful too. >> >> We're also looking at going the virtual router route where we put 2-3 servers in a HA cluster loaded up with 10Gb interfaces and running some sort of routing software. >> In case you didn't catch on, I'm >> fairly early in running this idea through the paces, although it seems like this is a pretty common thing nowadays. >> >>> On Mon, Jun 15, 2020 at 6:02 AM Colton Conor <colton.conor(a)gmail.com> wrote: >>> >>> For around $11,000 right now, you can get a brand new Juniper MX204 router. Alternatively, you can get a used MX240 / MX480 with quad power supplies, redundant quad core RE's, and 2 16X10G MIC cards >>>for around $12,000. >>> >>> My question, is there anything else worth looking at in this price range / port configuration? Open to both new and used options. Looking to take full BGP routes. >>> >> >> >> >> -- >> - Forrest

3 3

Re: ROV Deployment (was LDPv6 Census Check)
by John Kristoff 16 Jun '20

16 Jun '20

On Sun, 14 Jun 2020 18:09:24 +0000 Randy Bush <randy(a)psg.com> wrote: > thanks to a few vendor engineers who implemented as skunkworks, > to jay, you, and other large ops who have deployed, and to job > who has taken over waving the pom poms, i am rather optimistic. I concur. I asked our four major networks we (depaul.edu) had connectivity from if they supported ROV in early 2019. Cogent, HE.net, Internet2, and SeverCentral all said they do not and none had plans to deploy. Now two of those are doing some ROV. We've since replaced Zayo for Cogent and I asked them about it in late 2019. I know at least one of the remaining three is seriously looking at supporting it soon. Lots of reasons for the momentum, but two very noticeable reasons from my view were when AT&T announced their deployment and when Google got people worried about dropping routes. John

4 3

Re: Partial vs Full tables
by Jared Brown 16 Jun '20

16 Jun '20

From: Mike Hammett <nanog () ics-il net> Date: Fri, 5 Jun 2020 08:17:26 -0500 (CDT) > I've been wondering a similar thing for how to take advantage of the 150k - 250k hardware routes the CRS317 now has in > v7 beta. That many routes should cover the peering tables for most operators, maybe even transit's customers. Perhaps the thing you are looking for is SIR - the SDN Internet Router https://github.com/dbarrosop/sir TLDR; use pmacct to grab top N ASN speakers and install them into the FIB. Rinse and repeat. Alternatively filter out anything not from ARIN. Conveniently fits into 250k: Prefixes being announced by ARIN Region ASes: 238331 http://gregsowell.com/?p=5505 Should you want something that isn't quite so bleeding edge beta, perhaps pick up a used Arista 7050QX? It's about the same as a CRS317 and holds 144k routes. Jared

1 0

TIMELY – ARIN 45 Virtual Meeting Starts Later Today!
by John Curran 16 Jun '20

16 Jun '20

NANOGers – Our ARIN 45 Virtual Meeting will be held today and tomorrow, and is starting in approximately 5 hours… There’s plenty of time to register for this free event, and participate in the development of the policies by which we manage the ARIN registry. Details available below. Best wishes (and stay safe!) /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] ARIN 45 Will Be Here Soon – Get Ready! Date: 15 June 2020 at 12:34:01 PM EDT To: <arin-announce(a)arin.net<mailto:arin-announce@arin.net>> This week is the ARIN 45 Virtual Meeting, where we will be in the thick of important community discussions on the following policies: - Recommended Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements - Recommended Draft Policy ARIN-2019-10: Inter-RIR M&A - Recommended Draft Policy ARIN-2019-12: M&A Legal Jurisdiction Exclusion - Recommended Draft Policy ARIN-2019-20: Harmonization of Maximum Allocation Requirements under Sections 4.1.8 (ARIN Waitlist) and 4.2.2 (Initial Allocation to ISPs) - Recommended Draft Policy ARIN-2019-21: Reserved Pool Replenishment - Draft Policy ARIN-2020-1: Clarify Holding Period for Resources Received via 4.1.8 Waitlist - Draft Policy ARIN-2020-2: Grandfathering of Organizations Removed from Waitlist by Implementation of ARIN-2019-16 - Draft Policy ARIN-2020-3: IPv6 Nano-Allocations All draft policy text is available at: https://www.arin.net/participate/policy/drafts/ The ARIN 45 agenda will also feature several other informative sessions, including updates on ARIN’s IRR and RPKI. Leading up to the meeting, we want to make sure you are ready to participate. To help you prepare, ARIN has published all of the meeting materials online for you to review or download beforehand. Just visit: https://www.arin.net/ARIN45_materials If this is your first time attending an ARIN meeting, you’ll find the welcome handout particularly helpful if you want to familiarize yourself with some of the ins and outs of ARIN. Need a refresher on ARIN’s Policy Development Process (PDP) before joining us to talk policy? You may want to check out the on-demand version of our PDP webinar, which covers the entire process, start to finish: https://www.arin.net/reference/training/webinars/#the-policy-development-pr… View the full agenda and register today for this meeting while there’s still time: https://www.arin.net/ARIN45 Please contact us at meetings(a)arin.net if you have any questions. We look forward to your participation! Regards, American Registry for Internet Numbers (ARIN)

1 0

ROV Deployment (was LDPv6 Census Check)
by Randy Bush 16 Jun '20

16 Jun '20

>> we have rov in rfps received from paying customers > I hope this becomes the norm, globally. charlie lynn wrote the first rpki draft in 1999. the steves shanghaied me in 2000. considering it took eight years for the ietf to change a constant of 4k to 64k, rpki/rov is moving right along at a swift pace. thanks to a few vendor engineers who implemented as skunkworks, to jay, you, and other large ops who have deployed, and to job who has taken over waving the pom poms, i am rather optimistic. randy

2 1

... you kicked out the patch cable (or, major global internet outages)
by Ben Cannon 16 Jun '20

16 Jun '20

https://downdetector.com/ ...you kicked out a patch cable. (Nods to BOFH) In all seriousness, looks major... Long-haul cut? Did we lose a pie or COs? -Ben

3 2

academic paper on Peerlock BGP protection mechanism
by Job Snijders 15 Jun '20

15 Jun '20

Dear colleagues, An interesting paper has been made available as pre-print: "Peerlock: Flexsealing BGP" by Tyler McDaniel, Jared M. Smith, and Max Schuchard from the University of Tennessee. The paper probably is the most formal description of Peerlock so far. They even conducted active measurements to reverse-engineer what the state of Peerlock deployment is in the global Intenet routing system. Abstract: https://arxiv.org/abs/2006.06576 PDF: https://arxiv.org/pdf/2006.06576.pdf Recommended reading! Kind regards, Job

1 0

Fwd: [lacnog] LACNOG 2020 - Call for Presentations
by Carlos M. Martinez 15 Jun '20

15 Jun '20

Hi all, LACNOG (the Latin American and Caribbean Network Operators Group) will be a virtual meeting this year. Looking forward to great talks from our big brother NANOG members :-) /Carlos LACNOG PC Forwarded message: > From: Jorge Villa <villa(a)reduniv.edu.cu> > To: Latin America and Caribbean Region Network Operators Group > <lacnog(a)lacnic.net> > Subject: [lacnog] LACNOG 2020 - Call for Presentations > Date: Mon, 08 Jun 2020 11:49:02 -0400 > > LACNOG 2020 - Call for Presentations > > > > https://www.lacnog.org/eventos/ > > > > LACNOG, the Latin American and Caribbean Network Operators Group, will > hold its LACNOG 2020 conference in the city of Santa Cruz de la > Sierra, Bolivia, from 5 to 9 October 2020, which will be co-located > with the LACNIC 34 event. > > > > The LACNOG 2020 Program Committee invites the Internet community to > submit their proposals for the event. > > > > In line with the spirit of LACNOG, proposed topics must be geared > towards Internet development in the region. The following is a > non-exhaustive list of some of the topics of interest for the LACNOG > 2020 meeting: > > > Network operation and professional experiences, success stories > Internet of Things > MANRS > Community networks > IPv6 integration and deployment > Experiences involving botnets, malware, spam, viruses, denial of > service attacks and exploit techniques > IP network architecture, sizing, configuration and administration > Routing and switching protocols, including unicast, multicast, > anycast, SDN, etc. > End-user applications (e.g. e-mail, HTTP, DNS, NFVs, etc.) > Value-added services such as VPNs, distributed systems, cloud > computing, etc. > Peering, Internet traffic exchange, IXPs > Network data security and management, attack mitigation > Network monitoring, performance, measurements and telemetry > Network automation, evolution and convergence > Infrastructure and physical transport, including optical and wireless > networks > Legislation, regulations and Internet governance issues > Research and education > > > Possible presentation formats include: > > > Lightning talk: brief, 8-minute presentation plus 4 additional minutes > for questions. > Presentation: 20-minute presentation plus 5 additional minutes for > questions. > > > The deadlines for the 2020 call for proposals will be as follows: > > > Reception of proposals: 8 June - 7 July 2020 > Proposals will be accepted until: 7 July 2020 at 23:59 UTC-3 (Uruguay > time) > Evaluation by the Program Committee: 8-19 July 2020 > Announcement of results: 20 July 2020 > Deadline for submitting the final presentation: 1 August - 18 > September 2020 > Final presentations will be accepted until: 21 September 2020 at 23:59 > UTC-3 (Uruguay time) > Event date: 5-9 October 2020 > > > Applicants must submit a summary and a draft of the slides of their > proposed presentation along with a brief biography and photograph > using the form available at https://vulcano.lacnog.org/e/lacnog2020 > > > > If your work is selected, you authorize LACNOG and LACNIC to publish > your name, photograph, biography, and final work in the event program. > > > > Regardless of the chosen format, all works must presented in person at > the event venue. > > > > Given the current pandemic caused by the coronavirus (covid-19) > outbreak, there is the possibility that the event may be held in > virtual format, in which case speakers will be notified in advance and > the necessary adjustments will be coordinated based on the schedule > determined by the Program Committee. > > > > Applicants whose proposals are accepted will be exempted from paying > their in-person event registration fee but will not automatically > receive financial assistance for their travel and/or accommodation > expenses. However, LACNIC offers a fellowship program for attending > the LACNIC 34 event which will be held jointly with LACNOG 2020 to > which speakers can apply independently. When submitting your draft to > the LACNOG Program Committee, please specify whether you are applying > (or planning to apply) for a LACNIC fellowship. > > > > Speakers presenting their work at the LACNOG 2020 conference will > receive a certificate acknowledging their participation. > > > > Guidelines for Submitting a Presentation for LACNOG have been prepared > containing a description of the criteria that will be considered when > evaluating each proposal, presentation format details and other data. > These Guidelines are available at > https://www.lacnog.org/guiapresentaciones/. > > > > Communications with the Program Committee will be handled through > pc(a)lacnog.org. > > > > We thank you in advance for your attention and look forward to your > proposals for LACNOG 2020. > > > > Program Committee > _______________________________________________ > LACNOG mailing list > LACNOG(a)lacnic.net > https://mail.lacnic.net/mailman/listinfo/lacnog > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog

1 0

Partial vs Full tables
by James Breeden 15 Jun '20

15 Jun '20

I have been doing a lot of research recently on operating networks with partial tables and a default to the rest of the world. Seems like an easy enough approach for regional networks where you have maybe only 1 upstream transit and some peering. I come to NANOG to get feedback from others who may be doing this. We have 3 upstream transit providers and PNI and public peers in 2 locations. It'd obviously be easy to transition to doing partial routes for just the peers, etc, but I'm not sure where to draw the line on the transit providers. I've thought of straight preferencing one over another. I've thought of using BGP filtering and community magic to basically allow Transit AS + 1 additional AS (Transit direct customer) as specific routes, with summarization to default for the rest. I'm sure there are other thoughts that I haven't had about this as well.... And before I get asked why not just run full tables, I'm looking at regional approaches to being able to use smaller, less powerful routers (or even layer3 switches) to run some areas of the network where we can benefit from summarization and full tables are really overkill. James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james(a)arenalgroup.co<mailto:james@arenalgroup.co> | office 512.360.0000 | www.arenalgroup.co<http://www.arenalgroup.co/>

24 60

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

15 Jun '20

> From: David Sinn > Sent: Friday, June 12, 2020 4:19 PM > > > On Jun 11, 2020, at 2:02 PM, Mark Tinka <mark.tinka(a)seacom.mu> wrote: > > > > 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? > > Yes. Path enumeration when you use mult-tier Clos topologies within a PoP > causes you many, many problem. > Hi David, Can you be more specific please? Maybe some examples with numbers. I can see how you might run out of L2 rewrite/adjacency table space on a particular node if you enumerate every possible path downstream of it (especially on leaf nodes), cause that number is has a dependency on the size of the fabric in terms of the total number of links in the fabric (which balloons quickly). Let's focus on the alternate case then, (the deep label-stack one) At each node in the multi-tier Clos (which I assume is the Russ White's butterfly model? But any Clos or Benes fabric needs the same) you need to program a label to uniquely identify each egress interface ,so now there's this nice one-to-one relationship between label and egress interface. Now the depth of the label-stack depends on the number of hops the packet needs to traverse across the fabric. But how deep could the fabric realistically be? Even in the "butterfly" model with separate pods instead of leaf nodes I counted 9 hops (that's not ultra-deep is it)? It's the VM doing label imposition as programmed by the fabric controller (all in SW so can go as deep as you want) and all fabric nodes are just popping top label so no big deal. adam

1 0