- NANOG - lists.nanog.org

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

IBM Cloud global outage caused by "incorrect" BGP routing
by Hank Nussbacher 14 Jun '20

14 Jun '20

1 0

six pages for rov issues
by Randy Bush 13 Jun '20

13 Jun '20

chris at the ever fantastic six has done a stunning bit of work to let six members see rpki/irr announcement issues https://www.seattleix.net/rs-drops randy

4 3

Re: ARIN
by Scott Weeks 13 Jun '20

13 Jun '20

--- nanog(a)nanog.org wrote: I had to do several things in ARIN. The support has team was very quick responding, very useful with their recommendations to my questions, and had a great attitude towards solving problems. thank you all ARIN support desk -------------------------------------------------- I mentioned this the last time we had this conversation, but I want to say it again. As mentioned, folks are quick to complain and slow to compliment. So, I want to add a +1 to the original email. I am having my first dealings with them since about 10 years ago. And now, just like then, the support folks are stellar in their interaction with me. Thanks a LOT! :) scott

1 0

ARIN
by Mehmet Akcin 13 Jun '20

13 Jun '20

hey there, I just wanted to share my experience dealing with ARIN support this week. I think it's not very common to see people taking the time to write something like this but I personally think we should do more often. It has been long time since I had to deal with RIRs and this week I had to do several things in ARIN. The support has team was very quick responding, very useful with their recommendations to my questions, and had a great attitude towards solving problems. I can certainly say they went above and beyond when I opened a ticket with wrong request type and they asked me if they can close it and open a new one for me? I mean.. this is called going Above and Beyond! thank you all ARIN support desk and especially Lisa Liedel for this great experience. and @John Curran <jcurran(a)arin.net> please accept this sincere thanks on your team's behalf! Mehmet

4 3

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

13 Jun '20

On Fri, 12 Jun 2020 at 23:25, David Sinn <dsinn(a)dsinn.com> wrote: > > Should we design a rational cost-efficient solution, we should choose > > the lowest overhead and narrowest working keys. > > In the abstract, sure. But if you want a practical, deployable, production network, it's multi-dimensioned. We have probably largely converged to the same place. Your vantage point sees practical offerings where IPIP may make more sense to you than MPLS, my vantage point definitely only implements the rich features I need in MPLS tunnels (RSVP-TE, L2 pseudowires, FRR, L3 MPLS VPN, all of which technically could be done of course with IPIPIP tunnels) And the theory we agree that less is more. ECMP appears to be your main pain point, the rich features are not relevant, and you mentioned commodity hardware being able to hash on IPIP. I feel this may be a very special case where HW can do IPIP hash but not MPLSIP hash. Out of curiosity, what is this hardware? Jericho can do MPLSIP, I know JNPR's pipeline offering, Paradise, can. Or perhaps it's not even that the underlaying hardware you have, cannot do, it's that the NOS you are being offered is so focused on your use-case, it doesn't do anything else reasonably, then of course that use-case is best by default. -- ++ytti

2 1

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

12 Jun '20

On 12/Jun/20 17:19, David Sinn wrote: > Yes. Path enumeration when you use mult-tier Clos topologies within a PoP causes you many, many problem. Okay, got you. I thought you were running into these problems on the "usual suspect" platforms. Yes, commodity hardware certainly has a number of trade-offs for the cost benefit. We've been evaluating this path since 2013, and for our use-case, it will actually make less sense because we are more large capacity, small footprint, i.e., typical network service provider. If we were a cloud provider operating at scale in several data centres, our current model of running Cisco's, Juniper's, Arista's, e.t.c., may not necessarily be the right choice in 2020, particularly in the edge. Mark.

1 0