Subject: RE: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt

From: "Bound, Jim" <[email-masked]>
Date: Fri, 2 Jul 2004 02:05:24 -0400

Tim,

We have a few edits that we probably need to rev again.

When the node needs to communicate with IPv4 it must assume an IPv6
routing protocol not an IPv4 one. So IPv4 capabale nodes would in
invalid from the sense that this network states that all nodes are there
with IPv6 and IPv4 is only legacy on a specific network.  So I think the
update is overboard?

Do you see my point?

Thanks
/jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tim Chown
> Sent: Thursday, July 01, 2004 8:26 PM
> To: [email-masked]
> Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt
> 
> 
> Hi Jim,
> 
> It looks good to go.
> 
> Very minor comment (can be ignored if we want to get the 
> draft published :)
> 
> Perhaps Section 3.1 could be clearer - is the correct interpretation:
> 
> Scenario 1:  Wide-scale/total dual-stack deployment of IPv4 
> and IPv6 capable hosts and network infrastructure.
> 
> Scenario 2:  Sparse IPv6 dual-stack deployment in IPv4 
> network infrastructure.
> 
> Scenario 3:  IPv6-only network infrastructure with some 
> IPv4-capable nodes/applications needing to communicate over 
> the IPv6 infrastructure.
> 
> If so, then 
> 
> "   Scenario 3: Enterprise deploying a new network or 
> re-structuring an
>                existing network, decides IPv6 is the basis for
>                most network communication, to coexist with IPv4."
> 
> might be better as:
> 
> "   Scenario 3: Enterprise deploying a new network or 
> re-structuring an
>                existing network, decides IPv6 is the basis 
> for most network 
>                communication.  Some IPv4 capable 
> nodes/applications will
> 		need to communicate over that infrastructure.
> 
> Or is that the wrong intepretation?
> 
> Finally, how does communication between IPv4-only and 
> IPv6-only nodes or applications fit into the above three 
> scenarios, if any of them?  Would that be part of Scenario 3? 
>  Perhaps make that clearer?
> 
> Section 3.1 is actually quite heavily the key in which 
> mechanisms are favoured, so the wording is very important.
> 
> Tim
> 
> On Tue, Jun 29, 2004 at 12:30:26AM -0400, Bound, Jim wrote:
> > WG,
> > 
> > Chairs asked me to send this note to you. Updated spec below. First 
> > error below I am just the editor see authors in the spec.  
> What we did 
> > and I as editor is took 100% Alain's and Pekka's input as best we 
> > could for additional clarity.  But, in section 4 we put additional 
> > note that this section is more of an overview that the reader must 
> > look at as components and all the components would fill up 
> many pages 
> > (as all
> > scenarios) and more of that is analysis as opposed to defining a 
> > scenario, and analysis is the next step.  We also added normative 
> > references we felt were applicable to the spec that exist and talk 
> > about the general subject (e.g. DNS, Applications).  I as 
> one author 
> > may not be able to respond to mail this week as I am abroad 
> in Europe, 
> > but will do my best.
> > 
> > Regards,
> > /jim
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of [email-masked]
> > Sent: Monday, June 28, 2004 3:31 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.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		: IPv6 Enterprise Network Scenarios
> > 	Author(s)	: J. Bound
> > 	Filename	: draft-ietf-v6ops-ent-scenarios-03.txt
> > 	Pages		: 16
> > 	Date		: 2004-6-28
> > 	
> > This document describes the scenarios for IPv6 deployment within 
> > Enterprise networks.  It will focus upon an Enterprise set 
> of network 
> > base scenarios with assumptions, coexistence with legacy 
> IPv4 nodes, 
> > networks, and applications, and network infrastructure requirements.
> > These requirements will be used to provide analysis to 
> determine a set 
> > of Enterprise solutions in a later document.
> > 
> > A URL for this Internet-Draft is:
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-03.
> > tx
> > t
> > 
> > To remove yourself from the I-D Announcement list, send a 
> message to 
> > [email-masked] with the word unsubscribe in 
> the body of 
> > the message.
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> > 
> > 
> > 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-ent-scenarios-03.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:
> > 	[email-masked].
> > In the body type:
> > 	"FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-03.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.
> > 
> 
> 
> 
> 
>

---

From: Tim Chown <[email-masked]>
Date: Fri, 2 Jul 2004 09:57:01 +0100

Ah, OK.

The wording may seem subtle, but the solution space is very different.

If Scenario 3 is an IPv6-only infrastructure and IPv6 nodes, that wish to
communicate with a separate IPv4-only network, then you're in the NAT-PT, 
TRT or ALG space (depending which layer you want to translate at).

If Scenario 3 is IPv6 infrastructure (routers, and IPv6-only on the wire)
but with some dual-stack nodes or legacy applications communicating with each
other over IPv4 (e.g. the application is IPv4 only) or to IPv4 nodes outside 
the network, then you may be in the DSTM solution space.

This also applies to the last line of Example Network C (end of Section 3.3).

I just think section 3.1 is the real focus of this work in that people will
point at it as justification for transition mechanism X being in scope or
not for Enterprise.  But if you don't think that needs to be clarified, 
that's also fine by me :)

One other quick comment if a quick revision is being made - perhaps the text
at the start of Section 3.3 should clarify whether Example A is paired with
Scenario 1, B with 2 and C with 3, or whether each Example can apply to
any of the scenarios.

Tim