Hi Marco, Apologies for the late reply. Thanks for reading the draft. Please see some answers to your questions/comments inline below.
On Fri, 2012-03-09 at 11:51 +0000, Marco Liebsch wrote:
> Hi Carlos,
>
> I have a few clarifying questions to your new draft. The draft proposes the
> distributed logical interface. I don't really get the advantage of
> virtualizing
> the previous LMA on the MN's current LMA if packets are routed through
> the previous LMA anyway. Why not using the current LMA to serve simply
> as MAG for forwarded traffic (which remains anchored at previous LMA)
> and using the new LMA to anchor the new address/prefix?
What you just mention is exactly what the draft does. Additionally, the
logical interface simplifies the interface between the MN and the access
router that behaves as LMA/MAG. It does so because by interacting with
the MN as different "logical" routers (one per anchoring LMA), you can
make full use of the ND based features (e.g., RFC4191) in a very easy
way.
>
> The draft writes that the idea hides the change of the anchor from the
> mobile node. The DGW2IF on the new LMA does not pretend to be LMA1, or?
> I don't see how the anchor change is kept transparent to the MN.
The point is that from the point of view of the MN, it always "sees" as
directly connected (1-hop away) each of the anchor LMAs. Every time the
MN moves and attaches to a new access router, the only thing it notices
is that a new ("logical") router appears on the link, advertising a new
prefix (and, in most use cases, the others start advertising the
prefixes with lifetime=0 to deprecate them).
>
> I somehow agree also to Pete's opinion that solving the packet routing after
> anchor relocation above the anchors is a good option. It simply allows more
> optimal routes.
I have to read his draft, but unless you have control on the routing
infrastructure (and this is not always possible, and it takes time to
converge), I don't see many other options to ensure address continuity.
>
> Now I am deviating a bit, but into the direction of an important question:
> That's directly related to the question of how persistent we need to be
> about IP address continuity. Now, some proposals consider termination
> of an IP address prefix, which is anchored at a previously used anchor point,
> as soon as the IP session, which uses that address, terminates. New sessions
> can use the address being anchored at the new mobility anchor. My opinion is
> that we need to find a good choice about the lifetime of such an anchored IP
> address, as it may also be registered with other services, e.g. IMS,
> messaging, etc,
> and would require an updated registration after a change in the registered
> address.
> And even if such lifetime is short, we may not accept suboptimal routing paths
> via the previous anchor after anchor relocation.
Session lifetime and prefix anchoring termination is a tricky and
important issue. As I see it, DMM is compatible with a "classical"
centralized approach (at least for the solutions that are basically
extending currently standardized IP mobility protocols to operate in a
more "distributed" way). For those applications that are known in
advance to require very long address lifetime (compared to the anchoring
mobility rate), I'd say that those sessions it might make sense to keep
them centrally anchored (or to enable applications to be able to survive
to an IP address change).
Thanks,
Carlos
>
> What do you think?
>
> Thanks,
> marco
>
>
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf Of
> > Carlos Jesús Bernardos Cano
> > Sent: Montag, 5. März 2012 18:40
> > To: [email protected]
> > Subject: [DMM] New DMM draft: draft-bernardos-dmm-distributed-
> > anchoring-00.txt
> >
> > Dear all,
> >
> > We've just submitted a new I-D on the DMM space. The draft describes a
> > network-based DMM approach extending PMIPv6, and focusing on the
> > required extensions to effectively support simultaneously anchoring several
> > flows at different distributed anchors.
> >
> > As usual, comments would be warmly welcomed!
> >
> > More info below:
> >
> > Title : PMIPv6-based distributed anchoring
> > Author(s) : Carlos J. Bernardos
> > Juan Carlos Zuniga
> > Filename :
> > draft-bernardos-dmm-distributed-anchoring-00.txt
> > Pages : 23
> > Date : 2012-03-05
> >
> > Distributed Mobility Management solutions allow for setting up
> > networks so that traffic is distributed in an optimal way and does
> > not rely on centralized deployed anchors to provide IP mobility
> > support.
> >
> > There are many different approaches to address Distributed Mobility
> > Management, as for example extending network-based mobility protocols
> > (like Proxy Mobile IPv6), or client-based mobility protocols (as
> > Mobile IPv6), among others. This document follows the former
> > approach, and proposes a solution based on Proxy Mobile IPv6 in which
> > mobility sessions are anchored at the last IP hop router (called
> > distributed gateway). The distributed gateway is an enhanced access
> > router which is also able to operate as local mobility anchor or
> > mobility access gateway, on a per prefix basis. The draft focuses on
> > the required extensions to effectively support simultaneously
> > anchoring several flows at different distributed gateways.
> >
> > This draft introduces the concept of distributed logical interface
> > (at the distributed gateway), which is a software construct that
> > allows to easily hide the change of anchor from the mobile node.
> > Additionally, the draft describes how to provide session continuity
> > in inter-domain scenarios in which dynamic tunneling or signaling
> > between distributed gateways from different operators is not allowed.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-bernardos-dmm-distributed-
> > anchoring-00.txt
> >
> > Thanks,
> >
> > Carlos
> >
> > --
> > Carlos Jesús Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B
> > 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67
--
Carlos Jesús Bernardos Cano http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67
signature.asc
Description: This is a digitally signed message part
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
