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

[Pekka Savola <pekkas@netcore.fi>]

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?

> 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?).

Fine.
 
> Last paragraph
> ==============
> I have a number of problems with that paragraph as it is worded:
>
> 	- "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.

> But I see two valid points in the paragraph:
>
> 	- 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