Subject: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt

From: [email-masked]
Date: Mon, 8 Apr 2002 15:30:37 -0500

Folks,

This is a WG last call for: Mobile IP Regional Registration -
draft-ietf-mobileip-reg-tunnel-06.txt
This draft is a standards track WG document.

Please send in your comments by April 22nd, 2002 to the authors or
to the WG discussion list.

-Basavaraj

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Fri, 19 Apr 2002 15:20:31 -0400

HI All,

Is there a problem statement associated with this draft?  We are not
clear on what problem this draft is trying to solve.  If the idea is to
enable a fast handoff by reducing signaling all the way to the HA,
this falls in the domain of the handoff draft for v4.

It seems like a heavy weight idea for implementation, without clear
need.  Please comment.

Thanks,
Madhavi

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 19 Apr 2002 12:39:37 -0700

Hello Madhavi,

I think the problem statement is clear.  A method is needed by which
registrations can be localized.

Fast handoff does not solve this problem.  Every new attachment to
an access router still would need to deliver a binding update to
a home agent.

Regards,
Charlie P.

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Fri, 19 Apr 2002 17:29:04 -0400

Hi Charlie,

Thanks for the quick response.  

> registrations can be localized.

I agree that minimizing the long haul is needed.  However,
I'm not clear on why introducing a hierarchy and heavy weight 
changes to MIP entities is beneficial.  It imposes much
on a practical implementation.  

Dynamic 'local' home agent allocation could minimize the long haul 
without the new messages and much change to MN. 

I respectfully disagree that the problem statement is clear.

Regards,
Madhavi

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 19 Apr 2002 15:03:56 -0700

> on a practical implementation.

This is debatable.  It is possible to make good implementations
that don't take much code.

> without the new messages and much change to MN.

This is another technique.  It has advantages and disadvantages.
That doesn't mean the problem statement is unclear.  It more
means that there is another solution which may be more appropriate
for your constraints, but for a slightly different problem.  For
instance, your solution would not work for a host with a
statically allocated home address.  And yet I have no problems
with the solution to the other problem that you mention.  In fact,
I helped to work on it.

> I respectfully disagree that the problem statement is clear.

I hope this helps, and anyway I really think you are trying to
solve a somewhat different problem.

Regards,
Charlie P.

---

From: Milind Kulkarni <[email-masked]>
Date: Fri, 19 Apr 2002 15:14:42 -0700

I agree with Madhavi's opinion that the problem statement
is not very clear. There are only two perceived problem
this draft is trying to solve as per section 9:

9. Regional Registration Message Formats
   <cut>
   These messages are used by the mobile node instead of the 
   existing Registration Request and Registration Reply, in 
   order (1) to make registration work faster, and also 
   (2) to reduce network load for Mobile IP registration.

Argument #2 is very weak. While it may be good to localize
the registrations, it is probably just a small optimization.
However, all the extra messaging and work that the MN, RFA,
GFA need to do, doesn't address the root cause. After doing 
all this Regional registration messaging, the problem of 
hand-off remains, although the frequency of that may be 
slightly reduced.

What do others think?

Thanks,
Milind

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 19 Apr 2002 15:23:06 -0700

> hand-off remains, although the frequency of that may be

I guess I'm not "others", but anyway I have an opinion about it.

First, regional registration is not mandatory.  If your
product is not intended to be sold into a market that needs
it, you do not have to implement.

Second, there are many distinct techniques that each produce
some performance improvement.  You do not have to implement
all of them or any of them, but I don't believe that means
that the opportunity should be removed for those people who
may need the additional performance improvement.

Third, it's done.  It's not like we have to make a huge
investment to produce the technology.  We already have it.
There's no reason to prohibit people who want it from using it.

Fourth, regional registration does not reduce the frequency
of handover.  It only localizes the resulting signaling.

Regards,
Charlie P.

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 19 Apr 2002 17:43:01 -0500

