Subject: RE: [mobile-ip] Last Call: Regional Tunneling input

From: "Alan O'Neill" <[email-masked]>
Date: Wed, 24 Apr 2002 02:14:44 -0400

Hi Annika, comments in-line

-----Original Message-----
From: Annika Jonsson [mailto:[email-masked]]
Sent: 23 April 2002 00:03
To: Alan O'Neill; [email-masked]
Subject: Re: [mobile-ip] Last Call: Regional Tunneling input

Hi Alan,

I have read your suggestions, and I have a few comments.

First, regarding the dynamic allocation of HA: we do support that in the 
current draft. We assume that it is the GFA that participates in the 
authentication procedure as AAA client and not the FA (see section 3.1.2). 
The reason for this is that it is the GFA that acts as FA towards the HA, 
and therfore needs the keys for securing registration messages. So, in this 
way, a AAA server can dynamically allocate an HA, and the GFA will be 
informed about this.

AWO> My draft was written from 05 so I'll reread ok and come back on this

Second, the problem with how to handle different addressing plans between 
FA - GFA and GFA - HA. I agree that this should be supported. Let's see if 
I understand your suggestion correctly:
* The GFA address advertised in the Agent Advertisement should be the 
"local" address of the GFA, where it can be reached from the FA.
* A Home registration from a MN should never include any CoA address
* The FA sends the registration req. on to the GFA "local" address
* The GFA allocates CoA to the MN
* The GFA IP extension (forget the name change for now...) should be used 
to transport the selected CoA to the HA and to carry the selected CoA back 
to the MN, as is already the case in the draft.

I agree that dynamically allocating the CoA is the best way, and it seems 
resonable that this is the responsibility of the GFA and not the FA. But, 
the reason why we didn't specify that all MN:s must use that method is that 
we wanted to be backwards compatible wiht HA:s that does'nt specifically 
support Regional registrations (or rather, the GFA IP extension). If MN:s 
are allowed to put the CoA in the Registration request, the HA will never 
need to know that the visited network uses regional registrations, and the 
GFA will look like a normal FA. I still think this is a good feature.

AWO> Yes - I appreciated your motivation.

To allow this, the FA must advertise a publicly routable GFA (CoA) address. 
If the FA and GFA belongs to a private address domain, the FA needs to have 
a mapping from the public CoA address to the private GFA address that it 
should use to send the Registration request to. I think this solves the 
problem.

To summarise, I suggest that we:
* clarify that dynamic allocation of CoA is preferable
* add that the FA might use another address to communicate with a GFA than 
the CoA advertised, and that it in that case needs a mapping between these 
two addresses
* change the allocation of CoA and use of the GFA IP address extension, by 
saying that it is the responsibility of the FA to select GFA, but not to 
include any GFA IP extension, because it is the responsibility of the GFA 
to allocate CoA, and it will add the GFA IP extension.

Do you agree that this solves the problems you raised?

AWO> Not really as this only addresses the case of the MN moving in a
private domain underneath a GFA with a single public interface. When the GFA
has multiple interfaces with a mixture of public and private, or when the
local domain is the public domain and the GFA has a private interface then
it still breaks down. For your scheme to work you need the FA to have
extensive address mapping knowledge. This is essentially also impossible to
achieve when the GFA has multiple interfaces with different address blocks
towards HAs. The FA does not know what to advertise to the MN because it
cannot know which GFA interface the MN RREQ will need to traverse before
seeing the RREQ, and by then it is too late if the MN has already put a GFA
CoA into the CoA field. So to be generally applicable I realy think that the
CoA field should always be zero and that the GFA should insert the GFA CoA
for the HA. 

Now this means that an upgraded HA can always tell if an initial home reg
came via a GFA...a good thing in my book.
Unfortunately, a legacy HA will fail this reg - again a good thing in my
book..more pressure on IT department/operator to upgrade the HA. Remember,
the HA and MN share a unique relationship and having them on widely
different MIP versions for any length of time is somewhat perverse to me.
What is therefore missing is to enable the GFA to insert the assigned GFA
CoA into the RREP for the MN if the HA failed to do so. The second attempt
can therefore still succeed to the legacy HA. Each refresh under the same
GFA also works and we only have a problem again on each GFA change-over
whilst the MN and HA are on such different versions...

Alan.

/Annika

