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

From: "Ahmad Muhanna"<[email-masked]>
Date: Fri, 19 Apr 2002 18:25:00 -0500

Hello Charlie;
I am sorry you may have come across this point before but I hope you have a
quick answer.

In section 1. Introduction of this draft it says:
"
   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].
"

Now: as per RFC3220, FA are required to set the 'F' bit in Agent
advertisement as per section
2.1.1.
"
   An Agent Advertisement message MUST NOT have the 'B' bit set if the
   'F' bit is not also set.  Furthermore, at least one of the 'F' bit
   and the 'H' bit MUST be set in any Agent Advertisement message sent
"

Also, in RFC3220 section 2.1.1. It is required to have at least one care-of
address
when the 'F' bit is set.

"
      Care-of Address(es)

               The advertised foreign agent care-of address(es) provided
               by this foreign agent.  An Agent Advertisement MUST
               include at least one care-of address if the 'F' bit is
               set.  The number of care-of addresses present is
               determined by the Length field in the Extension.
"

On the other hand, (in section 3.3.) this draft says that the 'I' bit MUST
be set to support
the regional tunneling management. It also continues to say that IF the
'I' bit is set, there MUST be at least one care-of address in Agent
Advertisement.
However, it say that this care-of address could be set to ZERO.

Now:
Here is the conflict:

A Foreign Agent which supports regional tunneling management MUST support
registrations according to Mobile IPv4 [9]. In other words, this FA MUST set
both the 'F' and 'I' bits.
I hope you agree.

The problem is that you override the requirement of RFC3220 " Which is a
MUST"
by allowing the FA to set the only included care-of address to ZERO.

A legacy Mobile Node which does not support regional tunneling management
will
not be able to register with this FA.

Please let me know of what you think?
Thanks for consideration.

Ahmad Muhanna

---

From: "Ahmad Muhanna"<[email-masked]>
Date: Fri, 19 Apr 2002 20:32:25 -0500

Hello Charlie;
one more thing.

DO we need section 6?

I thought that there is a new draft which also address GNAI for the AAA use.
draft-ietf-mobileip-aaa-nai-00.txt

Can not we add FA-NAI subtype to the this draft and get rid of
section 6?

Regards; 
Ahmad Muhanna 
Nortel Networks

---

From: "Ahmad Muhanna"<[email-masked]>
Date: Mon, 22 Apr 2002 11:25:41 -0500

Hi Annika;
I believe that any solution for optimizing the Mobile IP protocol
must address the issue of backward compatibility until we come up
with a clear and permanent solution for this issue.

Please see more comments inline. 

Regards;
Ahmad Muhanna

> Hi
> see my comments below...
> >registrations according to Mobile IPv4 [9]. In other words, 
> this FA MUST 
> >set both the 'F' and 'I' bits.
> >I hope you agree.
> 
> Yes.
> 
> Correct.
> You are right. If a FA is configured not to address any CoA, 
> it will not 
> support "pure RFC 3220" MN:s. It is up to the administrator 
> of the network 
> to decide if this is OK or not. We want to support backwards 
> compatibility, 
> but we also want to support optimisations, and that's why the draft 
> includes both options.
> 

Good point. However, you are putting the blame on the end user (carrier)
while
I believe that a robust protocol will avoid enabling the end user to 
unintentionally block all RFC3220 compliant MN, It is a standard too!!. 
I thought we are optimizing RFC3220 anyway.
I do not see any point of having this option available. Why the care-of 
Address needs to be set to Zero in Agent Advertisement message.

One more very serious issue in this regard:
In section 3.3:
"
   If the `I' bit is set, and there is only one care-of address, it is
   the address of the GFA. When only the GFA address is present, and
   thus the local foreign agent is not advertising its care-of address,
   the FA-NAI (see section 7.2) SHOULD also be present to enable the
   mobile node to determine whether or not it has changed foreign agent
   (so that a new regional registration may be initiated).  The mobile
   node also uses the FA-NAI to decide whether or not it is in its home
   domain.  The decision is based on whether the realm part of the
   advertised FA-NAI matches the mobile node's realm.  If the `I' bit
   is set, and there are multiple care-of addresses, the first care-of
   address is the local FA, and the last care-of address is the GFA.