Milind and Madhavi,
   Isn't it very late to raise the problem statement issue for reg-tunnel
draft? This draft has been around since so long and it in fact is rooted
on Charlie and others' research as early as 1998. Sorry to say, but what
have you been doing then?
   reg-tunnel draft for v4 and a similar one for v6 (at the expense of 
flaring up some early debates) are part of extensions to the base 
mipv4/v6 protocols for domain-based mobility.
   Let's go for them.
Regards,

 >>>>>to the WG discussion list.
--behcet

---

From: Milind Kulkarni <[email-masked]>
Date: Fri, 19 Apr 2002 16:10:24 -0700

Behcet,

Regarding being late on this draft, isn't that how things 
usually get done, during last minute? Just kidding :)

But that's not the point. IMHO the point is, better late 
than never. And the last-call email solicits comment by 
April 22 (which is still good 3 days away).

I am entitled to an opinion just like anyone else. And I 
am not sorry about expressing it. 

Regards,
Milind

Whatever

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Fri, 19 Apr 2002 23:54:06 -0400

Hi Behcet

It is certainly not our intention to undermine anyone's
research.  However, when a draft is to become an RFC, there
are implications for implementation.  At that point, it
is not that simple to say that one need not implement the RFC.

Thus, we are simply trying to understand the problem space 
that the regional tunneling draft is trying to solve.  It
seems to impose many changes to the existing MIP architecture, not
to mention, the mobile node.   Since an RFC will move this work
from research to deployment, we are trying to understand the
technical merits.  

We do apologize for the late nature of these comments.  However, 
I'm not sure that because our comments are late is reason to dismiss
them or the fact that this work has been going on since 1998 is 
reason to standardize it.  Hopefully, we can have a technical
discussion to address our comments.

I hope that you and Charlie can understand our position.

Regards,
Madhavi

P.S.  As I was not following the WG in 1998, I'm not sure that
what I was doing then is relevant.  However, if you are still
interested, do send me an email and I will be glad to elaborate.

---

From: "Dana L. Blair" <[email-masked]>
Date: Sat, 20 Apr 2002 07:59:55 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Behcet Sarikaya
> Sent: Friday, April 19, 2002 6:43 PM
> To: [email-masked]
> Subject: Re: [mobile-ip] WG Last Call:

Not really.  That's what last call is for.

> have you been doing then?

Personal comments like this question don't promote the exchange of
ideas.

I appreciate the research efforts of any individual because certainly
the internet has benefited from research.

However, internet drafts are about application.  Not all research is
implemented.

> mipv4/v6 protocols for domain-based mobility.

Unnecessary extensions.

If you'll define "domain-based mobility" in a new email thread,
we might be able to see how the base mobile IP RFCs and the
handover draft (with some possible updates) can solve the problem.

thanks,
Dana

---

From: "Dana L. Blair" <[email-masked]>
Date: Sat, 20 Apr 2002 07:59:51 -0400

I am trying to understand the problem this draft is addressing.

The Abstract:

   Using Mobile IP, a mobile node registers with its home agent each
   time it changes care-of address.  If the distance between the
   visited network and the home network of the mobile node is large,
   the signaling delay for these registrations may be long.  We propose
   a new kind of "regional" registration, i.e., registration local to
   the visited domain.  Regional registrations reduce the number of
   signaling messages to the home network, and reduce the signaling
   delay when a mobile node moves from one foreign agent to another,
   within the same visited domain.

From the abstract, seems like it is trying to limit the impact of
home agent round trip when the care-of address changes.

From the introduction:
By registering locally, the signaling delay is reduced, and this may
improve the performance of handover.

The only circumstances mentioned where the care-of address will change
and "MAY" produce the undesired "long" home agent round trip is handover.

I don't think we need an RFC that "MAY" fix a problem this is already being
addressed
by another working group draft,
draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt.

Looks to me like the purpose of this draft is to point out a problem that
occurs during handover.  So, if the handover draft is not addressing the
problem,
then the handover draft needs a little more work.

