Re: Comments on draft-liebsch-dmm-framework-analysis-00

..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: [email protected] [mailto:[email protected]] On Behalf Of
>Marco Liebsch
>Sent: Dienstag, 20. November 2012 10:59
>To: Peter McCann; [email protected]
>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:[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