RE: [nemo] new draft

["Pascal Thubert \(pthubert\)" <[e-mail]>]

Hi Mazen:

I believe that it is pretty natural for a Mobile Router to own more than
one egress interface. Typically today, you'll find MRs with a modem and
a 802.11 interfaces.

It is also expected that you'll find some proprietary logic for a MR to
select its interface and its AR over that interface. Sometimes, it's as
obvious as: .11 is fast and free, modem is slow and expensive... guess
what, modem has a lower priority then WIFI.

On the other hand, potential ARs may be on a same (or same type of)
egress interface, but they might provide uneven services (nesting level,
security, bandwidth). I would really like to see a draft that examines
that problem and makes recommendations on how MRs should behave, what
should be customizable in the AR selection, etc... if you're interested
:)

For current implementations or trials, a set of tools are available:

RFC 2461: RA is the base tool for all. Proves to be a little slow for
mobility

RFC 3775: improves ND making RA faster and more verbose.

DNA: should go further in NUD but still, the AR is the horizon.  

draft-ietf-ipv6-router-selection-05.txt helps the node (the MR in our
case) select its attachment router based on a preference, and routes if
you are lucky enough to find an AR that has a more specific route to
home. The draft does not say how the routers negotiate that in the
backend and I believe it's a good thing.

draft-thubert-tree-discovery-00.txt adds information for nested MRs, and
since TD forms trees, Route Information Option from
draft-ietf-ipv6-router-selection-05.txt can safely be proxied. Also, it
is expected that more metrics - such as bandwidth - will be added to TD
to help MRs make even more educated decisions.

All have the concept that the MR makes the final decision for AR
selection. This can be based on the actual reachability, bandwidth ...
it gets by trying the ARs. This can be based on node policies. An
external box does not know about all this. 

Note also that the problem you address is valid for any multihomed node,
e.g. a web server.

So, conceptually, I'm not too keen in pushing that draft the way it's
presented, in terms of architecture and in terms of WG.

On the other hand, I agree that there is a need for a gateway that would
be placed like the ARC.
One example, as we all know it, is a HA for LMM. See
draft-droms-nemo-dhcpv6-pd-01.txt for a NEMO version of it.

I agree that the reservations can not placed end to end because it's
hard to move them when the MR moves, and that it would be cool to place
reservations in loose hops, like:

MR<->LMM<->HA<->HA<->LMM<->MR
Or
MR<->LMM<->CR

So again, I would like to see a draft describing which functions to
place in such gateway...
I would also like to see extensions to
http://www.ietf.org/internet-drafts/draft-jang-dhc-haopt-00.txt to help
locate that gateway and find out about its capabilities, as opposed to
overload RAs over and over.

What do you think?

Pascal