Subject: [MEXT] LISP as a solution for some part of the DMM requirement

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 01 Aug 2011 11:28:34 -0700

Hello folks,

At IETF 81, LISP for mobile devices was presented.
While I am not yet convinced about the specific
solution presented, I started to look at LISP as
a possible component of an overall DMM solution.

LISP has a website:
http://www.lisp4.net

For people who are unfamiliar, this issue of IPJ
has a tutorial article about LISP:
http://www.lisp4.net/docs/ipj_11-1.pdf

The LISP draft for mobile nodes is accessible here:
http://datatracker.ietf.org/doc/draft-meyer-lisp-mn/

Comments?  I think that LISP should be added to the
comparison matrix in my draft with Dapeng Liu.
Would that be helpful?

Regards,
Charlie P.

---

From: "Seok-Joo Koh" <[email-masked]>
Date: Tue, 2 Aug 2011 08:50:18 +0900

Dear Charles,

I think the LISP can also be considered as a promising candidate
in the design of DMM solutions. Several works are being progressed
to use or extend the LISP for mobility support, which inlcude LISP-MN draft
and many research papers. Actually, I am also considering how to extend
the LISP scheme in the DMM perspective.

LISP is a network-based ID-LOC separation scheme and thus it may give some
advantages for effective mobility support. On the other hand, it is noted that
the current version of LISP and LISP-MN may need to be more enhanced
in terms of scalability in the mobile environment. For example, one concern of LISP
is that the LISP EIDs may not be aggregated anymore in the mobile networks, since
each mobile node will have its own distinctive EIDs that do not conform the concerned mobile domain.
This may decrease the scaling benefits of original LISP.
We may need to design a new enhanced EID structure to be used for mobile environment.
Nontheless, it is worthwhile to consider LISP as a promisng candidate in the disign of DMM, I think.

By the way, as I already said in this IETF DMM ad hoc meeting, the urgent action item of DMM is
to make one or more introductory I-Ds with WG consensus, which may include
the problem statements and requirements for DMM, use cases/scenarios, and comparison matrix, etc.

Regards,

*************************
Seok-Joo Koh
http://protocol.knu.ac.kr/
*************************

----- Original Message ----- 
From: "Charles E. Perkins" <[email-masked]>
To: "mext" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 02, 2011 3:28 AM
Subject: [MEXT] LISP as a solution for some part of the DMM requirement

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

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 01 Aug 2011 20:13:04 -0700

Hi Charlie,

I agree, we have to look at other approaches and bring any value added
features to MIPv6/PMIPv6 protocols that its missing today. But, I've to say,
I'm still trying to understand the DMM problem statement and what DMM should
translate to:

- Is it about optimized routing path ? This is very subjective and the
requirement may vary based on the use-case. Very much depends on the
placement of the anchor point. No solution on the table can ever solve this,
unless we assume the target site where the CN is located, or the ISP above
is providing some new location functions. This new location function, sure,
can be a proxy home agent at the global internet level too, for the argument
sake, providing direct path to the access network where the MN is currently
attached. We also have talked some time back on the Global HAHA, as an
approach of session re-anchoring.

- Is it about moving from a centralized one box model to more distributed
zillion box model ? This sounds very promising on the paper. But, as we
discussed during the DMM BOF, rolling out a zillion pizza box type box
anchors sounds very cool. Sure, but we bring back ten-fold complexity in the
form of building distributed charging, Legal Intercept, DPI, Inline
services, hotlining, high-availability ...etc etc, which are now part of
that one central anchor box. It is to be noted, we have not seen a true
distributed service deployed in the internet today, other than DNS.  But, I
agree, if this about building a true internet, who the heck cares about all
of these functions, in the true spirit.

Either way, I assumed any of the new solution will be bound by the following
parameters:

- The signaling protocol will continue to be based on MIPv6/PMIPv6 signaling
semantics. 

- We will not introduce a new client, what is now MIP client struggling to
make it to every variants of operating systems.

- Any client-based solution will be an extension on top of DSMIP. Any
network-based solution will be an extension to PMIPv6

I hope we can discuss the solution approaches in the next meeting and bring
new extension to MIPv6/PMIPv6 protocols.

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 01 Aug 2011 20:22:38 -0700

With respect to the solutions, there are multiple approaches that are on the
table. To me, to achieve a flat distributed model, we need:

- the ability to select a mobility anchor closer to the access network where
the mobile node is attached. 3GPP Rel-10 has done quite a few enhancements
on the aspects of gateway selection. Using the parameters eNB, APN, RNC-ID,
BSC-ID, ...etc

- the ability to re-anchor a session, or create a new session on a new
anchor closer to the new attachment point

- the ability to allow the mobile node to identify the assigned IP address
properties, distinguish between an address assigned in the previous access
network, from an address assigned in the current access network, so it can
continue to use the new address for new sessions and phase out the older
address/mobility session on the previous anchor over a period of time. In
other words, enhancing the SAS rules with mobility awareness will give the
needed session re-anchoring capabilities

This approach gives me the gateway selection closer to the access network
where the mobile node is attached and the needed optimized routing path. So,
I'm trying to understand what are the expectation from the DMM efforts,
beyond this.

