Let me ask a question to make sure I understand the approach this document takes to analyzing the problem space. In the Introduction, you state: "The initial version of this draft introduces a basic set of FEs and interfaces between these FEs to support IP address continuity in DMM, without being specific to the used mobility management protocol, which operates below the mobility anchor." And later, you introduce the FE_MA to represent this mobility anchor. I *think* you are trying to define DMM as something that runs above another mobility management protocol. Would it be legal to set the FE_MA equal to the access router, and the other mobility management protocol to NULL? That is, would it be allowed in your framework to use *only* the DMM protocol to get packets to an AR, to which the MN is currently attached?
Section 3 states: "Imported HoA/HNP of a mobile node will be treated as identifier and non-routable IP address (prefix), as it probably does not match the new mobility anchor's location in the topology." I disagree. The old address (prefix) will need to be routable at least inside the new anchor point. If this anchor point is directly connected to the MN (i.e., it is the AR) then the route will be to a local link address. If this new anchor point uses a tunnel to get the packets to the MN, then the old address will be routable to the tunnel interface. Elsewhere in Section 3: "Forwarding can be for example accomplished by an IP tunnel to the egress function, address translation to a routable IP address or other means." I hope that "other means" can include installing an actual route for the destination IP on routers between the ingress and egress. I'd be happy to provide a diagram and text to show how draft-mccann-dmm-flatarch can fit into this functional framework. In the language of your draft, I think that the FE_MAs are integrated with the ARs, the FE_MCTX is the DNS server that stores the UE's current address, FE_E is co-located on the currently serving AR, and FE_I and FE_IEC are made up of a distributed network of routers running BGP (there is no single point of failure for FE_I). -- 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
