Subject: [netlmm] Comments to draft-giaretta-netlmm-mip-interactions-02

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 20 Nov 2007 14:31:50 +0000

Hi Gerardo and all,

I have some comments for this draft that might be usefull.

1) I think scenario B should be somewhat expanded to cover not only MIPv6
nodes but also other nodes that do not want to or are not authorized to
receive PMIPv6 services.
For example section 3.2 says that:
" However, in case there are nodes that implement Mobile IPv6 and want to
use this protocol, the network must offer MIPv6 service to them."
This statement makes no sense and should be removed/rephrased, since the
"network" can not possibly provide "MIPv6 services", since such services are
only offered by the HA. The only thing that the "network" needs to provide
in this case is what any "normal" node is expecting i.e., an prefix
topologicaly correct for its location, which is what is correctly stated in
the rest of the section.
2) In Section 3.3 (scenario C) I think given the multihoming discussion that
now exists in PMIPv6 spec, this scenario is getting a bit more complex. The
reason is that an MN may have multiple PMIPv6 "sessions" on the same or
different LMAs, while scenario C seems to be dealing only with a single
PMIPv6 session. In the light of that realization, mapping MIPv6 sessions to
PMIPv6 sessions is a bit trickier, while returning "home" is also
potentially trickier...except if we manange to simplify things as I suggest
below.

3) In the same section the issue of "returning home" is discussed. It seems
ot me that for the MN to even know that it returned "home" it must receives
an RA with its home prefix. Since in a PMIP domail such an RA is sent by the
MAG, I assume that PMIP needs to create the MAG-LMA tunnel before the RA is
sent and before the MN realizes that it returned "home". In any case the MN
can not be considered connected to its home link until it is directly
connected to its HA (which again indicates that the PMIP tunnel must first
be created). This also indicates that a MIPv6-deregistration can not
possibly remove the PMIPv6-Binding Cach entry for this MN, since that would
effectively remove the MN from its home link...a catch22 issue.

The bottom line is that IMHO, the PMIPv6 and MIPv6 Binding Cache entries
should be kept *independent* and should NOT affect each other. I think this
would resolve or even invalidate a lot of the race conditions/cases
described in this document. In essence, Scenario A and C should look
identical, except that in C the HA is directly connected to one of the LMAs
and thus HNPs are shared between them.
   - The HA should only listen to BUs coming from the MN and the LMA should
only consider PBUs coming from MAGs.
   - As such when an HA needs to forward a packet, it simply looks at the
MIPv6 binding for the next hop and tunnel to the indicated CoA.
   - If the MIPv6-CoA represents a PMIPv6 domain then, packets will be
routed the corresponding LMA which can look at its own PMIPv6 Binding
Entries to find the correct MAG.
   - If the MN has already moved to another MAG, then the handoff will be as
good as the PMIP handoff and any local optimizations are allow it to be.
   - If the MN has moved to another domain (PMIP or non-PMIP), then the
handoff will be as good as the target domain bootstraping procedures are
allowing it to be.

Isn't this enough? If you think this way then race conditions do not exists,
since the two protocols operate indepedently from each other. In any case,
running PMIPv6 and MIPv6 in the same box should be no different than running
MIPv6 and your favorite L2 Mobility tunneling protocol in the same box (GTP,
A10/11 or whatever) ;-)

Thoughts?

George
_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm