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

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

Hello Pekka,

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

I believe the objective is to offer IPv6 connectivity to end users,
whether this is achieved over MPLS or not is not directly relevant to
the end user (ie they buy "IPv6" not really "IPv6-over-MPLS"). So I was
proposing a wording which separates the service "offered" (IPv6
connectivity) from the way it is achieved (ie by carrying IPv6 over
MPLS).

This is no big deal.
 
>> > 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.).  

Yes, but my perception is that:
	- they would like to minimise the risks of having to do more
such upgrades in the future. 
	- when having to do such upgrades, operators would rather
minimise their impact.
So for some operators, the concern is not so much to get a new software
image loaded on the core routers, the concern is more that they would
rather avoid activating new functionality/protocol/config/forwarding
which could potentially impact the core for other services (and
introduce their own new family of issues and bugs, which in turn forces
future upgrades for fixes and so on ...).

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

Sure. 
But, given the choice, if a particular feature can be supported either
(i) via a method which requires new software/routing/config/forwarding
in the core or (ii) via a method which is transparent for the core, some
people may be interested in the latter approach.

Some operators with large scale MPLS VPN services are telling me that
this is a meaningful consideration for them (just discussed it again
Yesterday with one of them). I am not suggesting this applies to every
MPLS operators, just that the document could leave it up to operators to
decide whether this is a relevant consideration for them or not, rather
than making the decision for them that it can not possibly be a relevant
consideration.

Cheers

Francois

>> > 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
>> 
>> 
>>