Re: [c-nsp] LDPv6 Census Check
On 11/Jun/20 06:51, Saku Ytti wrote: > Every HW designer > has sighed in relief when I've said I don't care about it, because > it's also very HW unfriendly, like IPv6 generally. Unfortunately SRv6 > is somewhat easy to market with the whole 'it's simple, just IP' > spiel. Mine have sighed in disbelief that I don't share their vision of an SR(v6) world :-). What's funny is that the ASR920 does not support SRv6, which I think is more due to hardware limitations than a lack of coding kiddies. Conversely, you don't need new bits of hardware to support LDPv6. Today, there is no box that supports LDPv4 that cannot support LDPv6, by just extending the code. No further hardware needed. Instead, I'm being asked to "upgrade" to the NCS540 so that I can get LDPv6. You, sometimes, have to wonder in what world these folk live. It's a Coronavirus era now - people want to hold on to all the $$ they don't have, and only spend it where they will extract the most value. Boeing and Airbus are struggling to reach customers that have pending deliveries; now isn't the time for vendors to posture. We need value, not product. Mark.
Re: [c-nsp] LDPv6 Census Check
On Thu, 11 Jun 2020 at 10:37, Mark Tinka wrote: > Mine have sighed in disbelief that I don't share their vision of an > SR(v6) world :-). I don't like to conflate these two; SR is great, SRv6 is horrible abomination. SR is what MPLS should have been day1, but it probably was easier to market LDP than to say 'we need to change all IGP protocols'. -- ++ytti
Re: LDPv6 Census Check
On Wed, Jun 10, 2020, at 20:51, Mark Tinka wrote: > Well, according to them, SRv6 is winning customers over, and nobody > wants LDPv6. Then again, they have LDPv6 in IOS XR; figures. 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. And don't forget SRv6 is also heavily associated (marketing-wise) with 5G 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. 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. 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".
Re: [c-nsp] LDPv6 Census Check
On 11/Jun/20 09:42, Saku Ytti wrote: > > I don't like to conflate these two; SR is great, SRv6 is horrible > abomination. SR is what MPLS should have been day1, but it probably > was easier to market LDP than to say 'we need to change all IGP > protocols'. Fair point. Mark.
RE: [c-nsp] LDPv6 Census Check
> Mark Tinka > Sent: Wednesday, June 10, 2020 6:19 PM > > 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. > Hey Mark, My stance is that should I go with anything "new" for label distribution the MPLS SR/SPRING is getting to a point where it might be mature enough. Also "BGP free core" means internet won't talk to your core -i.e. free to use private addressing -so no need for v6 at all in the "underlay" (as hipsters call it these days). Alternatively using public "infrastructure subnet" (i.e. not advertised to the Internet) for a "BGP free core", the aim is to make money of the core -what additional revenue stream am I getting by enabling v6 in the underlay/management plane that would offset the pain of dealing with the increased bug surface? And with regards to the XE/XR discrepancies, I mentioned my prophecy a number of times, I think XE future in SP products portfolio is next to none. adam
Re: [c-nsp] LDPv6 Census Check
Saku Ytti wrote on 11/06/2020 05:51: Unfortunately SRv6 is somewhat easy to market with the whole 'it's simple, just IP' spiel. it's not "just IP": it's ipv6 with per-router push / pop operations on ipv6 extension headers, i.e. high touch in areas which are known to be deeply troublesome on hardware. In this regard alone, the specification is problematic enough that it's unearthed a bug in the IPv6 standard (rfc8200). Nick
Re: [c-nsp] LDPv6 Census Check
On 11/Jun/20 10:32, adamv0...@netconsultings.com wrote: > Hey Mark, > My stance is that should I go with anything "new" for label distribution the > MPLS SR/SPRING is getting to a point where it might be mature enough. "Getting to a point" doesn't really work if you are actively running a network today :-). While I do agree that going with the new thing is always a good plan, one has to truly consider the overall gain vs. labour required to get there. Going from static routing to an IGP + BGP makes sense when you scale up. Switching from Distribute Lists to Prefix Lists makes sense when you scale up. Route summarization after you dump your old Cisco 2501 for an ASR9901 doesn't add value any longer. You get the idea. The position about not needing a label distribution protocol in SR is actually quite sexy. But considering how powerful router control planes are nowadays, especially when they are being virtualized on or off chassis, I just don't see the gains expected by removing LDP and going SR, on a box and code that supports both. Yes, if you are talking about dumping a spaghetti of RSVP tunnels, that makes sense as there is a gain in day-to-day network administration. But in this case, we are just speaking about LDP. 10 years ago, we worried about how well an IP network would scale running OSPF or IS-IS. With control planes what they are today, who really cares anymore? You may recall we've been running CSR1000v for route reflection since 2014 - millions of routes being carried everyday, converging in seconds. We've never had to think about those boxes until last year when we did the server hardware refresh as a matter of course, not because anything was struggling. What I'm saying is not all new tech. NEEDS to get deployed just because it's new. If that was the case, we'd all be running Inter-AS DSCP over IPoDWDM :-). > Also "BGP free core" means internet won't talk to your core -i.e. free to > use private addressing -so no need for v6 at all in the "underlay" (as > hipsters call it these days). Careful with that one - Cisco's proposal to me was to run my IPv6 network on link-local :-). Don't encourage them, hehe. > Alternatively using public "infrastructure subnet" (i.e. not advertised to > the Internet) for a "BGP free core", the aim is to make money of the core > -what additional revenue stream am I getting by enabling v6 in the > underlay/management plane that would offset the pain of dealing with the > increased bug surface? I don't know about you, but my BGP-free core is inaccessible from the world even if it lives in public-IPv4 land. That's how pure MPLS forwarding works. You'd have be "inside" to reach it (IGP). Also, if you link every feature to a revenue stream, you'll never deploy RPKI or DNSSEC :-). > > And with regards to the XE/XR discrepancies, I mentioned my prophecy a > number of times, I think XE future in SP products portfolio is next to none. Which is fine - but customers are spending real money and need to keep real networks running with real costs for real years. If Cisco want to kick IOS XE to the side, let customers know so we can make informed decisions about where to purchase gear. The current state-of-the-art is that kit you buy today is probably good years after standard depreciation policies, probably longer. If Cisco's model is to throw boxes away sooner than that like they did in the old days, that is not consistent with where the tech. has gotten to in the past 2 decades. Mark.
Re: [c-nsp] LDPv6 Census Check
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 IP
Re: [c-nsp] LDPv6 Census Check
Mark Tinka wrote on 11/06/2020 10:48: We are asking for LDP to extended to support IPv6. Really, how hard is that? Nearly impossible, apparently. It would require a change of mindset. Nick
Re: [c-nsp] LDPv6 Census Check
On 11/Jun/20 11:58, Nick Hilliard wrote: > Nearly impossible, apparently. > > It would require a change of mindset. I'll leave that to the Coronavirus - it will open eyes. Mark.
Re: [c-nsp] LDPv6 Census Check
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.
Re: [c-nsp] LDPv6 Census Check
On Thu, 11 Jun 2020 at 12: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. 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
Re: [c-nsp] LDPv6 Census Check
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.
RE: [c-nsp] LDPv6 Census Check
> From: Mark Tinka > Sent: Thursday, June 11, 2020 10:21 AM > >> -what additional revenue stream am I getting by enabling v6 in the >> underlay/management plane that would offset the pain of dealing with the >> increased bug surface? > > Also, if you link every feature to a revenue stream, you'll never deploy > RPKI or DNSSEC :-). > Well RPKI or DNSSEC is at least adding a value, even something you can brag about to your customers (we are part of the solution not part of the problem etc...). But running MPLS over IPv6 in addition to already running it over IPv4, gaining new functionality or features in the process that could be ultimately monetized in providing better service to customers? -maybe even exposing the network to a new set of bugs? -I don't know, that doesn’t sound like a good use of company resources especially in these uncertain times . Maybe I'm being overly harsh here maybe if you could please explain the drivers or expected net value out of this exercise please? adam
Re: [c-nsp] LDPv6 Census Check
On 11/Jun/20 14:17, adamv0...@netconsultings.com wrote: > Well RPKI or DNSSEC is at least adding a value, even something you can brag > about to your customers (we are part of the solution not part of the problem > etc...). Bragging doesn't bring in income, it's just PR :-). > > But running MPLS over IPv6 in addition to already running it over IPv4, > gaining new functionality or features in the process that could be ultimately > monetized in providing better service to customers? -maybe even exposing the > network to a new set of bugs? -I don't know, that doesn’t sound like a good > use of company resources especially in these uncertain times . Maybe I'm > being overly harsh here maybe if you could please explain the drivers or > expected net value out of this exercise please? Oh dear, you sound like our Finance department now; "drivers" and "net value" :-). If I take your line of reasoning, deploying SRv6 likely requires new hardware, which means $$. How much money will I charge customers for my shiny new SRv6? LDPv6 builds on LDPv4. Just like IPv6 builds on IPv4. At best, you can remove BGPv6 from your core, which lowers your administration costs in that part of the network even further, costing you less in human time running it, resources you can otherwise re-deploy to other time- and money-saving activities. At worst, you get IPv4/IPv6 feature parity, and who doesn't like that :-). And how much money did LDPv6 cost you to deploy? $0. Mark.
Re: [c-nsp] LDPv6 Census Check
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. signature.asc Description: OpenPGP digital signature
Re: Partial vs Full tables
> On Jun 10, 2020, at 3:05 PM, William Herrin wrote: > > On Wed, Jun 10, 2020 at 11:20 AM Brian Johnson > wrote: >> Disagree with Bill here. It will depend on the complexity of the network as >> to use of uRPF in any mode (loose or strict). In general, I never use uRPF >> on transit links and use pure filters to ensure accurate filters are in >> place. uRPF may be used internally in either mode to great advantage and >> I’ve done it both ways. > > > Hi Brian, > > Do you know and understand what you broke? It's one thing to make a > judgement call. Quite another to wave your hands and say, "Oh well, > nobody complained so it must be OK." > Hi Bill, I fully understand that I have not “broken” anything. If I run uRPF in loose mode on my internal links, I will not forward packets from a source that doesn’t exist in my routing tables to the rest of the internet. Just say thank you and we can stop this silliness. > >> If you are looking for corner cases, avoid networking. I do not know of a >> protocol or a technique that I cannot find a corner case for. > > Not sure what you're saying here. Corner cases aren't a bad thing. > They're just the point where a technology or technique is most likely > to break. If you want reliability, you're supposed to identify the > corner cases and then you're supposed to game out what happens in > those corner cases. A result will be acceptable or unacceptable and if > it's unacceptable you don't do that. If you haven't identified and > gamed the corner cases then (A) you can't prove your stuff is reliable > and (B) it probably isn't. Actually corner cases are the exception to any rule. You will never solve for all of the corner cases unless you have dictatorial control of the entire system. I can only control what I send. I can say that sending packets from unknown sources from a network I do control is a no-no, ICMP response or not. > With RPF, the corner cases you're looking for are: what situations > would cause a packet to come from the wrong interface? For example, if > you had some sort of routing loop where router A thought it could get > to a destination via router B but router B thinks that destination > unreachable so it returns the packet to its default route at router A. > RPF then drops the packet because router B isn't an acceptable source. > That's a corner case for RPF but it's an acceptable case because the > packet would be dropped regardless. So a non-problem corner-case. Interesting... I never thought of a non-problem as a problem. > Another corner case with strict RPF is that your best route to a > destination is transit C but a packet with that source arrives from > transit D. That's broken, it causes significant problems for the > network and as a result it constrains you to not use strict RPF in > network scenarios where that's possible. See my original response where I say not to use it in that scenario. > Loose mode RPF tries to overcome the limitation by saying: as long as > there's a route announced from D we'll accept packets from D even if C > is the best route. Saying that a route to the source has to be in the routing table on an internal network, something I can control, is a valid way to stop spoofing. uRPF cannot, and should never be used to, make routing decisions and does not do that anyway. The rest of your comments are not reasonable since I already said to not use uRPF on TRANSIT LINKS. Happy to expand that to PEERING LINKS. For internal networking, you CAN use uRPF to great effect, corner case arguments notwithstanding. Not everyone runs a large multi-national tier-1/2 network. Some of us run the thousands of eye-ball networks and just say thank you when we don’t allow spoofing. BTW... RPF and uRPF are significantly different things. :) > > Regards, > Bill Herrin > > -- > William Herrin > b...@herrin.us > https://bill.herrin.us/
Re: [c-nsp] LDPv6 Census Check
On Thu, 11 Jun 2020 at 15:58, Mark Tinka wrote: > > Well RPKI or DNSSEC is at least adding a value, even something you can brag > > about to your customers (we are part of the solution not part of the > > problem etc...). > > Bragging doesn't bring in income, it's just PR :-). Unsure of others, but we didn't implement RPKI for shit and giggles, we implemented it, because customers wanted us to do RPKI. -- ++ytti
Re: [c-nsp] LDPv6 Census Check
On 11/Jun/20 15:34, Saku Ytti wrote: > > Unsure of others, but we didn't implement RPKI for shit and giggles, > we implemented it, because customers wanted us to do RPKI. I'll be honest, none of our customers ever asked us to deploy RPKI and ROV. Will they benefit from it, sure? Is it about to become part of an RFP requirements document? Probably not. Then again, the typical NTT customer probably has an engineering department that understands and demands RPKI, because they are a sizeable operator themselves. We only have a handful of customers that technically appreciate that we've deployed RPKI. For the rest, it doesn't register. Not sure if beating up on Job for months qualifies as "a customer wanting RPKI from NTT" :-). Mark.
RE: [c-nsp] LDPv6 Census Check
> From: Mark Tinka > Sent: Thursday, June 11, 2020 1:56 PM > > On 11/Jun/20 14:17, adamv0...@netconsultings.com wrote: > > > Well RPKI or DNSSEC is at least adding a value, even something you can > brag about to your customers (we are part of the solution not part of the > problem etc...). > > Bragging doesn't bring in income, it's just PR :-). > Good PR might ;) > > > > > But running MPLS over IPv6 in addition to already running it over IPv4, > gaining new functionality or features in the process that could be ultimately > monetized in providing better service to customers? -maybe even exposing > the network to a new set of bugs? -I don't know, that doesn’t sound like a > good use of company resources especially in these uncertain times . Maybe > I'm being overly harsh here maybe if you could please explain the drivers or > expected net value out of this exercise please? > > Oh dear, you sound like our Finance department now; "drivers" and "net > value" :-). > I thought I sound like a network architect :( > If I take your line of reasoning, deploying SRv6 likely requires new hardware, > which means $$. How much money will I charge customers for my shiny new > SRv6? > No, my line of reasoning is if you have MPLS LSPs signalled over v4 I see no point having them signalled also over v6 in parallel. Or if your full-mesh RSVP-TE is killing your RSVP-TE or you're in need of TE, then might want to look at SR MPLS. > LDPv6 builds on LDPv4. Just like IPv6 builds on IPv4. At best, you can remove > BGPv6 from your core, I'm using VPNv6 & VPNv4 so not sure I follow how LDPv6 allows for removal of BGPv6 (is it BGPv6 over v4 NHs/transport?) but then again if it works over v4... > which lowers your administration costs in that part of > the network even further, costing you less in human time running it, > resources you can otherwise re-deploy to other time- and money-saving > activities. At worst, you get IPv4/IPv6 feature parity, and who doesn't like > that :-). > I knew there's a bit of OCD hidden in this at some level :) > And how much money did LDPv6 cost you to deploy? $0. > Apart from X months worth of functionality, performance, scalability and interworking testing -network wide code upgrades to address the bugs found during the testing process and then finally rollout across the core and possibly even migration from LDPv4 to LDPv6, involving dozens of people from Arch, Design, OPS, Project management, etc... with potential for things to break while making changes in live network. adam
Re: [c-nsp] LDPv6 Census Check
On Thu, 11 Jun 2020 at 16:45, Mark Tinka wrote: > Not sure if beating up on Job for months qualifies as "a customer > wanting RPKI from NTT" :-). I'm sure we can blame Job for this, why not. But probably because of his lobbying some customers are _requiring_, i.e. flat out told they will stop accepting transit offers from providers who don't do RPKI. -- ++ytti
RE: [c-nsp] LDPv6 Census Check
> From: Saku Ytti > Sent: Thursday, June 11, 2020 3:29 PM > > On Thu, 11 Jun 2020 at 16:45, Mark Tinka wrote: > > > Not sure if beating up on Job for months qualifies as "a customer > > wanting RPKI from NTT" :-). > > I'm sure we can blame Job for this, why not. But probably because of his > lobbying some customers are _requiring_, i.e. flat out told they will stop > accepting transit offers from providers who don't do RPKI. > Case in point. On the other hand not sure if any of the customers would care whether LSPs are signalled over v4 as opposed to v6. adam
Re: [c-nsp] LDPv6 Census Check
On 11/Jun/20 16:28, Saku Ytti wrote: > I'm sure we can blame Job for this, why not. But probably because of > his lobbying some customers are _requiring_, i.e. flat out told they > will stop accepting transit offers from providers who don't do RPKI. As my Chad friend would say, "I like the sound of this". Mark.
Re: [c-nsp] LDPv6 Census Check
On 11/Jun/20 16:36, adamv0...@netconsultings.com wrote: > Case in point. > > On the other hand not sure if any of the customers would care whether LSPs > are signalled over v4 as opposed to v6. They care if your core router CPU doesn't struggle from dealing with churning BGP routes at scale, taking the network down. Not every bit of good network operation can be attributed to direct revenue. BCP-38 is a great example, and that is still poorly deployed despite being supported. Mark.
Re: Partial vs Full tables
On Thu, Jun 11, 2020 at 6:25 AM Brian Johnson wrote: > I fully understand that I have not “broken” anything. Handwaving, la la la, only sunshine in the sky. Got it. -Bill -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: [c-nsp] LDPv6 Census Check
On 11/Jun/20 16:25, adamv0...@netconsultings.com wrote: > Good PR might ;) I'm old school - build something customers want to use, and the money follows. Care to guess how much PR Tik Tok do :-)? But I digress. > No, my line of reasoning is if you have MPLS LSPs signalled over v4 I see no > point having them signalled also over v6 in parallel. It's not about signaling IPv4 LSP's over IPv6. LDPv4 creates IPv4 FEC's. LDPv6 creates IPv6 FEC's. The idea is to create IPv6 FEC's so that IPv6 traffic can be label-switched in the network natively, allowing you to remove BGPv6 in a native dual-stack core. > Or if your full-mesh RSVP-TE is killing your RSVP-TE or you're in need of TE, > then might want to look at SR MPLS. No RSVP-TE here, thank the Lord :-). > I'm using VPNv6 & VPNv4 so not sure I follow how LDPv6 allows for removal of > BGPv6 (is it BGPv6 over v4 NHs/transport?) but then again if it works over > v4... Nothing like the real thing: In IPv4-land, you get this: 24005 49017 105.16.Y.Z/32 Te0/0/0/2 105.16.A.B 8614773 49017 105.16.Y.Z/32 Te0/1/0/0 105.16.C.D 8121753 49017 105.16.Y.Z/32 Te0/7/0/5 105.16.E.F 9964543 In IPv6-land, you get this: 2c0f:feb0:X:Y::Z/128 25071 25458 BE1 Link-local 25458 BE2 Link-local In Junos land, it looks like this: 7967 *[LDP/9] 1w5d 01:21:05, metric 1 > to fe80::de38:e1ff:fe15:dc02 via ae2.0, Swap 145674 If I run an IPv6 traceroute toward a host that sits behind a router doing LDPv6, this is what happens: run traceroute 2c0f:feb0:2f:ff00:::: traceroute6 to 2c0f:feb0:2f:ff00:::: (2c0f:feb0:2f:ff00::::) from 2c0f:feb0:1:2::112, 64 hops max, 12 byte packets 1 ae-5-0.er6-01-fra.de.seacomnet.com (2c0f:feb0:1:2::111) 165.567 ms 166.158 ms 166.924 ms MPLS Label=145786 CoS=0 TTL=1 S=1 2 xe-0-0-0-0.cr6-02-mrs.fr.seacomnet.com (2c0f:feb0:1:2::f9) 165.682 ms 2c0f:feb0:1:2::279 (2c0f:feb0:1:2::279) 165.817 ms 168.123 ms MPLS Label=25494 CoS=0 TTL=1 S=1 As you can see, just as with IPv4, IPv6 packets are now being MPLS-switched in the core, allowing you to remove BGPv6 in the core and simplify operations in that area of the network. So this is native MPLSv6. It's not 6PE or 6VPE. Your IPv4 domain could fall over and your MPLSv6 network will still be alive, because it's neither 6PE nor 6VPE. And vice versa - your IPv6 network could die, and your MPLSv4 will be unaffected. > I knew there's a bit of OCD hidden in this at some level :) Safe to say the Internet is one big OCD project :-). My OCD is sleeping at 3AM, in peace, lockdown or not, hehe. > Apart from X months worth of functionality, performance, scalability and > interworking testing -network wide code upgrades to address the bugs found > during the testing process and then finally rollout across the core and > possibly even migration from LDPv4 to LDPv6, involving dozens of people from > Arch, Design, OPS, Project management, etc... with potential for things to > break while making changes in live network. Which you wouldn't have to do with SRv6, because you trust the vendors? And no, LDPv6 does not call for one to migrate from LDPv4. They can live together, side-by-side, just as native dual-stack IPv4/IPv6 does. We are running LDPv4 and LDPv6 side-by-side, with no problems, between IOS XR and Junos, as you can see above. This is a live network, carrying revenue-generating, production traffic. It's not a fantasy. Mark.
Re: Partial vs Full tables
On 6/10/20 6:01 PM, Baldur Norddahl wrote: > Am I correct in assuming loose mode RPF only drops packets from > unannounced address space in the global routing table? And the downside > of doing so is that sometimes we do receive packets from that address > space, usually back scatter from traceroute or other ICMP messages. > > Currently about 25% of the routable address space is not advertised in > the DFZ. Loose mode RPF could filter this. Is there any data on how much > traffic actually arrives from this space? > Loose mode RPF will essentially drop traffic received on the interface if the router does not have any route for. (will not match a default or a discard route, at least in IOS-XR) As Bill has pointed out, this may drop traffic from some peering networks that are not in the global routing table. Though one could argue that if a packet needs to be fragged it's typically closer to the edges rather than the transit/peering links. -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://pgp.inoc.net/rblayzor/
Re: [c-nsp] LDPv6 Census Check
On Thu, 11 Jun 2020 at 18:32, David Sinn 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
Re: Partial vs Full tables
On Thu, Jun 11, 2020 at 12:01:38AM +0200, Baldur Norddahl wrote: Am I correct in assuming loose mode RPF only drops packets from unannounced address space in the global routing table? And the downside of doing so is that sometimes we do receive packets from that address space, usually back scatter from traceroute or other ICMP messages. uRPF absolutely kills the pps performance or your hardware due to the packet having to be recirculated to do the check(at least this is the case on every platform that ive ever tested it on). use acl's to protect your edge. -b
Re: Update your ARIN IRR data access methods (was: Fwd: [arin-announce] New Internet Routing Registry Release)
Hello - The 'whois.radb.net' IRR instance and the RADb services have been updated to reflect ARIN's IRR updates. - - Mitchell Mitchell Kuch and the RADb Team On Wed, Jun 10, 2020 at 2:54 PM John Curran wrote: > > 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 > Subject: [arin-announce] New Internet Routing Registry Release > Date: 10 June 2020 at 2:34:55 PM EDT > To: > > 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.
Re: Partial vs Full tables
On Thu, Jun 11, 2020 at 9:08 AM brad dreisbach wrote: > uRPF absolutely kills the pps performance or your hardware due to the packet > having to be recirculated to do the check(at least this is the case on every > platform that ive ever tested it on). use acl's to protect your edge. Hi Brad, Don't the ACLs generally live in a partition of the TCAM too? So you're going from two constant-time TCAM lookups per packet (route, acls) to three (route, urpf, acls)? Not rhetorical; getting close to the edge of my knowledge here. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Partial vs Full tables
You are a dismissive little twit aren’t you. :/ > On Jun 11, 2020, at 9:56 AM, William Herrin wrote: > > On Thu, Jun 11, 2020 at 6:25 AM Brian Johnson > wrote: >> I fully understand that I have not “broken” anything. > > Handwaving, la la la, only sunshine in the sky. Got it. > > -Bill > > > > -- > William Herrin > b...@herrin.us > https://bill.herrin.us/
Re: Partial vs Full tables
> On Jun 10, 2020, at 6:40 PM, brad dreisbach wrote: > > On Thu, Jun 11, 2020 at 12:01:38AM +0200, Baldur Norddahl wrote: >> Am I correct in assuming loose mode RPF only drops packets from unannounced >> address space in the global routing table? And the downside of doing so is >> that sometimes we do receive packets from that address space, usually back >> scatter from traceroute or other ICMP messages. > > uRPF absolutely kills the pps performance or your hardware due to the packet > having to be recirculated to do the check(at least this is the case on every > platform that ive ever tested it on). use acl's to protect your edge. > > -b Completely agree for edge scenario 100%. And now for Bill to talk down to me…. :/
Re: [c-nsp] LDPv6 Census Check
Just to clarify the only routers who potentially need to inspect or do anything with those headers are endpoints who require information in the extension header or hops in an explicit path. In the simple example I gave, there are no extension headers at all. I'm pretty agnostic to IPv6 SR-MPLS and SRv6, but just want to clarify that. I'm not going to claim inserting/swapping v6 extension headers is what all routers made in the last 20 years are especially good at. ( But it's not impossible to do it in some shipping devices today at wire rate with deterministic latency. As for normal v6 forwarding, the way most higher speed routers made recently work there is little difference in latency since the encapsulation for the packet is done in a common function at the end of the pipeline and the lookups are often in the same memory space. NPUs are also being built today with enough on-package memory to hold larger routing tables. Whether a packet has to be buffered on-chip vs. off-chip has a much larger impact on latency/PDV than a forwarding lookup. Thanks, Phil On 6/11/20, 5:07 AM, "NANOG on behalf of Nick Hilliard" wrote: Saku Ytti wrote on 11/06/2020 05:51: > Unfortunately SRv6 is somewhat easy to market with the whole 'it's > simple, just IP' spiel. it's not "just IP": it's ipv6 with per-router push / pop operations on ipv6 extension headers, i.e. high touch in areas which are known to be deeply troublesome on hardware. In this regard alone, the specification is problematic enough that it's unearthed a bug in the IPv6 standard (rfc8200). Nick
Re: Partial vs Full tables
On 10/Jun/20 19:31, William Herrin wrote: > > Sorry, it'd be pre-coffee if I drank coffee and I was overly harsh > here. Let me back up: > > The most basic spoofing protection is: don't accept remote packets > pretending to be from my IP address. > > Strict mode URPF extends this to networks: don't accept packets on > interfaces where I know for sure the source host isn't in that > direction. It works fine in network segments whose structure requires > routes to be perfectly symmetrical: on every interface, the packet for > every source can only have been from one particular next hop, the same > one that advertises acceptance of packets with that destination. The > use of BGP breaks the symmetry requirement so close to always that you > may as well think of it as always. Even with a single transit or a > partial table. Don't use strict mode URPF on BGP speakers. > > Loose mode URPF is... broken. It was a valiant attempt to extend > reverse path filtering into networks with asymmetry but I've yet to > discover a use where there wasn't some faulty corner case. If you > think you want to use loose mode RPF, trust me: you've already passed > the point where any RPF was going to be helpful to you. Time to set it > aside and solve the problem a different way. We don't run Loose Mode on peering routers because they don't carry a full table. If anyone sent the wrong packets that way, they wouldn't be able to leave the box anyway. We do run Loose Mode on transit routers, no issues thus far. We do run Strict Mode on customer-facing links that are stub-homed to us (DIA). We also run Loose Mode on customer-facing links that buy transit (BGP). But mostly, BCP-38 deployed at the edge (peering, transit and customer routers) also goes a long way in protecting the network. Mark.
Re: Partial vs Full tables
On 11/Jun/20 00:41, Job Snijders wrote: > > Back to basics: as Ytti suggested earlier in the thread, it might be more > sensible to generate your own default route based on a 'stable anchor prefix' > coming from the ISP rather than accepting the default your ISP originates > towards you. This, for me, makes a bit more sense. Especially when the number of customers asking for default far outweighs those that don't, for a large network where designing this can be quite tricky. Mark.
Re: [c-nsp] LDPv6 Census Check
On Thu, 11 Jun 2020 at 19:49, Phil Bedard wrote: > As for normal v6 forwarding, the way most higher speed routers made recently > work there is little difference in latency since the encapsulation for the > packet is done in a common function at the end of the pipeline and the > lookups are often in the same memory space. NPUs are also being built today > with enough on-package memory to hold larger routing tables. Whether a > packet has to be buffered on-chip vs. off-chip has a much larger impact on > latency/PDV than a forwarding lookup. On-package is not important, on-chip or off-chip is what matters, i.e. do you eat SERDES to connect memory or not. Of course you could always implement a software feature that says these 32b/32 or 128b/128 addresses are blessed and need to live on tiny on-chip memory and from this CIDR we guarantee all are host routes. To achieve similar-to-MPLS performance, with few more bytes per number. The demand is, we need tunneling, then the question is what are the metrics of a good tunneling solution. By answering this honestly, MPLS is better. We could do better surely, but IP is not that. -- ++ytti
Re: [c-nsp] LDPv6 Census Check
Phil Bedard wrote on 11/06/2020 17:49: Just to clarify the only routers who potentially need to inspect or do anything with those headers are endpoints who require information in the extension header or hops in an explicit path. In the simple example I gave, there are no extension headers at all. perhaps, but no-one planning to use srv6 is going to invest in kit which can handle srv6 but not the TE component. Or deploy srv6 on existing kit which can't handle TE. Nick
Re: Partial vs Full tables
On Thu, Jun 11, 2020 at 9:35 AM Brian Johnson wrote: > You are a dismissive little twit aren’t you. :/ Someone stood up and said, "Nope, nothing I did could possibly have broken anything." I'm pretty sure that someone was you but feel free to call me on it if I'm mistaken. Look, at the risk of doing further offense, it's like I said: it's one thing to educate yourself about a topic and then make a judgement call about what's acceptable. It's quite another to remain willfully ignorant in service of your preferred view. I just got through describing specific scenarios where loose urpf fails when you responded that no, it doesn't break anything. If you'd said, "no, that breakage is a small price worth paying," I'd have debated the merits with you or simply let it stand as a contrary opinion. Refusing to acknowledge the breakage is worth only dismissal. Regards, Bill -- William Herrin b...@herrin.us https://bill.herrin.us/
IPv4 Broker / Service -
Hi Nanog, I have need of a reputable IPv4 broker or service - personal experience with said broker would be preferred. These would be for small blocks - /23, 24s - in the US, so ARIN. I know, I know, IPv6 for life and all that and I agree, but . you know, the business. I'm happy to take responses off-list, but I would really appreciate any recommendations. Thanks! Ed
Re: IPv4 Broker / Service -
Replied off-list Eric On Jun 11 2020, at 2:27 pm, edwin.malle...@gmail.com wrote: > Hi Nanog, > > > I have need of a reputable IPv4 broker or service – personal experience with > said broker would be preferred. These would be for small blocks - /23, 24s – > in the US, so ARIN. I know, I know, IPv6 for life and all that and I agree, > but … you know, the business. I’m happy to take responses off-list, but I > would really appreciate any recommendations. > > Thanks! > > Ed
Re: Partial vs Full tables
Wow. Full distorted vision of reality mode here… uRPF doesn’t “break” anything. I stand by that. It’s not a religious position. It’s an operational experience. One that I have multitudes of real world examples of it working to SOLVE issues. You seem to be willfully ignorant about how real networks use tools that you dislike to solve problems. This is way more of a problem with you disliking uRPF than me telling you that I like it for some applications. Now I remember why I usually never post on this list now. I will just dismiss your opinions going forward instead of trying to point out that you aren’t the only measure of a network. Thanks Bill. > On Jun 11, 2020, at 1:11 PM, William Herrin wrote: > > On Thu, Jun 11, 2020 at 9:35 AM Brian Johnson > wrote: >> You are a dismissive little twit aren’t you. :/ > > Someone stood up and said, "Nope, nothing I did could possibly have > broken anything." I'm pretty sure that someone was you but feel free > to call me on it if I'm mistaken. > > Look, at the risk of doing further offense, it's like I said: it's one > thing to educate yourself about a topic and then make a judgement call > about what's acceptable. It's quite another to remain willfully > ignorant in service of your preferred view. I just got through > describing specific scenarios where loose urpf fails when you > responded that no, it doesn't break anything. If you'd said, "no, that > breakage is a small price worth paying," I'd have debated the merits > with you or simply let it stand as a contrary opinion. Refusing to > acknowledge the breakage is worth only dismissal. > > Regards, > Bill > > -- > William Herrin > b...@herrin.us > https://bill.herrin.us/
Re: [c-nsp] LDPv6 Census Check
On 6/11/20, 1:19 PM, "Saku Ytti" wrote: On Thu, 11 Jun 2020 at 19:49, Phil Bedard wrote: > As for normal v6 forwarding, the way most higher speed routers made recently work there is little difference in latency since the encapsulation for the packet is done in a common function at the end of the pipeline and the lookups are often in the same memory space. NPUs are also being built today with enough on-package memory to hold larger routing tables. Whether a packet has to be buffered on-chip vs. off-chip has a much larger impact on latency/PDV than a forwarding lookup. On-package is not important, on-chip or off-chip is what matters, i.e. do you eat SERDES to connect memory or not. [pmb] Sorry meant to say on-die, not on-package. Typically the time it takes to do those lookups are built into the system specs to attain the performance you need with deterministic latency within a certain bounds. There are certainly corner cases where you make tradeoffs, especially now that single NPUs are 10+ Tbps, but it's not really an MPLS vs. IPv4 vs. IPv6 thing. The other key is to do those types of accesses in a single pass, not traverse multiple hierarchy levels or do multiple operations. If you are tunneling then the table for any of those types is going to small on a mid-point router.
Re: IPv4 Broker / Service -
For small needs? Honestly, don’t waste too much time. Overhead is expense. The market is competitive. You care about if it is clean, chain of custody and can it legitimately transfer to you. BTW, IPV6? ARIN v6 NAT block? Make sure you exhaust all options before paying. I have never used it. However, I find the people at Hilco reputable. https://ipv4auction.com Good luck! -M< On Thu, Jun 11, 2020 at 14:29 wrote: > Hi Nanog, > > > > I have need of a reputable IPv4 broker or service – personal experience > with said broker would be preferred. These would be for small blocks - > /23, 24s – in the US, so ARIN. I know, I know, IPv6 for life and all that > and I agree, but … you know, the business. I’m happy to take responses > off-list, but I would really appreciate any recommendations. > > > > Thanks! > > > > Ed >
Re: IPv4 Broker / Service -
Hi +1 for Hilco. I've made 2 deals with them, no problem, people are professional, Cheers Pierre Le jeu. 11 juin 2020 à 20:54, Martin Hannigan a écrit : > > For small needs? Honestly, don’t waste too much time. Overhead is expense. > > The market is competitive. You care about if it is clean, chain of custody > and can it legitimately transfer to you. BTW, IPV6? ARIN v6 NAT block? Make > sure you exhaust all options before paying. > > I have never used it. However, I find the people at Hilco reputable. > >https://ipv4auction.com > > > Good luck! > > -M< > > > On Thu, Jun 11, 2020 at 14:29 wrote: > >> Hi Nanog, >> >> >> >> I have need of a reputable IPv4 broker or service – personal experience >> with said broker would be preferred. These would be for small blocks - >> /23, 24s – in the US, so ARIN. I know, I know, IPv6 for life and all that >> and I agree, but … you know, the business. I’m happy to take responses >> off-list, but I would really appreciate any recommendations. >> >> >> >> Thanks! >> >> >> >> Ed >> >
Re: IPv4 Broker / Service -
Addrex.net I know some of the principles personally and would vouch for them. On June 11, 2020 at 14:27 edwin.malle...@gmail.com (edwin.malle...@gmail.com) wrote: > Hi Nanog, > > > > I have need of a reputable IPv4 broker or service ? personal experience with > said broker would be preferred. These would be for small blocks - /23, 24s ? > in the US, so ARIN. I know, I know, IPv6 for life and all that and I agree, > but ? you know, the business. I?m happy to take responses off-list, but I > would really appreciate any recommendations. > > > > Thanks! > > > > Ed > -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Re: [c-nsp] LDPv6 Census Check
On Thu, 11 Jun 2020 at 21:04, David Sinn 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
RE: [c-nsp] LDPv6 Census Check
> 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
Re: [c-nsp] LDPv6 Census Check
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.
RE: [c-nsp] LDPv6 Census Check
> From: Mark Tinka > Sent: Thursday, June 11, 2020 3:59 PM > > > No, my line of reasoning is if you have MPLS LSPs signalled over v4 I see no > point having them signalled also over v6 in parallel. > > It's not about signaling IPv4 LSP's over IPv6. > LDPv4 creates IPv4 FEC's. > LDPv6 creates IPv6 FEC's. > > The idea is to create IPv6 FEC's so that IPv6 traffic can be label-switched in > the network natively, allowing you to remove BGPv6 in a native dual-stack > core. > Right I see what you are striving to achieve is migrate from BGP in a core to a BGP free core but not leveraging 6PE or 6VPE? > > As you can see, just as with IPv4, IPv6 packets are now being MPLS-switched > in the core, allowing you to remove BGPv6 in the core and simplify > operations in that area of the network. > > So this is native MPLSv6. It's not 6PE or 6VPE. > So considering you already had v4 FECs wouldn't it be simpler to do 6PE/6VPE, what do you see as drawbacks of these compared to native MPLSv6 please? > > Apart from X months worth of functionality, performance, scalability and > interworking testing -network wide code upgrades to address the bugs > found during the testing process and then finally rollout across the core and > possibly even migration from LDPv4 to LDPv6, involving dozens of people > from Arch, Design, OPS, Project management, etc... with potential for things > to break while making changes in live network. > > Which you wouldn't have to do with SRv6, because you trust the vendors? > Well my point was that if v4 FECs would be enough to carry v6 traffic then I wouldn't need SRv6 nor LDPv6, hence I'm curious to hear from you about the benefits of v6 FEC over v4 FEC (or in other words MPLSv6 vs 6PE/6VPE). adam
RE: Partial vs Full tables
Mark (and others), I used to run loose uRPF on peering/transit links for AS3128 because I used to think that tightening the screws was always the "right thing to do". I instrumented at 60s granularity with vendor J uRPF drop counters on these links. Drops during steady state [bgp converged] were few [Kbps]. Drops during planned maintenance were at much rates for a few minutes. What was happening: I advertise a handful of routes to transit/peers from multiple ASBR. Typically my ASBR sees 800K FIB and a few million RIB routes We all know this takes a good amount of time to churn.. For planned maintenance of ASBR A [cold boot upgrades], if recovery didn't include converging my inbound routes before doing eBGP advertising, I'd be tossing packets due to loose uRPF. Remember during this time 'ASBR B' in my AS is happy egressing traffic as soon as 'ASBR A' advertises my dozen or so prefixes via eBGP, I start to see return traffic much sooner than before 'ASBR A' has converged. No more specific return route yet other than maybe default for a few minutes if unlucky.. The result is bit bucket networkwide despite ASBR B functioning just fine. Maybe everyone already convergences inbound before advertising eBGP and I made a rookie mistake, but what about unplanned events? For me the summary is that I was causing more collateral damage than good [verified by time series data], so I turned off loose URPF. YMMV. -Michael > -Original Message- > From: NANOG On Behalf Of Mark Tinka > Sent: Thursday, June 11, 2020 12:14 PM > To: nanog@nanog.org > Subject: Re: Partial vs Full tables > > > > On 10/Jun/20 19:31, William Herrin wrote: > > > > > Sorry, it'd be pre-coffee if I drank coffee and I was overly harsh > > here. Let me back up: > > > > The most basic spoofing protection is: don't accept remote packets > > pretending to be from my IP address. > > > > Strict mode URPF extends this to networks: don't accept packets on > > interfaces where I know for sure the source host isn't in that > > direction. It works fine in network segments whose structure requires > > routes to be perfectly symmetrical: on every interface, the packet for > > every source can only have been from one particular next hop, the same > > one that advertises acceptance of packets with that destination. The > > use of BGP breaks the symmetry requirement so close to always that you > > may as well think of it as always. Even with a single transit or a > > partial table. Don't use strict mode URPF on BGP speakers. > > > > Loose mode URPF is... broken. It was a valiant attempt to extend > > reverse path filtering into networks with asymmetry but I've yet to > > discover a use where there wasn't some faulty corner case. If you > > think you want to use loose mode RPF, trust me: you've already passed > > the point where any RPF was going to be helpful to you. Time to set it > > aside and solve the problem a different way. > > We don't run Loose Mode on peering routers because they don't carry a > full table. If anyone sent the wrong packets that way, they wouldn't be > able to leave the box anyway. > > We do run Loose Mode on transit routers, no issues thus far. > > We do run Strict Mode on customer-facing links that are stub-homed to us > (DIA). We also run Loose Mode on customer-facing links that buy transit > (BGP). > > But mostly, BCP-38 deployed at the edge (peering, transit and customer > routers) also goes a long way in protecting the network. > > Mark.
Re: Partial vs Full tables
On 12/Jun/20 04:01, Michael Hare wrote: > Mark (and others), > > I used to run loose uRPF on peering/transit links for AS3128 because I used > to think that tightening the screws was always the "right thing to do". > > I instrumented at 60s granularity with vendor J uRPF drop counters on these > links. Drops during steady state [bgp converged] were few [Kbps]. Drops > during planned maintenance were at much rates for a few minutes. > > What was happening: I advertise a handful of routes to transit/peers from > multiple ASBR. Typically my ASBR sees 800K FIB and a few million RIB routes > We all know this takes a good amount of time to churn.. > > For planned maintenance of ASBR A [cold boot upgrades], if recovery didn't > include converging my inbound routes before doing eBGP advertising, I'd be > tossing packets due to loose uRPF. > > Remember during this time 'ASBR B' in my AS is happy egressing traffic as > soon as 'ASBR A' advertises my dozen or so prefixes via eBGP, I start to see > return traffic much sooner than before 'ASBR A' has converged. No more > specific return route yet other than maybe default for a few minutes if > unlucky.. The result is bit bucket networkwide despite ASBR B functioning > just fine. > > Maybe everyone already convergences inbound before advertising eBGP and I > made a rookie mistake, but what about unplanned events? > > For me the summary is that I was causing more collateral damage than good > [verified by time series data], so I turned off loose URPF. YMMV. To be honest, we haven't seen this. We've got plenty of peering and transit exit/entry points, each just about dedicated to its own router, across multiple cities in Africa (peering) and Europe (peering + transit). We also only do about 10% - 15% of traffic via transit (remember, we don't run any kind of uRPF on our peering routers). We originate our aggregates from deep within the core, never from the transit, peering or edge routers. We did experience some slowness with the ASR9001 some years back during convergence for the transit network that was connected to that router in Amsterdam, but it had been slowing down for years. Since swapping it out for MX480's and/or MX204's, that problem has since gone away. Mark.
Re: [c-nsp] LDPv6 Census Check
On 11/Jun/20 23:45, adamv0...@netconsultings.com wrote: > Right I see what you are striving to achieve is migrate from BGP in a core to > a BGP free core but not leveraging 6PE or 6VPE? Yes sir. > So considering you already had v4 FECs wouldn't it be simpler to do 6PE/6VPE, > what do you see as drawbacks of these compared to native MPLSv6 please? Because 6PE, for us, adds a lot more complexity in how we design the network. But most importantly, it creates a dependency for the success of IPv6 on IPv4. If my IPv4 network were to break, for whatever reason, it would take my IPv6 network down with it. Years back, there was a nasty bug in the ASR920 that set an upper limit on the MPLS label space it created FEC's for. Since Juniper sometimes uses higher label numbers than Cisco, traffic between that ASR920 and our Juniper network was blackholed. It took weeks to troubleshoot, Cisco sent some engineering code, I confirmed it fixed the issue, and it was rolled out generally. During that time when the ASR920 was unavailable on IPv4, it was still reachable on IPv6. Other issues are also with the ASR920 and ME3600X/3800X routers, where 0/0 and ::/0 are the last routes to be programmed into FIB when you run BGP-SD. It can be a while until those boxes can reach the rest of the world via default. IPv6 will get there faster. I also remember another issue, back in 2015, where a badly-written IPv4 ACL kicked one of our engineers out of the box. Thankfully, he got back in via IPv6. I guess what I'm saying is we don't want to fate-share. IPv4 and IPv6 can operate independently. A failure mode in one of them does not necessarily propagate to the other, in a native, dual-stack network. You can deploy something in your IPv6 control/data plane without impacting IPv4, and vice versa, if you want to roll out gracefully, without impacting the other protocol. 6PE simply has too many moving parts to setup, comparing to just adding an IPv6 address to a router interface and updating your IGP. Slap on LDPv6 for good measure, and you've achieved MPLSv6 forwarding without all the 6PE faffing. > Well my point was that if v4 FECs would be enough to carry v6 traffic then I > wouldn't need SRv6 nor LDPv6, hence I'm curious to hear from you about the > benefits of v6 FEC over v4 FEC (or in other words MPLSv6 vs 6PE/6VPE). No need for 6PE deployment and day-to-day operation complexity. A simplified and more native tunneling for IPv6-in-MPLSv6, rather than IPv6-in-MPLSv4-on-IPv4. No inter-dependence between IPv6 and IPv4. Easier troubleshooting if one of the protocols is misbehaving, because then you are working on just one protocol, and not trying to figure if IPv4 or MPLSv4 are breaking IPv6, or vice versa. For me, those 4 simple points help me sleep well at 3AM, meaning I can stay up longer having more wine, in peace :-). Mark.
