Subject: Please review section 3 of Enterprise analysis

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Jan 2005 14:11:41 +0200 (EET)

Hi,

(co-chair hat on)

There haven't been comments since the revision of Enterprise Analysis 
doc was published, so asking explicitly.

Please review section 3 of the Enterprise analysis, and send your 
comments on the list.  Please try to do this within about a week, by 
2nd February.

Thanks!

(hat off)

---------- Forwarded message ----------
Date: Mon, 10 Jan 2005 15:50:07 -0500
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-v6ops-ent-analysis-01.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 Analysis
 	Author(s)	: J. Bound
 	Filename	: draft-ietf-v6ops-ent-analysis-01.txt
 	Pages		: 29
 	Date		: 2005-1-10

This document analyzes the transition to IPv6 in enterprise
  networks.  These networks are characterized as a network that has
  multiple internal links, one or more router connections, to one or
  more Providers, and is managed by a network operations entity.  The
  analysis will focus on a base set of transition notational networks
  and requirements expanded from a previous Enterprise Scenarios
  document. Discussion is provided on a focused set of transition
  analysis required for the enterprise to transition to IPv6,
  assuming a dual IP layer (IPv4 and IPv6) network and node
  environment, within the enterprise.  Then a set of transition
  mechanisms are recommended for each notational network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-01.txt

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-analysis-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-analysis-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: Pekka Savola <[email-masked]>
Date: Thu, 27 Jan 2005 11:01:38 +0200 (EET)

On Wed, 26 Jan 2005, Pekka Savola wrote:
> (co-chair hat on)
>
> There haven't been comments since the revision of Enterprise Analysis doc was 
> published, so asking explicitly.
>
> Please review section 3 of the Enterprise analysis, and send your comments on 
> the list.  Please try to do this within about a week, by 2nd February.
> (hat off)

I took a look mainly at the revised section 3.  Below are my 
*personal* comments, to get the commenting started.

I've mainly three kind of concerns/suggestions for improvement:
  1) terminology clarifications, so that we're talking about the same
     thing
  2) the model how the enterprise should go about deciding which cases
     to support, implying how we should present the cases
  3) input on the matrix and classification of different cases

.....

First, I'd like to note a few terminology/scope issues.

  - What is the more precise definition of 'host X network'?  Does that 
mean the IP capabilities supported by routers on the link(s) where the 
host plugs into, IP capabilities of the particular (geopgraphical) 
site ("whole network") or what? This has *major* impact on how to read 
the table, and how to think about the scenarios in general.  I've 
assumed the latter.

  - The first paragraphs restricts this disucussion only to dealing with
communications between different parts of the same enterprise, e.g.,
different branch offices at different countries etc.  I think this
restriction may be useful (though it's difficult to say), but this is the
first time I've seen it.

However, it is worth observing that I'd suspect a major goal for an
enterprise would be to also publish some services to the outside, or use
outside services.  According to this scope, these would be out of scope?

.....

The document states that it focuses on L3 issues.  That's OK as such, as
long as it's clear where those L3 decisions come from.  That is, AFAICS,
typically the v6 deployers should ask two main questions:

  1) "which kinds of applications [v4-only, ds, v6-only] do we want to
provide [to whom -- v4-only, ds, v6-only?] or use ourselves?"

  2) "are there any constraints on which network topologies should or should
not be supported?"

Based on that, you could take 1) as a basis, strike out or underline those
cases reflected by 2), and then go through and consider the rest of the
cases and every time ask the question, "is this something we want to
support; are there workarounds to avoid this scenario?"

The classification I presented below is an attempt to make that decision
easier from the _application_ perspective..

.....

I still have issues figuring out how to understand the matrix.  For
example, 5 first cases are "IPv6/DualIP" app/host scenarios, with IPv4 or
dual IP in the middle.  But my arithmetrics says there must be 2^3 = 8
different cases -- what's missing? dual-dual-dual
(network-provider-network), which is trivial; v4-v4-v4 which is
non-trivial; dual-v4-v4 (v4-v4-dual is there though) which is also
non-trivial.

This makes me think that there must be some clearer methodology for dealing
with these cases.

What I could think of was breaking up the section to different, higher-level
cases, in free-flowing text, which could then refer back to a part of a
matrix if needed.

I also observe that there should be two cases which are likely relatively
similar, whether you look at this from the "server" or "client" perspective
(as above: dual-v4-v4 and v4-v4-dual may not be 100% the same, but it might
make sense to try to group these together and see where that goes)

What I came up with were (with some thoughts on potential solutions in
[[]]'s:

  1) "IPv4-only legacy application communicating with newer IPv6-only app"
     (this is currently excluded from analysis, on purpose..)

    a) the v4-only app's host or network is dual-IP
        [[ * translation at the host or "close" network? ]]

    b) the v4-only app's network is v4-only
        [[ * avoid this case if possible!
           * the only choice would be translation at SP or "remote" network]]

  2) "IPv4-only application is used through a non-IPv4 network"

    a) host providing the application is dual-IP
       - host's network is v6-only
       - peer's network is v6-only
       [[ * in both cases, tunnel to SP,  peer nw, or peer host? ]]

    b) host providing the application is v4-only
       - host's network is v6-only
         [[ * avoid this case if possible!
            * otherwise, would have to do double translation at SP or peer network..]]
       - host's network is dual-IP
         [[ * straightforward tunneling, similar to 2.a) ]]

  3) "Dual-stack applications on dual-stack hosts"

     a) It just works (TM) when networks are any kind of mix of dual-IP and v4-only.
        However are two pathological cases..

     b) "local network v6-only, SP v4-only, peer network v6-only"
         [[ * straightforward tunneling. ]]

     c) "local network v6-only, SP v4-only or dual-IP, peer network v4-only"
         [[ * similar to 2.a) ]]

   4) "IPv6-only application on Dual-IP hosts through v4/dual-IP networks"

     a) networks support dual-IP, but the SP is v4-only
         [[ * straightforward tunneling between the networks ]]

     b) networks are v4-only, the SP is v4-only or dual-IP
         [[ * tunneling between the hosts, or via the SP in the middle ]]

     c) one network dual-IP, the other v4-only; the SP is either v4 or dual-IP
         [[ * another case of host-to-network tunneling, like 2.a) ]]

     d) both networks and the SP are dual-IP
         [[ * trivial native v6 case ]]

   5) "IPv6-only application on Dual-IP hosts through v6-only networks"

     a) "just works" if both networks are v6-only, SP is dual-IP
         Otherwise..

     b) the same as 3.b)

     c) the same as 3.c)

This is a slightly different way of presenting a (longer, more exhaustive)
matrix -- I'm sure there are probably better ways, but at least to me, this
is MUCH easier than looking at the matrix and trying to figure out the
differences between different options and what they mean in practice..

This doesn't mean the matrix couldn't be there, but that maybe it could be
something different cases from a classification like above could refer to
somehow.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings