Hi Pete, please see inline for my response. >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of >Peter McCann >Sent: Mittwoch, 7. November 2012 20:41 >To: [email protected] >Subject: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00 > >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.
That would imply a solution and that is not intended. The four defined DMM FEs can be mapped to components of existing protocols. My intention is to define DMM FEs, which enable DMM use cases but are not dependent on a mobility protocol. So, some functions can be applied to existing components of, say, iBGP in a route reflector, or a LISP resolver. But some components can be placed on a Mobile IP Home Agent or even a Mobile Node. Then we can analyze if the function of the DMM FE is implicitly supported by the existing protocol or if an extension is needed. That's the rationale behind these FEs. The FE_MA is mentioned as existing component and assumed as topological anchor of the MN's IP address. Some or all DMM FEs may apply to the existing MA. Depends on the analysis we want to perform. > 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? Yes, legal from my perspective :-) > > >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. The assumption is of course that below a mobility anchor (FE_MA) the mobility protocol performs location tracking and tunnel management or whatever. The defined DMM FEs enable the required level of indirection above or at the mobility anchor. > >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. Yes. > >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). I have that picture in mind, just lack of time caused mapping examples to be weak in version 00. I received other feedback and version 01 is actually there. I'd be happy if you contribute to the draft with our picture and text. By the way, the main motivation of the DMM FEs was to allow analysis beyond mobility protocols, hence including your solution proposal. I see the iBGP solution as hop-by-hop solution where each transport network router gets a per-host state when indirection is required. Each iBGP router hence implements an FE_I and FE_E at the same time. But let's discuss details tomorrow. marco > >-- >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 _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
