[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt
Jim,
Thanks for your reply. Further comments where I think I need
to clarify (points where there is no more to say deleted):
Bound, Jim wrote:
...
1) My first concern is that somehow it misses the most
important case and the way I would recommend any enterprise to go.
In the terminology of the document that case is
======================================================
|Application |Host 1 |Service |Host 2 |Application |
|----------- |Network|Provider|Network|---------- |
| Host 1 OS | | | | Host 2 OS |
=====================================+================
|Dual or IPv4| | |Dual IP|Dual IPv4|
0 | ---- |Dual IP|Dual IP | or |---- or ----|
| Dual | | |v4 only|Dual IPv4|
======================================================
In other words, why would an enterprise choose to paint
itself into any of the awkward corners of the other 13 scenarios?
Sorry I cannot respond to such a general statement ok.
Let me rephrase my concern. Somebody reading this draft without
the background knowledge of this WG will simply not realise
that the fundamental coexistence model is dual stack. They will
find themselves right in the discussion of the 13 scenarios
and think that they must pick one of them - but the first question
anyone should ask is "can I just do a straightforward dual stack
model?" I would argue that for the large majority of enterprise
customers the answer will be yes, except for the corner cases
where they will have to do something special. So I think the draft
needs to start out by saying this - either by inserting my Scenario 0
or by saying it in words.
I don't have this problem with draft-ietf-v6ops-ent-scenarios-05.txt,
which starts out with base scenario 1, widespread dual stack.
Will continue to respond. All these cases are real cases
Not denying that they will all exist somewhere.
and you or I or the IETF cannot second guess or mandate any transition to the enterprise.
No, but we can advise our customers on the simplest, cheapest solution.
Just go for a dual stack operating system and routing system,
and keep calling your software suppliers until they upgrade
to the new API. Why make it harder than it needs to be?\
This ia really naïve view
Yes. I think most enterprises would prefer it that way.
...it don't work that way at all and your assumption is one as casual
> and many are looking at ways to reduce cost and thus the 13 scenarios.
It's not only that. Enterprises are not going to voluntarily add IPv6
support if they perceive it as adding great operational complexity,
which is an ongoing cost. They will simply wait until it becomes simple.
In fact, sections 4 and 7 are written in this spirit - they
refer essentially to what I have shown above as secnario 0.
Not really reread the vlan discussion.
As far as I can see, that only splits the routing. As far as hosts,
DNS and middleware is concerned it's still a dual stack model.
I just don't get what are the drivers for the other
13 scenarios.
I can tell but they are all in ent scenarios doc.
True, I think my problem here is what I have said at the beginning of this
message.
...
3) My third main concern is that the draft doesn't discuss
the deployment of DMZs, which are a feature of all major
enterprise networks.
Nor should we and we do not intend to.
Well, I think then that we have to add it to
draft-vandevelde-v6ops-nap-00.txt, because it is one of the
first things enterprise network security managers will
ask about.
...
> It is not recommended to use 6to4 [6TO4] or a tunnel
broker [TBRK] > for an enterprise deployment. The
enterprise has a requirement for > long-term, stable IPv6
connectivity. 6to4 and the tunnel broker > are more
appropriate for SOHO or single node environments.
Sorry, but that's wrong. First of all, single-node 6to4 isn't
an IETF solution - it has never been documented - so it's not
accurate to cite the RFC. Secondly, 6to4 as described in RFC
3056 will work just fine for an enterprise - until the day
its own ISP provides native connectivity, of course. I'd say
a SOHO user has less chance of setting up RFC 3056 correctly
than a large enterprise.
Uh OH but good there will be strong disagreement. I am just editor.
I see both views. Both are required.
As a matter of fact I agree with the recommendation; I just want
to avoid mischaracterization of 6to4. Of course, if you simply
can't find an ISP to support you properly, a tunnel broker or
6to4 would always be possible.
That's it for now.
Brian