Subject: Re: [nemo] NEMO RO Problem

From: "Fan Zhao" <[email-masked]>
Date: Mon, 11 Oct 2004 23:52:45 -0700 (PDT)

Dear Carlos,

Sorry about the delay. Please see my reply in line.

Best regards,
fan

> Dear Fan,
> 
> 	Thanks for your reply. Please see, some comments in-line
> 
> El vie, 08-10-2004 a las 06:42, Fan Zhao escribi=F3:
> > Not really. In the very extreme case where HA is located on the 
routing
> >  path between the location of CN and the location of MR, the route 
taken
> >  by the traffic in NEMO Basic Support is the same as the =93optimal 
route=
> =94
> >  according to the definition in the document.
> 
> 	OK, you are right. I was thinking in terms of overhead too ...
>
That is right. I agree.
 
> > Assume that there are n CNs scattering around the Internet, which 
means
> >  that there is no one single CR topologically close to all CNs. If MR
> >  performs the RO functions with all the CN/CRs, the overhead (the 
number
> >  of tunnels and states) in MR is O(n). By choosing HA as CR for all 
these
> >  n CNs, MR just needs to maintain one tunnel with HA.=20
> >=20
> > On the other hand, from the perspective of CR, if there are m MRs
> >  belonging to the same home network scattering around the Internet,
> >  because of the same reason, CR may also choose to forward the 
traffic to
> > HA rather than each MR. So HA play dual roles, both CR and HA here,=20
> > though we may only put emphasis on one over the other before.=20
> 
> 	Yes, but if the traffic is sent to the HA, that's the operation 
of the
> NEMO Basic Support protocol, without RO, isn't it? I agree that there
> may be scenarios in which performing RO would be worse than not
> performing it, so there is a tradeoff.
>
Yes, you are right.
 
> >=20
> > These are all about the tradeoff. Even though MR has to go though its 
HA,=
> =20
> > because the traffic forwarded by this MR is aggregated to one=20
> > destination, from the parent MR point of view the number of CNs 
(The=20
> > child MR acts as one of MNNs.) is reduced, the better route than that 
in=20
> > NEMO basic support is still possible because the parent MR could 
perform=20
> > RO function.=20
> 
> 	I don't understand this sentence (sorry about me poor 
understanding
> ;->). Do you mean, in a nested NEMO, going only through a single HA, as
> a kind of RO?
>
The RO solution should allow each MR to decide whether it performs RO 
or not independently. When all MRs perform RO, the best route is formed.
I will address it more in the next version.  
 
> > If I understand correctly, you are talking about the sub-optimal 
route=20
> > when VMN performs MIP6 RO. Is it right? IMO, NEMO RO solution should 
not=20
> > make any change to protocols running on MNN. Maybe it sounds too 
solution=
> -
> 
> 	I completely agree that a general and global NEMO RO solution 
should
> not (if possible) change the protocols running on MNNs. But, OTOH, I
> think that besides having such a solution, perhaps it will be worth also
> to study some additional mechanisms, fully compatible with the "NEMO
> global RO solution", that may enhance the performance for some MNNs.

That will be very interesting. Any thoughts?  

> 
> 	Thanks a lot.
> 
> 	Kind Regards,
> 
> 	Carlos J.
> 
> > specific, what NEMO RO can do is to let MR broadcast the information 
of=20
> > NEMO RO capability (Not very great, still require the interaction) 
or=20
> > even better I see the possibility that NEMO RO can both keep the=20
> > transparency and remove the sub-optimal route caused by MIP6 RO. So 
I=20
> > strongly feel we should introduce the changes only to MR/CA/HA, one 
level=
> =20
> > above MNN. Note that CA includes the case of NEMO-aware CN.=20
> > =20
> > > 	Thanks a lot.
> > >=20
> > > 	Kind regards,
> > >=20
> > > 	Carlos J.
> > >=20
> > >=20
> > > >=3D20
> > > > Sincerely,
> > > > fan
> > > --=3D20
> > > Carlos Jes=3DFAs Bernardos Cano - http://www.it.uc3m.es/cjbc/
> > > GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40
> > >=20
> --=20
> Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/
> GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40
>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 12 Oct 2004 13:18:27 +0200

Dear Fan,

> That will be very interesting. Any thoughts?  

	Well, maybe now it's too soon to address this issue, but the point is
that there will be likely some interesting solutions that will be worth
to look at. One example is what Pascal has pointed out, but there can be
many others, e.g. based on prefix delegation, MIPv6, etc...

	Regards,

	Carlos J.
	
-- 
Carlos Jesús Bernardos Cano - http://www.it.uc3m.es/cjbc/
GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40