RE: Enterprise scenario text proposal

["Bound, Jim" <jim.bound@hp.com>]

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