This draft shouldn't move to the next phase because it's not solving a
un-addressed
problem.  The handover draft should be updated (if it not already) to solve
the
problem.

thanks,
Dana

BTW, this draft is not listed in the Last Call section of the status page,
http://www.ietf.org/IESG/status.html.  If we are going to have a status
page it should be up to date.

> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Monday, April 08, 2002 4:31 PM
> Subject: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
>
>
> Folks,
>

---

From: "Dana L. Blair" <[email-masked]>
Date: Sat, 20 Apr 2002 07:59:52 -0400

> [mailto:[email-masked]]On Behalf Of Charles E.
> Perkins
> Sent: Friday, April 19, 2002 3:40 PM
> To: Madhavi W. Chandra
> Cc: [email-masked]

Under what circumstances is this method needed ?  The only circumstance
mentioned in the draft is handoff "MAY" need this in the introduction.

> an access router still would need to deliver a binding update to

Then the fast handoff draft needs more work.

The reg-tunnel draft should not move to the next phase.

thanks,
Dana

---

From: "Dana L. Blair" <[email-masked]>
Date: Sat, 20 Apr 2002 07:59:53 -0400

> Sent: Friday, April 19, 2002 6:23 PM
> To: Milind Kulkarni
> Cc: Madhavi W. Chandra; [email-masked]

Charles,

Under what circmstances does registration not work fast enough ?

Under what circumstances does the network load for Mobile IP
registration need to be reduced ?

This draft implies that Mobile IP is not scalable without
additional infrastructure elements.  I completely disagree with
this implication.

> it, you do not have to implement.

If the draft is solving a unique problem, then it may be useful.

However, if implementing the draft is optional,
and there is no circumstance where the option is needed,
then we don't need an RFC for the option.

> may need the additional performance improvement.

The case for performance improvement in a specific circumstance
has not been made in this draft.

> There's no reason to prohibit people who want it from using it.

By creating a draft that doesn't address any real world circumstance,
it looks like there is a problem with mobile IP when there is none.
This creates alot of confusion when it comes down to what protocols
and functions should be implemented. 

> of handover.  It only localizes the resulting signaling.

Looks like you are saying handover won't work without regional 
registration.  I disagree with this.  If there is an issue not
addressed by the handover draft(s), it should be fixed there.
No need for another RFC.

thanks,
Dana

---

From: "James Kempf" <[email-masked]>
Date: Sat, 20 Apr 2002 05:42:37 -0700

I think there is still a problem with HA registration latency regardless
of whether you optimize handoff. The handoff signaling optimizes out the
movement detection algorithm, RegReg optimizes HA registration latency.
So there are two different problems. That said, RegReg is one solution
to optimizing HA registration, there are other solutions that leverage
fast handoff somewhat better and therefore would require less mechanism.
The RegReg solution was concieved and developed prior to the fast
handoff algorithms, so it is not suprising that it did not consider this
possibility. There has been some (limited) implementation experience
with RegReg, much less with fast handoff, and none with leveraging fast
handoff for localized HA signaling, so I don't see a problem with the
RegReg draft as it stands, with perhaps the exception that Alan
O'Neill's comments about fixing how the CoA and GFA addresses are
distributed should probably be taken into consideration.

Would be interesting to compare a RegReg implementation for localized
registration to an implementation that leveraged fast handoff.

            jak

----- Original Message -----
From: "Milind Kulkarni" <[email-masked]>
To: "Madhavi W. Chandra" <[email-masked]>
Cc: "Charles E. Perkins" <[email-masked]>;
<[email-masked]>
Sent: Friday, April 19, 2002 3:14 PM
Subject: Re: [mobile-ip] WG Last Call:
draft-ietf-mobileip-reg-tunnel-06.txt

---

From: "James Kempf" <[email-masked]>
Date: Sun, 21 Apr 2002 02:58:40 -0700

