Subject: RE: Proposed way forward with the transition mechanisms

From: "Karim El-Malki (AL/EAB)" <[email-masked]>
Date: Fri, 30 Jul 2004 00:39:50 +0200

I agree with Jonne. ISATAP is the most promising solution
for 3gpp tunnelling so I think it should be listed amongst
those that will proceed onto standards track. Actually I thought
there had been enough consensus on the list for ISATAP and
assumed it was on that list already.
/Karim

-----Original Message-----
From: [email-masked]
To: [email-masked]
Sent: 7/29/2004 10:22 PM
Subject: Re: Proposed way forward with the transition mechanisms

Hello everybody,
(chair hat off - this is totally my personal view)

when writing the proposal for the WG, Pekka and I noticed that we have
different view on some issues. In one topic especially, we seemed to
have pretty opposing views. This topic is the role of ISATAP. 

I do personally believe that ISATAP is pointed as the most promising
solution for automatic tunneling in the 3GPP analysis document and thus,
should be listed as a solution to be standardized. 

I thought even that there was at least some support in the WG for ISATAP
and it had been seen also at least somewhat applicable for enterprise
scenarios. This is of course difficult to say as the enterprise analysis
document is not existing, yet. 

However, I would hereby propose as an individual the addition of ISATAP
in the list of mechanisms that should be standardized on standards
track. (Of course, there has to be consensus in the WG to do that.)

I would like to hear what other people feel about this! (Pekka's view I,
at least, know already.)

Cheers,

Jonne.
On Thu, 2004-07-29 at 23:07, ext Soininen Jonne (Nokia-NET/Helsinki)
wrote:
> Dear v6ops WG,
> 
> our very own AD, David, sent the WG list mail on the July 1st about
the
> way forward and how he sees the way forward for our little WG. Pekka
and
> I have discussed the topic and found enough consensus among ourselves
to
> propose a way forward for the WG. Of course, you the WG, have to say
if
> you agree with the following approach. We believe that the discussion
> should be started now on the WG list and then continue it in the
> face-to-face meeting in San Diego to work the details further. The
final
> decision for the way forward is of course for the WG to make in the
> mailing list - as always in the IETF.
> 
> The proposal is to derive the different transition mechanisms from the
> Scenarios/Analysis documents and identify either the matching,
existing
> mechanism, or identify gap and list possible solutions. We have done
our
> own preliminary analysis. The proposal bellow is for discussion and
> should not be considered the final list. We would like to have
> discussion if it really does identify all needed mechanisms and just
the
> needed mechanisms. 
> 
> Bellow there is a list of mechanisms. This the list that Pekka and I
put
> together in quite short time. It may or may not be correct and that's
> something that we have to discuss on the list and in the face-to-face
in
> the meeting. So, this is just the baseline to start the discussion.
> 
> In the interest of time, we propose to do this on the list and after
> running the process document it into a draft. I can do the draft
editing
> myself.
> 
> In the following, is the analysis of the different scenarios/analysis
> documents (in no particular order).
> 
> 3gpp-analysis:
>  SIP v4/v6 transition mechanism
>  Zero-configured IPv6-over-IPv4 tunneling mechanism
> 
> unmanaged:
>   Teredo*
>   Configured tunneling through NAT
>   IPv4 over IPv6 tunneling mechanism
> 
> ISP:
>   BGP-tunneling*
>   Tunnel server/broker
> 
> Enterprise:
>   Analysis not done.
> 
> Summary:
>   Teredo*
>   BGP-Tunneling*
>   SIP v4/v6 transition mechanism - No candidates
>   Tunnel Server/Broker - TSP, Silkroad, Ayiya, STEP possible
candidates
>   Configured tunneling through NATs - No (direct) candidates, but
Tunnel
>         Server/Broker also addresses this
>   Zero-configured IPv6-over-IPv4 tunneling mechanism - TSP, Ayiya,
STEP,
>         ISATAP possible candidates.
>   IPv4 over IPv6 Tunneling - DSTM, TSP, Ayiya possible candidates;
many
>         tunnel server/broker approaches also address this.
> 
> (* Teredo and BGP-tunneling are already moving forward)
> 
> The suggestion is to go forward with Teredo/BGP-Tunneling immediately,
> work on SIP v4/v6 transition in SIP WG(s), and find the correct place
> for finding suitable solution for the following:
>  
>   a) zero-configuration both at the client or the server,
>   b) IPv6-over-IPv4 tunnels (with NAT traversal support), and
>   c) IPv4-over-IPv6 tunnels
> 
> This work should take use of 
> draft-ietf-v6ops-assisted-tunneling-requirements-00.txt.
> 
> Cheers,
> 
> Jonne & Pekka - the chairs.
-- 
Jonne Soininen
Nokia

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Jul 2004 02:08:42 +0300 (EEST)

