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

Le 02/08/2011 05:13, Sri Gundavelli a écrit :
> 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

Which meeting?

Alex

  and bring
> new extension to MIPv6/PMIPv6 protocols.
>
>
>
>
> Regards
> Sri
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 8/1/11 4:50 PM, "Seok-Joo Koh"<[email protected]>  wrote:
>
>> 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/
>> *************************
>>
>
> _______________________________________________
> MEXT mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mext
>