Subject: RE: Proposed way forward with the transition mechanisms

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Tue, 3 Aug 2004 00:57:04 +0200

> > 
> 
> Karen,
> 
> We had this discussion before. 

Yes, I know. But you, not I, started this....

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.

I'm a little lost here, but let me try to answers what I think your question is:

There are MUST requirements in the assited-tunneling-requirements document 
that are not mandated by all scenarios (3GPP in particular).

I assume that this is based on the prerequisite that you are looking for 
one-and-only-one "zero-configuration" tunnelling protocol to suit all scenarios.

Had we infinite time and infinite resources I may support defining one solution that fits it all. However given that this one-solution-fits-it-all isn't here for some time yet as well as it may end up be an over complex monster. I would rather go for a (limited, yes) number of good solutions each tailored for some appropriate subset of the scenarios.

To answers Pekka email as well, what I am missing from your document is a differentiation in between the various scenarios. In particular a requirement should only be a MUST if it is anticipated to be required by all scenarios.
Either that or a recognition that this document isn't applicable to 3GPP environments (at least).

> 
> 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?
> 

One major requirement I have which is not met by your "yet to be defined" protocol
is that it is exactly that - i.e. a yet to be defined protocol. Whereas Isatap
is defined, it is ready to use (and standardize) and it fulfils the requirement of 3GPP (which is not going to wait forever).

BR, Karen

> 	- Alain.

---

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Tue, 3 Aug 2004 01:38:49 +0200

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, August 03, 2004 1:20 AM
> To: Karen E. Nielsen (AH/TED)
> Cc: 'Alain Durand'; Karim El-Malki (AL/EAB); 'Soininen Jonne ';
> [email-masked] '
> Subject: Re: Proposed way forward with the transition mechanisms
> 
> 
> Karen E. Nielsen (AH/TED) wrote:
> > 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,
> 
> 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.

I assume that you're hinting at manually configured FQDNs - ?
The solution anticipated for 3GPP (at least) would be to rely on
FQDNs on the form isatap.<domain_name>", where
<domain_name> is the DNS suffix configured on the underlying IPv4 interface.

Other tunnel discovery possibilities, which I believe have been considered for 3GPP2 usage, is to use a special option in DHCP. It would be preferable to agree on relying on the same solution in both 3GPP and 3GPP2, but not an absolute requirement.

> 
> > * It is lightweight network architecture wise, i.e. it
> > requests one additional infrastructure element only, namely 
> the Isatap router.
> 
> And an extra module in every host stack that wants to use it.

So would all tunnelling mechanisms, I assume.

Karen

---

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Tue, 3 Aug 2004 02:16:23 +0200

I agree that it could be very simple, Isatap - as one example - is :-).

I did look at the non-registered mode (too).
It still requires NAT-traversal, firewall traversal, extensibility...

Karen
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Tuesday, August 03, 2004 2:07 AM
> Cc: [email-masked]'; Karim El-Malki (AL/EAB); 
> 'Soininen Jonne ';
> [email-masked] '
> Subject: RE: Proposed way forward with the transition mechanisms
> 
> 
> On Tue, 3 Aug 2004, Karen E. Nielsen (AH/TED) wrote:
> > Something else I perhaps forgot to stress in my answer, is that 3GPP
> > explicitly demands a lightweight protocol - tailored for usage on
> > mobile devices for a limited time only,
> > draft-ietf-v6ops-3gpp-analysis-10.txt - a protocol fulfilling the
> > requirements of your document seems to be anything but that.
> 
> Please look at the 'non-registered mode' in the document.  It 
> could be 
> *very* simple.
> 
> -- 
> 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: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Tue, 3 Aug 2004 21:10:19 +0200

> Lightweight is an undefined term.
> 

Right.

The term however is used in draft-ietf-v6ops-3gpp-analysis-10.txt to indicate,
I would assume, something along the following lines wrt capabilities:
* should be compatible with the constrains of the 3G links and
the capabilities of the the 3G UE
* the number of features (e.g. NAT traversal etc)
demanded by the tunnelling service are limited.
At least this is what I intended it to mean.

- And yes, this is still not very precise. 
Luckily now though, given that the wg should produce a zeroconf 
tunnelling requirements document, we should
be able to move away from relying on this vaque term only.

> As far as I can see, ISATAP adds extra data structures and
> extra state machine logic to the basic proto 41 encapsulation/
> decapsulation logic that every 3GPP device will need anyway.

Yes. Again I would assume that so would any mechs relying on
automated address assignment and proto 41 encapsulation opposed to manual
confiuration of the latter.

> The question is whether that costs more or less silicon and power
> than the alternatives. Until the alternatives have been defined,
> that question has no answer.

Yes (of course).
This with the twist though, that based on the requirements put forward (the
assisted-tunnelling draft) then these, yet to be defined, alternatives
will have to come with a lot of features not required by the 3GPP environment. 

> 
> Of course, 3GPP could decide to make its choice before the
> alternatives have been defined and evaluated, but that would
> be an act of faith. 

It might be a legitimate choice, to meet
> deadlines, but we should be clear about it.
> 

I agree about the last part.

I think that if what we have works 
and meets the time constrains (whereas the yet to be defined
won't) then faith doesn't really come into it.

Karen

>     Brian
> >>From: [email-masked] [mailto:[email-masked]]
> >>Sent: Tuesday, August 03, 2004 6:41 AM
> >>Cc: 'Pekka Savola'; Karim El-Malki (AL/EAB); 'Soininen Jonne ';
> >>[email-masked] '
> >>>Alain,
> >>>Something else I perhaps forgot to stress in my answer, is
> >>>that 3GPP explicitly demands a lightweight protocol - 
> >>
> >>tailored for usage
> >>
> >>>on mobile devices for a limited time only, 
> >>
> >>draft-ietf-v6ops-3gpp-analysis-10.txt 
> >> >
> >>
> >>>- a protocol fulfilling the requirements of your document 
> >>
> >>seems to be anything but that.
> >>
> >>
> >>Until we made an analysis of the existing protocols that 
> >>could be taken 
> >>as is or augmented to satisfy the "goals", it is not fair 
> to say that
> >>the protocol will not be "lightweight".
> >>
> >>	- Alain.
> >>
> >>
> >>
> > 
> > 
>