So it sounds like there is some amount of opposition to this draft going
to draft standard, and there is also the possibility of an alternative
and maybe simpler solution leveraging fast handoff, though the details
of such a solution need to be fleshed out.

Would there be any objection to moving this to experimental, such as was
done with the MIPv4 fast handoff draft itself, until these issues are
resolved?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 22 Apr 2002 09:54:14 -0700

Hi Charlie,

> > movement detection algorithm, RegReg optimizes HA registration
latency.
^^^^
This line...

> - Fast handover has to do with the local address (IP access address,
>   care-of address, ...)
> - Regional Registration has to do with the home address.
> This is a fundamental and very interesting difference.
^^^^^^^^
...is exactly what you say here...

> This inference is untrue unless you assign very particular meaning
> to the phrase "the fast handoff algorithms".
^^^^^

...which is why I don't quite understand why you say this.

> Again, I believe that there is no easy comparison, and that the
answers
> will always depend on various parameters that are not naturally
related
> to each other.

Sounds like I need to write the draft.

            jak

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 22 Apr 2002 07:53:45 -0700

Hello Dana,

> additional infrastructure elements.  I completely disagree with

I didn't see that implication in the draft.  It wouldn't be something
that I would write, as you may guess.  The circumstances you
request are those for which the additional registration traffic
is undesirable.  For instance, it could be that an access network
has an Internet Gateway that is expensive for traffic in and out
of the network.

> then we don't need an RFC for the option.

Surely you didn't mean that.  Surely you can allow for the
existence of RFCs to specify features that you do not have to
implement.

The option is needed where systems can be made to have
better performance by localizing registrations.  Results have
been published to show this, and it's intuitively obvious.

> has not been made in this draft.

Are you arguing now for a "Performance Considerations"?
Does this go before or after the "IANA Considerations"?
Can you point to other Proposed Standards with such text?

> and functions should be implemented.

I'm not confused, and we have implemented systems where the
protocol improves performance.  You don't have to, and from your
comments I would guess you would not recommend doing so.

> addressed by the handover draft(s), it should be fixed there.

I did not say this.  I only say that handovers can work better and
less expensively with regional registration.  Furthermore, I very
much disagree that every issue with handovers needs to be solved
in one draft.  There are many techniques for improvement, and
they should (MUST, even!) be treated separately.

Regards,
Charlie P.

---

From: "Alpesh S. Patel" <[email-masked]>
Date: Mon, 22 Apr 2002 09:43:03 -0700

James,

I strongly support your thought of moving this contribution to
experimental stage for the time being. Let us evaluate some simpler
alternatives to the fast handoff problem, which is more realistic.

Thanks
Alpesh

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 22 Apr 2002 10:52:53 -0700

Hello Jim,

Thanks for your clarification.  I see now that you did not say
the thing I thought you said, and I agree with what you did say.

In my defense, I will offer that I had not yet coffee!  (that's
a lousy excuse!)

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 22 Apr 2002 09:49:04 -0700

Dana,

> Please clarify some confusion that I have and I know a few
> others have.
>
> When you say "such as was done with the MIPv4 fast handoff draft
itself",
> specifically which draft are you referencing ?  Please provide
> the full name of the draft.
>

It is, in fact, draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt. There
is
some question whether we need two handoff techniques, one of which,
from the experimental evidence, doesn't work very well if the mobile
node moves too fast. In order to clarify the situation, the authors, WG
chairs, and ADs have agreed to move it to experimental.

I see a similar situation with draft-ietf-mobileip-reg-tunnel-06.txt,
which
is why I made the suggestion. There are other techniques that may work
better, but we don't know yet.

> When I commented on draft-ietf-mobileip-reg-tunnel-06.txt, I suggested
> the problem should be solved in
> draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt which is not
> in experimental state as far as I can tell.
>
> Also, as Basavaraj as stated in a later email, I don't think this
> should move to experimental.  We may need to discuss it more.
> There may be some merit but we need to understand under what
> specific circumstances an extra layer of fixed heirarchy is needed.
>

