Use cases for our work

[Tom Taylor]

What are the concrete use cases we have to work on to frame our discussion? Are
they access technology specific?

Mobile 2G, 3G, 4G
Wi-Fi
Cable
DSL

Are there any variations in core networks that we have to factor in?

Hosts access network directly vs. through operator-provided CPE.

What other dimensions?

Tom Taylor

[Brian E Carpenter]

Tom, I'd ask the question another way round.

What cases are *not* covered by existing documents and techniques?

It's not like this is a new topic. We've had transition models
in mind since the ngtrans days, and there's an existing set of
documents, as well as the general framework in
draft-arkko-ipv6-transition-guidelines. There's one specific
transition sequence in draft-ietf-v6ops-incremental-cgn, if
I may make so bold. So rather than starting again on the general
sweep across the technologies that led to RFC4029, RFC4779,
RFC4798, RFC4942 and RFC5181, could we start by identifying what
the gaps are that we need to fill? What are the aspects of
draft-arkko- that need filling out with more specific scenarios
and recommendations?

Also, if we tried to build a matrix of all access technologies
(inlcuding CPE variants), all network core technologies,
and all security practices, we'd need a very large sheet of
multidimensional paper indeed. I'm not optimistic that the
process would converge.

Brian

[Victor Kuarsingh]

Tom,

I would agree with the list you sent with a couple of comments.

I would say Ethernet/Fiber delivered access should be considered. Secondly, Wi-Fi may be a bit tricky since we could generalize that into two categories - consumer/enterprise wi-fi environments and provider controlled/managed environments.

If the latter is what you were referring to, then I guess that makes sense.

I will comment on Brian's concerns in my next email (to keep things in order)

regards,

Victor

[Victor Kuarsingh]

Brian,

Part of the discussion we (side group) had in Maastricht was that the guidelines provided to date concentrate on the available technologies, and provide very general guidance on when they can be used. These drafts, like draft-arkko-ipv6-transition-guidelines provide excellent information on IPv6 and transition technologies - but....

That said, the documents to date do not cover many items that providers are looking for when considering IPv6 transition (and IPv4 run out since this is a part of the mix). Draft-ietf-v6ops-incremental-cgn comes closer to what providers may be looking for (provides a specific view of one option that can be followed). I was trying to put together some text (for the groups consideration) as to what some of these points may be, but a short/abbreviated list follows.

(un-formatted, but a conversation piece) - when looking at what is available and what we may want/need:

- The drafts explain many of the technology "whats" but fall short of describing the "hows"
- Presentation of major (generic) use case network models which exist today, including network topologies and/or architectures
- Analysis criteria on how to recognize appropriate transition technologies for the current provider network (such information should/would include information related to deployed protocols and functions which may assist and/or hinder various technologies from being deployed)
- How multiple transition technologies can be deployed (simultaneously) for provider environments where access networks differ and have various capabilities
- Description of how multiple technologies can co-exist during initial as subsequent stages of migration (i.e. Moving from IPv4 Only to Dual-Stack to DS-Lite to NAT64).
- Considerations for legacy operation while moving to IPv6 and related transition technologies (i.e. many operators will have large caches of IPv4 only equipment which cannot be feasibly upgraded in the near future - like customer controlled/owned)
- Considerations which need to be made when applying various technologies to existing networks. Included in this would be impacts to protocols, routing platforms/systems, security polices, provisioning systems, network services (i.e. DHCP, DNS etc), law enforcement procedures and more
- Scaling characteristics of deployment modes for each technology model and intersections during co-existence (i.e. Some of the Network is DS-Lite and some is Dual Stack).
- BCPs on generic deployment models (how this fits into a network) including major and key services (i.e. DHCP, DNS)

many may not agree with all or any of my points, but I throw it out there for consideration. I will draw your attention (seems a bit self serving) to a draft I put together which has some of these characteristics in place. I looked at NAT44/LSN (in relation to IPv6 as well) and attempted to capture many of the provider considerations when looking to deploy such a technology. Some of the points included, how to make it work while not disrupting legacy IPv4 operation, how to add in Ipv6, how to scale the environments, and what the environment may look like over time - draft-kuarsingh-lsn-deployment-00. The goal here would be a different operator may look at this and say "ah, this is how I can make this work" and either use it, or not.

