Subject: Re: [MOBILE-IP] WG Last Call - (draft-ietf-mobileip-reg-tunnel-03.txt)

From: Gopal Dommety <[email-masked]>
Date: Tue, 10 Oct 2000 23:55:09 -0700

Hello Eva, Annika, and Charlie:

Couple of questions/concerns regarding the reg-tunnel-03.txt

1. What is the fundamental reason for introducing  new  regional registration request/reply messages. I think
this is unnecessary introduction of new message types.

        a) You are using extensions for the initial registration through the GFA. You could as well use the extensions
for achieving regional registrations.

        b) In fact your version 02 of the draft (draft-ietf-mobileip-reg-tunnel-02.txt) does not have these new messages.

Unless there is a good reason, I think you should use extensions. Using existing messages with extensions makes
implementation easier and cleaner (we have seen that in implementing anchor handoff draft draft-dommety-mobileip-anchor-handoff-02.txt).

2. What is the implementation of the current version of the Draft (not the previous versions)?

Thanks
Gopal

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 11 Oct 2000 21:10:54 -0700

Hello Gopal,

> this is unnecessary introduction of new message types.

We puzzled over this for quite a while, more than one time.
There is discussion about the reasons for the change in
Appendix A.  We think that processing is very much more
natural for the case when there are separate message types,
instead of extensions to the existing messages.  Clearly,
making extensions to the existing messages would have
the effect of introducing a lot of additional case analysis
into existing code for handling RFC 2002 registration
messages.  There are other reasons, as mentioned in the
draft appendix, related to allowing for non-disclosure of
foreign agent hierarchies.  This is especially true for multiple
levels of hierarchy.

It's not a simple issue.

>  a) You are using extensions for the initial registration through the GFA. You could as well use the extensions for achieving regional
> registrations.

That is different, because the initial registration _is_ a home registration.

> b) In fact your version 02 of the draft (draft-ietf-mobileip-reg-tunnel-02.txt) does not have these new messages.

We couldn't make it work very well that way in all cases, as I've alluded to already.

> implementation easier and cleaner (we have seen that in implementing anchor handoff draft draft-dommety-mobileip-anchor-handoff-02.txt).

On the contrary, I really think that using new messages makes the implementation
easier and cleaner, exactly because then the implementation does not have to build
up as much global state and case analysis.  Furthermore, as I have mentioned already,
there are cases that cannot be handled as easily with extensions.  I think that the
protocol needs to handle all cases as best it can do.

> 2. What is the implementation of the current version of the Draft (not the previous versions)?

We have an implementation.  I have heard of others, which of course I don't
want to disclose without permission.  Maybe we should try for an interoperability
test.

Regards,
Charlie P.

---

From: Gopal Dommety <[email-masked]>
Date: Wed, 11 Oct 2000 22:35:47 -0700

Charlie,

1.  If you can perform a global registration via the hierarchy with out requiring new messages, it is
possible to do regional reg without introducing the new messages.

2. The difference between the reg and global registration should be where the registration finally gets processed and reg reply is generated (i.e, in one case the it goes through the GFA to the HA and gets processed there, in the regional case
it is processed by the common GFA between the old and the new paths - if more than two levels of hierarchy is employed)..

3. The reasons you have given in the Appendix for introducing new messages are given below:

                -  a mobile node must be able to distinguish
                            between regional registrations and home
                            registrations, because when it uses
                            regional registration, the nounces are not
                            synchronized with its home agent;

                         -  a mobile node can use a zero care-of
                            address either to request a GFA (in a home
                            registration) or to signify the use of an
                            unspecified regional foreign agent (in a
                            regional registration).

Both these can be equally easily handled with the extensions approach.

>into existing code for handling RFC 2002 registration

Could you give concrete examples of the cases that cannot be handled by
an extension.

>foreign agent hierarchies.  This is especially true for multiple

don't see why multiple hierarchies is a problem.

moreover, if we are employing multiple hierarchies, if will apply to the home registration also.

>That is different, because the initial registration _is_ a home registration.

It should not be, other than the fact who is supposed to processes the message and the extensions.

>there are cases that cannot be handled as easily with extensions.  I think that the

could you provide concrete examples of what cases cannot be handeled?

Regards,
Gopal

---

From: Madhavi Subbarao <[email-masked]>
Date: Thu, 12 Oct 2000 10:48:00 -0400

Hi Charlie,

I'm also perplexed with the introduction of new message types.
Version 2 of your draft using extensions seemed like a more viable
approach.  Just curious...why wouldn't a MN be able to distinguish
between a regional registration and home registration by extensions
and flags?

Maybe your concrete examples will shed some light.

Thanks,
Madhavi

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 12 Oct 2000 09:38:55 -0700

Hello Gopal,

I regret to say that this is a bit more additional work than I can
schedule to do this week.  I'll try to make this effort next week or so.

Regards,
Charlie P.