Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-01.txt

From: [email-masked]
Date: Tue, 10 Feb 2004 16:06:11 -0500

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-01.txt
	Pages		: 17
	Date		: 2004-2-10
	
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-01.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-ent-scenarios-01.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-01.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: Ronald van der Pol <[email-masked]>
Date: Wed, 11 Feb 2004 16:35:32 +0100

> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-01.txt

section 3.1:

**Note To V6ops WG: Would a network topology map be useful here?

I don't think this is necessary in either one of the three scenarios.

What would be useful is to better define "parallel" in scenario 1.
E.g., what is the difference with "re-structuring" in scenario 3?
Does "parallel" mean different links and routers or does it mean
dual-stack (or both)?

section 3.2:
I think the term "address ownership" should be avoided.

section 3.3:
Is "Network A" an example of scenario 1, "Network B" of scenario 2
and "Network C" of scenario 3? If so, this could be made more clearly.

section 4.3:
**Note to V6ops WG: Should we discuss porting of applications too in
the legacy section?

I don't think so. Maybe just a reference to:
draft-shin-v6ops-application-transition-02.txt

section 5.1:
**Note to V6ops WG: Should we get into other DNS issues?

The sentence is quite terse, but I think it includes all issues.

section 5.2:
**Note to V6ops WG: Above is example of additional text we could add
  to each component we list here.  Are there other Routing issues?

The ISP draft has some nice text about IS-IS and OSPF with regard
to one or two processes. But maybe that's something for the analysis
document.

section 5.3:
**Note to V6ops WG: Should we get into other autoconfiguration
  issues?

IPv6 statefull autoconfiguration does not give all information
(e.g. DNS, NTP, etc servers). Maybe add what things should/could
be autoconfigured. But maybe this is also something for the
analysis draft.

In v4 part of a /24 is sometimes used in ACLs. E.g., the upper
/28 of a /24 is used for BOFHs by giving that /28 access to
services. With autoconf you cannot do that.

section 5.4:
**Note to V6ops WG: Should we get into other security issues?
The document describes the main requirements. More details could
go in the analysis document.

section 5.5:
**Note to V6ops WG: Should we get into other application issues?
Some applications cannot be ported (e.g., no source code).

section 5.6:
**Note to V6ops WG: Should we get into other Management issues?
People need to be trained.

section 5.7
**Note to V6ops WG: Should we get into other Address Planning issues?

Maybe add that IPv6 has /48 and /64 defaults. Especially the /64 is
quite different from v4, where one link can have a /24 and another
a /28.

**Note to V6ops WG: What other components are we missing?
I think you have quite some items already. I think the focus should
go now to the analysis draft.

	rvdp