regards,

Victor

[Rémi Després]

Le 9 août 2010 à 06:06, Brian E Carpenter a écrit :

> Tom, I'd ask the question another way round.
>
> What cases are *not* covered by existing documents and techniques?
>
> It's not like this is a new topic. We've had transition models
> in mind since the ngtrans days, and there's an existing set of
> documents, as well as the general framework in
> draft-arkko-ipv6-transition-guidelines. There's one specific
> transition sequence in draft-ietf-v6ops-incremental-cgn, if
> I may make so bold. So rather than starting again on the general
> sweep across the technologies that led to RFC4029, RFC4779,
> RFC4798, RFC4942 and RFC5181, could we start by identifying what
> the gaps are that we need to fill?

> What are the aspects of
> draft-arkko- that need filling out with more specific scenarios
> and recommendations?

6rd isn't mentioned in draft-arkko- although is a successful tool used and planned to be used by ISPs to offer IPv6 (Free, Swisscom, SoftBank, Comcast, Announcement by AT&T...).
This has IMHO to to be fixed.

RD

[Jari Arkko]

R�mi,

> 6rd isn't mentioned in draft-arkko- although is a successful tool used and planned to be used by ISPs to offer IPv6 (Free, Swisscom, SoftBank, Comcast, Announcement by AT&T...).
> This has IMHO to to be fixed.
>

I will add 6rd to the section that deals with tunnel-based solutions.

Jari

[Rémi Després]

Le 9 août 2010 à 09:08, Jari Arkko a écrit :

> Rémi,

>
>> 6rd isn't mentioned in draft-arkko- although is a successful tool used and planned to be used by ISPs to offer IPv6 (Free, Swisscom, SoftBank, Comcast, Announcement by AT&T...).
>> This has IMHO to to be fixed.
>>
>

> I will add 6rd to the section that deals with tunnel-based solutions.

Thanks Jari.
Most appreciated.
RD

>
> Jari
>

[Brian E Carpenter]

Victor,

IMHO that is a very good list of concerns/topics. There's also the
issue of gaps identified by ISPs who are already running, or
actively planning, v6 services. There's a (partial) list of gaps
in section 4 of draft-ietf-v6ops-isp-scenarios, so I won't repeat
it here.

Maybe our biggest initial challenge is organising the work to be done
into reasonably sized "projects". My concern with Tom's suggestion
is that organising by use case would generate far too many work items.
I think your list could be developed into a useful framework.

Regards
Brian

> ------------------------------------------------------------------------
>
>
> This e-mail (and attachment(s)) is confidential, proprietary, may be subject to copyright and legal privilege and no related rights are waived. If you are not the intended recipient or its agent, any review, dissemination, distribution or copying of this e-mail or any of its content is strictly prohibited and may be unlawful. All messages may be monitored as permitted by applicable law and regulations and our policies to protect our business. E-mails are not secure and you are deemed to have accepted any risk if you communicate with us by e-mail. If received in error, please notify us immediately and delete the e-mail (and any attachments) from any computer or any storage medium without printing a copy.
>
> Ce courriel (ainsi que ses pièces jointes) est confidentiel, exclusif, et peut faire l’objet de droit d’auteur et de privilège juridique; aucun droit connexe n’est exclu. Si vous n’êtes pas le destinataire visé ou son représentant, toute étude, diffusion, transmission ou copie de ce courriel en tout ou en partie, est strictement interdite et peut être illégale. Tous les messages peuvent être surveillés, selon les lois et règlements applicables et les politiques de protection de notre entreprise. Les courriels ne sont pas sécurisés et vous êtes réputés avoir accepté tous les risques qui y sont liés si vous choisissez de communiquer avec nous par ce moyen. Si vous avez reçu ce message par erreur, veuillez nous en aviser immédiatement et supprimer ce courriel (ainsi que toutes ses pièces jointes) de tout ordinateur ou support de données sans en imprimer une copie.