[c-nsp] Basic understanding of 6PE and 6VPE

[Mark Tinka]

On Tuesday, June 26, 2012 09:23:20 AM adam vitkovsky wrote:

> Right QOS is another thing that would need to be adjusted
> if native IP is introduced into MPLS only core
> Anyways as Saku mentioned if you are doing IPv4 natively
> than enabling native IPv6 makes perfect sense and if one
> runs BGP-free core and MPLS switching than 6PE/VPE is
> the natural choice

I'm on both sides of the fence.

We run a BGP-free core for IPv4, because we have MPLS 
switching in there. However, ICMP Tunneling is used in the 
core to ensure our customers and NOC can still have 
meaningul traceroute output when they troubleshoot.

MPLS requires IP to run, not the other way around. So having 
a proper, IP backbone is crucial to supporting MPLS, let 
alone the IP services you offer customers.

It is for this reason that we deploy native IPv6 in the 
core, and run BGP in there for IPv6. We refuse to support 
6PE because it adds complexity. 

When LDPv6 and RSVPv6 become a reality, we shall mirror our 
IPv4 topology and deploy MPLS for IPv6 in the core, but 
still maintain ICMP visibility of the network.

We like MPLS for the applications it affords us, and that's 
it. We don't try to use it to replace IP.

> Regarding the TTL hiding it's new to me that some
> Customers would like to see all the MPLS hops

Not all customers who run across your MPLS network are 
buying l3vpn services.

> However I guess if the network runs as supposed to the
> Customers wouldn't mind the missing extra hops in their
> traceroutes...

If networks run like they were "supposed to", this list 
wouldn't be as busy as it is.

> Personally I think that if the Customer has
> to tell you that there's something wrong with your core
> links than things must have gone fishy a while back(when
> the network was built, monitoring tools implemented or
> staff hired)

It isn't untrue that opening up your backbone to scrutiny by 
clueless customers gives you more work, e.g., hop 8 shows 
packet loss when doing traceroute, but an end-to-end ping 
from source destination reads 0% for packet loss - oh wait, 
perhaps ICMP throttling in the control plane of hop 8.

That said, we still believed it was worthwhile being able to 
offer our customers truth in network management. Besides, as 
Gert said, if all you can tell them is "everything tests OK 
on our side", you won't be left with any customers soon 
enough anyway.

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/20120706/615707b7/attachment.sig>