"
If the FA is advertising Only one Care-of address, it is the GFA Care-of
Address, 
this means that All Legacy MN will never detect that they were handing over
to a new FA
since they do not understand the FA-NAI extension and the care-of address in
the 
Agent Advertisement is always the same.

Thanks;
Ahmad

> /Annika

---

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

Hi Annika;
I am resending this message for the second time. It never made it to the
mailing list.

Regards;
Ahmad Muhanna

Thanks;
Ahmad

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Mon, 22 Apr 2002 11:57:58 +0200

I agree. There's no reason for jumping to experimental at
this point. Regional registrations are used as part
of a Fast Handoffs4 solution (as explained in Low Latency
v4 draft), but that's different from saying that they're
solving the same problem or that fast handoffs provides
an alternative to regreg. In any case the authors are
in the best position to clarify the problem statement
and it is premature to draw conclusions.
/Karim

-----Original Message-----
From: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Sent: 2002-04-22 07:23
Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt

James,

Obviously the authors of the draft need to address the concerns that
have been raised by WG members. Lets not jump the gun and simply
go forward with making this I-D an experimental RFC. I do not believe
that will be of any real value. Lets continue this discussion some more
and give the authors a chance to clarify the problem statement as well
as other details. And if we see that there is no WG consensus after
that,
we can drop the I-D (or make it experimental if the WG wants to do so).

-Basavaraj

> 
> 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: "Ahmad Muhanna"<[email-masked]>
Date: Mon, 22 Apr 2002 13:22:58 -0500

Hello Charlie;

I assumed that you already read the discussion of all backward compatibility
issues that I have raised earlier. That what I meant by affecting existing
Mobile Ipv4 
implementation.
On this thread at least 5 issues been identified to cause backward
compatibility issues 
with Mobile Node and Home Agents.

I hope I made myself clear.

Regards;
Ahmad Muhanna

> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Monday, April 22, 2002 1:11 PM
> To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
> Cc: [email-masked]
> Subject: Re: [mobile-ip] WG Last Call:
> draft-ietf-mobileip-reg-tunnel-06.txt
> 
> 
> 
> Hello Ahmad,
> 
> >> It is important to keep regional registration separate from
> >> Mobile IPv6,
> >> and from Mobile IPv4 for that matter.  I don't think anyone
> > 
> > I respectfully disagree. Your proposed solution in this 
> draft affects existing
> > Mobile IPv4 implementation in many aspects!!!
> 
> How do you mean that?  Regional agents can handle existing Mobile IPv4
> mobile nodes -- the mobile nodes just can't then use regional 
> messages.
> Mobile nodes that run the new protocol do not disturb other mobile
> entities.  If the home agent supports the ability to handle the
> non-mandatory extensions for zero care-of address, then the mobile
> node can use this feature.  If not, then the mobile node can either
> not use regional registration.  This would be a matter for 
> preconfiguration
> just as with the mobile security association.
> 
> The regional registration protocol is a new protocol, with new
> messages and extensions, that works well with Mobile IPv4.
> If there was a way to do it with Mobile IPv4, then we wouldn't
> have to make the draft.  Otherwise, aren't changes required in
> at least some implementation somewhere?
> 
> Regards,
> Charlie P.
>

---

From: "Alan O'Neill" <[email-masked]>
Date: Thu, 25 Apr 2002 22:34:50 -0400

Thanks Dana,

Nice explaination, but I don't see enough justification in this
email for a "regional element".

AWO> There isn't nor was intended to be..

Please be aware that I am open to the idea of a "regional element".
However, there must be specific scenarios which have obvious
improvements over current MN, FA, and HA relationships to warrant
an internet standard.

