[c-nsp] 6PE

[Mark Tinka]

On Wednesday, August 03, 2011 05:01:53 PM Mathieu Paonessa 
wrote:

> There's two different v4 world here:
> 	- We run IPv4 + IGP + MPLS with only the P/PE 
loopback
> and interco subnet. This keeps a very compact internal
> routing table and allows all our core infrasctructure
> not to be visible from outside.

Right, but MPLS forwarding requires IPv4 to be working. 
Something that can affect your IPv4 forwarding (it could be 
configuration, it could be code, it could be hardware) has a 
high chance of affecting your MPLS forwarding.

Now not only have you lost both v4 and MPLS, you've also 
lost v6 if you're doing 6PE (yes, it is possible that 
something which affects your v4 may not affect your v6, and 
vice versa).

I've seen many networks get themselves out of trouble when 
they muck up their v4 ACL's, but can still log back into the 
router/switch via v6. Of course, not a valid reason to 
deploy v6, but a good side benefit nonetheless.

> 	- "Internet" IPv4 is running inside a VRF like any 
other
> MPLS IP/VPN. Any routing issue on that IPv4 Internet
> world would not affect our IPv6 infrastructure.

Of course, but I wasn't talking about your v4 Internet - I 
was just saying that MPLS needs v4 to work, and 6PE needs 
MPLS. So in a long chain, 6PE needs v4, and would, thus, be 
sensitive to v4 events that have the potential to cause MPLS 
events.

> For many network these days, if your MPLS dies, your
> network dies.

Yes, but for others, it's not the case if your v6 is native.

Native v6 isn't affected by MPLS failure. 6PE is affected by 
MPLS failure, whatever the failure is caused by.

> Sure but what's the issue there?

Troubleshooting is more difficult, traceroutes look strange, 
complexity is increased especially at the edge, e.t.c.

Of course, it's not the end of the world, but if native is 
an option that is feasible, it certainly is much simpler to 
deploy and manage. Whether an operator chooses to go native 
or 6PE is really up to them.

> If you're running MPLS
> you're tunneling in v4 ou v6 anyway.

Ummh - not necessarily. Yes, v4 is wrapped inside MPLS for 
forwarding in the core when you turn MPLS on. But you also 
have native v4 running in the core which can forward v4 
packets without having them wrapped in MPLS (normally 
packets following the IGP, barring special cases of MPLS-
TE).

6PE is different - there's no v6 running in the core. It's 
just one big hole through which v6 packets enter, and 
hopefully, come out at the other end :-).

What I don't mind is native MPLS signaling for v6. That way, 
you still have native v6 configured in the core. But that's 
another IETF story :-).

> Damn, I must be one of those zealots :)

MPLS does have its benefits, and we use it to deliver 
several applications in our network, including IPTv services 
to a decent number of homes. So we do like it.

But it is possible to believe in MPLS too much that it tends 
to become a panacea. This is not just an operator problem, 
some vendors too. It's no secret that a huge amount of 
revenue for vendors comes from MPLS-related sales, which is 
why young IP engineers today want to learn about MPLS before 
they know what an IP address is :-). But let me not digress.

> Depending on what your network looks like, not always.
> For example if you run OSPF, you'll have to run two IGP
> so that makes twice the work when deploying new devices.
> Not saying that I've seen many people modifying their
> ospf cost in v4 and forgetting to do it in v6 when
> changing their routing topology.

There's a solution for that - go IS-IS :-).

But seriously, is native/dual-stack hard to do? Certainly! 
Ensuring that your v4 and v6 policies always match is a 
challenge to the level of human diligence (or laziness). You 
know what they say about good engineers :-).

But the long-term gain in suffering the pain now, in my 
opinion, is all worth it. For us, the simplicity of 
native/dual-stack is a huge pay off for all the time and 
hassle it took to equalize v4 and v6 configurations.

I can understand that for some networks, the effort may 
simply be too much to bear, so 6PE and other tunneling 
technologies are likely the only option, even though they 
may not be simple to manage in the long-term.

It's a trade-off.

> One of the reasons we went for 6PE back in 2007 is that
> we still had some Engine 2 GSR cards on the network and
> those are not able to do IPv6 in hardware. There was no
> way on earth that we would run software IPv6 on our core
> and had no budget to renew the core at that time.

Like I said, constraints such as yours are obviously very 
valid, as you have no other option but to tunnel v6 into v4 
somehow.

However, some networks don't have this restriction, and the 
extra effort involved in going dual-stack turns them away 
from, well, going native/dual-stack. We're human.

Some other folks have gone 6PE because they want to ensure 
v6 forwarding rates are equal to those of v4/MPLS (as the 
router assumes it's forwarding v4/MPLS packets). This is 
because most vendors, today, are spinning ASIC's that have 
lower pps forwarding rates for v6 than v4 and MPLS, but I'm 
sure you knew that already :-).

> I've done a presentation during the last FrNOG meeting
> about our 6PE experience. The talk is in french but the
> slides are in english (http://dai.ly/kRr5WE) if that
> could help.

I'm not doubting the efficacy of 6PE, or any other 
transition mechanism out there. It does work, and is 
carrying v6 traffic for many of the world's largest networks 
today.

Is it something I'd recommend for my (friend's) network. 
Short of being an evil competitor, probably not; unless 
there are extenuating circumstances as mentioned above.

Cheers,

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/20110803/a629e7b9/attachment.pgp>