[j-nsp] LSP's with IPV6 on Juniper

[adamv0025 at netconsultings.com]

Hi Rob,
Some interesting points you raised indeed,


> Of Rob Foehl
> Sent: Wednesday, August 29, 2018 6:14 AM
> 
> On Tue, 28 Aug 2018, adamv0025 at netconsultings.com 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::