Fine. I believe a draft is required about how to use the mechanisms in
draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt and forwarding
from previous care-of address for regional registration. I do not
believe that the description should go into
draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt itself because
that draft is already too big.

As for draft-ietf-mobileip-reg-tunnel-06.txt, I'm curious how many
people are really going to implement it. Is there any interest in
3GPP2 in it? This question was put for
draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt and the
answer was "no one", which was another reason why it
was taken to experimental.

            jak

---

From: "Dana L. Blair" <[email-masked]>
Date: Mon, 22 Apr 2002 10:26:30 -0400

> [mailto:[email-masked]]On Behalf Of James Kempf
> Sent: Sunday, April 21, 2002 5:59 AM
> To: James Kempf; Milind Kulkarni; Madhavi W. Chandra
> Cc: Charles E. Perkins; [email-masked]

When you say "such as was done with the MIPv4 fast handoff draft itself",
specifically which draft are you referencing ?  Please provide
the full name of the draft.

thanks,
Dana

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 22 Apr 2002 08:03:24 -0700

Hello Jim,

James Kempf wrote:

> possibility.

This inference is untrue unless you assign very particular meaning
to the phrase "the fast handoff algorithms".  There have been quite a
few fast handover algorithms, and the differences between them does
not materially affect their overall ability to interact with the regional
registration algorithm.  In other words, using fair terminology, the
designers of the Regional Registration draft _did_ consider the interactions

with fast handovers.  In fact, there is an interesting generalization that I

think I have discussed with you in the past:
- Fast handover has to do with the local address (IP access address,
  care-of address, ...)
- Regional Registration has to do with the home address.
This is a fundamental and very interesting difference.

Furthermore, the _manner_ in which the two techniques optimizes
the handover latency is _substantially different_.  While they are
harmonious and SHOULD work together, they are subject to different
constraints and fail or succeed separately.

                          ..........

> registration to an implementation that leveraged fast handoff.

Again, I believe that there is no easy comparison, and that the answers
will always depend on various parameters that are not naturally related
to each other.

Regards,
Charlie P.

---

From: Tom K Weckstrom <[email-masked]>
Date: Tue, 23 Apr 2002 00:53:58 +0300

Hello, all.

I join this thread rather late - it's 2002-04-23 here, but 2002-04-22
still somewhere on this globe, so I didn't miss the deadline,
right. ;)

On Mon, Apr 22, 2002 at 09:49:04AM -0700, James Kempf wrote:
> 3GPP2 in it?
---end quoted text---

I have been working around the regional registration, localised
mobility management, etc. since 1998 first in the Dynamics group and
later on at Lifix Systems and YES, we are still interested in
implementing the standard for regional registrations, especially, if
we can change it a bit before it gets to RFC. ;)

Dynamics group has implemented the regional registrations into the
current Dynamics - HUT Mobile IP implementation after a rather long
research and trial period. The protocol is definitely not identical to
the current proposal available in
draft-ietf-mobileip-reg-tunnel-06.txt. Please, read Jouni Malinen's
thesis from
http://www.cs.hut.fi/Research/Dynamics/publications/jkmaline_thesis.ps.gz to understand how Dynamics does regional registrations.

Lifix Systems is willing to move from the "Dynamics type" regional
registrations protocol to an RFC compliant solution, if we can agree
on the protocol to be standardised. We have good experiences on
localising the mobility management and also research results are
available.

More comments to follow.

Regards,
	Tom

-- 
Tom Weckström         <[email-masked]>          PGP id:  E1DB55E9
Lifix Systems Oy      <http://www.lifix.fi/>  Mobile: +358 50 350 5997
Yliopistonkatu 5       3rd floor               FIN-00100 Helsinki

---

From: Tom K Weckstrom <[email-masked]>
Date: Tue, 23 Apr 2002 02:48:29 +0300

Hello all.

