Hi, Marco, Thanks for the response. See below.
Marco Liebsch wrote: > 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. Ok I understand that you want to put some of your components in the existing mobility anchor (and at least the FE_MA would be there) but you also seem to be distinguishing between a DMM protocol that runs *above* the FE_MA and another mobility protocol that runs *below* the FE_MA. Is that a correct interpretation? > >> 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 :-) Good. It seems to me that designating the leaf node in your architecture as containing FE_MA is confusing because there may in fact be no mobility protocol running between FE_MA and AR (they may be one and the same entity). >> 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. Sure, but at least one node needs to have a "route" for the old IP address, even if it is just a route to a local tunnel interface. > The defined DMM FEs enable the required level of indirection > above or at the mobility anchor. Right this reflects my understanding of your two-layer model. I am just wondering why we can't further decouple ourselves from the mobility protocol that may exist beneath the FE_MA. It may not exist or may only be at L2 (or L1). >> 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. Good. >> 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. Sorry I had a conflict and couldn't attend DMM this morning. I will take a look at your version 01 and contribute where necessary. -Pete > > marco _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
