Subject: RE: Proposed way forward with the transition mechanisms

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Mon, 2 Aug 2004 21:43:00 +0200

Hi Alain,

I find it difficult to argue based on draft-ietf-v6ops-assisted-tunneling-requirements-00.txt given that this draft so clearly focuses on the full-fledged 
tunnelling functionality demanded by (perhaps ?) the ISP environment
and not the lightweight tunnelling function requested for the 3GPP environment.
Examples - just to pick a few: NAT traversal, prefix delegation, extensibility requirements of draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. Neither of which can be found in the 3GPP v6ops documents, that is RFC 3574 and draft-ietf-v6ops-3gpp-analysis-10.txt.

I opt for standard track standardization of Isatap as it serves the needs of the 3GPP environment. In particular:

* It is simple and easy to deploy,
* It is lightweight network architecture wise, i.e. it
requests one additional infrastructure element only, namely the Isatap router.
* It provides a scalable and simple service discovery mech (DNS)
* Tunnel set-up protocol at client side is simple
* It is stateless and provides the most efficient tunnel-set up protocol there is at the server side (none)
* Ipv6 Address (/128) assignment and configuration is provided using simple and well-understood mech (IPv6 RS/RA)
* Keep-alive is achieved using simple and well-understood mechs (IPv6 RS/RA)
* It is "ready to use". There is no major open issues and it may be readily standardized.
* It is there, both on paper and in running code and it solves a pressing need in 3GPP

Karen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Alain Durand
> Sent: Friday, July 30, 2004 7:43 AM
> To: Karim El-Malki (AL/EAB)
> Cc: 'Soininen Jonne '; [email-masked] '
> Subject: Re: Proposed way forward with the transition mechanisms
> 
> 
> 
> On Jul 29, 2004, at 3:39 PM, Karim El-Malki (AL/EAB) wrote:
> 
> > I agree with Jonne. ISATAP is the most promising solution
> > 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: Alain Durand <[email-masked]>
Date: Mon, 02 Aug 2004 14:16:32 -0700

> Examples - just to pick a few: NAT traversal, prefix delegation, extensibility requirements of draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. Neither of which can be found in the 3GPP v6o…

Karen,

We had this discussion before. This is NOT because we want to be able to 
support environment with NAT or prefix delegation,.. that this
(still to de defined) protocol will not work with no overhead
in environments like 3GPP where those features are not (yet) needed.

So you still haven't answered my question. Let me ask it differently.
What does Isatap enable that a protocol metting the requirements
described in draft-ietf-v6ops-assisted-tunneling-requirements-00.txt
will not?

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 3 Aug 2004 00:41:50 +0300 (EEST)

On Mon, 2 Aug 2004, Alain Durand wrote:
[...]
> described in draft-ietf-v6ops-assisted-tunneling-requirements-00.txt

Or put yet another way,

"Could you provide requirements from the 3GPP (analysis) to be
considered in assisted-tunneling-requirements if there's 
something missing?"

(co-chair hat on)
We've received input from the ADs that it's important to understand
the actual requirements learned from the different analysis documents
better.  Even if the requirements from the 3GPP analysis wouldn't be
incorporated in this particular document, they should be spelled out a
bit better to be considered separately.

But more of this later.
(co-chair hat off)

-- 
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: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Aug 2004 01:19:43 +0200

> * It is simple and easy to deploy,

Manual configuration is easy to deploy at 3GPP scale?

 From the ISATAP draft:

8.3.2 Potential Router List Initialization

    ISATAP nodes initialize an ISATAP interface's PRL with IPv4 addresses
    discovered via manual configuration, a DNS fully-qualified domain
    name (FQDN) [STD13], a DHCPv4 option, a DHCPv4 vendor-specific
    option, or an unspecified alternate method. FQDNs are established via
    manual configuration or an unspecified alternate method.

> requests one additional infrastructure element only, namely the Isatap router.

And an extra module in every host stack that wants to use it.

     Brian