Enterprise Analysis Discussion Pekka S. and Jim B.

["Bound, Jim" <jim.bound@hp.com>]

Folks,

offline discussion btw Pekka S. and I on Ent Analysis.  Pekka S. felt
might be useful to send to WG.

/jim

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

It is not motivating the team to work on this with no comments.

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

OK.

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

It implies the capability of the routing infrastructure. Dual IP means
v6 and v4.


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

Yes we are trying to make this document focused so it is useful. Most
enterprises only deal with its enterprise and then provide external
access.  External access requirements are out of scope of this document.
We did not want to address teleworkers or mobility as that is pretty
much after the Enterprise gets up and running. 

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

Yes we are only concerend about the enterprise proper in the document.

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

I do not think our spec or the IETF can even begin to guess what policy
an Enterprise will select at all nor should we be stating policy in our
spec is our view.

> 
> 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?"

I think we may be able to do this but in different way I think we need
some discussion here as its not clear totally from your words above.
But I think a list of what the matrix supports may be the way to
approach it without dictating policy to the Enterprise in our spec.

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

OK will respond below.

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

Don't use math that won't work per our rules of engagement.  We covered
the cases we thought important if we want to discuss missing cases then
that is the way to proceed and discussion on each new case that is
missing.

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

We think its pretty clear :--)

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

Your call for free flowing text in this sense is great. But I will tell
you as editor we need the WG to engage and also more authors to write.
Right now it is pretty much Dave, I, and Steve writing.

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

I view it again transparent to server or client.  But maybe I am missing
something.

If you want a spec on war and peace for the Enterprise you may have the
wrong team and should reassign this to another group of authors.  We
don't have the time or the need to do the extensive work you want.  We
are trying to provide a guideline which is what all the other scenarios
did.  I feel we are being singled out compared to the analysis done for
Unmanaged, 3GPP, and ISPs.  Not upset with you at all but I think your
asking for to much and maybe that is not us.

Also as a note this is all getting done already in the industry and the
enterprise analysis is almost complete for IPv6 by many.  I don't know
if you talk to customers and such and maybe its your geography.  Did you
see the Japan IPv6 Promotional Council IPv6 deployment guide?  It is
unbelievable good work and was funded to hire team to do it.  Nothing we
are doing in v6ops even comes close.  Many enterprises are using that
for what we are doing here.

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

This will not happen in reality for at least 2-3 years that is why we
did not include it. By that time the work here will need to be
completely updated.  Thus we focused on what might remain useful for the
next 18 months.

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

You lost me.  Are you saying IPv6 something wants to talk to this app?

> 
>   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? ]]

Do you mean v6 only used or v4 cannot be used?

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

I think we address the above for v6 dominant case.

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

There may be v6 dominant I doubt v6 only?  I think you need to reread
our terminology maybe?

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

I hear what your saying but we need to come to alignment on terminology,
scope, and focus of the work before we can dive down much further is my
guess.

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

I see where your going.

thanks
/jim

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