[MEXT] Reply from Dino [Re: LISP as a solution for some part of the DMM requirement]

Hello folks,

Dino has replied to Seok-Joo Koh's message, but he is not on
the [mext] mailing list, so I am forwarding his reply.

Regards,
Charlie P.


-------- Original Message --------
Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement
Date: Mon, 1 Aug 2011 19:01:50 -0700
From: Dino Farinacci <[email protected]>
To: Seok-Joo Koh <[email protected]>
CC: Charles E. Perkins <[email protected]>, mext <[email protected]>

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

LISP-MN EIDs do aggregate no matter where the EID roams. The reason is 
because the registering map-server the LISP-MN registers to keeps the 
aggregate. It is the control-plane anchor point. The mapping database 
does not need to store more-specifics anywhere else but the 2 (or 4) 
map-servers the LISP-MN registers to. The mapping database topology is 
based-on/arranged on address allocation hierarchy so aggregation is 
optimized.

> 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 protected]>
> To: "mext" <[email protected]>
> Cc: <[email protected]>
> Sent: Tuesday, August 02, 2011 3:28 AM
> Subject: [MEXT] LISP as a solution for some part of the DMM requirement
>
>
>>
>> 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.
>>
>> _______________________________________________
>> MEXT mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/mext
>