Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sat, 24 Mar 2001 01:40:27 +0100

Another late reply

> >         Your proposal relies on using the GMA's address
> >         which is the same address management as the MAP
> >         in Extended mode.
> > 
> > > >         So what's the justification for the additional cost
> > > >         and overriding the routing protocols ?
> 
> I believe we are not overriding routing protocols any more than you
> are, once we compare with your extended mode.
> 
	=> ??? I don't get that. Multi-level hierarchy forces packets
	into a fixed route between levels. I don't know what you mean ??
	Extended mode != multi-level hierarchy.

> > > Better optimization of last hop bandwidth usage, network-controlled
> > > load balancing (your scheme has hop count and priority in a MAP
> > > option, these trust MN does something it may not be designed to
> > > do and require more than one MAP options to make a choice even
> > > possible).
> > >
> >         => Are you referring to the MAP option ?
> >         I hope this is not the BW argument. This argument is
> >         not valid IMO. RAs are designed to have several
> >         options regardless of the use of MIP. I hope we can agree on that.
> 
> We can still try to reduce the size of the RA, i.e. number of extensions
> needed for a load-balancing network.
> 
	=> Jari, have you read the draft ? What load balancing 
	extensions are you referring to ? The load balancig described
	in the draft is something else. Have a look at rev 2 or 3.

> >         Now regarding the parameters in the MAP option,
> >         I don't see what the MN would have difficulty with.
> >         If the MN supports HMIPv6 then it MUST understand
> >         the option. If it does something wrong, like choosing
> >         a MAP with a 255 preference (indicating that it should
> >         not be used), the MAP will simply reject the BU.
> >         What's the problem with that ?
> 
> You rely on the MN to behave correctly. Also, you do not specify
> the load balancing, you need external box to do that. 
> 
	=> See above

	regards,
	Hesham

---

From: "Jari T. Malinen" <[email-masked]>
Date: Tue, 27 Mar 2001 01:41:14 -0800

Hesham,

Sorry for late response due to mail problems..

>         Extended mode != multi-level hierarchy.

It seems to resemble a multi-level hierarchy, at least for packets
going to previous MAP address or when using nested mobile routers.

In extended mode MN is dislocated as compared to both the fixed and
mobile MAP. The mobile node needs to let the lower MAP to know how
to route packets to MN. Consider packets coming from CN to old RCoA
(CoA registered with CN before MN can register new CoA after lower
MAP moved). The packets get re-routed from HA of the mobile MAP to
wherever the mobile MAP moved, taking them to the higher MAP since
this should hold the RCoA for the lower MAP. It will consume the
routing header of a route-optimized packet. Now the packet's destination
address will be home address of the MN in the mobile network.
Could you clarify routing to this address, re-capsulation through
lower MAP or perhaps by host-based routing?

A second case to consider is when MN can recursively be a mobile
router. There is a need for a host-routing protocol or recapsulating
tunneling to navigate packets through nested mobile networks.
Using MAP as the connection point of mobile networks looks essential
to the method of getting packets to these nested networks thus fixing 
packets to pass MAPs.

>         in the draft is something else. Have a look at rev 2 or 3.

You introduce load balancing in the most recent draft in a different role,
let me re-phrase my word load-balancing as signaling load balancing.

Considering RA size in IPv6 and cost of last mile bandwidth it is
in our requirements advisable trying to avoid extending it further.
If we can do with one extension and still distribute signaling load,
it extends scalability the bigger the visited domain.

>         Hesham

Best Regards,

-Jari