Sri

On 8/1/11 8:13 PM, "Sri Gundavelli" <[email-masked]> wrote:

> requirement may vary based on the use-case. Very much depends on the placement
> of the anchor point. No solution on the table can ever solve this, unless we
> assume the target site where the CN is located, or the ISP above is providing
> some new location functions. This new location function, sure, can be a proxy
> home agent at the global internet level too, for the argument sake, providing
> direct path to the access network where the MN is currently attached. We also
> have talked some time back on the Global HAHA, as an approach of session
> re-anchoring.
> 
> discussed during the DMM BOF, rolling out a zillion pizza box type box anchors
> sounds very cool. Sure, but we bring back ten-fold complexity in the form of
> building distributed charging, Legal Intercept, DPI, Inline services,
> hotlining, high-availability ...etc etc, which are now part of that one
> central anchor box. It is to be noted, we have not seen a true distributed
> service deployed in the internet today, other than DNS.  But, I agree, if this
> about building a true internet, who the heck cares about all of these
> functions, in the true spirit.
> 
>> in terms of scalability in the mobile environment. For example, one concern
>> of 
>> LISP

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Aug 2011 13:28:09 +0200

> At IETF 81, LISP for mobile devices was presented.

In Mobopts?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Aug 2011 13:28:59 +0200

Le 02/08/2011 01:50, Seok-Joo Koh a écrit :
> By the way, as I already said in this IETF DMM ad hoc meeting,

Sorry, which IETF DMM ad hoc meeting?

Alex

