Subject: AW: AW: IPv6 in MPLS Networks

From: "Bonness, Olaf" <[email-masked]>
Date: Tue, 24 Feb 2004 17:58:52 +0100

Hi Pekka,

within a complex ISP network you will never switch on IPv6 with one finger snip. You will choose a staged approach were you can scale according to the real requirements. Besides that you will for sure leave the core routers untouched as long as you can, because an error within this core router does you much more harm than a problem in one PE.

Furthermore MPLS has per definition a very flexibel and powerful label stack principle that allows us to implement new services based on it. Why not use this approach in a first step for offering IPv6 at the edges and than integrate it in the MPLS core sometimes in the future. The whole IPv6 migration is only a question of using the right mechanism at the right time ;-).
Besides that this MPLS label stack is more flexibel than (configured) tunnels and has as well less overhead.

Regards
	Olaf

> -----Ursprungliche Nachricht-----
> Von: Pekka Savola [mailto:[email-masked]]
> Gesendet: Montag, 23. Februar 2004 10:15
> An: Bonne?, Olaf
> Cc: [email-masked]
> Betreff: Re: AW: IPv6 in MPLS Networks
> 
> 
> On Thu, 19 Feb 2004, Bonness, Olaf wrote:
> [...]
> > Besides that, the costs for updating the software of several
> > thousands of routers are pretty high (in comparission to the actual
> > IPv6 business case ;-), so that IMHO the BGPTUNNEL is a very good
> > approach (at least for the first step !) for an IPv6 service offer
> > based on a MPLS backbone. The later steps of an IPv6 integration
> > could be than approach 2 and approach 1 from your email. (BTW
> > sometimes you have to upgrade your HW as well if you want to realise
> > "native" IPv6 MPLS and thats real expensive.)
> 
> I think typically the number of PE routers is much higher than the 
> number of core routers.  This would seem to imply that upgrading the 
> core is irrelevant nuisance compared to upgrading PE routers.  That 
> is, if you already have to upgrade 1000 PE routers -- and if v6 
> doesn't work properly, the customers attached to those are screwed 
> anyway -- upgrading 50 core routers is not so big an issue, when put 
> into the perspective.
> 
> Further, all of this, the lack of business case etc., can be avoided
> by using configured tunneling instead.  Until you have enough
> customers, etc., you could just set up a more hierarchical topology --
> no need to bother with a full mesh. Simple and robust, requiring zero
> new mechanisms.
> 
> In a few years time it might even be that those routers which were
> unable to do real IPv6 forwarding have been phased out and native IPv6
> (or directly over MPLS)  introduction in the core is possible.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>

---

From: Pekka Savola <[email-masked]>
Date: Wed, 25 Feb 2004 10:25:36 +0200 (EET)

On Tue, 24 Feb 2004, Bonness, Olaf wrote:
> within a complex ISP network you will never switch on IPv6 with one
> finger snip. You will choose a staged approach were you can scale
> according to the real requirements. 

Sure, the introduction of IPv6 is always gradual -- how fast each step
can be done (or is feasible to do) is a different issue, of course.

> Besides that you will for sure
> leave the core routers untouched as long as you can, because an
> error within this core router does you much more harm than a problem
> in one PE.

It's not as black and white.  The complexity at the PE vs the core is 
also a factor.  That is, if the changes in the core are very simple 
(compared to changes in the PEs, for example), making changes in the 
core start to be increasingly attractive as the number of PEs which 
need modification grow.  That is, when the number of modified PEs is 
high, a problem in the IPv6 code of those PEs would cause a similarly 
large amount of harm.

> Furthermore MPLS has per definition a very flexibel and powerful
> label stack principle that allows us to implement new services based
> on it. Why not use this approach in a first step for offering IPv6
> at the edges and than integrate it in the MPLS core sometimes in the
> future. 

I have no objection to putting IPv6 directly on top of MPLS. However,
I greatly detest hacks which would include additional encapsulation in
IPv4 at the BGP/IGP/whatever control plane.

> The whole IPv6 migration is only a question of using the
> right mechanism at the right time ;-). 

Precisely :).  Configured tunneling at the start, when there are only 
few customers, and when the relevance grows, migration to 
IPv6-over-MPLS or real dual-stack?  Seems to fill these requirements 
pretty neatly :)

> Besides that this MPLS label
> stack is more flexibel than (configured) tunnels and has as well
> less overhead.

Agreed -- the question is of course whether the flexibility is
essential.  That is, tunnels eat 20 bytes off your IPv6 MTU, MPLS does
not -- and MPLS LPSs would require set-up.  Those seem to be basically
the only differences, protocol-wise.  But practically the IPv6 MTU at
the moment is already 1480 bytes due to tunnels so there's little lost
there :).  So it might be that tunnels are preferable to direct MPLS
encapsulation because direct encapsulation does not give sufficient
additional benefits in the first step.