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. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LDPv6 Census Check
> On Jun 11, 2020, at 8:41 AM, Saku Ytti wrote: > > 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. But now you are comparing apples and oranges. You're asserting that all IP lookups require external memory. But your talking about comparing a lite-core to a heavy-core. As I said, it depend on deployments. If you have a lite-IP core you don't need external memories. So there isn't a lag question going out to massive memories needed for 2M+ entires. So it is not always that lookups are slow, expensive, complex. Sure, you can build a network around a heavy core but you can also build one without. Sweeping generalizations that MPLS is always better than all other technologies is just that, a sweeping generalization. It misses a ton of points. Rewrites on MPLS is horrible from a memory perspective as maintaining the state and label transition to explore all possible discrete paths across the overall end-to-end path you are trying to take is hugely in-efficient. Applying circuit switching to a packet network was bad from the start. SR doesn't resolve that, as you are stuck with a global label problem and the associated lack of being able to engineer your paths, or a label stack problem on ingress that means you need a massive ASIC's and memories there. IP at least gives you rewrite sharing, so in a lite-core you have way better trade-off on resources, especially in a heavily ECMP'ed network. Such as one build of massive number of open small boxes vs. a small number of huge opaque ones. Pick your poison but saying one is inheriantly better then another in all cases is just plane false. > 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! 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. David > > -- > ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LDPv6 Census Check
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. 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. And if the argument is coming down to the lookup delay between the two and your talking about the WAN, speed of light is dominate so the ns differences are in the noise, baring the monetary exchanges. Your follow on statement about more ports and smaller silicon is in abstract somewhat correct but is practice not. Across the silicon manufactures no one in the open market is making a purely MPLS capable chip. With the cost of chips today, you must have multiple customers for the silicon, or, if you are using wholly internally, have enough volume to justify the $100M's that it costs to make. So everyone is optimizing around re-use and maximal customer overlap for execution. So they all do MPLS and IP and SR and IPIP and ... making the argument moot. But please to not take this as saying SRv6 is great. The community got v6 wrong in a number of areas and SR is not helping that. v4 as a transport vs. MPLS is a useful conversation to be had, again depending on deployment and philosophy around large vs. small network nodes. David > On Jun 10, 2020, at 9:51 PM, Saku Ytti wrote: > > On Thu, 11 Jun 2020 at 00:48, Mark Tinka wrote: > >> On 10/Jun/20 21:36, Phil Bedard wrote: >>> In its simplest form without TE paths, there isn't much to SRv6. You use a >>> v6 address as an endpoint and a portion of the address to specify a >>> specific VPN service. You completely eliminate the label distribution >>> protocol. >> >> A BGPv6-free core is a decent use-case for us. > > 100% Eliminating label forwarding in core is not an asset, it is a > liability. Label forwarding is fast, cheap and simple[0]. You can do > it with on-chip memory in constant time. IP lookups are slow, > expensive and complex[0]. SRv6 marketing is false, bordering dishonest > marketing of an unclean abomination of a protocol. 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. > > [0] None of this is hard to measure, it is a known fact. And all of it > matters, you can measure lower jitter for MPLS than IP, you can better > carry DDoS traffic when using MPLS compared to IP and you can have > more ports in front-plate for the same money, by spending external > memory SERDES for WAN ports. > > > > -- > ++ytti > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LDPv6 Census Check
please remove me from this mailing list On 11/06/2020 15:58, Mark Tinka wrote: 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. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LDPv6 Census Check
Hi, On Thu, Jun 11, 2020 at 01:17:55PM +0100, adamv0...@netconsultings.com wrote: > But running MPLS over IPv6 in addition to already running it over IPv4, Not "in addition to" but "to throw out the IPv4 part" :-) More relevant to strongly growing networks that do not need to roll out IPv4 to new parts, though. (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...) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LDPv6 Census Check
On Thu, 11 Jun 2020 at 13:33, Robert Raszuk wrote: > SR-MPLS implies globally (domain wide) label significance. Index in the IGP > extensions is there just to relax requirement to use the same block on all > nodes - so the block does not need to be continuous in an SR domain. It is > recommended by Cisco but not required by standard. As all need to agree on having label at a given offset for the application, the range either needs to be continuous or have the same holes which are not used by anyone. It is slightly more convenient to an equal size continuous label. This is not unlike VPLS. -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LDPv6 Census Check
On 11/Jun/20 12:54, Robert Raszuk wrote: > No doubt. > > However one network is not equal the other. Especially SP/ISP network > requirements and any to any traffic patterns there are very different > from typical hub and spoke connectivity in the content or service > serving enterprise. Totally agree, which is why I said if you are building a backbone across all continents, the ability of your hardware is the least of your problems. You'll probably spend more time dealing with backbone and license issues. > > So if I am to put 1000 routers in the flat network, reduce OSPF timers > and inject all 1000 BGP next hops with label to all 999 PEs while I > only need 999 PEs to ever reach 10 next hops I would keep to argue > flat IGP is not the right choice. While I don't use OSPF, that almost sounds like something you'd do at an EBC with a vendor in the lab. Real networks may operate slightly less over-zealously :-). But who knows, only time will tell. The problem is each time we seem to reach the peak of what control planes can do, they up the ante. If I was having this discussion with you 10 years ago, I'd be in total agreement. > > Moreover as one of the best industry IGP developer and expert I highly > respect stated very recently the end to end flooding time should stay > below 200 ms. That is not your ICMP RTT ... that is time to receive > the LSA/LSP to local RE, install in LSDB and send it back. That > determines the flooding radius you should try not to exceed. And the > time packet takes to even get from LC to RE is very platform dependent > as I am sure most of you know very well :) I won't diss the IGP developers, they help us to eat. But after being in the game this long, I've often found that caution and real life don't always align. Naturally, we will take the considerations, and see what feedback we get from the actual network, and adjust accordingly. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LDPv6 Census Check
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'. Drikus. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LDPv6 Census Check
> Well, we operate a single IS-IS L2 domain across 3 continents. > > We use what-I'd-call aggressive IS-IS detection and convergence timers, > in addition to BFD and LFA/IP-FRR. > > We do very okay. > No doubt. However one network is not equal the other. Especially SP/ISP network requirements and any to any traffic patterns there are very different from typical hub and spoke connectivity in the content or service serving enterprise. So if I am to put 1000 routers in the flat network, reduce OSPF timers and inject all 1000 BGP next hops with label to all 999 PEs while I only need 999 PEs to ever reach 10 next hops I would keep to argue flat IGP is not the right choice. Moreover as one of the best industry IGP developer and expert I highly respect stated very recently the end to end flooding time should stay below 200 ms. That is not your ICMP RTT ... that is time to receive the LSA/LSP to local RE, install in LSDB and send it back. That determines the flooding radius you should try not to exceed. And the time packet takes to even get from LC to RE is very platform dependent as I am sure most of you know very well :) Cheers, R. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LDPv6 Census Check
On 11/Jun/20 12:28, Robert Raszuk wrote: > > Spot on ! OSPF is not any better. > > And yes you can build a global flat IGP. But this is not a design I > would endorse in most networks. > > Reason is that most networks do not have latest connectivity > restoration techniques and still wait for typical "IGP convergence" So > if you flood globally you need to adjust your IGP & SPF timers with > the notion of global flooding. > > If you however scope your flooding domains to be relatively small (say > per 1-few regions in a continent) you can easily and safely make those > timers much more aggressive hence significantly reducing connectivity > restoration times upon failures. Well, we operate a single IS-IS L2 domain across 3 continents. We use what-I'd-call aggressive IS-IS detection and convergence timers, in addition to BFD and LFA/IP-FRR. We do very okay. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LDPv6 Census Check
> 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. > LDP or MPLS LSPs require hop by hop label swapping (directly connected or over say IP tunnels). So labels in LDP are always locally significant. SR-MPLS implies globally (domain wide) label significance. Index in the IGP extensions is there just to relax requirement to use the same block on all nodes - so the block does not need to be continuous in an SR domain. It is recommended by Cisco but not required by standard. Thx R. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LDPv6 Census Check
/* removing nanog list as I am not subscribed there and it bounces back */ > 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. Spot on ! OSPF is not any better. And yes you can build a global flat IGP. But this is not a design I would endorse in most networks. Reason is that most networks do not have latest connectivity restoration techniques and still wait for typical "IGP convergence" So if you flood globally you need to adjust your IGP & SPF timers with the notion of global flooding. If you however scope your flooding domains to be relatively small (say per 1-few regions in a continent) you can easily and safely make those timers much more aggressive hence significantly reducing connectivity restoration times upon failures. Many thx, R. On Thu, Jun 11, 2020 at 12:15 PM Mark Tinka wrote: > > > 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. > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LDPv6 Census Check
> > 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'. > 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. - - - 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. Best, R. [**] - https://mailarchive.ietf.org/arch/msg/ipv6/Ef05LFFij45mm8fM8hLFXknxoIA/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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
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. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 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". -- R.-A. Feurdean ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
