[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> 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 you mean IPv6 only stack yes but not dual stack which adds v4 in v6
tunnels as solution. 

I don't believe we will see IPv6 ONLY stacks for a very long time.

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

And tunnel broker space too.

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

So far only one person thinks that and they are not a god and I do not
like to appease such egoes though I did offer a compromise to that ego
which goes against my grain quite frankly and intend to speak with that
ego in private at San Diego to iron out our consistent battles once and
for all.  I am sick of speaking to this ego.

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

This is doable yes.

Thanks
/jim

> 
> Tim
> 
> On Fri, Jul 02, 2004 at 02:05:24AM -0400, Bound, Jim wrote:
> > 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: owner-v6ops@ops.ietf.org
> > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tim Chown
> > > Sent: Thursday, July 01, 2004 8:26 PM
> > > To: v6ops@ops.ietf.org
> > > 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: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] 
> > > > On Behalf Of Internet-Drafts@ietf.org
> > > > Sent: Monday, June 28, 2004 3:31 PM
> > > > To: i-d-announce@ietf.org
> > > > Cc: v6ops@ops.ietf.org
> > > > 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
> > > > i-d-announce-request@ietf.org 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:
> > > > 	mailserv@ietf.org.
> > > > 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.
> > > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> 
>