Subject: RE: [mobile-ip] RE: [mobile-imp] WG Last Call: draft-ietf-mobilei p-reg-tunnel-06. txt

From: "Ahmad Muhanna"<[email-masked]>
Date: Mon, 22 Apr 2002 14:14:24 -0500

Hi Annika;

You are proposing a solution for a specific problem. 
You are making this great claim that this solution supports existing Mobile
IPv4 implementation. 

"
   Foreign agents that support regional registrations are also required
   to support registrations according to Mobile IPv4 [9].  If there is
   a foreign agent address announced in the Agent Advertisement, the
   mobile node may register that foreign agent care-of address with its
   home agent [9].  
"

Not only this, BUT you also make another great claim without demonstrating
HOW!!!
"
   For mobile nodes that cannot process a NAI, or with mobility agents
   that are not configured to advertise their NAI, regional registration
   is still useful, but the lack of certain features may result in less
   than optimal results.
"

On the other hand, it seems that you assume that the whole network will 
be upgraded at the same time to accommodate your solution.

We are dealing with at least three different entities, MN, FA, and HA. you
added another one GFA.
There is a great absolute possibility that those entities do not belong to
the same operator.
Unless your draft addresses clearly how these entities would know what the
others support in reference
to what you are proposing or offering a smooth solution without violating
the existing entities,
there will continue to be backward compatibility issues and your first claim
is not justified.

I hope I made myself clear here in order to address these backward
compatibility issues.

Regards;
Ahmad Muhanna

> 
> 
> Hi,
> 
> you are right in all cases, but it only matters in one case 
> in my opinion. 
> It is the difficult balance between backwards compatibility 
> and optimisations.
> 
> That the GFA IP extension and zero CoA field is not backwards 
> compatible is 
> obvious, but this is an optimisation, since it is better for 
> the visited 
> network to be able to allocate GFA and CoA dynamically. I 
> think we should 
> allow this, but not as the only solution. That is why I would 
> like to keep 
> the possibility for the MN to include the CoA address in my answer to 
> Alan's suggestions.
> 
> The first issue that you bring up is more critical, namely 
> what happens if 
> a HA doesn't support these new extensions? The 
> "UNSUPPORTED_EXTENSION" 
> doesn't exist, as you say. So the HA will probably answer 
> with e.g.  128 
> reason unspecified, or 129 administratively prohibited , or 
> 134 poorly 
> formed Request. We should correct this, and clarify that if 
> the MN receives 
> such a reply, it should try to send a new registration using 
> the advertised 
> CoA.
> 
> /Annika
> 
> 
> 
> At 22:35 2002-04-21 -0500, Ahmad Muhanna wrote:
> 
> >Well, me too. I am not sure what I was doing in 1998.
> >
> >I believe the scope of this discussion is really absolutely too late.
> >However, I would like to continue to raise technical issues about
> >this draft which mostly related to backward compatibility.
> >
> >In section 4.4: Home Agent Considerations:
> >
> >Issue No. 1:
> >"
> >    A Registration Request that does not contain a GFA IP Address
> >    extension or a Replay Protection Style extension is processed
> >    by the home agent as described in [9].  If the home agent
> >    receives a Registration Request with one of these extensions,
> >    and the home agent does not support the extension, the home
> >    agent must return a Registration Reply with the Code value set to
> >    UNSUPPORTED_EXTENSION [9].
> >"
> >
> >This section mandates that a legacy HA rejects any 
> Registration Request which
> >contains a GFA IP Address extension or a Replay Protection 
> Style extension 
> >with
> >an error code of UNSUPPORTED_EXTENSION. Where is the 
> backward compatibility
> >here. Also, it references RFC3220 while RFC3220 does not 
> have an error 
> >code of
> >UNSUPPORTED_EXTENSION.!!!
> >
> >Issue No. 2:
> >"
> >    If a home agent receives a Registration
> >    Request message with the care-of address set to zero, and a GFA
> >    IP Address extension, it MUST register the IP address of the GFA
> >    as the care-of address of the mobile node in its mobility binding
> >    list.
> >"
> >
> >This section also mandates that a legacy HA to accept a 
> Registration Request
> >with Care-of Address set to zero and a GFA IP Address 
> extension and to 
> >include
> >the GFA IP address as the care-of address in the binding table.
> >Is this backward compatible solution!!!!!
> >
> >Issue No. 3:
> >"
> >If a home agent
> >    receives a Registration Request message with the care-of 
> address set
> >    to zero, but no GFA IP Address extension, it MUST deny 
> the request
> >    by sending a Registration Reply message with the Code 
> field set to
> >    ZERO_CAREOF_ADDRESS (see section 8.4).
> >"
> >
> >This section also mandates that a legacy HA rejects a 
> Registration Request
> >which contains a care-of address field of zero by sending a 
> Registration 
> >Reply
> >message with error code of ZERO_CAREOF_ADDRESS.
> >Again, where is the backward compatibility here or we are 
> asking all carriers
> >to update their HAs in order to be standard compliant by not 
> supporting this
> >feature!!!
> >
> >I hope that there is someone out there who have an answer 
> for these issues.
> >
> >Regards;
> >Ahmad Muhanna
> >
> >
> 
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 22 Apr 2002 12:48:29 -0700

Hello Ahmad,

I'll try to make some answers here.

>    mobile node may register that foreign agent care-of address with its

This is O.K., right?  What does it mean, "great claim"?

>    is still useful, but the lack of certain features may result in less

If the mobile node cannot process NAI, then it can still do regional
registration.  Why not?  Also, isn't it better to write down where
additional configuration at the mobility agents can help to get the
best results?  I think it's better to fully explain as much as possible
here.

> be upgraded at the same time to accommodate your solution.

Not true!  It is possible to mix regional foreign agents with regular
foreign agents, and so on.

> We are dealing with at least three different entities, MN, FA, and HA. you

Well, if you don't have a GFA, then you don't have regional registration.
Do you mean to suggest otherwise?

> There is a great absolute possibility that those entities do not belong to the
> same operator.
> to what you are proposing or offering a smooth solution without violating the
> existing entities,

As far as I can remember, regional registration has been targeted mainly
at domains (regions) operated by the same operator.  Maybe there are
more considerations with multi-operator domain, but that really was not
on our radar.

> I hope I made myself clear here in order to address these backward

I think that the places where new features are enabled by mechanism that
is not able to be parsed by RFC 3220 mobile nodes should not necessarily
be given as examples of the lack of backward compatibility.  Mobile nodes
that don't do regional registrations should be able to be served by
foreign agents that do offer regional registrations in addtion to
home registrations.  I am not aware of a place in the draft that would
make this untrue.

Mobile nodes that wish to use regional registration with foreign agents
that do not support it, will not succeed.  Mobile nodes that wish to use
zero care-of addresses with home agents that do not support it, will
not succeed.  Mobile nodes that cannot use advertisements unless the
advertisement contains a care-of address, cannot register with a
foreign agent that does not offer a care-of address.  These are not
examples of backward incompatibility.  After all, to take the latter
case, if the foreign agent doesn't offer a care-of address, it just
is not running RFC3220, presumably for some good reason from the
perspective of the local operator.  The mobile node that only run
RFC3220 should just cannot use that foreign agent.

We have attempted to preserve backwards compatibility, while allowing
the regional registration to offer new features and thus extend to
scenarios where RFC 3220 would not work anyway.  That has to be
considered O.K.

Regards,
Charlie P.