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

From: [email-masked]
Date: Mon, 22 Apr 2002 00:23:11 -0500

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: Charlie Perkins <[email-masked]>
Date: Mon, 22 Apr 2002 09:41:14 -0700

Hello Jim and Basavaraj,

James Kempf wrote:

> Raj,
>
> Dana has already expressed his opposition to it going forward as
> standard, based on his belief that the function it is trying to perform
> can be performed with considerably less mechanism using the fast handoff
> techniques

As I tried to explain in my last note, these techniques are different,
and solve different problems which are both related to handover
performance.  Handovers are affected by a number of factors, and
it's not appropriate to expect that every factor will be solved by
the same mechanism.

>
>            I certainly believe we need to continue the discussion, and
> support that, but I also believe there is enough question about the
> draft's value as a standard that we should consider other avenues for
> publication.

Publication as Proposed Standard is appropriate, because the work
has been done, implemented, and shown to work.

>                                                   The only concern is that
> it may serve
> as a precedent for Mobile IPv6, where the issue is more important, due
> to the lack of a large installed base. I'm categorically opposed to
> introducing any hint of VLR-like functionality into  Mobile IPv6
> networks unless there is no other way to provide the functionality and
> it is critically needed.

It is important to keep regional registration separate from Mobile IPv6,
and from Mobile IPv4 for that matter.  I don't think anyone is suggesting
that such protocol become mandatory to implement.

If the protocol is done, works, and is useful for some systems, then
that is enough reason for publication.  If your Mobile IPv6 system
does not need it, then you should not put it in -- nor would anyone
expect you to do so.

Also, characterizing the solution as "VLR"-like is prejudicial
and inaccurate in my opinion.  VLRs are a lot different, and
only become similar at a very very high level view.

Regards,
Charlie P.

---

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

Raj,

techniques. I certainly believe we need to continue the discussion, and

My own feeling is that the fast handoff techniques and forwarding from
previous care of address for those mobile nodes that don't implement the
fast handoff techniques can, in fact, perform the functions in the draft
with considerably less mechanism, but, of course, we need a draft to
describe how. The mechanisms outlined in the draft introduce a VLR-like
functionality for Mobile IP, and they will require expensive
infrastructure to support it, because it will require replication to
provide reliability, and such equipment is always expensive. I really
don't want to see such functionality introduced into IP networks.
However, just as with route optimization, I don't believe that this
draft will see widespread deployment, because the basic infrastructure
for Mobile IPv4 is pretty much set, even though the draft doesn't
require changes in other IP nodes. The only concern is that it may serve
as a precedent for Mobile IPv6, where the issue is more important, due
to the lack of a large installed base. I'm categorically opposed to
introducing any hint of VLR-like functionality into  Mobile IPv6
networks unless there is no other way to provide the functionality and
it is critically needed.

                jak

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Sunday, April 21, 2002 10:23 PM
Subject: RE: [mobile-ip] WG Last Call:
draft-ietf-mobileip-reg-tunnel-06.txt

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Mon, 22 Apr 2002 14:44:20 -0400

Hi Charlie and Raj,

On Mon, Apr 22, 2002 at 09:41:14AM -0700, Charlie Perkins wrote:
> performance.  
> Handovers are affected by a number of factors, and

Agreed, that not all scenarios will be solved by the same mechanism.

I am still grappling, however, with what exact scenario the regional
registration solution will 'benefit'.  I guess much of my doubt stems
from trying to weigh the performance benefit of reg. registration with
the implementation overhead.  Reg. Registration is now introducing
another single point of failure (namely, the GFA)...requiring much
more awareness in the MN...adding another MIP element....  

As I remarked in another email, it is not as easy to say that the RFC
doesn't have to be implemented after it takes on a life as a standard.
Thus, it may be prudent to reevaluate the applicability of the
regional registration draft with respect to developments in MIP since
it's inception.  For all I know, it may be the case that the regional
registration draft is alleviating an issue that cannot otherwise be
addressed by FH or dynamic home agent allocation.  It just seems to me
that the latter two mechanisms will provide a solution that will no
longer make the long haul signaling to the HA a major issue.

