Hi Rob, Some interesting points you raised indeed,
> Of Rob Foehl > Sent: Wednesday, August 29, 2018 6:14 AM > > On Tue, 28 Aug 2018, [email protected] wrote: > > > Just out of curiosity is there a business problem/requirement/limitation > you're trying to solve by not changing the next hop to v6 mapped v4 address > and using native v6 NHs instead please? > > I'd asked a similar question as the OP two weeks ago in the thread about > mixing v4 and v6 in the same BGP peer groups, after several responses > extolling the virtues of avoiding any conflation between the two. If that's the > case for routing, but forwarding v6 in an entirely v4-dependent manner on a > 100% dual stack network is tolerable, then this inconsistency is... > inconsistent. > It's a slippery slope this separation one, what separation is sufficient separate LDP or IGP or even BGP for v6? I guess the key to striking the balance between separation and convergence is probability. Let me explain, Let's divide the routing information carried by a typical NSP network into 3 sets. The graph can be imagined as 3 concentric circles of different sizes. The outermost layer represents the internet routes, the one below represents customer routes and the centre circle represents infrastructure routes. Routes from the outermost layer representing the internet has the highest probability of screwing your network. In most cases the outer layer of internet routes is vast in comparison with the other two but there are few cases where its dwarfed by the customer routes layer. But the point is the number of routes doesn't matter it's the number of routing information sources -the higher the number the higher the probability that someone somewhere will screw up and that mess ends up in your as well as everyone else's BGP and when that happens you want as little collateral damage as possible thus separation is the means to reduce the fallout. And that's not only separation of this layer from the other two layers but also various separations within the layer itself. Second layer below that represents customer routes in some NSPs have millions of customer routes compared to "just" ~700k internet routes. Though usually majority of these routes are originated from managed CPEs or LNS-es etc... meaning the routing information sources are under control of the provider. And yes if you are an ISP then majority of your customer routes would fall into the internet routes layer, and there are also wires only services where customer is managing CPE. But the point is again irrespective if the number of routes in this layer the number of routing information sources is always smaller compared to the internet routes layer. As a result the lower probability of something bad happening naturally results in lower incentive to invest the time and effort to mitigate potential fallout. The inner circle/layer is composed of solely the infrastructure routes, this should be a very sterile environment. But the main point is that there's just one entity responsible for introducing all routes in this layer. This layer is where actually simplicity means robustness. Because the probability of say a malformed IPv4 TLV will bringing down ISIS for both v6 and v4 is such extremely low that the added complexity of running separate IGP/MPLS protocol stack for v6 and v4 is just added complexity that in itself is just asking for trouble. > By all outward appearances, v6 is still a second class citizen when it comes to > TE, and it doesn't seem unreasonable to ask why this is the way it is in 2018. > There are plenty of valid reasons for wanting parity. > Personally I'd vote against IPv6 support for existing RSVP-TE, the protocol has been around for ages with no new major features added and therefore all the implementations are very stable, I'd vote for a separate protocol altogether that can be enabled alongside the RSVP-TE (SR for instance). > > On contrary 6PE/6VPE is such a well-trodden path. > > The world is covered with well-trodden paths that have fallen into disuse > with the arrival of newer, better, more convenient infrastructure. > I wish you were right, but look at those DC folks and all that madness around VXLAN or now EVPN for VXLAN, -I mean there are these headers that can actually be stacked (like MPLS or IPv6 header) and could solve all their problems while keeping my life simpler when creating DCI solutions. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
