[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Enterprise scenario text proposal
I have to confirm what Jim is saying. customers are asking for v6-only
native deployment with some level of v4 legacy support (i.e. tunnelling).
Marc.
-- Friday, March 19, 2004 07:03:00 -0500 "Bound, Jim" <jim.bound@hp.com>
wrote/a ecrit:
> Dave,
>
> Will respond later traveling and cannot right this moment. But your
> missing DSTM and you entered the analysis for enterprise scenarios and
> we do not want to go there until after the scenarios are done. So will
> not respond to that later. Also we have enterprises moving directly to
> IPv6 Native as a strategy as soon as possilbe using dual stack so legacy
> v4 can be supported if required.
>
> thanks
> /jim
>
>> -----Original Message-----
>> From: owner-v6ops@ops.ietf.org
>> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Dave Thaler
>> Sent: Thursday, March 18, 2004 7:34 PM
>> To: v6ops@ops.ietf.org
>> Subject: Enterprise scenario text proposal
>>
>> 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
>>
>>
>>
>>
>
------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------