Hi Pete, please see inline. Sorry for the delay in continuing the discussion.
>-----Original Message----- >From: Peter McCann [mailto:[email protected]] >Sent: Donnerstag, 8. November 2012 19:43 >To: Marco Liebsch; [email protected] >Subject: RE: Comments on draft-liebsch-dmm-framework-analysis-00 > >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? The draft is not a solution, but a functional framework. As you write, some functions can be placed on an existing mobility anchor (which may be even co-located with an access router). Typically, the Egress Function is at the MN's topological anchor after anchor relocation. To analyze if a mobility protocol supports one or more of the required functions to enable DMM implicitly, some of the other identified DMM functional entities could be placed on the mobility anchor, or even on a MAG or a MN in case of host mobility. See, this is solely for the analysis. But also for the identification and specification of extensions. If we place the FE_IEC to an iBGP router, maybe the defined DMM function is implicitly supported by the iBGP protocol. That's the rationale behind the framework. And that was my intention to allow enabling DMM with support from non-mobility protocols, e.g. being deployed in the transport network. This can be in your example iBGP, or MPLS or OpenFlow. > >> >>> 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). Yes, then it's local IPC of a function call ;-) FE_MA is just a general naming of the MN's topological anchor or, maybe better, point of attachment. The DMM framework simply assumes that packets arriving at that point of attachment can be forwarded to the MN without any help of the functional entities of the DMM framework. If this is the Access Router or a Base Station, that requirement is met. > >>> 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. If the DMM solution supports importing the 'old' address to the new point of attachment (mobility anchor, access router, whatever), then the FE_MCTX handles that. Means the MN's current point of attachment knows the 'old address' and has a state (mobility state at the anchor or Neighbor state at an Access Router) to allow association of the arriving packet with the attached MN. If we do not importing the 'old' address context into the new point of attachment, then it's a scenario you refer to above and we need a state at the previous point of attachment and tunnel the packet to the new point of attachment. That would imply an indirect route via the previous point of attachment, hence sub-optimal. > >> 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). The framework is exactly this: Decouple functions for DMM support from the mobility protocol. If there is no mobility protocols, means the point of attachment is the MN's current access router, the Egress Function may be located on Access Routers and the control functions can be applied to existing or extended functions of the transport network (LISP, iBGP, OpenFlow, ..) > >>> 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. What about this: In iBGP, routers implement the control plane in a distributed manner (if we do not assume route reflectors first). Routing states are clear between an Ingress and an Egress Function. Each router needs to have a per-host state to take further routing decisions on a per-hop basis. That could look like this: iBGP Router +------------------+ | FE_IEC | | / \ | | / \ | --->FE_I------->FE_E----->data | | +------------------+ What do you think? marco > >-Pete > >> >> marco > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