(note -- please don't copy v6ops-owner@)

On Fri, 30 Jul 2004, Karim El-Malki (AL/EAB) wrote:
> I agree with Jonne. ISATAP is the most promising solution for 3gpp
> tunnelling so I think it should be listed amongst those that will
> proceed onto standards track. Actually I thought there had been
> enough consensus on the list for ISATAP and assumed it was on that
> list already. /Karim

FWIW, my own personal opinion...

I do not see a strong technical reason for ISATAP, especially in 3GPP.

Any relatively simple tunneling solution which requires no user
interaction to set up should be sufficient there.

The only reasons I can think of why folks want to go for ISATAP are:
 1) some have already started deploying it or piloted it, and may even 
    have already committed to it -- meaning if they care about the 
    IETF, their only option is to push for it as hard as they can.
 2) it's already "out there", requiring a smaller amount of 
    specification etc. than other mechanisms.

I personally believe that we could make do with one additional
mechanism, a tunnel server, developed based on the assisted tunneling
requirements.  If there is sufficient commitment from the people,
achieving that, even in the short term, should not be too challenging.

A significant goal has been to minimize the number of mechanisms --
"Less is More"; this was also stated by the ADs at IETF59 as well.  
Producing just one slightly more generic mechanism could help us to
obviate the need for an additional mechanism -- and thus not going for
ISATAP in 3GPP would seem useful at least for the reduction of the
required mechanisms.

And remember, ISATAP -- as implemented -- is going to be published as
Experimental RFC even if it didn't go for Standards Track -- it's
already in the RFC editor's queue.  That's sufficient for documenting
a protocol and creating interoperable implementations.  There's no
need for Standards Track (just) for that.  Standards Track should IMHO
mean just those mechanisms we really, really need -- the "IETF seal of
approval and review".  IMHO, ISATAP doesn't seem to fulfill that
criterium.

That is why I must oppose adding ISATAP to the list of standardized
mechanisms at this point.

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

---

From: "Karim El-Malki (AL/EAB)" <[email-masked]>
Date: Fri, 30 Jul 2004 01:44:31 +0200

Isn't there a reason number 3 you forgot about?

3) It is an appropriate solution for the 3GPP scenario.

We can't all either be conspiring to push our solution
(your reason 1) or plain stupid (your reason 2: we don't
know why we want ISATAP but it takes little work to
complete it). I haven't heard one valid technical
reason why ISATAP doesn't make sense in a 3gpp network.
So I can't see how you reach your conclusion nor a reason
why ISATAP should go experimental instead of standards
track.
/Karim

---

From: Alain Durand <[email-masked]>
Date: Thu, 29 Jul 2004 22:42:39 -0700

On Jul 29, 2004, at 3:39 PM, Karim El-Malki (AL/EAB) wrote:

> for 3gpp tunnelling

For the sake of the discussion, could the ISATAP proponents summarize
why they think ISATAP is a better fit than a tunnel broker solution 
based
on draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. in a 3GPP 
environment?

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Jul 2004 09:15:13 +0300 (EEST)

[Pekka:]
> reason why ISATAP doesn't make sense in a 3gpp network.

Sorry, I was a bit inprecise when I wrote "The only reasons I can
think of why folks want to go for ISATAP are:" -- what I meant was
"The only reasons I can think of why folks want to go for ISATAP *in
particular* are:" or even "The only reasons I can think of why folks
want to *require* ISATAP are:".

I can see that many people see it as an appropriate solution, as you
say.  But it's (IMHO) just that -- *a* solution; not *the* solution.  
What I was hard time seeing (my two reasons above) why something else
-- which would be more generic, applicable in more scenarios --
couldn't be an equally appropriate (or even more so) a solution.