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?

> 
>>   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