My previous attempt with all the old emails did not pass the mailing
list policies (the email was over 40kB). I'll now retry with some
reduced amount of text.

---end quoted text---

I have read through the draft-ietf-mobileip-reg-tunnel-06.txt and have
a multitude of comments. Some of them I see in the v06 last call
thread already, some of them I mentioned in my previous email
regarding the last call of version 03 of this same draft in October
2000. Unfortunately, the playgorund's MIP archives only go back to
2001-02, so I had to include my previous concerns to this email. Some,
but only a few, of my concerns from 2000-10 have been corrected. The
authors did give justifications for the solution back in 2000, but I
still have open questions regarding the solution. For some issues I
noticed in 2000, I would not be so strict with my comments any
more. The attached emails are for a "small" history study. I'll soon
send my v06 comments in another email.

Regards, Tom

---

From: Tom K Weckstrom <[email-masked]>
Date: Tue, 23 Apr 2002 02:53:26 +0300

Hello.

Please, read the attached text file for my comments on
draft-ietf-mobileip-reg-tunnel-06.txt.

Please, consider this as a first stage and by no means exhaustive
"issue list". I'll get back with concrete proposals later this week.

On Tue, Apr 23, 2002 at 02:48:29AM +0300, Tom K Weckstrom wrote:
> a multitude of comments.

...

> I'll soon send my v06 comments in another email.
---end quoted text---

Regards, Tom

---

From: "Dana L. Blair" <[email-masked]>
Date: Tue, 23 Apr 2002 11:49:50 -0400

> From: Charlie Perkins [mailto:[email-masked]]
> Sent: Monday, April 22, 2002 10:54 AM
> To: Dana L. Blair

We need to explore the cases where it is desireable.

> has an Internet Gateway that is expensive for traffic in and out

What type of expense are you referring to ?

I don't believe the occassional mobile IP re-registration is
so expensive as to warrant a new layer of fixed heirarchy.
Is there some other traffic that would be too expensive ?

> existence of RFCs to specify features that you do not have to

I did mean that.  The circumstance that needs this is still not clear.
Without that we don't need a standard.  They only case that
is mentioned in the draft is handover, and it says "MAY" improve
performance.

> been published to show this, and it's intuitively obvious.

Performance by what criteria.  They typical criteria are:
CPU, Memory, Delay, Bandwidth.  You may have considered others.
Which criteria and under what circumstances is performance improved ?

No one is saying that a system can't implement the protocols and insert
a new layer of fixed heirarchy if the company chooses too.  Any company
is free to implement what they prefer.

But just because something is implemented, does not mean it should be a
standard.  We are discussing the merits for creating an IETF standard
which where benefits of implementing the standard should be obvious.
They aren't obvious or intuitively obvious with this draft.

But they could be if the right circumstance were described.

> Can you point to other Proposed Standards with such text?

No, I am not arguing for "Performance Considerations".  Your draft
is arguing for performance considerations.  From the Introduction:
" By registering locally, the signaling delay is reduced, and this may
  improve the performance of handover."

The draft is claiming that it MAY improve performance for handover.

If it doesn't improve performance then we don't need the draft.

I don't think it improves performance.

But even if it does, it should be in the handover draft.

Otherwise, the handover draft is incomplete.

> comments I would guess you would not recommend doing so.

You can sell your systems.  You don't need an rfc to accomplish
that.

> less expensively with regional registration.  Furthermore, I very

The handover draft is still a work in progress.  We should improve
that draft, not create another one.

> they should (MUST, even!) be treated separately.

If the handover draft was in rfc status, then I might agree.
But it's not.  We need to get handover working to the satisfaction
of the interested parties.  Anything that we know that makes handover
better should be in the handover draft.  At this point I am not convinced
that this draft makes handover better.

thanks,
Dana

---

From: Tom K Weckstrom <[email-masked]>
Date: Fri, 26 Apr 2002 17:28:53 +0300

Hello all.

---end quoted text---

My time ran out for sending the concrete proposals I promised
during this week, so here we go. In a nutshell:

