Subject: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00

From: Peter McCann <[email-masked]>
Date: Wed, 7 Nov 2012 19:40:46 +0000

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

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.  

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.

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

--
Peter J. McCann
Huawei Technologies (USA)
[email-masked]
+1 908 541 3563
Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ  08807-2863  USA

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 7 Nov 2012 23:26:16 +0000

Hi Pete,
please see inline for my response.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Peter McCann
>Sent: Mittwoch, 7. November 2012 20:41
>To: [email-masked]
>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:
>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.

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

>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.
The defined DMM FEs enable the required level of indirection above or at the
mobility anchor. 

>destination IP on routers between the ingress and egress.

Yes.

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

marco

>_______________________________________________
>dmm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dmm

---

From: Peter McCann <[email-masked]>
Date: Thu, 8 Nov 2012 18:42:57 +0000

Hi, Marco,

Thanks for the response.  See below.

Marco Liebsch wrote:
>> 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?

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

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

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

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

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 20 Nov 2012 09:59:20 +0000

Hi Pete,
please see inline. Sorry for the delay in continuing the discussion.

>From: Peter McCann [mailto:[email-masked]]
>Sent: Donnerstag, 8. November 2012 19:43
>To: Marco Liebsch; [email-masked]
>Subject: RE: Comments on draft-liebsch-dmm-framework-analysis-00
>
>Hi, Marco,
>
>>> I
>> 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.
>
>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

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

>>> I disagree.  The old address (prefix) will need to be routable at
>>> least inside the new anchor point.  If this anchor point is directly
>>> 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.
>>
>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.
>
>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, ..)

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

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 20 Nov 2012 10:09:15 +0000

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

>Marco Liebsch
>Sent: Dienstag, 20. November 2012 10:59
>To: Peter McCann; [email-masked]
>Subject: Re: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00
>
>Hi Pete,
>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>> Of Peter McCann
>>> 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.
>>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?
>
>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.
>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.
>
>>
>>>
>>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
>>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
>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.
>
>>
>>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).
>
>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:
>>>> 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.
>
>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.