Subject: [v6ops] Review of draft-zhou-v6ops-mobile-use-case and draft-tsou-v6ops-mobile-transition-guide

From: "Soininen, Jonne (NSN-FI/Espoo)" <[email-masked]>
Date: Thu, 11 Nov 2010 07:28:23 +0200

Hello,

I took a look at two drafts mentioned above. I assume these drafts are
interlinked and therefore consider them together here.

draft-zhou-v6ops-mobile-use-case:

I have some reservations with this draft. What is the purpose of the draft
in the first place? It seems that it seems to list some transition scenarios
and some random technologies. However, the document does not quite explain
why these scenarios and why these technologies.

The question is (like for Behcet's draft on Wednesday) if the document is
supposed to give guidance to 3GPP or explain IETF how 3GPP networks work?

I also have more detailed comments, but I'm not sure if it is worth the
while to give them before getting an answer to the meta comment.

draft-tsou-v6ops-mobile-transition-guide:

I guess with this draft the document submission deadline came too early. It
seems that this document is quite raw and I really cannot make heads or
tales of this. I do not quite understand how the parts of the network to
give guidance have been selected and why others have been omitted. I guess
this document needs still quite a bit of work before it should be even
considered.

Cheers,

Jonne. 
-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Nov 2010 18:39:09 +1300

Jonne,

The very short draft-carpenter-v4v6tran-framework-00.txt
is an attempt at a meta document that (being biased) I
would like to set the scene for the two documents you
have reviewed and a few others. I agree that you are
looking at very early work.

Regards
   Brian Carpenter

---

From: "Soininen, Jonne (NSN-FI/Espoo)" <[email-masked]>
Date: Thu, 11 Nov 2010 08:00:59 +0200

Hi Brian,

I wasn't aware that this is supposed to be the framework document for the
two others. This puts the other documents into perspective. However, I'm not
(at least yet) convinced.

Your document describes a quite detailed documentation process, which will
create (I assume) some sort of guidance to the operators how to do
transition. Is this assumption right?

I'm a bit worried that this documentation will take very long time, and be
really high level to basically address the "common case" between operators.
In addition, in the 3GPP space there is something like this already ongoing
in 3GPP (23.975) (Actually now rereading the 3GPP spec it seems that much of
the content for the two drafts are taken from the 3GPP spec).

I don't really understand why we would replicate work other people do here.
In addition, I'm not sure that it is that easy to come to a conclusion in
this discussion at this point, and I think we would use quite a bit of time
for work that might not be that useful.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: Tom Taylor <[email-masked]>
Date: Thu, 11 Nov 2010 14:44:54 +0800

First point: 23.975 doesn't cover the whole problem. I hope to 
demonstrate that with my presentation tomorrow afternoon. Second point: 
the two drafts that have been posted are unchanged from the ones 
presented to the V4toV6trans interim meeting in September. We got some 
good comments on the list and in that meeting that we have taken into 
account. I'll confess that the current drafts were placeholders until I 
figured out what if anything could be added to work already in progress.

The charts I've provided for tomorrow's session are my answer: there are 
a few things that can be added to what has already been written, I'll 
update (i.e, completely rewrite) the drafts to capture them, but I'm not 
sure the resulting draft will stand alone or be merged into other work.

> for work that might not be that useful.
...

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Nov 2010 20:30:36 +1300

Jonne,

> transition. Is this assumption right?

That is the intent of the authors. Of course, the WG gets to decide whether
this is what we should do.

> 
> I'm a bit worried that this documentation will take very long time, 

So am I, from my memory of the last round of similar work.

> and be

Yes, because otherwise we would just be publishing individual operators'
plans and experience.

> I don't really understand why we would replicate work other people do here.

IMHO we shouldn't. If there are documents in other SDOs that do what is needed.
it seems pointless to repeat them (as long as they are public documents).
But see Tom Taylor's comment on this.

> for work that might not be that useful.

Well, some operators are asking for such guidance and seem willing to
work on this. But clearly this is a point where the WG needs to reach
a consensus.

   Brian

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 11 Nov 2010 02:00:02 -0700

Hi,

> sure the resulting draft will stand alone or be merged into other work.

Regarding draft-ietf-v6ops-v6-in-mobile-networks, your chart says "looks in
more detail than RFC 4215 into the question of NAT placement".

This is part of what's discussed there. As the Introduction states:

o Public and Private IPv4 address exhaustion and implications to
  mobile network deployment architecture;

o Placement of Network Address Translation (NAT) functionality and
  its implications;

o IPv6-only deployment considerations and roaming implications;

o Fixed-Mobile Convergence and implications to overall
  architecture.

The general observation is that what you _seem_ to be proposing is
documented in different places. I am not convinced, based on your drafts and
charts, that there are gaps that IETF needs to work on.

Regards,

-Rajeev

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Tom Taylor <[email-masked]>
Date: Thu, 11 Nov 2010 19:08:35 +0800

Do you feel that your draft goes into equal depth on all of these topics?

On 11/11/2010 5:00 PM, Rajeev Koodli wrote:
...

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 11 Nov 2010 03:55:10 -0700

It goes into the appropriate level of depth, following the normal WG process
(it's finished WGLC).