..small correction in the figure below: Packets should arrive at the FE_E of the iBGP router, then the next hop state is checked, then packets are transmitted via FE_I. So please swap FE_I and FE_E in the figure.
marco >-----Original Message----- >From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of >Marco Liebsch >Sent: Dienstag, 20. November 2012 10:59 >To: Peter McCann; dmm@ietf.org >Subject: Re: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00 > >Hi Pete, >please see inline. Sorry for the delay in continuing the discussion. > >>-----Original Message----- >>From: Peter McCann [mailto:peter.mcc...@huawei.com] >>Sent: Donnerstag, 8. November 2012 19:43 >>To: Marco Liebsch; dmm@ietf.org >>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: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf >>>> Of Peter McCann >>>> Sent: Mittwoch, 7. November 2012 20:41 >>>> To: dmm@ietf.org >>>> 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 >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
