Re: [DMM] Two new drafts

"Seil Jeon" <seiljeon@av.it.pt> Wed, 10 July 2013 12:33 UTC

Return-Path: <seiljeon@av.it.pt>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1496D21F9FFE for <dmm@ietfa.amsl.com>; Wed, 10 Jul 2013 05:33:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqQfWh3PagMH for <dmm@ietfa.amsl.com>; Wed, 10 Jul 2013 05:33:31 -0700 (PDT)
Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0E021F9AFE for <dmm@ietf.org>; Wed, 10 Jul 2013 05:33:29 -0700 (PDT)
Received: from [192.168.20.80] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 70056986; Wed, 10 Jul 2013 13:33:26 +0100
From: Seil Jeon <seiljeon@av.it.pt>
To: "'Sri Gundavelli (sgundave)'" <sgundave@cisco.com>
References: <002501ce7c8b$7b532cf0$71f986d0$@av.it.pt> <24C0F3E22276D9438D6F366EB89FAEA81032CE4E@xmb-aln-x03.cisco.com>
In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA81032CE4E@xmb-aln-x03.cisco.com>
Date: Wed, 10 Jul 2013 13:33:28 +0100
Message-ID: <001b01ce7d69$ae834680$0b89d380$@av.it.pt>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIbO6oMkUKV0Wbe/UrbjBuMgiCTAJjEUeWQ
Content-Language: ko
Cc: dmm@ietf.org
Subject: Re: [DMM] Two new drafts
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2013 12:33:35 -0000

Hi Sri,

In the sense that NAT-based solutions have not been documented in the 3GPP
standards and the NATing with single PDN connection would give complexities
much in handling the flows and dynamically applying policies, I agree with
your opinions. Additionally, I took the potential of putting mobility
properties to prefixes into my head, though it needs to be reviewed more in
the way.

Regards,
Seil


-----Original Message-----
From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] 
Sent: Tuesday, July 09, 2013 8:46 PM
To: Seil Jeon
Cc: 'Alper Yegin'; dmm@ietf.org
Subject: Re: [DMM] Two new drafts

Hi Seil,

In one abstraction, that middleware is the socket layer performing address
binding. The key point is that we need to add additional meta-data to a
prefix and carry them in ND/DHCP from the network to the host. So, the host
has awareness on different types of IP addresses for use and with the
corresponding properties. This helps in DMM solution, also for supporting
SIPTO in WLAN-EPC integrated solutions. We don't have to deal with monster
NAT's in case of IPv6-based flow offload.



Regards
Sri




 

On 7/9/13 3:02 AM, "Seil Jeon" <seiljeon@av.it.pt> wrote:

>Hi Sri,
>
>Picking source address by an application would be the right way to go?
>I've
>known that's the work of the middleware.
>The middleware needs to be aware of the applications and thus to act 
>properly.
>
>Regards
>Seil
>
>-----Original Message-----
>From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of 
>Sri Gundavelli (sgundave)
>Sent: Tuesday, July 09, 2013 6:23 AM
>To: Alper Yegin; dmm@ietf.org
>Subject: Re: [DMM] Two new drafts
>
>Hi Alper,
>
>Thanks for sharing the documents.
>
>I did a quick review of the dmm-ondemand draft. This is inline with my 
>thinking as well. IMO, the following base semantics will allow us to 
>realize some of the DMM deployment models.
>
>- Prefix Coloring/ Coloring of IP addresses based on the properties
>
>- Delivering the properties as meta-data in address assignment 
>procedures (ND, DHCP ..)
>- Evolving the source address selection Rules, allowing application to 
>pick source address based on the requirements
>
>With these semantics, a UE can obtain multiple IP addresses with 
>different properties, bind applications to those addresses based on the 
>application requirements, roam within the network loosing some local 
>addresses and generating some new ones ...
> 
>
>Slides from 2010 I think ..?
>
>http://www.psg.com/~charliep/txt/ietf81/alt_mext/Evolving-The-SAS-Rules
>-fo
>r
>-Mobility-Awareness-2.pdf
>
>
>Good to see this. Hope we make progress on these base work such as 
>prefix coloring Å which are the enablers ..
>
>http://www.ietf.org/id/draft-korhonen-6man-prefix-properties-01.txt
>http://datatracker.ietf.org/doc/draft-bhandari-dhc-class-based-prefix/
>
>
>Your proposal can leverage the above work.
>
>
>
>Regards
>Sri
>
>
>
>
>
>
>
>On 7/8/13 8:30 AM, "Alper Yegin" <alper.yegin@yegin.org> wrote:
>
>>Hello dear DMM folks,
>>
>>We published the following two new drafts which relate to the DMM WG.
>>
>>http://www.ietf.org/id/draft-yegin-dmm-cnet-homing-00.txt
>>
>>http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-00.txt
>>
>>We'd appreciate if you can read and share your comments.
>>
>>(Related IPR statements will be posted on the IETF site soon)
>>
>>Cheers,
>>
>>Alper
>>
>>
>>_______________________________________________
>>dmm mailing list
>>dmm@ietf.org
>>https://www.ietf.org/mailman/listinfo/dmm
>
>_______________________________________________
>dmm mailing list
>dmm@ietf.org
>https://www.ietf.org/mailman/listinfo/dmm
>