At 22:23 2002-04-15 -0400, Alan O'Neill wrote:
>Below is the abstract for the draft that makes last call suggestions on
>Regional tunneling.
>
>see
>http://search.ietf.org/internet-drafts/draft-oneill-mip-regtun-mods-00.txt
>
>Abstract
>
>    Regional Registration modifies the normal MIP Registration signalling
>    back to the HA so that the signalling can traverse an intermediate
>    Gateway Foreign Agent (GFA). The registered binding is between the Home
>    Address (HoA) and the GFA Care-of Address (GFA-CoA) in the Home Agent
>    (HA), and between the GFA-CoA and the Foreign Agent (FA-CoA) in the
GFA.
>    Two extensions are defined to support this new Registration processing
>    these being the Hierarchical Foreign Agent extension (HFAext) and the
GFA
>
>    IP address extension (GFAIPext). The former is used to carry the FA CoA
>    to the GFA and the latter is used by the FA to allocate a GFA to the
MN,
>    and by the FA, GFA, HA to securely return the GFA IP address to the MN.
>
>    The present processing rules for the HA registration enable the FA to
>    advertise the GFA to the MN in a Foreign Agent Advertisement (FAA) and
>    for the MN to include that GFA address into the CoA field of the MIP
home
>
>    Registration. This however assumes a number of things about the GFA
>    address in the FAA and the addressing realms between the FA-GFA and
GFA-
>    HA.. Specifically, the GFA CoA and the GFA IP address must potentially
be
>
>    from two different addressing plans and hence cannot be in the same
FAA.
>    This draft describes the issues and suggests a solution that requires
>    slight modifications to the required extensions, that generalises the
>    Home Registration signalling for arbitrary intermediate MIP nodes, and
>    only slightly modifies the processing rules for the MIP Home
>    Registration. This draft also describes a way to support dynamic HA
>    allocation along-side Regional Registrations.

---

From: "Dana L. Blair" <[email-masked]>
Date: Wed, 24 Apr 2002 07:59:36 -0400

snip...

> book..more pressure on IT department/operator to upgrade the HA.

I don't think it's good when protocols deployed to potentially millions
of devices are not backward compatible.  You are making an implicit
assumption about common administration of the MN, FA, GFA, and the HA
by the same entity (IT department, ...).  This is not a valid
assumption for internet connectivity.

Remember,
> different MIP versions for any length of time is somewhat perverse to me.

Disagree for the same reasons again.  If the base mobile IP protocol
is broken (and I don't belive it is), then we should fix it before
it gets too widely deployed.  Otherwise, changes to the MN, FA, and
HA functionality MUST be backward compatible.  I don't believe
introducing a new and unecessary layer of fixed heirarchy
is important enough to break backward compatiblity.

The necessary test for this draft should be backward compatibility.
But that may not be sufficient to warrant a new RFC.

thanks,
Dana

---

From: Annika Jonsson <[email-masked]>
Date: Thu, 25 Apr 2002 15:37:19 +0200

Hi Alan,

see below...

>CoA field should always be zero and that the GFA should insert the GFA CoA

I think that you misunderstood me (or I you). What you say here is more or 
less what I meant. The only difference is that I still think that an FA 
could in most cases advertise a GFA CoA. This should be a public address, 
sort of a "default CoA", that an MN MAY use, e.g. if it's HA doesn't 
support the GFA IP extension. By specifying that an MN SHOULD set the CoA 
field in the Registration request to zero, that method will be used in most 
cases. I agreed that we could change so that the FA only forwards the 
registration to the GFA, and the GFA selects CoA, and adds the GFA IP 
extension.

I don't think that this requires the FA to have an extensive mapping 
knowledge. It needs to know the address to use to send the registration 
request to the GFA, but you can never get away from that.

I hope this is clearer.

/Annika

---

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

Annika,

	My main concern about this draft:

1) Has there been any studies/scenarios about the impact to in-flight
traffic to the MN, while it is performing regional re-registrations? 

2) How does the old FA handle the data that is received while the MN
re-registers with a new FA? 

3) I understand this is not any worse from the normal (in 2002) case
without regional registrations, but the case below can make such delay
longer.

From Section 5.0, 4th paragraph, 
"If the advertised GFA is not the same as the one the mobile node has
   registered as its care-of address, and if the mobile node is still
   within the same domain as it was when it registered that care-of
   address, the mobile node MAY try to perform a regional registration
   with its registered GFA. If the foreign agent cannot support
   regional registration to a GFA, other than advertised, the foreign
   agent denies the regional registration with code UNKNOWN_GFA (see
   section 9.3).  In this case the MN has to do a new home registration
   via the new GFA."

As you see, there is extra registration step here,( if the current GFA
used by the MN is not supported by the FA), adding possible delays to
traffic, would it be reasonable to expect all FAs in the same domain to
handle the regional registration to the different GFAs. Or do I
misunderstand the above paragraph?

With the route optimization draft being optional extensions, we should
be concerned about any additional delays to traffic destined to the MN.

Thanks,
EQ

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Fri, 26 Apr 2002 11:30:55 -0400

Annika,

> misunderstand the above paragraph?

This seems to also be the case when the MN sets the CoA=0.0.0.0,
and the HA doesn't support Regional Registrations...two RRQ trips
if the MN attempts to register again with a non-zero CoA.  
Can you please comment on this as well?

Thanks,
Madhavi

---

From: Ståle Olsen <[email-masked]>
Date: Fri, 26 Apr 2002 13:51:29 +0200

I have been trying to get an overview over the different solutions for the MN.

I've found the following:

    1. Cisco points to a Third party vendor called Birdstep.com
    2. Intel seems to be puting something on the market rigth now.
    3. There are several Unix/linux implementations.

Any feedback on where i / we can find a real good MS alternative until they implement it them selfs would be great !!  :)