Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues

From: Soliman Hesham <[email-masked]>
Date: Thu, 2 Oct 2003 09:27:21 -0400

> > => I didn't ask to have "don't tunnel from the UE"
 > > in the text. I was commenting on the new text.
 > > I don't think the draft should include opinions on how 
 > > easy it is to upgrade to V6 and whether that involves
 > > SW or HW upgrades. It's not useful. 
 > 
 > It seems very useful to me, although the wording may not be 
 > optimal.  If 
 > upgrading to v6 is relatively easy, we can recommend 
 > upgrading to IPv6.

=> I'm afraid that we cannot make a general assessment 
here of how "easy" it is to upgrade to v6. Leave it to
the operators because we have no "one statement fits all".
As a general comment. I'd like to minimise opinions in 
IETF specs and keep it concrete and straight forward. 

If operators think it's easy to upgrade, I'm sure they
will do what they need to do. Putting it in the draft
will not "make them believe".

 > >    That's 
 > >  > also expected to happen during the early phases of 
 > >  > transition.  If the 
 > >  > operator doesn't care about IPv6 users at all, the users can 
 > >  > just stay out 
 > >  > of those networks.
 > > 
 > > => The point is: Your operator cares about v6 and wants 
 > > to offer you the services that IPv6 enables 
 > 
 > Right so far..
 > 
 > > while you're
 > > roaming. 
 > 
 > If your SP wants to enable services while you're roaming, 
 > your SP needs to 
 > convince those networks it has roaming agreements with to enable v6? 

=> No way... What's the incentive for another operator to do that? 
Even if this is possible. I think we should refrain from
anticipating business dealings that do not exist. 
We should handle the technology part and let operators
run their business. 

On this note, please see the note from Andreas Schmidt
(Swisscom) on the need for tunneling in the early days of
IPv6.

 > 
 > > It is not relevant how the visited operator feels
 > > about v6. 
 > 
 > I fear this is very relevant.  Your home operator can't 
 > really offer what 
 > it can't provide.  So, it should not *guarantee* you IPv6 
 > services while 
 > you roam, as simple as that..

=> Well, it can when tunneling is used. But you seem
to say that it "shouldn't", despite the fact that it
can.

 > > But the point is, 
 > > requiring an operator to support v6 will not necessarily
 > > eliminate tunneling when the UE roams to another network
 > > (whose managers don't want to support v6 and will implement
 > > v6ops recommendations). 
 > 
 > So, don't use v6 in those networks then?

=> Unless you provide a serious reason we can't support
this suggestion, especially when there are ways of achieving
this. 

 > > => But in this case the visited network doesn't care about 
 > > v6. I'm not sure how eliminating the use of V6 through 
 > > a tunnel will give the visited network an incentive to
 > > deploy v6.
 > 
 > For example, if the customers select a different operator 
 > when they roam
 > because the one they tried first doesn't support v6 
 > ("v4-only operator
 > loses customers and thus money"), I guess the operator which didn't
 > support v6 would start to see some benefit in deploying v6 
 > if the number
 > of users warrants that.  There could also be some PR 
 > gains/losses involved
 > here.

=> I just can't relate this to what's happening today.
This is really speculative and I prefer to keep the
draft technical and concrete. The draft doesn't mandate
tunnelling but it doesn't discount it either. I don't
see any good reasons for discounting it. If people think
it's too complex (I don't) then they won't implement it 
or deploy it. This is not our call though. This is up to vendors
and operators to choose.

Hesham

---

From: Pekka Savola <[email-masked]>
Date: Fri, 3 Oct 2003 09:12:22 +0300 (EEST)

> will not "make them believe".

I think this is not true at all.  Remember that we're not specifying a 
protocol here .. but giving recommendations on deployment.  We can, and 
should, "make them believe".  Education is one important part of the 
solutions specs.
 
> => No way... What's the incentive for another operator to do that? 

Not to lose money from the customers it would bring, simple as that.

> (Swisscom) on the need for tunneling in the early days of

Tunneling inside the operator, a completely different beast than roaming..

> to say that it "shouldn't", despite the fact that it

Yeah, it *could* provide a service, if we recommend a tunneling mechanism
(or multiple ones) to be implemented in all UE's.  If it isn't implemented 
in all UE's it's not going to fly.  So, we have to balance whether we want 
the transition mechanism at the UE, or not; and which kind of transition 
mechanism it would be (i.e., whether there would be any problems in that).

Configured tunneling could be acceptable to me _in the roaming case
(only)_, but a bit unsure yet.  Depending on how 3GPP architecture is
built up, "automatic this" (in conjunction with v4 PDP context activation 
procedures), this the difficulty could range from trivial to really 
difficult.

> this suggestion, especially when there are ways of achieving

Ways which may jeopardize the simplicity and robustness of the 3GPP 
transition.

> or deploy it. This is not our call though. This is up to vendors

It is our business to make the best recommendations we can.  Saying "do
whatever you want [or whatever some others seem to be doing]" or listing
3-4 different options of possible ways forward is not useful advice.  We
should figure out which recommandations are best, and if someone chooses
to ignore them for whatever reason, that's not our problem.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings