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

From: <[email-masked]>
Date: Mon, 9 Feb 2004 09:10:19 +0100

Hi,
See my comments below.

> 
> Why is BGPTUNNEL recommended in this analysis?
It has not been our intention to recommend BGPTUNNEL, but I still
believe it is a viable option and should be mentioned. Perhaps the text
needs some polishing.  

> 
> Who is actually using it?

I don't know who is using it right now but I do know it is being
considered. 

> 
> Also, the draft version in the analysis should be 01 not 00, if it
does
> stay in as a clearly marked last resort method...

Will be changed to "work in progress"

Regards,
Mikael

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 9 Feb 2004 11:38:12 -0000

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

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 9 Feb 2004 12:47:17 -0000

Hello,

>> I don't know who is using it right now but I do know it is being
 
It is already deployed in large scale production (100+ PE devices). 
As Mikael mentioned it is also planned or considered by other operators.

Several commercial implementations are available and their
intereoperability tested by several operators.

I support Mikael's approach for isp-scenarios to indicate that BGPTUNNEL
is a viable option.

Francois

---

From: <[email-masked]>
Date: Tue, 17 Feb 2004 18:02:06 -0000

Hello Tim,

Francois pointed out an email you commented on regarding who is actually using it?

Well be may not have it deployed, but this is something BT may consider using to start IPv6 deployment in the future.  However as you should know it wont happen if the standards are not their.  Well it doesn't help, lets put it that way.

Best Regards,
Stuart

-----Original Message-----
From: Francois Le Faucheur (flefauch) [mailto:[email-masked]] 
Sent: 06 February 2004 15:19
To: FLF
Subject: FW: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt

you guys may want to comment on that question?

>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Tim Chown
>> Sent: vendredi 6 février 2004 15:49
>> To: [email-masked]
>> Subject: Re: WG Last Call: 
>> draft-ietf-v6ops-isp-scenarios-analysis-01.txt
>> 
>> 
>> Also, the draft version in the analysis should be 01 not 00, 
>> if it does
>> Tim
>> On Fri, Feb 06, 2004 at 09:46:11AM -0000, Francois Le 
>> Faucheur (flefauch) wrote:
>> > Hi,
>> > 
>> > Suggestion for "8.2 Example 2"
>> > 
>> > Perhaps 
>> > 
>> > " IPv6 deployment might start with an upgrade of a couple 
>> of PE routers to support [BGPTUNNEL], because this will 
>> allow large-scale IPv6 support without hardware or software 
>> upgrades in the core. "
>> > 
>> > would read better as:
>> > 
>> > " IPv6 deployment might start with an upgrade of PE 
>> routers to support [BGPTUNNEL] (starting perhaps by a couple 
>> PE routers and then extending to other PEs as needed), 
>> because this will allow large-scale IPv6    support without 
>> hardware or software upgrades in the core. "
>> > 
>> > Otherwise, it sounds like deploying on two boxes gives 
>> "large scale support".
>> > 
>> > Cheers
>> > 
>> > 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-scen
arios-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: Marc Blanchet <[email-masked]>
Date: Fri, 27 Feb 2004 01:28:23 -0500

good document and work. quoted text provided with comments in <MB> and with
suggested text when appropriate.

Marc.
----------------------

   It is also outside the scope of this document to describe different      
   types of access or network technologies.  

<MB>to be more precise, suggesting:
s/of access or network technologies/of layer1-2 access or network
technologies/.
</MB>
...

3.2.1 Stage 1 Scenarios: Launch 
... 
           
   The immediate first step consists of getting a prefix allocation      
   (typically a /32) from the appropriate RIR according to allocation      
   procedures. 

<MB>while clearly a good advice, not sure really useful to discuss here
given the objective of the document.</MB>

   The selection of one candidate depends largely on the presence or      
   absence of NATs between the two tunnel end-points and whether the      
   user's IPv4 tunnel end-point address is static or dynamic. In most      
   cases, 6to4 and ISATAP are incompatible with NATs, and UDP      
   encapsulation for configured tunnels has not been specified.

