Hello,
Thanks for having taken into account earlier suggestions on "scenarios" draft.
A few suggestions on this version:
"
A workaround is to use BGP for signaling and/or to perform IPv6-
over-IPv4/MPLS or IPv6-over-IPv4-over-IPv4/MPLS encapsulation, for
example, as described in [BGPTUNNEL]. "
I suggest replacing "workaround" by "an alternative approach". This is not a workaround. It is a very fine solution for those who do not wish to upgrade the core to IPv6 right away, which is what this section is all about.
" There seem to be multiple
possibilities, some of which may be more preferable than others. "
I suggest replacing "may be more preferable than others" by something like "may be more preferable than others depending on the specific considered environement".
" More analysis is needed in order to determine which are the best
approach(es): "
I suggest replacing "the best approach(es)" by "the best approach(es) for a specific environment".
"
1) require that MPLS networks deploy native IPv6 support or
use configured tunneling for IPv6.
2) require that MPLS networks support setting up IPv6 LSPs,
and IPv6 connectivity is set up using them, or configured
tunneling is used.
3) use only configured tunneling over the IPv4 LSPs; this
seems practical with small-scale deployments when the
number of tunnels is low.
4) use something like [BGPTUNNEL] to perform IPv6-over-
IPv4/MPLS encapsulation for IPv6 connectivity.
"
Without suggesting any specific text for the "analysis in order to determine which are the best approach(es) for a specific environment", it seems that:
- 1) and 2) may be attractive where the operator is willing to perform significant control plane upgrade in the core.
- 3) may be attractive where the operator wants to avoid upgrade in the core AND has a small-scale deployment for IPv6
-4) may be attractive where the operator wants to avoid any upgrade in the core AND has small or large scale deployment of IPv6
Do we agree?
Cheers
Francois
>> -----Original Message-----
>> From: owner-v6ops@ops.ietf.org
>> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of
>> Internet-Drafts@ietf.org
>> Sent: vendredi 5 décembre 2003 21:30
>> Cc: v6ops@ops.ietf.org
>> Subject: I-D ACTION:draft-ietf-v6ops-isp-scenarios-analysis-00.txt
>>
>>
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories.
>> This draft is a work item of the IPv6 Operations Working
>> Group of the IETF.
>>
>> Title : Scenarios and Analysis for
>> Introducing IPv6 into ISP Networks
>> Author(s) : M. Lind
>> Filename : draft-ietf-v6ops-isp-scenarios-analysis-00.txt
>> Pages : 26
>> Date : 2003-12-5
>>
>> This document first describes different scenarios for the
>> introduction of IPv6 into an existing IPv4 ISP network without
>> disrupting the IPv4 service. Then, this document analyses these
>> scenarios and evaluates the suitability of the already defined
>> transition mechanisms in this context. Known challenges are also
>> identified.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-isp-scen
arios-analysis-00.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-v6ops-isp-scenarios-analysis-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment:
draft-ietf-v6ops-isp-scenarios-analysis-00.URL
Description: draft-ietf-v6ops-isp-scenarios-analysis-00.URL