Subject: RE: Proposed way forward with the transition mechanisms

From: "Soliman Hesham" <[email-masked]>
Date: Fri, 30 Jul 2004 00:32:58 -0400

Hi Jonne/all, 

I continue to think that ISATAP is a good
solution for the cellular environment and is a 
good candidate for 3GPP. 

To preempt some of the discussion I'll be specific,
I'm talking about:

- host to router model
- Assuming ingress filtering
- Assuming authentication in the network.

I think it should go to standards track. I won't
be in the meeting but if there is a vote count 
me in! 

Hesham

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]On
 > Behalf Of Soininen Jonne (Nokia-NET/Helsinki)
 > Sent: Thursday, July 29, 2004 4:22 PM
 > To: [email-masked]
 > 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]
 > 
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 31 Jul 2004 00:20:24 -0400

I believe we must work to standardize both ISATAP and DSTM for sure
because they are being deployed and we need to make sure they are
deployed correctly with the necessary additions we as WG and IETF need
to put on them. But we should show how they play into the scenarios.  If
the market is using it then I think we have to work on it. There will be
no perfect Transition Mechanisms only ones that assist with some
problems and why one size does not fit all.

More later and I will do my best to contribute to this discussion it is
very imporant.

Thanks and to both Chairs for bringing this discussion forward that is
good leadership.

/jim 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Soininen Jonne 
> (Nokia-NET/Helsinki)
> 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.)
> 
> (Pekka's view I, at least, know already.)
> 
> Cheers,
> 
> Jonne.
> > 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.
> > 
> > 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.
> > 
> 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.
> > 
> > running the process document it into a draft. I can do the draft 
> > editing myself.
> > 
> >   Zero-configured IPv6-over-IPv4 tunneling mechanism - TSP, 
> Ayiya, STEP,

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 31 Jul 2004 00:29:21 -0400

ISATAP disappears once use is not required there is not administration
to remove it on the end node and other forms of transition  can be used.
That is not the case with tunnels that are not automatic.  This is one
reason I know of very large Japan Provider that is using ISATAP
currently for 3G+GPRS+etc pilots.

I also think it unwise to question the markets decision just like we did
not 6to4.  And I know users who will never use 6to4.  The point is
ISATAP has a market it exists.  It will expand and exists with or
without us.  I suggest we be smart and work on it.

/jim 

> [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Friday, July 30, 2004 5:10 AM
> To: Tim Chown
> Cc: [email-masked]
> Tim Chown wrote:
> > On Thu, Jul 29, 2004 at 11:22:12PM +0300, Soininen Jonne 
> (Nokia-NET/Helsinki) wrote:
> > 
> promising 
> >>solution for automatic tunneling in the 3GPP analysis document and 
> >>thus, should be listed as a solution to be standardized.
> > 
> > 
> > Our own experience (non-small enterprise) is that we prefer 
> to deploy 
> > a structured (configured) transition mechanism - in our case 
> > VLAN-based
> > IPv6 propogation - rather than an unstructured (automatic) 
> method.  So
> > we don't see any need for ISATP in our particular scenario. 
>   However,
> > I can see why some others see some attraction.
> 
> I think many enterprise networks will agree, not to mention 
> that since ISATAP solves the NBMA problem, it has some 
> intrinsic complexity. So I do echo Alain's question: what 
> makes ISATAP fit better than ordinary tunnels, in the 3GPP secnario?
> 
>     Brian
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 31 Jul 2004 00:30:15 -0400

I agree we would need an additional spec.  Again this one is deployed
already in several very large pre-production pilots serving many users
and sites.
/jim 

> [mailto:[email-masked]] On Behalf Of Pekka Savola
> Sent: Friday, July 30, 2004 5:35 AM
> To: Tim Chown
> Cc: [email-masked]
> On Fri, 30 Jul 2004, Tim Chown wrote:
> > On Fri, Jul 30, 2004 at 11:06:55AM +0200, Brian E Carpenter wrote:
> > > 
> > > 6to4 is already Proposed Standard, so its status is not currently 
> > > under discussion. Deployment is its own reward.
> > 
> > I was only commenting on Jonne's list, which includes 
> tunnel broker (an
> > existing RFC) but not 6to4.   The list should be draft-only, or all
> > mechanisms, I think, to avoid confusion.
> 
> It is draft-only, in the sense that the tunnel broker RFC 
> (3053) does not document the actual protocol, just the 
> concept.  If we go down that path, an additional spec would be needed.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 
>