Jim, What Brian just described are some of the typical network topologies I would like to see described and discussed. - Alain. On Friday, February 21, 2003, at 07:57 AM, Brian E Carpenter wrote:
Jim, I think you're misinterpreting my use of the b-word. I'm not (of course) talking about business models. I'm talking about scenarios. For example: A bank running a massive ATM network with some number of gazillions of transactions per second against central databases. An engineering company running distributed design systems across 20 different sites around the world. A pharmaceutical company running both compute-intensive and ERP applications. etc. Each one fleshed out with how they do things today, and what they want to achieve by adding IPv6. Brian "Bound, Jim" wrote:Brian,I share some of Alain's concerns. I think that enterprise customers will not look at IPv6 as a goal in itself, but as a tool for certain business scenarios they need to support.We discussed this on the team. I agree with business justification.We discussed this and this is not an IETF mission or purpose. TheSo I think the draft should start with a set of business scenarios, and then maybe continue with the technology scenarios (plus analysis of which business scenarios they support). At the end, it would then be possible to deduce which technology scenarios are useful.
business scenarios are not common and will vary. If we pick X business
scenarios and leave out Y then the Y types will not be happy. This is
not a goal of any scenario document unmanaged, ISP, or 3gpp. So I would
suggest that this is not on any of the design teams plates. If your
correct and I do not believe you are to add this then none of the
current scenarios should be moved to the IESG.
We have that expertise for "operations" and will not focus on dataHowever, I wouldn't advocate pulling back the draft. I think we should just ask the team to go back and develop the business scenarios (or use cases, if you prefer the term). And if necessary, pull in more expertise for this (e.g. to cover Big Iron and major data centers and hosting centers).
center or big iron. Reason is that one persons belief of data center or
big iron is not the same as anothers. In the follow on draft analysis of
the enterprise which will be technical will have assumptions that a
"data center" could use.
That being said I would suggest the IPv6 Forum, Asian IPv6 Task Force,
North American IPv6 Task Force have the business scenarios and cases
done. It is also those forum charter not the IETF.
Also would suggest if we want to focus on the data center specifically
we should build a separate draft and set of work to discuss first what
it means and then execute on those assumptions it should not be part of
the enterprise work.
This team and work should be the dumping ground for all the things we
have to do that are not covered in the other specs. Or else we will be
here for 5 years working on this and this team is not going to do that.
Like DNS is the dumping ground for anything we cannot figure out in our
community to store data I would suggest and that is wrong too.
Regards,
/jim
Brian Alain Durand wrote:Margaret, First, I would like to say that I appreciate the effort ofthe designteam to address such a difficult issue. However, that said, I'm not very comfortable with this document. On one hand, it is badly needed and already very late, on theother hand,I'm not sure it is taking the right direction. I already have commented several times that this design team is way too 'transition tool' centric in its approach, somehow making the hidden assumption that solving the 'enterprise' case in the (yet to come) analysis/solution document will consist only of picking the 'right' transition tool developed by NGtrans. What I would like to see are things like the following instantiated for a set of 'typical' enterprise environment: - how does the internal networks looks like? - how is the networks are managed? (who is responsible, what is outsourced, is ITcompetent/reliableor not ...) - what are the procedure/tools in place to manage the network? (not only SNMP, but for example tools to create DNS zone files) - is the public internet used (via VPN...)? - what are the connections to the Internet? - Is the v4 address space private or public? - Is the v4 address space 'portable'? (hint: do they needportable v6address space) - How much v4 address space is available? - Are they multi-homed? - how is security enforced? - how does the datacenter looks like if there is one? - what kind of applications are used in the Internet/intranet/extranets/...) (is it in-house code? is the source code available? is an Ipv6 version of the code available to buy?....) - how naming service/directory service is performed (two face DNS?) -... There is a little of that buried in section 4, variabledescription,but I think this document should really instantiate those variables and more (the ones I just described above for example,certainly muchmore) in a set of several 'typical' enterprise environments instead of focusing on cases describing how enterprises are thinkingof deployingv6 at the IP level (section 5, which is basically which networks to connect)or abstractcases of transition mechanisms (section 6, point of transition methods) which belongs not in this document but in the solution document. With this in mind, I would not recommend the wg adopting this document. - Alain. On Thursday, February 20, 2003, at 08:46 AM, Margaret Wasserman wrote:Hi All, I made a mistake last week and approved the publication of the enterprise scenarios document as a WG work item without actually checking with the WG first... Sorry. So, let's do this the right way... The enterprise scenarios/analysis team believes that the current version of their scenarios document is ready for consideration as a v6ops WG item. The document can be found at:http://www.ietf.org/internet-drafts/draft-ietf-v6ops-entnet-scenarios- 00.txt This work is clearly within the charter of v6ops. Could members of the WG please comment on whether you believe that this document should be accepted as a WG item? In other words, doesit take the right technical direction, and would it serve as a useful basis for our work? Is it sufficiently complete that it is ready for WG review and refinement? If there is sufficient support to accept this document, it will remain a WG work item. If not, we will move it back to individual submission status. Sorry for my mistake and any confusion it may cause. Margaret