RE: IPv6 in MPLS Networks

["Francois Le Faucheur (flefauch)" <flefauch@cisco.com>]

Hello,

>> -----Original Message-----
>> From: owner-v6ops@ops.ietf.org 
>> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola
>> Sent: mercredi 11 février 2004 19:21
>> To: v6ops@ops.ietf.org
>> Cc: jonne.soininen@nokia.com
>> Subject: IPv6 in MPLS Networks
>> 
>> 
>> Hi,
>> 
>> As ISP scenarios and analysis document is currently at last 
>> call, the 
>> biggest issue (excluding the tunnel service considerations, 
>> which need 
>> resolving in other documents as well) seems to be the 
>> recommendations/text about IPv6 deployment in MPLS networks.
>> 
>> The possibilities (or a combination of these) include at least:
>> 
>>  1) Requiring that MPLS networks deploy native IPv6 support or use
>>     configured tunneling to achieve IPv6,
>> 
>>  2) Requiring that MPLS network support setting up IPv6 LSPs,
>>     and IPv6 connectivity is set up using these or configured 
>>     tunneling,
>> 
>>  3) Using only configured tunneling over IPv4 LSPs, or
>> 
>>  4) Using something like [BGPTUNNEL] to automatically 
>> encapsulate IPv6 
>>     over IPv4 over MPLS to obtain IPv6 connectivity.
>> 
>> Based on a quick operator poll, software upgrades in MPLS 
>> networks are
>> acceptable.  

From the description of the question asked in the "poll", it seems to indicates that software upgrades have been done in the past and probably will have to be done again in the future to fix something or get some new functionality (given no other choice). Sure.

I believe a poll with additional questions would indicate that :
	(i) nonetheless, there is a strong desire to keep the MPLS core stable and therefore, where possible, a preference for avoiding to activate new functionality in that core;
	(ii) given the choice to start-off a new service via a method which requires no new functionality in the core OR via another method which requires activating new routing/config/forwarding, some of these operators will be favoring a method which leaves the core untouched, at least for some period of time.

>>Due to that, the main reason to use a mechanism like
>> BGPTUNNEL appears to be to get around the vendor's shortcomings in
>> IPv6 forwarding performance in the core network, 

Yes, taking advantage of MPLS performance when those are higher than IPv6 performance on the installed equipment is a motivation.

>>so 
>> marketing solution
>> such as this might have disadvantages in the medium and long term, at
>> least.

Yes, BGP-TUNNEL is a designed as a migration approach to handle current situation. The proposal is to refer to it as a valid migration approach to handle current situation.

>> 
>> We're soliciting input on how to best handle this situation.  Please
>> send feedback to the chairs or on the list.  Tentatively, we're
>> scheduling 20-30 minutes for discussion in Seoul, but how productive
>> such discussion would be would depend on the framing and the contents
>> of presentations and/or discussion.
>>  

I will not attend the Seoul meeting. So here's my suggestion again (and then I'll shut up):

I suggest that the isp-scenario draft indicates that BGP-TUNNEL is a valid option where:
	- the MPLS operator wants to take advantage of higher MPLS forwarding performance than IPv6 forwrading performance on installed core equipment and/or
	- the MPLS operator wants to protect the stability of the core and, for some time, avoid/postpone activating new routing/config/forwarding in the core.

Thanks

Francois

                                       
>>                              
>> Please send your ideas (if any).
>>                                                              
>>                              
>>  Thanks,
>>   Pekka & Jonne
>> 
>> 
>>