Hi, Carlos, Juan-Carlos,
I have read draft-bernardos-dmm-distributed-anchoring-00, and I have a few
comments.
First, I want to bring up something that I think is common to several of
the DMM proposals, and that is sub-optimal use of the backhaul resources.
It seems that when you use an AR as an anchor point, and move to a new AR,
the traffic for that session has to traverse the backhaul 3 times in each
direction, like this:
-----
| Rtr |
/ ^ -----\
1 / / 2 \ 3
v / v
---- ----
| AR | | AR |
---- ----
Although it may seem at odds with the goal of "distributing" mobility to
use the crossover router as the point of traffic redirection, it would make
for much more optimal use of the backhaul resources. I believe it is possible
to route the traffic more optimally with a standard off-the-shelf router at
the crossover point (using mechanisms detailed in draft-mccann-dmm-flatarch-00).
Second, I like the idea of moving the prefix assigned to the MN from one AR
to another. However, why do we need to keep the AR's MAC address the same?
IPv6 should handle the failover of a first-hop router from one instance to
another
with no problems. You see the same prefix advertised from a different MAC
address;
what's the big deal? You can just keep using the prefix as you did before,
addressing
packets to the new access router.
Third, I don't like the idea of having to ship so much state around the network
through the HSS. In your draft you talk about (out-of-scope) mechanisms to get
the prefix and the anchor gateway address to the new D-GW. There is also the
complication
of knowing which prior prefixes the MN wants to keep at its new attachment
point.
It seems to me that we should avoid the behavior that a new prefix is always
assigned
at each new point of attachment; rather, we should force the MN to take some
sort of
affirmative action to acquire an address/prefix for its use, such as DHCP-PD.
This
would be done occasionally, not on every handover, and the MN could register
its intent
to keep an address through e.g., dynamic DNS update. Then the new D-GW could
lookup
the DNS name of the MN at the time it attaches, see the list of addresses that
are
currently assigned, and take steps to attract the packets for those prefixes.
This
could be a tunnel or it could be a BGP UPDATE as outlined in
draft-mccann-dmm-flatarch-00.
Finally, I don't quite understand the "Local Prefixes" concept presented in the
draft.
I understand how LIPA is supposed to work, but I don't understand why you need
to treat
such prefixes differently from any other prefix on the D-GW1 link. You are
tunneling
all the traffic back to the D-GW1 AR, correct? Wouldn't the traffic just
naturally
follow the proper path through to the D-GW1 and from there to the local CN?
Personally, I think it might be better to use client-based Mobile IP for any
scenario
where the current AR cannot attract the packets for a given prefix, such as
when the
MN moves out of the domain of one operator. That situation is very similar to
the LIPA
case and could be solved with a single mechanism.
Looking forward to continued discussion,
-Pete
--
Peter J. McCann
Huawei Technologies (USA)
[email protected]
+1 908 541 3563
Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 USA
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
