Subject: RE: Proposed way forward with the transition mechanisms

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

It may or it may not end up being lightweight.
For 3GPP lightweight however is demanded.

Karen

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Aug 2004 18:51:23 +0200

> For 3GPP lightweight however is demanded.

Lightweight is an undefined term.

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

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.

    Brian

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 03 Aug 2004 10:08:45 -0700

> decapsulation logic that every 3GPP device will need anyway.

Can you be more specific on what you mean by "state logic"?
ISATAP just uses route entries in the IPv6 routing table as
for any other IPv6 interface.

Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Aug 2004 23:13:44 +0200

> for any other IPv6 interface.

Well, since there are new data structures defined explicitly
in the ISATAP spec, surely there *must* be additional logic
to create, process, and delete those data. I'm referring to
sections 8.1 and 8.3.1 of draft-ietf-ngtrans-isatap-22.txt.

I'm not trying to set the clock back, but none of that arises
for 6over4 as far as I know.

     Brian

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 03 Aug 2004 16:16:39 -0700

Brian,

> sections 8.1 and 8.3.1 of draft-ietf-ngtrans-isatap-22.txt.

I guess you are talking about the Potential Router List (PRL)?
For the purpose of ingress filtering and perhaps default router
discovery, the PRL should be quite small - usually no more than
1 entry. Any other uses for the PRL shouldn't add any more state
beyond what the client already maintains.

> for 6over4 as far as I know.

Out of respect for the earlier works, I won't add anything
futher on this.

Thanks - Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Aug 2004 01:37:49 +0200

> I guess you are talking about the Potential Router List (PRL)?

That and the associated timers in 8.3.1, and then the PRL
initialisation and refresh actions.

> beyond what the client already maintains.

OK. But if I was a picky hardware designer, I'd need to know
how many entries the PRL might grow to in the worst case.

    Brian