- Clarify the draft so that there is one way to implement the solution
  (the MUST features) and then try to clarify the different options
  around the MUST solution. The current -06 version offers sooo many
  possibilities. Also some optional features may be removed
  altogether, e.g. MN registering directly to the GFA.

- I propose a signaling, where upon the handoff, ony one registration
  request is sent and only one reply is sent back. This is how
  Dynamics - HUT Mobile IP works when a hierarchical model is
  deployed. The details of the messages can be left for future
  discussion. The current message design from v. -06 can be used
  mostly. As an addition, the FAs need to learn about their children
  in the tree. The draft can propose manual configuration, or an
  automated registration protocol for FAs. This has also been
  implemented by Dynamics Group, so just copy that working solution to
  the specs. The use of BUs (ala route optim.) as it is done in the
  current rdaft can be allowed, if zero packet loss is of high
  importance, but to me it is an additional plus that itself should
  not be used as an integral part of regional
  tunneling/registrations. I know, why it is used as an integral part
  at the moment, but it does not need to be so, if the FAs know their
  children in the tree.

- Reach for backwards compatibility:
	- Advertise a single care of address (the GFA address)
	- RFC 3220 compliant implementations would benefit from
          regionalised registrations, but GFA would always handle the
          handoff as a crossover FA.
	- If complete transparency is desired, there is an issue with
          nonce based replay protection. We have to work this out.

- Give "candy" for those who implement the necessary extensions to
  their clients:
	- An intelligent client would add a PFAN type extension to
          tell the hierarhcy, the previous FA through which it
          registered. --> Faster handoffs handled lower in the hierarchy.

- Make a list / matrix of conflicting proposals, so that we can see
  where the prolems are. The current discussion about the need of the
  draft, etc. can also be lifted to the next level.

- Specify the way to distribute keys between GFA, the RFAs and the
  FAs. Again, an implementation and specification about this is
  available in http://www.cs.hut.fi/Research/Dynamics/

I hope this gets the discussion further and to a generally acceptable
-07 version of the draft.

I'll be on vacation next week, but I'll check the thread and give
further comments as soon as I return. I'll be happy to help in
defining the next version of the draft.

Best regards, Tom

-- 
Tom Weckström         <[email-masked]>          PGP id:  E1DB55E9
Lifix Systems Oy      <http://www.lifix.fi/>  Mobile:  +358 50 350 5997
Innopoli 2	      Tekniikantie 14	      FIN-02150 Espoo

---

From: "Emad Qaddoura" <[email-masked]>
Date: Fri, 26 Apr 2002 20:53:53 +0200

Tom,

You stated below " The use of BUs (ala route optim.) as it is done in
the
  children in the tree."

Since the regional registration adds more delays to the overall scheme
of MIP registrations, then, in my view, a route optimization should be
an integral part and not optional. MIP as it is in 2002 is not with zero
packet loss, and this draft would make it even with more packet loss.
This may classify MIP as a mobility protocol for NON-REAL time
applications. I have been off the list for sometime, I was not aware if
this has been already the classification for MIP? 

What would be the impact on TCP dependent applications when the delay
prolongs due to regional registrations? May be someone can clarify?

Therefore, this draft or others, should always take into consideration
the impact on packet loss and SHOULD always minimize it.

Thanks,
EQ

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tom K
Weckstrom
Sent: Friday, April 26, 2002 4:29 PM
To: [email-masked]
Cc: Charles E. Perkins; Annika Jonsson; Eva Gustafsson
Subject: Re: [mobile-ip] WG Last Call:
draft-ietf-mobileip-reg-tunnel-06.txt

Hello all.

---end quoted text---

- Give "candy" for those who implement the necessary extensions to
  their clients:
	- An intelligent client would add a PFAN type extension to
          tell the hierarhcy, the previous FA through which it
          registered. --> Faster handoffs handled lower in the
hierarchy.

Best regards, Tom