> and from Mobile IPv4 for that matter.  

This will be hard to do...especially for MIPv4.  Standardizing the
regional registration draft has an implicit suggestion that base MIP
needs added architecture.  Even though it may not be explicitly stated
anywhere, it will no doubt be the message that is conveyed.
Otherwise, customers/vendors may wonder why a regional registration
draft is needed.  

> I don't think anyone is suggesting

True.  However, as a community that is trying to get MIP 'off the
ground', we should be careful about what we standardize so as to not
complicate the MIP protocol...or at least, ensure that there is a real
need for the added architecture.

Regards,
Madhavi

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 22 Apr 2002 14:12:42 -0500

Hello Madhavi,
  You seem to be constrained by the present deployment of MIPv4 which 
seems to be only in 1XRTT networks, at PDSN nodes, etc.
  In order to apply LMM to these architectures another level needs to be 
added to create a regional organization of PDSN routers or the like, 
which of course will not happen.
   By keeping FAs at the edge of the network, the 3G architectures are 
achieving part of what LMM is trying to do anyways.
  The above is certainly great, but does not in my opinion mean that WG 
should limit its work into this architecture and state-of-art (or should 
it, Raj?).

  I think this is the issue being raised by the problem statement 
questioning people.

Regards,
Madhavi W. Chandra wrote:

--behcet

---

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

Hello Madhavi,

> Agreed, that not all scenarios will be solved by the same mechanism.

O.K.  The direct implication of this is that not all systems
have to implement the same protocols.

> more awareness in the MN...adding another MIP element....

Performance improvements always come at the cost of additional
implementation.  So, I think they should be considered optional,
except where the health of the Internet is at stake.  For systems
where the performance improvement is immaterial, the implementation
cost should not be undertaken.  The scenarios where regional
registration provides benefits are those where localized signaling
is important for cost reduction (if traffic across the Internet
gateway is expensive for any reason).  It is also possible that
some systems may not be amenable for inclusion of fast handover
techniques, and in such circumstances the regional registration
would be helpful although not as good as regional registration
plus fast handover.

> doesn't have to be implemented after it takes on a life as a standard.

I don't believe this, and to the extent that it ever becomes true
it is a problem.  I think that protocols should always be implemented
based on the requirements of the underlying system.

> longer make the long haul signaling to the HA a major issue.

Dynamic home agent allocation is a lot more complicated that
regional registration, and carries with it a lot of other
implications (e.g., on domain names).  Fast handover is, in a
word, different.  I truly hope that we can get to an understanding
of the applicability of multiple different but non-competing solutions.
That way, we can get the best possible performance for handover
systems.

> needs added architecture.

I do not like this formulation.  Every protocol has a particular
realm of applicability.  Mobile IPv4 is just fine for a wide range
of applications.  Regional registration extends that to still more
scenarios.  That doesn't mean that the original protocol is at all
inadequate for the range of applicability it was designed for.  And,
conversely, it doesn't mean that we should be inhibited from finding
solutions to apply mobile networking techniques in places where
Mobile IPv4 doesn't work as well.  It's not a slur on Mobile IPv4.
I'm not a person who would do that!

>                       Even though it may not be explicitly stated

Then, I guess we need to make that clear in the draft.  That way,
anyone who wanted to know why the protocol was needed, would just
have to look at the protocol document to see why.

> need for the added architecture.

This protocol does not complicate RFC 3220, for the reason that it
is not part of RFC 3220 and is not mandatory.  It will only matter
for systems where people find that signaling volume and latency
and cost are problems to be reckoned with.  It could be that the
majority of Mobile IPv4 implementations will not have that problem.
I don't see this to be at odds with getting Mobile IPv4 started!

Regards,
Charlie P.