[c-nsp] 6PE FIB usage on 6500/7600

[Mark Tinka]

On Thursday, January 02, 2014 12:08:12 PM Phil Mayers wrote:

> 6vPE is IMO a slightly different beast, because the v4/v6
> variants are much closer. The use of v4 loopbacks in
> 6vPE next hops is a bit odd to be sure, but it's not a
> fundamentally different traffic forwarding paradigm as
> with 6PE.

Agree, but still not clean enough for me :-).

> That said, I agree that LDPv6 and friends would be good
> to have; one assumes big providers would be keen to run
> 4vPE and have v4-free cores to save on address space
> without using 10/8 for p2p links.

I think LDPv6 and RSVPv6 are dead, to be honest. No interest 
from vendors (probably because of little interest coming 
from operators - especially those flush with cash).

I think the future of an IPv6 control plane for MPLS is in 
SR. To be honest, I wouldn't bother developing LDPv6 or 
RSVPv6 with SR on the horizon, if I were a vendor in-tune 
with the times.

Vendors always complain about lack of use cases for MPLSv6, 
but I know one (in addition to an IPv6-free BGP core) - 
congruency between IPv4 and IPv6 for MPLS (or SR) Traffic 
Engineering. It's terrible that you can't point native IPv6 
traffic into an MPLS-TE LSP built over IPv4. So you end up 
with your IPv4 traffic taking the "best" path, while your 
IPv6 traffic is left to fend for itself. Not cool. Not cool 
at all.

It is for such reasons that I don't like today's breed of 
MPLS-biased forwarding engines (like Cisco's LSP for the 
CRS, and some of Juniper's PTX line cards), because they all 
assume everything is encapsulated in MPLS, including IPv6 
(6PE), and that's just not true when you're running (and 
sticking to) native IPv6. Those label-only forwarding 
engines have very little FIB space to keep them cheap and 
dumb, so what happens when you need to carry a full (and 
growing) IPv6 BGP table on such a card because you're a 
native IPv6 zealot, like myself?

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20140102/22a37775/attachment.sig>