Subject: RE: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 6 Feb 2004 09:34:55 -0000

Hello,

Below are some comments on section "4.1.1 MPLS Backbone".

First paragraph:
================
- I think we should be talking about offering "IPv6 connectivity via transport of IPv6 over MPLS" as opposed to offering "IPv6-over-MPLS connectivity".
- In addition to softwrae upgrade, I think it is worth conveying that support of IPv6 MPLS in the core would involve complete control plane upgrade including IPv6 routing if it is not there, configuration of IPv6 label distribution, monitoring, operations, ...

So, I would suggest enhancing enhancing 1st paragraph to:
"If MPLS is already deployed in the backbone, it may be desirable to provide IPv6 connectivity via transport of IPv6 over MPLS. However, setting up an IPv6 Label Switched Path (LSP) requires support of the corresponding control plane (routing, signaling) in the MPLS network; both LDP and RSVP-TE can set up IPv6 LSPs, but this would require corresponding upgrade (software, configuration, operations) in the MPLS core network. "

Second paragraph:
=================
I suggest replacing "may be economically attractive" by "may be attractive".
This will make sure we have consistent terminology with previous sentences (eg "approaches 1 and 2 are the most attractive") and avoid confusion (eg what is "economically attractive" but inattractive from other perspectives?).

Last paragraph
==============
I have a number of problems with that paragraph as it is worded:

	- "recommeding ... might not be such a good idea": I don't find this a very precise recommendation.
	- "No particular reason exists to avoid adding IPv6". Shouldn't we leave it to operators to decide for themselves whether avoiding/postponing complete upgrade of the control plane of their core (which may already be carrying L3VPN, L2VPN, Voice Trunking...) is a valid reason or not? The previous paragraph attempts to provide a balanced description of the pros and cons of each approach. It says "Approach 4 may be attractive for an operator who does not wish to upgrade the MPLS network and has a large-scale deployment." I think this is a more accurate statement.	
	- "Software upgrades are commonplace in MPLS networks". Is this suggesting that upgrades are more commonplace in MPLS networks than IP networks offering enterprise services? Isn't there a distinction to be made between upgrade on the edge when new services are added, and upgrade to the core which is more and more "service-unaware" ?

But I see two valid points in the paragraph:
	- [BGPTUNNEL] is primarily designed for migration period from existing environments, as opposed to the grand scheme of things for the long term future where IPv6 will be everywhere
	- where installed equipment has higher MPLS forwarding performance than native IPv6 performance, carrying IPv6 over MPLS results in performance benefits.

My recommendation is to drop the last paragraph and capture these two points by extending the last sentence of the second paragraph into:

"Approach 4 may be attractive for an operator who does not wish to upgrade the MPLS core network at this stage and/or who wants to take advantage of higher MPLS forwarding performance on installed equipment, and has a large-scale deployment. "

Thanks

Francois

>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Pekka Savola
>> Sent: vendredi 6 février 2004 06:59
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt
>> 
>> 
>> Hi all,
>> 
>> This is a WG Last Call for comments on sending
>> draft-ietf-v6ops-isp-scenarios-analysis-01.txt, " Scenarios and
>> Analysis for Introducing IPv6 into ISP Networks" to the IESG for
>> consideration as BCP:
>> 
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-01.txt

Please review these documents carefully, and send your feedback to the
list.  Please also indicate whether or not you believe that this document
is ready to go to the IESG.

There has been a lack of extensive reviews from the start, so 
reviewing this document would be especially welcome.

The last call will end in about 2.5 weeks, on 24th February.

Pekka & Jonne

---

From: Pekka Savola <[email-masked]>
Date: Fri, 6 Feb 2004 12:25:04 +0200 (EET)

On Fri, 6 Feb 2004, Francois Le Faucheur (flefauch) wrote:
> - I think we should be talking about offering "IPv6 connectivity via
> transport of IPv6 over MPLS" as opposed to offering "IPv6-over-MPLS
> connectivity".

Why?  I don't see how this is a relevant distinction?

> This will make sure we have consistent terminology with previous
> sentences (eg "approaches 1 and 2 are the most attractive") and
> avoid confusion (eg what is "economically attractive" but
> inattractive from other perspectives?).

Fine.
 
> 	- "No particular reason exists to avoid adding IPv6".
> Shouldn't we leave it to operators to decide for themselves whether
> avoiding/postponing complete upgrade of the control plane of their
> core (which may already be carrying L3VPN, L2VPN, Voice Trunking...)
> is a valid reason or not? The previous paragraph attempts to provide
> a balanced description of the pros and cons of each approach. It
> says "Approach 4 may be attractive for an operator who does not wish
> to upgrade the MPLS network and has a large-scale deployment." I
> think this is a more accurate statement.

There really doesn't seem to be any particular reason (except the one
spelled out), so it seems appropriate to say it.

> 	- "Software upgrades are commonplace in MPLS networks". Is
> this suggesting that upgrades are more commonplace in MPLS networks
> than IP networks offering enterprise services? Isn't there a
> distinction to be made between upgrade on the edge when new services
> are added, and upgrade to the core which is more and more
> "service-unaware" ?

I made a poll in NANOG list, asking whether the MPLS network core
routers are upgraded.  Every single MPLS operator (who answered) said
they DO upgrade their core router software, for a number of reasons
(including, fixing software bugs, adding support for newer hardware,
adding features such as CoS or support for larger MTUs, etc.).  This
point was specifically added to kill the misconception that "MPLS ==
no software upgrades in the core".

People will upgrade the software if they think they want the
capabilities of the new software. People turn on new features if they
think they need them.

> 	- where installed equipment has higher MPLS forwarding
> performance than native IPv6 performance, carrying IPv6 over MPLS
> results in performance benefits.
> 
> My recommendation is to drop the last paragraph and capture these
> two points by extending the last sentence of the second paragraph
> into:
> 
> "Approach 4 may be attractive for an operator who does not wish to
> upgrade the MPLS core network at this stage and/or who wants to take
> advantage of higher MPLS forwarding performance on installed
> equipment, and has a large-scale deployment. "

I strongly disagree with this.  Your rewording would obfuscate the
very point of being made.

Based on the feedback I've received, about the only reason people are
requesting something like BGPTUNNEL is that their vendor has sold them
crappy hardware which does not support IPv6 to a degree (e.g.,
line-rate) the folks want.  That point must be stated very clearly
(even clearer than now) when we're discussing different approaches to
IPv6 in MPLS networks.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings