Subject: [nemo] My simple thoughts on HAHA

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Nov 2004 19:23:57 +0100

HAHA is a method for MR to change its HA from a remote one to a closer 
one.  It implies that paths from CN to MR's HoA are changed from 
reaching the oldHA to reaching the newHA.  These changes are presumably 
done with a dynamic routing protocol.  HAHA also involves synchronizing 
the BCs of the two HAs such as to both know the current MR's CoA.

HAHA is presumably justified _only_ if the IP distance CN-oHA + oHA-MR 
is much longer than CN-nHA + nHA-MR.  Add to this that the IP distance 
oHA-nHA must be small in order to allow for route updates to not explose 
routing tables.  The distances CN-oHA and CN-nHA are potentially both 
much larger than the distance oHA-nHA, which should be small.

To me, this means that: if you can use route updates to update paths to 
MR, and if the new paths are _much_ shorter, then use this and there is 
no need to use Mobile IP too.

Any comments greatly appreciated, take this as my humble oppinion, and 
also note that there was/is a similar but still very different effort 
within mip4 WG (Dynamic Assignment of the HA) to which I contributed 
some discussion and on some points I've learned from them. 
http://www.atm.tut.fi/list-archive/MIPv4/msg00043.html

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 18 Nov 2004 15:00:50 +0900

Hello Alex

Thanks for comments.

At Wed, 17 Nov 2004 19:23:57 +0100,
> the BCs of the two HAs such as to both know the current MR's CoA.

I believe you read the global-HAHA draft.

> is much longer than CN-nHA + nHA-MR.  

Yes for path improvement.

> Add to this that the IP distance oHA-nHA must be small in order to
> allow for route updates to not explose routing tables.  

Can you clarify this?
The distance of oHA and nHA is not critical.

> no need to use Mobile IP too.

When HA propagates the home network prefix to the Internet, the route
entry is never changed unless HA changes its address. (The route is relatively stable).
On the other hand, the path to MR is changed according to MR's movement.
Propagation of route updaes from MR is not doable. We still need MobileIP. 

> http://www.atm.tut.fi/list-archive/MIPv4/msg00043.html

Thanks for reference.

regards,
ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Nov 2004 10:51:01 +0100

Hello Ryuji, thanks for your remarks.  I have some remarks, see below.
I agree with you half half.

Ryuji Wakikawa wrote:
>> HAHA is a method for MR to change its HA from a remote one to a 
>> closer one.  It implies that paths from CN to MR's HoA are changed
>>  from reaching the oldHA to reaching the newHA.  These changes are
>>  presumably done with a dynamic routing protocol.  HAHA also 
>> involves synchronizing the BCs of the two HAs such as to both know
>>  the current MR's CoA.
> 

Yes.  I think my remarks pertain to both drafts (HAHA and global HAHA).

>> HAHA is presumably justified _only_ if the IP distance CN-oHA + 
>> oHA-MR is much longer than CN-nHA + nHA-MR.
> 

Is there another justification and need for HAHA other than path
improvement?

> Can you clarify this? The distance of oHA and nHA is not critical.

Thanks for asking.  I have a set of remarks that I usually give when
discussing HAHA, but it's a bit long.  Feel free to skip.

I think the IP distance between oHA and nHA must be small in order for
route updates to take be able to take effects.  I mean the IP distance,
and not the physical distance.  IP distance is the number of IP hops.
The larger the IP distance, the smaller chances are that you can use
route updates.

Obviously, one can have oHA and nHA very far away physically (different
continents) but still very close in terms of IP, maybe even neighbours.
  One can also have oHA and nHA near each other but with very long IP
distances between them.

In my oppinion, it is on these apparent contradictions that HAHA relies.
  On one hand it says: because you're in London you're obviously closer
to London HA than Melbourne HA (physical distance), on another hand it
assumes both HAs are close in IP terms (such as route updates are possible).

>> To me, this means that: if you can use route updates to update 
>> paths to MR, and if the new paths are _much_ shorter, then use this
>>  and there is no need to use Mobile IP too.
> 
> 

Ok, I see.  But there must be two routes of this kind of stable route,
no?  There must be one stable route towards the HoA proxy-ND'ed by oHA
and another stable route towards the HoA proxy-ND'ed by nHA, no?  And
packets from CN to the MR must actually be duplicated to both of these
paths, no?

> On the other hand, the path to MR is changed according to MR's 
> movement. Propagation of route updaes from MR is not doable. We still
>  need MobileIP.

I agree that route updates from MR is not doable.  I agree we need
Mobile IP.

What I mean is that if we use Mobile IP (and not route updates) then
HAHA (route updates between oHA and nHA and BC sync) can not bring any
significant benefit in path improvement.  The distances CN-HA and HA-MR
are potentially much larger than the distance oHA-nHA (the one that is
reduced).

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 19 Nov 2004 05:08:20 +0900

Hello Alex

At Thu, 18 Nov 2004 10:51:01 +0100,
> I agree with you half half.

:-)

> Is there another justification and need for HAHA other than path

Yes, of course.
You can check the presentation slide presented in NEMO WG.
http://www.mobilenetworks.org/nemo/ietf58/slides/ 

> assumes both HAs are close in IP terms (such as route updates are possible).

Which route updates are you talking about?
Binding synchrnoization or route update for the home network prefix?

> and another stable route towards the HoA proxy-ND'ed by nHA, no?  And

what is HoA proxy-NDed? 
HA only advertise the whole mobile network prefix to the Internet.
Among HAs, they may exchange route of certain MNP.

> packets from CN to the MR must actually be duplicated to both of these

duplication? no.

> significant benefit in path improvement.  The distances CN-HA and HA-MR

AFAIK, You statement is wrong:-p

> are potentially much larger than the distance oHA-nHA (the one that is

For example, with HAHA, MR supposes to associate with the closer
HA. It means HA-MR distance becomes shorter. CN's packet will be
interecepted by the nearest HA from CN. Thus, CN-HA path gets shorter.

There is another operation to bypass oHA-nHA tunnel.  MR associates
with the closer HA (nHA) and uses it for deliverying packets to the
Internet.  On the other hand, MR receives packets meant for its MNP
tunneled by the closer HA of CN.

path from MR to CN
MR - HA =============> CN
          tunnel

path from CN to MR
MR <==============HA - CN
      tunnel

regards,
ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Nov 2004 22:34:55 +0100

> Hello Alex

Hey Ryuji!  Thanks for your answers.  If I'm not clear somewhere, please
tell me.

> Yes, of course. You can check the presentation slide presented in 
> NEMO WG. http://www.mobilenetworks.org/nemo/ietf58/slides/

These slides spell to me "Load Balancing and High Availability and
Optimal Paths (RO) are all goals of HAHA".  Am I wrong?

If I am not wrong then I'd suggest:
-make sure HAHA targets load balancing and thus remove all reference to
  HAHA from the Problem Statement draft or
-make sure HAHA targets RO, keep HAHA in the RO PS draft, and remove
  Load Balancing and High Availability from the slides you reference
  above.

The PS draft should not describe HA Load Balancing problems, no?

>>>> Add to this that the IP distance oHA-nHA must be small in order
>>>>  to allow for route updates to not explose routing tables.
>>> 
>> Thanks for asking.  I have a set of remarks that I usually give 
>> when discussing HAHA, but it's a bit long.  Feel free to skip.
>> 
>> I think the IP distance between oHA and nHA must be small in order 
>> for route updates to take be able to take effects.  I mean the IP 
>> distance, and not the physical distance.  IP distance is the number
>> of IP hops. The larger the IP distance, the smaller chances are
>> that you can use route updates.
>> 
>> Obviously, one can have oHA and nHA very far away physically 
>> (different continents) but still very close in terms of IP, maybe 
>> even neighbours. One can also have oHA and nHA near each other but 
>> with very long IP distances between them.
>> 
>> In my oppinion, it is on these apparent contradictions that HAHA 
>> relies. On one hand it says: because you're in London you're 
>> obviously closer to London HA than Melbourne HA (physical 
>> distance), on another hand it assumes both HAs are close in IP 
>> terms (such as route updates are possible).
> 
> 
> Which route updates are you talking about? Binding synchrnoization or
>  route update for the home network prefix?

Route updates that update the routes towards MNP and route updates that
update the routes towards HoA.  Not the Binding Sync messages.

>>>> paths to MR, and if the new paths are _much_ shorter, then use 
>>>> this and there is no need to use Mobile IP too.
>>> 
>>> 
>>> When HA propagates the home network prefix to the Internet, the 
>>> route entry is never changed unless HA changes its address. (The 
>>> route is relatively stable).
>> 
>> Ok, I see.  But there must be two routes of this kind of stable 
>> route, no?  There must be one stable route towards the HoA 
>> proxy-ND'ed by oHA and another stable route towards the HoA 
>> proxy-ND'ed by nHA, no?  And
> 
> 
> what is HoA proxy-NDed?

A stable route towards the Home Address for which the new Home Agent is
entitled to do proxy Neighbour Discovery.

> Among HAs, they may exchange route of certain MNP.

The HA advertises the super-prefix (/48 home link out of which /64s are
derived) to the Internet.  This super-prefix can not change when the MR
attaches to a new HA.  Do we agree on this?  May I call this the Home
Network model? (not the Extended Home Network model).

I do not see why oHA and nHA would exchange routes (actually nHA sends a
route update to oHA) towards MNP.  oHA and nHA exchanging MNPs is
worthless if these MNPs are not advertised towards the Internet too.

>> packets from CN to the MR must actually be duplicated to both of 
>> these paths, no?
> 
> duplication? no.

Ok!  We agree!  So a packet from CN towards a fixed Home Address will
take a unique definite path, it won't be multicasted.  This path must
lead to one HA.  If one needs to modify this path to lead to another new
HA, then a route update in the Internet is necessary, no?

>>> movement. Propagation of route updaes from MR is not doable. We 
>>> still need MobileIP.
>> 

Me too.  Route updates from MR, or from HA, or from CN to the Internet
can probably not cope with the number of MRs and the number of routers
in between.

>> What I mean is that if we use Mobile IP (and not route updates) 
>> then HAHA (route updates between oHA and nHA and BC sync) can not 
>> bring any significant benefit in path improvement.
> 

To me, it's simply right.  If one uses Mobile IP it is because numerous
path updates in the Internet are not possible (the path updates that
would be generated by numerous mobiles moving around).  If path updates
_are_ possible, then Mobile IP is not needed.  Why would one update a
path, and at the same time bother to use MR-HA tunnels?

>> are potentially much larger than the distance oHA-nHA (the one that
>>  is reduced).
> 
> For example, with HAHA, MR supposes to associate with the closer HA.

It is useful for MR to associate with the closer HA _only_ if this HA
can also intercept packets addressed from CN to the HoA that was valid
at the old HA, no?

> It means HA-MR distance becomes shorter.

Yes, the path nHA-MR may be shorter than oHA-MR.  However, it is not
enough for _that_ path to be shorter in order to be beneficial.  RO does
not look at shortening the HA-MR paths, but at CN-MR paths.  SO you want
the path CN-nHA-MR to be much shorter than the path CN-oHA-MR.  The path
oHA-nHA must be small such as to allow for route updates (if route
updates, not BC syncs, are used between HAs) are used.  If HAHA
eliminates that short oHA-nHA path then there is no benefit in using it
because it is much smaller than what the CN-HA or HA-MR paths may become.

> CN's packet will be interecepted by the nearest HA from CN.

This assumes that your nHA is nearer the CN than the oHA, and at
the same time that the nHA is nearer the MR than the oHA, and at the
same time that a Home Address is reachable at both HAs.   Am I right?

Or does it only assume that whatever HA is closer to CN can intercept a
packet towards HoA and forward it to the current HA?  If this is what
you meant, then all HAs must be able to intercept a certain HoA and at
the same time when this inter-HA forwarding takes place it induces new
angles to the multi-angular paths.

This one-HA-close-to-any-CN-and-wherever-MR-goes may also be possible in
some closed system.  This is a possibility indeed.  It still stays a
small system.

> Thus, CN-HA path gets shorter.

Yes, it may be shortened by 1 or 2 IP hops with a total distance of 10
hops.  Like RO reducing the path from 10 hops to 9 hops.  I don't think
the PS draft should look into these solutions, it's too much effort for
too little achievement.

> path from MR to CN MR - HA =============> CN tunnel
> 
> path from CN to MR MR <==============HA - CN tunnel

Great!  So we end up with a smaller triangular routing, not the maximum
triangular routing CN-HA-MR.  This looks to me like an intermediate step
on an RO scale.  The goal of RO should be to have straight paths MR-CN,
not through some other HA, even if closer, no?

If you do this little triangle, why would MR bother to bind its HoA to
its CoA at nHA?  It would not need to send binding updates at all to
nHA, just tunnel packets to CN, no need of Mobile IP, no?

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 19 Nov 2004 15:16:17 +0900

Hello Alex

At Thu, 18 Nov 2004 22:34:55 +0100,
> Optimal Paths (RO) are all goals of HAHA".  Am I wrong?

Yes. 

>   Load Balancing and High Availability from the slides you reference

Thanks for input. 

Let me clarify what authors are trying at this point.
We try to separate the HAHA draft after we got comments that HAHA
has too many things in single draft. Thus, we first define the base
specification (protocol part) in the haha-protocol and protocol usage
and operations into another draft (haha-globa is just one of).  We
couldnot complete other operational drafts for loadbalance/redundancy
at this point.

> worthless if these MNPs are not advertised towards the Internet too.

I think what you miss here is that each HA advertise the same
super-prefix to the Internet. The route for the same prefix is
advertised from different network. For example, packets from CN1 may
reach to oHA, but others from CN2 may reach to nHA. Please refer the
base spec ( draft-wakikawa-mip6-nemo-haha-spec-00.txt) for more info.

> HA, then a route update in the Internet is necessary, no?

No... Since multiple HAs have the same super-prefix and advertise the
same prefix to the Internet.

> can also intercept packets addressed from CN to the HoA that was valid

Alex, HoA is never changed on the HAHA.
Even if each HA is located at different links, this is transparent to MR.

> because it is much smaller than what the CN-HA or HA-MR paths may become.

Well, as I wrote in previous mail, the path between CN and MR can be
different in each direction. From CN->MR, you can use CN-oHA-MR path
if it is shorter. In other direction, you can use MR-nHA-CN if it's
shorter, too.

> same time that a Home Address is reachable at both HAs.   Am I right?

Yes.

> angles to the multi-angular paths.

This is YES, too. This is already specified in the HAHA-global draft.
You don't need ProxyND to intercept packets for NEMO, since packet is
intercepted by using routing table.

> the PS draft should look into these solutions, it's too much effort for

I can not agree with this argument.
How many hops you can reduce totally depends on topology (where HAs
are configured).

> not through some other HA, even if closer, no?

If HA is on the path from CN to MR, it is not critical except for
tunnel. (But most of RO solution relies on tunnel).
In the current Internet, many packets are routed through one of IXP.
If HA is located at IXPs, the redundant path can be kept minimum.

When HA is just on the way to MR from CN, do you see critical overhead?

> nHA, just tunnel packets to CN, no need of Mobile IP, no?

MR basically sends single BU to HAs all the time.
That's why we introduce binding synchronization in HAHA.

regards,
ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Nov 2004 11:46:26 +0100

Ryuji, thank you for replies, it is good to know.

Ryuji Wakikawa wrote:
> Let me clarify what authors are trying at this point. We try to
> separate the HAHA draft after we got comments that HAHA has too many
> things in single draft. Thus, we first define the base specification
> (protocol part) in the haha-protocol and protocol usage and
> operations into another draft (haha-globa is just one of).  We 

Ryuji it seems to me this is a good approach.  It is good to split in
spec and usage documents.  HAHA as I understand it is a protocol that
may solve some problems within some systems.  The HAHA base spec may
specify a benefit-agnostic universal protocol and the HAHA usage drafts
may exemplify what are its RO benefits, its Load Balance benefits, its 
Multi-Homing benefits on a per-item basis and so on, am I right?

However, I do not see a direct link between HAHA and the NEMO Working
Group.  There has never been a NEMO Problem Statement that would require
a solution like HAHA.  There is nothing in the Charter (AFAIK) about
requiring HAHA.  There is no HAHA Problem Statement.

Secondly, many of the potential benefits of HAHA are valid to MH too.
Thus I suggest maybe the mip6 WG is better interested first, and if they
need it, then maybe NEMO needs it too.  But I do not find it a good
approach to push it here first.

Thus, until Authors write the HAHA usage draft that pertains to RO
benefits exclusively, it may not be necessary to cite or refer HAHA in
the NEMO RO Problem Statement.

> reach to oHA, but others from CN2 may reach to nHA.

Ryuji, I think I can understand that.  But, the problem that HAHA was
trying to solve was like "it's unwise to attach to Melbourne HA if
you're in London" and the solution was "please attach to London HA
because closer".  That problem and solution says nothing about where the
CN is placed.  It may very well be that there is HA near where you are
but the CN is near where your old HA is.  In this case, HAHA not only
does not bring benefits, but it may actually _induce_ longer paths.

No?

> Please refer the base spec (
> draft-wakikawa-mip6-nemo-haha-spec-00.txt) for more info.

Please take your time refer me to a specific paragraph in that draft.

>> Ok!  We agree!  So a packet from CN towards a fixed Home Address
>> will take a unique definite path, it won't be multicasted.  This
>> path must lead to one HA.  If one needs to modify this path to lead
>> to another new HA, then a route update in the Internet is
>> necessary, no?
> 
> 

This is a particular case.  It does mean to me a lot about multi-homing.

>> It is useful for MR to associate with the closer HA _only_ if this
>> HA can also intercept packets addressed from CN to the HoA that was
>> valid at the old HA, no?
> 
> Alex, HoA is never changed on the HAHA. Even if each HA is located at
> different links, this is transparent to MR.

Ryuji, a HoA that is valid at two different HAs is a very special kind 
of scenario to me.

>> Yes, the path nHA-MR may be shorter than oHA-MR.  However, it is
>> not enough for _that_ path to be shorter in order to be beneficial.
>> RO does not look at shortening the HA-MR paths, but at CN-MR paths.
>> SO you want the path CN-nHA-MR to be much shorter than the path
>> CN-oHA-MR.  The path oHA-nHA must be small such as to allow for
>> route updates (if route updates, not BC syncs, are used between
>> HAs) are used.  If HAHA eliminates that short oHA-nHA path then
>> there is no benefit in using it because it is much smaller than
>> what the CN-HA or HA-MR paths may become.
> 
> 

I see what you mean.  It still lacks logic, it's like saying that the 
path between two points is shorter in one direction and longer in the 
other direction; or that there are two different shortest paths between 
two points depending on the direction (if it's shortest in one direction 
it should be shortest in the reverse direction too).

>> the same time that the nHA is nearer the MR than the oHA, and at
>> the same time that a Home Address is reachable at both HAs.   Am I
>> right?
> 
> 
> Yes.

Look, if you believe this is correct, I believe this can not be 
achieved, because an MR does not choose its CNs.  It's the user who 
chooses a CN.  The MR may choose its HA, but the CN is chosen by the 
user.  And the CN may be _any_ end node in the Internet.

>> Or does it only assume that whatever HA is closer to CN can
>> intercept a packet towards HoA and forward it to the current HA?
>> If this is what you meant, then all HAs must be able to intercept a
>> certain HoA and at the same time when this inter-HA forwarding
>> takes place it induces new angles to the multi-angular paths.
> 
> 
>  You don't need ProxyND to intercept packets for NEMO, since packet
> is intercepted by using routing table.

Look, I think we are in a very large disagreement here, but we may 
discuss this on another thread.  Basically, NEMO Basic Support doesn't 
say "you don't need proxyND" and it does not forbid it either.

>> This one-HA-close-to-any-CN-and-wherever-MR-goes may also be
>> possible in some closed system.  This is a possibility indeed.  It
>> still stays a small system.
>> 
>> 
>> Yes, it may be shortened by 1 or 2 IP hops with a total distance of
>> 10 hops.  Like RO reducing the path from 10 hops to 9 hops.  I
>> don't think the PS draft should look into these solutions, it's too
>> much effort for too little achievement.
> 
> 
> I can not agree with this argument. How many hops you can reduce
> totally depends on topology (where HAs are configured).

It depends on the HA topology and on where the CNs are placed too.

>>> There is another operation to bypass oHA-nHA tunnel.  MR
>>> associates with the closer HA (nHA) and uses it for deliverying
>>> packets to the Internet.  On the other hand, MR receives packets
>>> meant for its MNP tunneled by the closer HA of CN.
>>> 
>> Great!  So we end up with a smaller triangular routing, not the
>> maximum triangular routing CN-HA-MR.  This looks to me like an
>> intermediate step on an RO scale.  The goal of RO should be to have
>> straight paths MR-CN, not through some other HA, even if closer,
>> no?
> 
> 
> tunnel. (But most of RO solution relies on tunnel). In the current
> Internet, many packets are routed through one of IXP. If HA is
> located at IXPs, the redundant path can be kept minimum.

Ryuji, I think we have a larger disagreement here.  I do not believe 
that having HA in the IXP and without using Proxy-ND is in the scope of 
NEMO.  I really think what you say may be possible, maybe even 
recommendable to do in order to achieve shorter paths, but I don't think 
we can do this in NEMO.  This is not Routing Area.

> When HA is just on the way to MR from CN, do you see critical

I see unnecessary overhead because encapsulation.

>> If you do this little triangle, why would MR bother to bind its HoA
>> to its CoA at nHA?  It would not need to send binding updates at
>> all to nHA, just tunnel packets to CN, no need of Mobile IP, no?
> 
> 
> MR basically sends single BU to HAs all the time. That's why we
> introduce binding synchronization in HAHA.

Yes, I knew that.

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Sat, 20 Nov 2004 00:17:02 +0900

On Fri, 19 Nov 2004 11:46:26 +0100

> requiring HAHA.  There is no HAHA Problem Statement.

What's the point here, Alex ? It is correct that this is not in the
charter, but are you suggesting that this discussion should be happening
on the NEMO ML because it's not a charter item ?  

> the NEMO RO Problem Statement.

Alex, I totally disagree here. If the RO PS is about studying potential
approaches (which is still doubtul), I don't see why some potential
solutions should be excluded from the analysis. Potential solutions
don't even have to be proposed at the IETF.

Thierry

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Nov 2004 17:18:57 +0100

Thierry, let me clarify my message,

Thierry Ernst wrote:
>> Ryuji it seems to me this is a good approach.  It is good to split
>>  in spec and usage documents.  HAHA as I understand it is a
>> protocol that may solve some problems within some systems.  The
>> HAHA base spec may specify a benefit-agnostic universal protocol
>> and the HAHA usage drafts may exemplify what are its RO benefits,
>> its Load Balance benefits, its Multi-Homing benefits on a per-item
>> basis and so on, am I right?
>> 
>> However, I do not see a direct link between HAHA and the NEMO 
>> Working Group.  There has never been a NEMO Problem Statement that
>>  would require a solution like HAHA.  There is nothing in the 
>> Charter (AFAIK) about requiring HAHA.  There is no HAHA Problem 
>> Statement.
> 
> charter, but are you suggesting that this discussion should be 
> happening on the NEMO ML because it's not a charter item ?

No I did not try to say that.  Chairs decide what discussion is appropriate.

I just said that there is no HAHA problem statement and that HAHA is not
in the Charter.

>> Secondly, many of the potential benefits of HAHA are valid to MH 
>> too. Thus I suggest maybe the mip6 WG is better interested first, 
>> and if they need it, then maybe NEMO needs it too.  But I do not 
>> find it a good approach to push it here first.
>> 
>> benefits exclusively, it may not be necessary to cite or refer HAHA
>> in the NEMO RO Problem Statement.
> 
> 
> Alex, I totally disagree here. If the RO PS is about studying 
> potential approaches (which is still doubtul), I don't see why some 
> potential solutions should be excluded from the analysis. Potential 
> solutions don't even have to be proposed at the IETF.

Thierry, you're right it is still doubtful whether the RO PS item
studies potential approaches as it does now.

However, there should be a difference when analyzing and referencing the
potential solutions.  For example parts of RFC's that specifically may
help with NEMO RO should be given priority over parts of individual
drafts, IMHO.  More specifically, it is strange to see section 3.2 
Infrastructure Optimization describes an optimization in terms of the 
"C-side" router (ok, not the "CR" of ORC) when it's clear to me that if 
any such optimization is to take place it should spell "BGP" or "OSPF" 
at least (my oppinion).

If we let a specific RO PS analyze all possibly imaginable solutions,
and we'd still like it to be non-partial, then the draft risks to become
real big.  There are and always will still be things that have _not_
been discussed recently, and that are _not_ parts of the taxonomy draft,
and that someone may like to include one day in the RO PS.  One thing 
that comes to mind is "renumbering", or "router renumbering RR".

Finally, let me re-say I agree that Chairs decide what's being discussed
or not.

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 24 Nov 2004 16:10:37 +0900

Hello Alex

sorry for late reply.

At Fri, 19 Nov 2004 11:46:26 +0100,
> approach to push it here first.

There is a problem statement related to MIP6 HAHA.
draft-jfaizan-mipv6-ha-reliability-01.txt

We tried to discuss HAHA (global HAHA) in NEMO, since this usage is
applicable to NEMO. We don't have any intention to work on HAHA only at NEMO WG.
If you look at the previous HAHA drafts, we submitted to both MIP6/NEMO WG.
We gave presentation at MIP6 WG, too.

> does not bring benefits, but it may actually _induce_ longer paths.

This can be solved by operations and configurations where you
configure HAs on the Internet.

<SNIP>

> it should be shortest in the reverse direction too).

Both paths can be shorten.

> user.  And the CN may be _any_ end node in the Internet.

That's why HAHA can distribute HAs to the Internet.

> say "you don't need proxyND" and it does not forbid it either.

My point is NEMO can be configured in this way with aggregated home
network.

<SNIP>

> we can do this in NEMO.  This is not Routing Area.

HAHA is not about having HA in IXP without proxy ND. This is just one
of HAHA configurations. Whether we discuss new topic or not must be
decided by WG. I did presentation at San Diego IETF to ask whether
NEMO WG is interested in this topic or not. AFAIK, many people in the
meeting is interested. The chairs advised us to keep HAHA discussion 
in NEMO WG.

> I see unnecessary overhead because encapsulation.

Although nobody know NEMO extend, NEMO Basic always tunnels packets at
least:-)

regards,
ryuji