Also, I would hesitate to suggest modifications to a draft which itself
has questionable merit as a standard.  Maybe you should start from
scratch with what you really need instead of creating various
modification drafts.

AWO> That is also happening but understand that when I started this (pre
last call) that RegTun was already there with unknown future status so
ignoring it would have been somewhat arrogant and unfair to those authors
methinks...

Alan

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Alan O'Neill
> Sent: Wednesday, April 24, 2002 2:15 AM
> To: Annika Jonsson; Charles E. Perkins; Madhavi W. Chandra; James Kempf;
> [email-masked]
> So I thought given the thread I would add some higher layer
> thoughts behind
> Flarions interest in this draft and respond to some of the other comments
> raised. I do so coming from an intial viewpoint of seeing
> absolutely no need
> for regional registration for MIP...so am a slightly converted strong
> sceptic..as you will see below.
>
> Firstly, I agree with many that avoiding additional points of failure and
> the cost/benefit of regional registration makes its usefulness
> debatable...
> I agree that the hand-off aspects of this draft should be split
> out into the
> hand-off work and that additional work is required on the 'home signaling
> via regional node plane' to address some of the technical issues,
> especially
> regarding backwards compatibility and GFA CoA assignment (see my previous
> response to Annika on the latter and Ahmeds excellent analysis on the
> former). Even then, (if I was a neutral), I think I would say
> that we would
> need to see more deployment demand to progress the mechanisms in
> this draft
> on standards track.
>
> However, Flarion has one of the more challenging environments for
> MIPv4 and
> we will deploy something, sometime, somewhere soon (hopefully in huge
> volumes ;-) In reviewing a lot of MIP work in anticipation of that
> deployment, reviews that are still ongoing and for obvious reasons
> commercially sensitive at this time, it is apparent that there are some
> missing bits. We plan to continue to write these up and submit them
> following discussions and agreement with our core router partners and
> customers to then hopefully trigger standards activity where necessary.
> RegTunMods and RevTunMods were the first two such drafts and there will be
> others unrelated to regional tunneling...
>
> One such missing bit appears to be the need to be able to advertise the
> existence of a regional element (the 'I' bit) to the MN, to
> detect when that
> element has changed and to register to a home agent via each new regional
> element. We specifically have little interest in the RFA, in the regional
> element being a GFA and in the regional registration to the GFA itself. My
> analysis of, and feedback on, the RegTun draft in [RegTunMods]
> was motivated
> simply by the desire to be able to re-use the home registration regional
> extensions and hence co-exist with GFAs that might already have been
> deployed. I am open-minded about them getting deployed, but very
> unhappy if
> the general regional element capability is lost or eventually not
> standardised.
>
> I can and will elaborate much further on these points in suitable
> drafts as
> soon as I am able. This will hopefully be a matter of days or at
> worst a few
> weeks. In the absence of that justification and information I would be
> supportive of the draft being revised and taken to experimental. I would
> however recommend that we try to separate out the home signaling via a
> regional element, from the type of regional element and its features, as I
> think (well know :-) they are distinct. A generalised address carrier with
> sub-types can be used to transport addresses up and down that signalling
> plane and be used to trigger address type specific processing..ie
> a GFA CoA
> sub-type means do GFA type things. I think this redesign is a
> good idea even
> just for GFA as who knows what future requirements will come upon us (ours
> aside) and nailing up a general capability is unfortunate. This address
> carrier should maybe be defined in a separate draft.
>
> I also believe that the regional element should be able to be in
> the core or
> at the edge as alluded to by other responders, although ours will
> likely be
> in the core much to the horror of some of you no doubt. I wouldn't do it
> though unless I thought it was absolutely necessary...believe me.
>
> I think we should also finally recognise the extensive and excellent work
> that has gone into RegTun, and await both suitable revisions and then
> vendor/customer interest before committing this to standards track.
>
> Regards,  Alan.
>
>
>
>
>
>
>