> the
> urgent action item of DMM is
> ----- Original Message ----- From: "Charles E. Perkins"
> <[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Aug 2011 13:29:42 +0200

Le 02/08/2011 05:13, Sri Gundavelli a écrit :
> I hope we can discuss the solution approaches in the next meeting

Which meeting?

Alex

  and bring
> On 8/1/11 4:50 PM, "Seok-Joo Koh"<[email-masked]>  wrote:
>
>> Dear Charles,
>>

---

From: Romain KUNTZ <[email-masked]>
Date: Tue, 2 Aug 2011 14:09:01 -0700

Hello,

I fail to see how LISP would fall in the MEXT charter item, which concentrates on MIPv6-based DMM solution ('Operational considerations for distributed use of Mobile IPv6'). If LISP is foreseen as a potential solution for distributed mobility management, that should probably be discussed in the Network WG, where LISP and LISP MN are discussed.

Regards,
Romain

On Aug 1, 2011, at 16:50, Seok-Joo Koh wrote:

> ----- Original Message ----- From: "Charles E. Perkins" <[email-masked]>

---

From: <[email-masked]>
Date: Tue, 2 Aug 2011 21:15:32 +0000

I agree with Romain's comment.
The scope of DMM within the context of the MEXT WG is to reuse Mobile IPv6
protocols, extensions and elements to address the concerns of the base
Mobile IP model. 

Mobility using LISP may be a good solution in itself. I have no idea or
opinion about such a solution at the present time.

I believe that we can address the DMM requirements with a few extensions
to MIP6 signaling and guidelines for deployment. Expanding the scope of
DMM beyond the base MIP6 protocol would be taking us down a path with no
visible end.

-Basavaraj

On 8/2/11 4:09 PM, "ext Romain KUNTZ" <[email-masked]> wrote:

>Hello,
>
>I fail to see how LISP would fall in the MEXT charter item, which
>concentrates on MIPv6-based DMM solution ('Operational considerations for
>distributed use of Mobile IPv6'). If LISP is foreseen as a potential
>solution for distributed mobility management, that should probably be
>discussed in the Network WG, where LISP and LISP MN are discussed.
>
>Regards,
>Romain
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 02 Aug 2011 14:41:36 -0700

Hello folks,

I agree that LISP work should not be done in the [mext]
working group.

However, if the LISP design shows how to make a good
solution for distributed anchoring, it is pertinent to
our work insofar as it provides a model for the [mext]
solution.  In that case, if we are fortunate, it would
be easier to devise an appropriate solution by using
the LISP distributed anchoring as a guide.

Please note that I do not yet claim that LISP does
what is needed -- only that we ought to take a look.

Regards,
Charlie P.

On 8/2/2011 2:15 PM, [email-masked] wrote:
> On 8/2/11 4:09 PM, "ext Romain KUNTZ"<[email-masked]>  wrote:
>
>> Hello,
>>
>>> To: "mext"<[email-masked]>
>>> Cc:<[email-masked]>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 2 Aug 2011 14:50:04 -0700

IRON also provides an alternate approach to mobility
management. I'll have to look at what is meant by
distributed anchoring, but IRON essentially allows
MNs to access a topologically-close HA and move
to a new nearby HA if they move far away from the
former one. The MN<->HA relationship is managed
similar to how a MOBIKE client corresponds with
a MOBIKE security gateway.

Thanks - Fred
[email-masked] 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Charles E. Perkins
> Sent: Tuesday, August 02, 2011 2:42 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MEXT] LISP as a solution for some part of the 
> DMM requirement
> 
> 
> Hello folks,
> 
> >>> to use or extend the LISP for mobility support, which 
> inlcude LISP-MN
> >>> draft
> >>> LISP is a network-based ID-LOC separation scheme and thus 
> it may give
> >>> some
> >>> advantages for effective mobility support. On the other 
> hand, it is
> >>> noted that
> >>> in terms of scalability in the mobile environment. For 
> example, one
> >>> concern of LISP
> >>> each mobile node will have its own distinctive EIDs that 
> do not conform
> >>> the concerned mobile domain.
> >>> Nontheless, it is worthwhile to consider LISP as a 
> promisng candidate
> >>> in the disign of DMM, I think.
> >>>
> >>> the problem statements and requirements for DMM, use 
> cases/scenarios,
> >>> and comparison matrix, etc.
> >>>
> >>> Regards,
> >>>

---

From: <[email-masked]>
Date: Tue, 2 Aug 2011 21:58:58 +0000

Hi Charlie,

>the LISP distributed anchoring as a guide.

If the LISP design helps in alleviating the concerns that we have
identified as some of the key issues in I-D
draft-patil-mext-dmm-approaches-01.txt (Sec 3), then maybe yes. If we have
to incorporate LISP based mobility as a solution for DMM, then we have an
issue, because at the present time it can be perceived that the problems
could be solved within the framework of MIP6 signaling and network
elements.

-Basavaraj

>>>> each mobile node will have its own distinctive EIDs that do not
>>>>conform

---

From: "Seok-Joo Koh" <[email-masked]>
Date: Wed, 3 Aug 2011 08:29:27 +0900

Hello there,

To my understanding, this thread of discussion was intended to review LISP
so as to collect a lot of useful information in the perspective of DMM requirements,
NOT to make specific schemes, such as MIP-based, PMIP-based, or LISP-based DMM solutions.

It seems that the issues on DMM requirements are under the scope of MEXT WG, as described in the WG 
charter.
However, it is still unclear to me which WG is appropriate to develop specific solutions for DMM:
MIP-based DMM -> MEXT WG ?
PMIP-based DMM -> NETEXT WG ?
LISP-based DMM -> LISP WG ?
or
all the issues shall fall into the MOPOPT RG ??

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 02 Aug 2011 17:22:35 -0700

> PMIP-based DMM -> NETEXT WG ?

There is no reason to define a PMIP-only or a CMIP-only solution, unless the
extension makes sense only to one of the mobility models. Many of the
protocol options/extensions are relevant to both the approaches. Looking at
revocation work [RFC-5846], it was done in MEXT WG, but the options were
specified for both the client-based and network-based variants of MIPv6
protocol. We need to ensure, we don't take MIPv6 and PMIPv6 in two different
directions. LMA serving network-based mobility domain is a feature extension
on home agent, its the same code base, same function to most part will be
supporting client-based mobile nodes and IP hosts in a PMIPv6 domain. They
are not two different systems, but a common anchor point supporting two
different mobility approaches, over a common protocol semantics.

In any case, as Raj/Romain and others pointed out, we need to look at the
problem statement and identify the needed extensions. At this point, I'm not
going with the assumption that, we need to redesign the protocol, boil the
ocean, or come back with a radically new approach, but rather identify the
needed incremental extensions to fix some of the gaps.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Thu, 4 Aug 2011 09:03:33 -0700

Seok-Joo,

At this point it is not clear that new mechanisms are needed thus the
question on where should solution work be undertaken seems a bit
premature. For now I' d advise people interested in the DMM work to
focus on what are their requirements and then see how the MIPv6
protocol suite can be applied to fulfill those.

--julien

On Tue, Aug 2, 2011 at 4:29 PM, Seok-Joo Koh <[email-masked]> wrote:
> It seems that the issues on DMM requirements are under the scope of MEXT WG,
> as described in the WG charter.
> ----- Original Message ----- From: <[email-masked]>

---

From: "Seok-Joo Koh" <[email-masked]>
Date: Fri, 5 Aug 2011 15:15:50 +0900

Julien,

Your comment is completely agreed.
I believe the first step of DMM shall be to make a couple of WG documents on 
problem statements and requirements, together with applicability to
the current MIP protocol suite. Our energy needs to be focused on those issues.

Thanks,
Seok-Joo Koh

----- Original Message ----- 
From: "Julien Laganier" <[email-masked]>
To: "Seok-Joo Koh" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, August 05, 2011 1:03 AM
Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement

Seok-Joo,

--julien

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 8 Aug 2011 14:09:05 +0200

I agree on that point and a good solution for DMM may require a look
beyond Mobile IP protocols and their extensions. As discussed
with some of you at IETF81, I think a solution which supports DMM
above anchor level should be at least on the table for discussion.
LISP is one candidate that could support IP address continuity
after anchor re-location (handover between two anchors). The issue
to solve is at an appropriate mapping base and to push an update
of the MN's locator state at the ITR(s) to allow session continuity.

Maybe beyond MEXT scope, but reasonale enough for
being included to the discussion.

marco

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 8 Aug 2011 14:09:14 +0200

marco