Hi Alex, Thanks a lot for your review. Comments inline below.
On Fri, 2018-03-09 at 18:29 +0100, Alexandre Petrescu wrote: > > 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. [Carlos] Yes. We can make this more clear in the next revision. > > > (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. [Carlos] The document assumes node/host mobility (not network mobility). > > > 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? [Carlos] Not from the point of view of data forwarding. It is still a centralized point for the control plane, but some mechanisms could be to distribute the operation of the LMD, so it is not 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? [Carlos] We have not tried, but the system would only work if mobiles do not move and only during the lifetime of the bindings. > > [...] > > > 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. [Carlos] Yes, there are tunnels to the anchoring MAAR for the time an address anchored there is in use. > > > HSS > > What it means? [Carlos] Home Subscriber Server. It is a 3GPP entity. We have received this comment from other reviewers, so we will expand the acronym and explain it in the next revision. In any case, we use it as an example. > > > 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? [Carlos] Just the routing tables of MAAR1 and MAAR2. > > > 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'. [Carlos] The triplet are the same, but we also use the same name of the interface in the diagrams (in the system, the name of the interface does not matter, could be called in anyway, the important point is the triplet you mentioned). 'mn1mar1' refers to the logical interface (i.e., triplet) exposed by MAAR1 to MN1 for the prefix anchored by MAAR1 to MN1. 'mn1mar2' refers to the logical interface (i.e., triplet) exposed by MAAR2 to MN1 for the prefix anchored by MAAR2 to MN1. If the MN is using addresses from both the prefixes anchored at MAAR1 and MAAR2, while the MN is attached to MAAR2, 'mn1mar1' and 'mn1mar2' logical interfaces will be configured at MAAR2. > > 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. [Carlos] Please check the previous and let me know if you agree. > > > 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'. [Carlos] We can clarify this and use the same term consistently. This is a good point. > > One wonders whether the 'anchoring MAAR' is an S-MAAR or P-MAAR. [Carlos] The anchoring MAAR is a P-MAAR for addresses anchored at MAARs others that the S-MAAR. The S-MAAR is also an anchoring MAAR, as it provides a prefix locally anchored. In the text, typically we use the term ¡anchoring MAAR' to refer to a 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. [Carlos] This is a good point. We will clarify this in the terminology section of the next revision. > > > This is similar to the LIPA scenario currently being > > consider by 3GPP. > > LIPA... appears just once, I do not know it. [Carlos] We will explain this term in the next revision. > > > 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 ? [Carlos] We mean that there would be an RADVD on each logical interface. If I recall it properly, we actually implement this by our code directly generating the RAs, not by using RADVD, but it could be also done with RADVD. > > Do you mean there is only one radvd that runs on the DLIF called > 'mn1marx'? [Carlos] Different RAs are sent though the different logical interfaces. > > > 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. [Carlos] We include the Prefix Length option as in the HNP option of RFC 5213 and the MNP option of RFC3963. But we foresee that this value will be equal to 64 in most cases, as the prefix length in IPv6 is typically 64-bits. Do you think we should also have examples with other prefix lengths? Thanks! Carlos > > Alex > _______________________________________________ dmm mailing list email@example.com https://www.ietf.org/mailman/listinfo/dmm