<MB>configured tunnels with tunnel brokers [TSP] is specified for
NAT traversal.
</MB>  
            
   However, NAT traversal can be avoided if the NAT supports    
   forwarding protocol-41 [PROTO41]. 

<MB>s/protocol-41/protocol-41 and configured to do so./</MB>

   The connectivity mechanisms can be categorized as "managed" or 
   "opportunistic."  The former consist of native service or a 
   configured tunnel (with or without a tunnel broker); the latter 
   include 6to4 and, e.g., Teredo; they provide "short-cuts" between 
   nodes using the same mechanisms and are available without contracts 
   with the ISP. 

<MB>Teredo needs a Teredo server located outside of the NAT, which means
in the architecture presented in section 2, as customer connection network.
</MB>
 
   Most interesting are the managed services. When dual-stack is not an 
   option, a form of tunneling must be used. When configured tunneling 
   is not an option (e.g., due to dynamic IPv4 addressing), some form of 
   automation has to be used. The options are basically either to deploy 
   an L2TP architecture (whereby the customers would run L2TP clients 
   and PPP over it to initiate IPv6 sessions) or to deploy a tunnel 
   configuration service. The prime candidates for tunnel configuration 
   are STEP [STEP] and TSP [TSP], which are not analyzed further in this 
   document. 

<MB>would also add that these services are able to do NAT traversal.
Suggesting:
s/are STEP and TSP , providing tunnels with or without the presence of NAT./
</MB>

   Note that when customers use dynamic IPv4 addresses, the      
   tunneling techniques may be more difficult to deploy at the ISP's 
   end, especially if a protocol including authentication (like PPP for

   IPv6) is not used. This may need to be considered in more detail      
   with tunneling mechanisms.  

<MB>disagree for TSP. TSP re-establish the tunnel automatically in the
event of a change of IPv4 address
Suggesting replacing text:

   Note that when customers use dynamic IPv4 addresses, manually configured

   tunneling techniques may be more difficult to deploy at the ISP's 
   end, especially if a protocol including authentication (like PPP for

   IPv6) is not used. However, [TSP] does support automatic re-establishment
   of the tunnel when the IPv4 address change.

</MB>

5.2 Access Control Requirements  

   When a provider does not wish to give its IPv4 customers      
   automatic access to IPv6 services, specific IPv6 access control must 
   be performed in parallel with the IPv4 access control. This does not 
   imply that different user authentication must be performed for IPv6, 
   but merely that the authentication process may lead to different 
   results for IPv4 and IPv6 access.   

<MB>to add:
The [TSP] tunnel broker provides the AAA capabilities to manage this
access control if desired.
</MB>

   Note that when the customer connection network is shared between the 
   users or the ISPs, and not just a point-to-point link, authenticating 
   the configuration of the parameters (esp. prefix delegation) requires 
   further study. 
<MB>TSP does it. to add:
TSP tunnel broker does prefix delegation in this context
</MB>

   This can be done, for example, by mapping a DHCP response to a      
   physical connection and storing this in a database. It can also be      
   done by assigning a static address or prefix to the customer. 

<MB>to add: TSP Tunnel broker provides this binding between user and
address and prefix delegated.</MB>

8.1 Example 1  

   Customers (with some exceptions) are not connected using a tunnel 
   broker, because offering native service faster is considered more 
   important -- and then there will not be unnecessary parallel 
   infrastructures to tear down later on.  However, a 6to4 relay is 
   provided in the meantime for optimized 6to4 connectivity.

<MB>don't understand that argument. if "offering native service faster
is considered more important, then why care about 6to4 at all?
6to4 relay should be considered similar to tunnel broker in terms
of ways to provide ipv6 through the not-yet-upgraded-ipv4 network.
</MB>

   [V6SEC]        P. Savola, "IPv6 Transition/Co-existence Security      
                  Considerations" 
                  Work in progress 

<MB> adding tsp as reference

[TSP]          M. Blanchet, "IPv6 Tunnel broker with Tunnel Setup
Protocol(TSP)",
	       work in progress, draft-blanchet-v6ops-tunnelbroker-tsp-00, feb 2004
</MB> 

------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------