Le 06/03/2018 à 23:17, Carlos Jesús Bernardos Cano a écrit :
Hi,
We have submitted a revised version of our draft addressing the
comments we got in Singapore:
- Added some statements about which model from draft-ietf-dmm-
deployment-models our solution follows (addressing a comment received
from Sri). - Added some text relating to
draft-ietf-dmm-ondemand-mobility (addressing a comment received from
Danny).
Additionally, we added some terminology from
draft-ietf-dmm-deployment- models and other minor changes.
In Singapore we got quite good support of the document. I'd like to
request feedback/reviews from the WG.
Carlos, here are some comments.
Current IP mobility solutions, standardized with the names of Mobile
IPv6 [RFC6275], or Proxy Mobile IPv6 [RFC5213], just to cite the two
most relevant examples, offer mobility support at the cost of
handling operations at a cardinal point, the mobility anchor,
By mobility anchor I think you mean HA or LMA.
(i.e., mobility is offered on a per-node basis, not being possible to
define finer granularity policies, as for example per-application).
Just some thought: it's 'per-node(s)' basis vs 'per-application' basis,
because there is also 'per-nodes' vs 'per-node', i.e per-MH vs per-MR.
o The LMA is relieved from the data forwarding role, only the
Binding Cache and its management operations are maintained. Hence
the LMA is renamed into Central Mobility Database (CMD), which is
therefore a Home-CPA. Also, the CMD is able to send and parse both
PBU and PBA messages.
It's renamed, but it still is a single-point-of-failure?
o The MAG is enriched with the LMA functionalities, hence the name
Mobility Anchor and Access Router (MAAR). It maintains a local
Binding Cache for the MNs that are attached to it and it is able to
send and parse PBU and PBA messages.
Have you tried to disconnect CMD and the system still worked, just with
MAARs?
[...]
temporal
temporary
definitely
definitively(?)
[...]
Overall, I have the feeling there are still some tunnels (MAAR1 to
MAAR2), so still the paths are not shortest possible.
HSS
What it means?
In order to maintain the prefix anchored at MAAR1 reachable, a
tunnel between MAAR1 and MAAR2 is established and the routing is
modified accordingly.
When you say 'routing is modified accordingly' does it mean that
tunnel-related entries in the routing tables of MAAR1 and MAAR2 are
updated? Or does it mean that entries _not_ related to the tunnels are
updated?
3.6. The Distributed Logical Interface (DLIF) concept
I like the idea of the network presenting itself as a same entity to the
MN. Whether the MN is attached to MAAR1 or to MAAR2, the MN sees the
same MAC address and IP address of the default router.
However, I have difficulty to grasp the term 'distributed logical
interface'. It sounds as if the same interface name, e.g. 'mn1mar1',
was present on both MAAR1 and MAAR2. In reality, only the triplet 'MAC
address', 'link-local address' and the 'global prefix' are same on MAAR1
and MAAR2 interfaces. These latter are called differently, though:
'mn1mar1' and 'mn1mar2'.
Maybe the DLIF could be named 'mn1marx'. But I dont think you ifconfig
'mn1marx' whereas I am almost sure you do ifconfig mn1mar1 and ifconfig
mn1mar2.
Each serving MAAR exposes itself towards a given MN as multiple
routers, one per active anchoring MAAR associated to the MN.
'serving MAAR' vs 'active anchoring MAAR' ok, but sometimes you have
just 'anchoring MAAR'.
One wonders whether the 'anchoring MAAR' is an S-MAAR or P-MAAR.
Overall, you have:
- Serving MAAR
- Previous MAAR
- [non-active] anchoring MAAR
- active anchoring MAAR
Not sure which is which since the latter two are not defined in Terminology.
This is similar to the LIPA scenario currently being
consider by 3GPP.
LIPA... appears just once, I do not know it.
These routes are advertised through the distributed
logical interface representing the MAAR providing access to the local
network (MAAR1 in this example).
By 'distributed logical interface' do you mean mn1marx or mn1mar1,
mn1mar2...? Do you mean there is an radvd on each of mn1mar1, mn1mar2
advertising that prefix? Do you mean you modify the radvd.conf file
each time the MN moves, and restart the radvd daemon ?
Do you mean there is only one radvd that runs on the DLIF called 'mn1marx'?
Prefix Length
8-bit unsigned integer indicating the prefix length of the IPv6
prefix contained in the option.
This 'Prefix Length' variable appears several times in the message
formats, yet all the examples of prefixes shown in the draft are of
length precisely 64. I do not understand why.
In order to illustrate that is true variable, can we have one of the
examples that says '63' instead of '64'?
Otherwise, it may sound little logical to keep that as variable. Just
use /64s everywhere and dont transmit Prefix Length in no message.
Alex
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
