[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enterprise scenario text proposal
Hi,
We are deploying IPv6 in an enterprise here (1,500 users, ~1,000 hosts)
and are documenting the process within the 6NET project. I can certainly
write up this experience and issues (there is a "similar" draft for an
ISP deploying customer dialup/DSL provision in Japan). Pekka is OK with
the idea, and we can probably produce this within the next 4 weeks as a
first draft. A specific example may help discussion.
Regarding 3.3, we *have* deployed by injecting prefixes into VLANs, and
I know other etnerprises that are doing the same. We also have full
SSM and ASM multicast v6 running enterprise-wide, and have for example
used Flute/Mad for reliable IPv6 multicast file sharing around a number of
European academic enterprise sites.
The gaps are largely with commercial apps, like MS Exchange, but I'll cite
them all in the draft.
Tim
On Thu, Mar 18, 2004 at 04:34:08PM -0800, Dave Thaler wrote:
> >From the minutes:
> > Dave Thaler: As the slide says, enterprise scenarios document doesn't
> yet
> > give much help in what's required. But Enterprises want v6 with
> little
> > overhead in any case.
> > Jonne: not discussing enterprise today, Dave should contribute to
> > Enterprise work.
>
> To start following up on my action item, here's text I'll propose for
> possible addition to the draft-savola-v6ops-tunneling-00.txt draft.
> For now, I only consider "Scenario 1" (as defined in
> draft-ietf-v6ops-ent-scenarios-01.txt), which is making IPv6 equivalent
> to IPv4. Personally I don't consider scenario 2 (supporting only a
> particular set of apps) as significantly unique to the enterprise
> scenarios and as it's not in any of the other non-enterprise scenarios,
> I will ignore it. I leave scenario 3 (essentially IPv4 over native
> IPv6) to others, as I don't have data on that scenario and it's not
> clear to me whether it's really enterprise specific (could this arise
> in 3GPP? I don't know).
>
> +'s indicate proposed additions to the existing draft.
>
> ---
> 3.3 Enterprise Scenarios
>
> The only scenario which is obvious at the moment is when the
> enterprise wishes to deploy IPv6 without changing the gear to be
> dual-stack, without injecting IPv6 into existing VLANs, or without
> adding additional IPv6 routers in the VLANs.
>
> + There are three subcases of this scenario:
> +
> + 1. When the enterprise does not NAT between different parts
> + of the internal network. This case is useful to separate
> + from case 2 merely because it is generally the common case,
> + where simplicity is the most highly valued.
> +
> + 2. When NATs exist within the enterprise network, e.g., to connect
> + branch offices to the corporate network.
> +
> + 3. When the enterprise internally uses multicast
> applications/protocols
> + that they want to transition to IPv6. Here the enterprise has
> + already deployed intra-domain IPv4 multicast to support this
> usage.
> + As with case 1, there are no internal NATs in this case since IPv4
>
> + multicast itself does not cross NATs.
> +
> + NAT traversal must be supported in case 2, and IPv6 multicast must
> + be supported in case 3.
> +
> + The need for direct connectivity in all cases is strong due to two
> + factors:
> + * the high end-to-end bandwidth requirements for enterprise
> + applications, e.g., many clients accessing various servers,
> + such that bottlenecks occur if all traffic must be funneled
> + through one or a few tunnel endpoints;
> + * the use of collaborative applications, possibly including
> + high-bandwidth streams such as audio/video.
> +
> + Finally, most enterprise networks currently lack IPv6 expertise, and
> + have a great need to keep costs low. Hence simplicity and low
> + infrastructure costs are also required.
>
> ---
>
> 4.1 Scenarios Evaluation
>
> +++++++++
> NAT-T Direct ISP Secure Simple Low Multicast
> Overhead
> Unman 1.1 * * N - - - -
> Unman 1.2 * N * -/* - - -
> Unman 2 * - * - * - -
> 3GPP 1 N -/* * - * * -
> 3GPP 2 N -/* * - * * -
> + Enterprise 1 N -/* * * * - -
> + Enterprise 2 * -/* * - * - -
> + Enterprise 3 N -/* * - * - *
>
> Legend: * = MUST; - = Nice to have; N = No
>
> + Multicast support indicates whether the mechanism must be able
> + to support multicast traffic.
>
>
> ---
> 4.2 Mechanisms Evaluation
>
> One should note that we are not evaluating the specific version of
> the specification, but rather the mechanism in a more generic sense
> ("which features could this mechanism easily be made to work with?").
>
> +++++
> NAT-T Direct ISP Secure Simple Low Impl. Depl. Mcast
> Overhead
> Teredo Y Y N Y N N R Y N
> ISATAP N Y@ Y N/R R Y Y R? N
> TSP Y N Y? Y R N R R? Y?
> STEP Y N Y Y Y/R Y N N Y?
> + L2TP Y N Y Y N N Y Y Y
> + 6to4 N Y N N Y Y Y Y N
> + 6over4 N Y Y R Y Y Y R Y
>
> @: intra-site, no NATs in the path
>
> Legend: Y = Yes; R = Relatively good; N = No
>
> + Multicast indicates whether the mechanism is able to support
> + multicast traffic.
>
> ---
>
> -Dave
>
>