June 2020 - Test - lists.nanog.org

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

Amateur Hour - NANOG79 Video Archives?
by Mick O'Donovan 14 Jun '20

14 Jun '20

Hi All, I like many participated at NANOG79 remotely using the Digitell.io streams. Unfortunately I must have missed a memo though, as I can't see to find the video archives of these talks. I'm especially interested in revisiting the NMaaS and the Covid Service Providers perspective ones as well as the RPKI deployment talk from Job for example. How might one see these now post NANOG79? Thanks in advance, -- - MickoD <mick(a)mickod.ie>

5 6

Re: [c-nsp] LDPv6 Census Check
by Christian Meutes 14 Jun '20

14 Jun '20

On Fri, Jun 12, 2020 at 10:22 PM David Sinn <dsinn(a)dsinn.com> wrote: > Except that is actually the problem if you look at it in hardware. And to > be very specific, I'm talking about commodity hardware, not flexible > pipelines like you find in the MX and a number of the ASR's. I'm also > talking about the more recent approach of using Clos in PoP's instead of > "big iron" or chassis based systems. > TE gives you the most powerful traffic engineering tool kit available. Naturally it has a bit more weight than just a single screwdriver. It can you build nearly any kind of multipath transport while that Clos thing is just one architecture hunting for the cheapest implementation of IP/LDP-style ECMP. On those boxes, it's actually better to not do shared labels, as this > pushes the ECMP decision to the ingress node. That does mean you have to > enumerate every possible path (or some approximate) through the network, > however the action on the commodity gear is greatly reduced. It's a pure > label swap, so you don't run into any egress next-hop problems. You > definitely do on the ingress nodes. Very, very badly actually. > Actually shared links are not a swap but just a pop similar to SR. But indeed this would shift your ECMP issue just to the headend. So for your ECMP scaling there would still be an option left to use an implementation which offers you a merge-point with a single label to all upstreams for a certain equal-cost multipath downstream. This does exist, so would certainly fix your ECMP scaling problem. But advanced control-plane code is certainly not cheap so in the end, like it was already said before, if a simple and cheap platform can solve all your needs then it might be the better one. Let‘s see what problems we need to solve in five years again. What I'm getting at is that IP allows re-write sharing in that what needs > to change on two IP frames taking the same paths but ultimately reaching > different destinations are re-written (e.g. DMAC, egress-port) identically. > And, at least with IPIP, you are able to look at the inner-frame for ECMP > calculations. Depending on your MPLS design, that may not be the case. If > you have too deep of a label stack (3-5 depending on ASIC), you can't look > at the payload and you end up with polarization. > Not really as you are still forced to rewrite on imposition for the simplest form of tunneling, and for TE as often as you need to go against your SPT as well, it‘s just happening on IP (and IP rewrites are more expensive than MPLS rewrites / forwarding operations).

1 0

LDPv6 Census Check
by Mark Tinka 14 Jun '20

14 Jun '20

Hi all. Just want to sample the room and find out if anyone here - especially those running an LDP-based BGPv4-free core (or something close to it) - would be interested in LDPv6, in order to achieve the same for BGPv6? A discussion I've been having with Cisco on the matter is that they do not "see any demand" for LDPv6, and thus, won't develop it (on IOS XE). Meanwhile, it is actively developed, supported and maintained on IOS XR since 5.3.0, with new features being added to it as currently as 7.1.1. Needless to say, a bunch of other vendors have been supporting it for a while now - Juniper, Nokia/ALU, Huawei, even HP. IOS XR supporting LDPv6 notwithstanding, Cisco's argument is that "the world" is heavily focused on deploying SRv6 (Segment Routing). While I know of one or two questionable deployments, I'm not entirely sure much of the world is clamouring to deploy SR, based on all the polls we've done at various NOG meetings and within the general list-based operator community So I just wanted to hear from this operator community on whether you would be interested in having LDPv6 support to go alongside your LDPv4 deployments, especially if you run native dual-stack backbones. Or if your focus is totally on SRv6. Or if you don't care either way :-). Thanks. Mark.

8 35