Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt

From: "Bound, Jim" <[email-masked]>
Date: Thu, 14 Oct 2004 10:34:40 -0400

Brian, 

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Thursday, October 14, 2004 8:58 AM
> To: Bound, Jim
> Cc: [email-masked]
> Subject: 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.

What we can do is add discussion of dual stack up front and I can write that for sure.  I agree with your concern.

What I don't agree with is your belief of corner cases.  I am seeing these cases in the following DOD, FAA, Homeland Securitiy, Satcom IXs, Providers, CEA-to-Provider evolution, and 3G.  But it is not the business of the IETF to begin to define markets or trends we just come here and support what we believe are requirements.  We can provide balance here for the norm and the more aggressive early adopters moving to dominant IPv6.

> 
> I don't have this problem with draft-ietf-v6ops-ent-scenarios-05.txt,
> which starts out with base scenario 1, widespread dual stack.

Understand.

> 
> > Will continue to respond.  All these cases are real cases
> 
> Not denying that they will all exist somewhere.

Good.

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

I am different I "listen" to my customers business case and then give them input.  I see completely the need for dominant IPv6 view.

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

Those who don't are as important as those who do prefer different.

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

We simply do not agree.

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

For the apps I agree.  I think you and a very few are trying to KILL the IPv6 Dominant model and we as authors are standing on our position.  I am willing to make it clear why the different models exist but not kill the IPv6 dominant scenarios if my co-authors agree.

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

Yes and I think we can fix that and from that view your 100% correct.

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

Good I just saw that and what we can do is reference that work ok?

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

Again completely agree.

> That's it for now.
>      Brian

Good input and directtion.

Thanks
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 15 Oct 2004 23:45:58 -0400

Pekka, 

> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Thursday, October 14, 2004 12:57 PM
> To: Brian E Carpenter
> Cc: Bound, Jim; [email-masked]
> On Thu, 14 Oct 2004, Brian E Carpenter wrote:
> > 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 have the same concern as Brian.

Responded to Brian on that one.

> 
> The authors note in the draft that there are a lot of 
> combinations, (like close to a hundred, I recall from IETF60) 
> and listing them all the matrix doesn't make sense.  That's 
> OK.  What I was writing in my review comment is that because 
> the matrix shows a number [less than all] of entries, it 
> should be sufficiently clearly explained what those rest are, 
> and properly bring forward those ones that clearly make sense 
> even if that requires only relatively small amount of text.

We will not discuss what is not there only what is there if the WG sees
cells we missed please tell us. 

> 
> For example, one approach I could see might be having two matrices:  
> one for the "really common and simple" cases (which a lot of 
> enterprises would probably look for), and "more complex" 
> cases which require need to be analyzed in more depth, and 
> solutions provided for.

There are solutions for all combinations except true v6 only and v4
only.  Suggest you see next draft and it will be more clear.  

> 
> That might be one way to clearly show that there are both 
> very simple approaches and and more complex/advanced 
> approaches, without having to list every possible combination 
> out there.  There might be other ways to do that as well.

Also what is simple to one is complex to the other we clearly need to
make it clear.  And will do our best as quick as possible.

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