From nobody Wed May 6 07:37:24 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708851ACDAB; Wed, 6 May 2015 07:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O470C5vdU3zQ; Wed, 6 May 2015 07:37:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AED1ACDB9; Wed, 6 May 2015 07:36:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150506143642.21240.67068.idtracker@ietfa.amsl.com> Date: Wed, 06 May 2015 07:36:42 -0700 Archived-At: Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 14:37:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management Working Group of the IETF. Title : On Demand Mobility Management Authors : Alper Yegin Kisuk Kweon Jinsung Lee Jungshin Park Danny Moses Filename : draft-ietf-dmm-ondemand-mobility-00.txt Pages : 10 Date : 2015-05-06 Abstract: Applications differ with respect to whether they need IP session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies. This document describes a solution for taking the application needs into account in selectively providing IP session continuity and IP address reachability on a per- socket basis. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 6 07:50:17 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB31A1ACDA3 for ; Wed, 6 May 2015 07:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxJNe7BEGOup for ; Wed, 6 May 2015 07:50:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A24291ACDAB for ; Wed, 6 May 2015 07:48:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150506144856.27737.18602.idtracker@ietfa.amsl.com> Date: Wed, 06 May 2015 07:48:56 -0700 From: IETF Secretariat Archived-At: Subject: [DMM] Milestones changed for dmm WG X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 14:50:16 -0000 Changed milestone "Submit 'Exposing mobility state to mobile nodes and network nodes' as a working group document(s).", resolved as "Done", added draft-ietf-dmm-ondemand-mobility to milestone. URL: https://datatracker.ietf.org/wg/dmm/charter/ From nobody Wed May 6 09:56:32 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6731B2CB1 for ; Wed, 6 May 2015 09:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cULRJKSVBAxV for ; Wed, 6 May 2015 09:56:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 880981B2CC5 for ; Wed, 6 May 2015 09:56:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150506165628.3961.21360.idtracker@ietfa.amsl.com> Date: Wed, 06 May 2015 09:56:28 -0700 From: IETF Secretariat Archived-At: Subject: [DMM] Milestones changed for dmm WG X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 16:56:31 -0000 Changed milestone "Submit 'RFC4283bis on MN-IDs as a working group document'.", set state to active from review, accepting new milestone. Changed milestone "'RFC4283bis on MN-IDs as a working group document' submitted to the IESG.", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/dmm/charter/ From nobody Wed May 6 11:16:20 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851E51B2E06; Wed, 6 May 2015 11:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuK6rxpBaVCo; Wed, 6 May 2015 11:16:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4E11B2E02; Wed, 6 May 2015 11:16:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150506181618.10401.55043.idtracker@ietfa.amsl.com> Date: Wed, 06 May 2015 11:16:18 -0700 Archived-At: Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-fpc-cpdp-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 18:16:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management Working Group of the IETF. Title : Protocol for Forwarding Policy Configuration (FPC) in DMM Authors : Marco Liebsch Satoru Matsushima Sri Gundavelli Danny Moses Filename : draft-ietf-dmm-fpc-cpdp-00.txt Pages : 26 Date : 2015-05-06 Abstract: The specification as per this document supports the separation of the Control-Plane for mobility- and session management from the actual Data-Plane. The protocol semantics abstract from the actual details for the configuration of Data-Plane nodes and apply between a Client function, which is used by an application of the mobility Control- Plane, and an Agent function, which is associated with the configuration of Data-Plane nodes according to the policies issued by the mobility Control-Plane. The scope of the policies comprises forwarding rules and treatment of packets in terms of encapsulation, IP address re-writing and QoS. Additional protocol semantics are described to support the maintenance of the Data-Plane path. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 6 11:18:17 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DBB1A88F1 for ; Wed, 6 May 2015 11:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbXbuVpGWtBv for ; Wed, 6 May 2015 11:18:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 263011A8942 for ; Wed, 6 May 2015 11:18:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150506181814.16788.9418.idtracker@ietfa.amsl.com> Date: Wed, 06 May 2015 11:18:14 -0700 From: IETF Secretariat Archived-At: Subject: [DMM] Milestones changed for dmm WG X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 18:18:17 -0000 Changed milestone "Submit 'Forwarding path and signaling management' as a working group document.", resolved as "Done", added draft-ietf-dmm-fpc-cpdp to milestone. URL: https://datatracker.ietf.org/wg/dmm/charter/ From nobody Sun May 10 19:24:07 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762A81A00BD for ; Sun, 10 May 2015 19:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5qGATr8zt00 for ; Sun, 10 May 2015 19:24:04 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8A51A0095 for ; Sun, 10 May 2015 19:24:04 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so97837799pac.1 for ; Sun, 10 May 2015 19:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=7vUwQTrdVQuuN/v6CrLeKY+iwrI6ZjpkzHG14nlrUPw=; b=INv9LGTOCQV5SAbLctKM+dG5yFuJsNlbuOw/BOhW4WcUSnAbT6VqI20cNY44pYDFCK 3Ht9ijmoV7+B9YGwS7MxdkD4pvm+DBkwjYyX/R7RPwEc6D0Nl841tKLqTrnYXvA24ekW c4P2jHVN8Qu0g41m5ySzNcgM2tS9sRzNZme0mCqsSCXbP3L1Qy/GSkG6KRp4ZDZoUxuX McJVDnvEz7exwdSW0qCDnMJ+VTtM1KL+3t8PQADXHBpuHtGoT2Zk/VqE/qcsE/Ovkqkp 2Uo1ry/qztpydjP+lMx4mu9Qbrf4GDG1q5smb4CQgunYlKI1I1Pp3jOjPueVknNInD2g H1vA== X-Received: by 10.66.141.231 with SMTP id rr7mr15561643pab.86.1431311044552; Sun, 10 May 2015 19:24:04 -0700 (PDT) Received: from ?IPv6:2601:9:3400:6c:c035:82b9:db41:accc? ([2601:9:3400:6c:c035:82b9:db41:accc]) by mx.google.com with ESMTPSA id ym6sm11369275pac.32.2015.05.10.19.24.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 May 2015 19:24:03 -0700 (PDT) From: Jouni Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sun, 10 May 2015 19:24:01 -0700 Message-Id: <7C0E71A9-89F4-4309-A003-EF6FA0CBDD8D@gmail.com> To: dmm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [DMM] Handling of the WG documents and the comment resolution X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 02:24:06 -0000 Folks, We are going to try incorporating Issue Tracker as a tool for tracking = all changes to WG documents even _prior_ they get into the WGLC state. = The procedure is rather straight forward. If you want to make sure your = comment really gets addressed and discussed, issue a ticket into the = Issue Tracker -> that gives you a ticket number and subject field to = refer to in the email discussions. If you want text to be changed = (added/deleted/reworded) enter the EXACT change proposal text into the = ticket you create. Remember to mention the _document_version_ the ticket = is about. The progress of the discussion and the conclusion will be = updated to the ticket before it gets closed - updating ticket multiple = times to reflect the current status is also possible. The closing of a = ticket is by consensus and typically done by the ticket issuer (and = sometimes by the chairs/editors). The document editors then incorporate = approved closed tickets into the WG draft. If you are new to Issue Tracker surf to: http://tools.ietf.org/wg/dmm/trac/report and create an account (through the login procedure). Read: http://trac.tools.ietf.org/wg/dmm/trac/wiki/TracTickets and start contributing. Current DMM =E2=80=9Ccomponents=E2=80=9D are: 4283mnids -> draft-ietf-dmm-4283mnids fpc-cpdp -> draft-ietf-dmm-fpc-cpdp ondemand-mobility -> draft-ietf-dmm-ondemand-mobility Select =E2=80=9Cseverity=E2=80=9D as =E2=80=9CSubmitted WG Document=E2=80=9D= . Ignore both =E2=80=9Cmilestone" & =E2=80=9Cversion=E2=80=9D pulldown = selections. - Jouni & Dapeng= From nobody Mon May 11 07:21:41 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475FB1A891D for ; Mon, 11 May 2015 07:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLSw9-B93YkB for ; Mon, 11 May 2015 07:21:37 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C98F1A8915 for ; Mon, 11 May 2015 07:21:37 -0700 (PDT) Received: from [192.168.2.7] ([85.101.123.213]) by mrelay.perfora.net (mreueus003) with ESMTPA (Nemesis) id 0Lm5Tj-1ZR9P40hzF-00ZhFH for ; Mon, 11 May 2015 16:21:36 +0200 From: Alper Yegin Content-Type: multipart/alternative; boundary="Apple-Mail=_E67E7615-C503-4876-82FE-21CB074162BB" Date: Mon, 11 May 2015 17:21:18 +0300 Message-Id: <97709AAC-7B8A-4195-8062-53327A8CB4FA@yegin.org> To: dmm@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:2I3z4euJNWuY+LuHmNsI53vN/vjIMLdkI/My6tAMXCdHJSqi5Ui OOWJkoMOoqcd3O5sSRd6EgKimgNC6KWrxxSBVOYBzu69rkJBSkxHlFZmWwAiYffTrxA0DWT 9ED4NvOxrKcgZNTrRDpBmK7sXBDr8QLDll01ATVevNo7eRirKxbU5/AyAUDLJl/VVC1nJRf Jjek7SUNmjQgqsDNveJzg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [DMM] WT#1 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 14:21:39 -0000 --Apple-Mail=_E67E7615-C503-4876-82FE-21CB074162BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, As you have seen, the first deliverable of our WT#1, on demand mobility = API is published as a WG I-D: https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/ For all of your outstanding issues, please use the issue tracker per = chairs' request. We'll be picking up the discussion initially on the DMM = ML, and carrying over to a scheduled tele chat as needed. Meanwhile, as for the other deliverables of the WT#1, more specifically = the protocol extensions for carrying out IP address types, we need more = discussion. There's already one proposal on the table: https://datatracker.ietf.org/doc/draft-moses-dmm-dhcp-ondemand-mobility/ Comments on that I-D, and additional proposal (if any) are welcome. Once again, we can setup a tele chat for that item as well -- depending = on the need. Consider this as an invitation to generate discussions to progress the = work, and I'm here to help :-) Alper --Apple-Mail=_E67E7615-C503-4876-82FE-21CB074162BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/

For all of your outstanding issues, please = use the issue tracker per chairs' request. We'll be picking up = the discussion initially on the DMM ML, and carrying over to a scheduled = tele chat as needed.

Meanwhile, as for the = other deliverables of the WT#1, more specifically the protocol = extensions for carrying out IP address types, we need more discussion. = There's already one proposal on the table:


Comments on that I-D, and additional = proposal (if any) are welcome.
Once again, we can setup a tele = chat for that item as well -- depending on the = need.

Consider this as an invitation to = generate discussions to progress the work, and I'm here to help = :-)

Alper

= --Apple-Mail=_E67E7615-C503-4876-82FE-21CB074162BB-- From nobody Tue May 12 12:51:57 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83241ACEA6 for ; Tue, 12 May 2015 12:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhUBRVhMSyTs for ; Tue, 12 May 2015 12:51:56 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA30D1A87D2 for ; Tue, 12 May 2015 12:51:55 -0700 (PDT) Received: by layy10 with SMTP id y10so14123822lay.0 for ; Tue, 12 May 2015 12:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=k2HtVBmzzqr0CZM6Z+HG8fUX3diBwsjKRFq4Ec/8A8M=; b=aM5+pSNVw8mpAy0jFTDgKfk1MTYSKLA8oQtP4UMJ9ZmSlHmMYFhTjHE1VCUueSncNJ XHM3DEVCqdXWTwIfb43aXVvwWXfzwjBwoDLLAd+RAwGILxAqInNmkAI8t2Ieraey77vs L1uzbfZSDnEKHJUu6dAnbjmBvUgfPF9mBh7QJOz5eg4lyGzx2rlwQWXGeaniq+ldJbfY TBAup9Z+joFii4U+fnf6w/EKF9deD1DLd//vgw2hAdK8s48kP2MI+VBRSdXbZpnqbQzv hOGH8+vIWvUOnXTBR9KiqFPpeYSVbyvJhkegCnJYY6jfq2B/4ucbZMjp5+5ZGSc8rPKB hUCQ== MIME-Version: 1.0 X-Received: by 10.112.147.73 with SMTP id ti9mr13404284lbb.108.1431460314267; Tue, 12 May 2015 12:51:54 -0700 (PDT) Received: by 10.114.74.225 with HTTP; Tue, 12 May 2015 12:51:54 -0700 (PDT) Date: Tue, 12 May 2015 14:51:54 -0500 Message-ID: From: Behcet Sarikaya To: Satoru Matsushima Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dmm@ietf.org" Subject: [DMM] vepc draft Rev. 04 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:51:56 -0000 Hi Matsushima-san, I have a question on your draft: In Sec. 3.2, page 11, you say In step (15), the EPC-E advertises routes to upstream routers ... Are these routes static/host routes? Regards, Behcet From nobody Thu May 14 18:05:25 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4B31B2E8E for ; Thu, 14 May 2015 18:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3DHFLq09gJG for ; Thu, 14 May 2015 18:05:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB251B2E87 for ; Thu, 14 May 2015 18:05:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWB12156; Fri, 15 May 2015 01:05:07 +0000 (GMT) Received: from SZXEML430-HUB.china.huawei.com (10.82.67.185) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 May 2015 02:05:06 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.158]) by szxeml430-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.03.0158.001; Fri, 15 May 2015 09:05:02 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: Enhanced mobility anchoring Thread-Index: AQHQZ+2Q2EAkZ5QP+UmZfjSKm6JQuZ0vC9KAgCEBEbCALHlOoA== Date: Fri, 15 May 2015 01:05:02 +0000 Message-ID: <6E31144C030982429702B11D6746B98C521F2EF5@szxeml557-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.83] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C521F2EF5szxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [DMM] Enhanced mobility anchoring X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 01:05:11 -0000 --_000_6E31144C030982429702B11D6746B98C521F2EF5szxeml557mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIGNoZWNrIHlvdXIgYXZhaWxhYmlsaXR5IGZvciBhIHRlbGVjb25mZXJlbmNlIHRvIGRp c2N1c3MgZW5oYW5jZWQgbW9iaWxpdHkgYW5jaG9yaW5nLiBUaGFua3MuDQoNCkggQW50aG9ueSBD aGFuDQoNCg== --_000_6E31144C030982429702B11D6746B98C521F2EF5szxeml557mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlBsZWFzZSBjaGVjayB5b3VyIGF2YWlsYWJpbGl0eSBmb3IgYSB0ZWxlY29uZmVy ZW5jZSB0byBkaXNjdXNzIGVuaGFuY2VkIG1vYmlsaXR5IGFuY2hvcmluZy4gVGhhbmtzLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SCBBbnRob255IENoYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6E31144C030982429702B11D6746B98C521F2EF5szxeml557mbxchi_-- From nobody Fri May 15 09:11:36 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D561A1EEE for ; Fri, 15 May 2015 09:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeTarUZa65K9 for ; Fri, 15 May 2015 09:11:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B0421A1EF4 for ; Fri, 15 May 2015 09:10:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWB86802; Fri, 15 May 2015 16:10:56 +0000 (GMT) Received: from SZXEML430-HUB.china.huawei.com (10.82.67.185) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 May 2015 17:10:16 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.131]) by szxeml430-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.03.0158.001; Sat, 16 May 2015 00:09:56 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: Enhanced mobility anchoring Thread-Index: AQHQZ+2Q2EAkZ5QP+UmZfjSKm6JQuZ0vC9KAgCEBEbCALHlOoIAA/GEQ Date: Fri, 15 May 2015 16:09:55 +0000 Message-ID: <6E31144C030982429702B11D6746B98C521F4018@szxeml557-mbs.china.huawei.com> References: <6E31144C030982429702B11D6746B98C521F2EF5@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C521F2EF5@szxeml557-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.235] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C521F4018szxeml557mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [DMM] Enhanced mobility anchoring X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 16:11:35 -0000 --_000_6E31144C030982429702B11D6746B98C521F4018szxeml557mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIGNoZWNrIHlvdXIgYXZhaWxhYmlsaXR5IGZvciBhIHRlbGVjb25mZXJlbmNlIHRvIGRp c2N1c3MgZW5oYW5jZWQgbW9iaWxpdHkgYW5jaG9yaW5nLiBUaGFua3MuDQoNCmh0dHA6Ly9kb29k bGUuY29tL2ZpYmZid3lid2h3czY1Z2INCg0KSCBBbnRob255IENoYW4NCg0K --_000_6E31144C030982429702B11D6746B98C521F4018szxeml557mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Q bGVhc2UgY2hlY2sgeW91ciBhdmFpbGFiaWxpdHkgZm9yIGEgdGVsZWNvbmZlcmVuY2UgdG8gZGlz Y3VzcyBlbmhhbmNlZCBtb2JpbGl0eSBhbmNob3JpbmcuIFRoYW5rcy4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+aHR0 cDovL2Rvb2RsZS5jb20vZmliZmJ3eWJ3aHdzNjVnYjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkggQW50aG9u eSBDaGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_6E31144C030982429702B11D6746B98C521F4018szxeml557mbschi_-- From nobody Sat May 16 06:01:20 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2451A0242 for ; Sat, 16 May 2015 06:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bQwyltA7rAM for ; Sat, 16 May 2015 06:01:17 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6895A1A0105 for ; Sat, 16 May 2015 06:01:17 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so17655508igb.0 for ; Sat, 16 May 2015 06:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XDz4Hx2u/W7x2BVgrpUGJ+p1ozyx0sTEPCdclnnf43A=; b=sf63d2X45mc9SuaH+dhH0IdFGPLwQXT32qTiOx03Sg2ln7H2YltuaZQHoU/7aLgjmF PYT4MQdfq87hSaZWuCV8Dp4JjzSV3KclgR+tGA9Zj96EWYPCfEbyeDMSXJzYIM1c/oyV 17AL+nonM0Rmo71s1lGfo0ixHp2R7fzix2s+USLzvz8gMDBAZKzhGqAdim8jNj2YFOmM EF1EJEvhk5SOAX0GuUUgDaRAG2sg2I//U+sDtTV+ToYb2DMBItCl7bwHu7PgTEWC08Nh Ei9LmDlYgMqHoN4ZD8t4Utpup0F8XdqukzD6pXtAm36GZfTaOjdFBS1wZH+iQvI0tqtM gopw== MIME-Version: 1.0 X-Received: by 10.107.8.87 with SMTP id 84mr15264137ioi.87.1431781276876; Sat, 16 May 2015 06:01:16 -0700 (PDT) Received: by 10.36.64.79 with HTTP; Sat, 16 May 2015 06:01:16 -0700 (PDT) In-Reply-To: References: Date: Sat, 16 May 2015 22:01:16 +0900 Message-ID: From: Satoru Matsushima To: "sarikaya@ieee.org" Content-Type: multipart/alternative; boundary=001a113f2c5a67866f0516328e77 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] vepc draft Rev. 04 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 13:01:19 -0000 --001a113f2c5a67866f0516328e77 Content-Type: text/plain; charset=UTF-8 Hi Bechet-san, Thank you for your question. In step (15), I meant that EPC-E advertises prefix including UE assigned prefixes. For example, in the case of /64 prefixes assigned to UEs from a /56 space, that /56 is advertised by EPC-E to upstream routers. So the advertised route isn't host routes. Depends on configuration policy, but one case is that the source of that advertised /56 route might be statically configured in EPC-E. Regards, --satoru On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya wrote: > Hi Matsushima-san, > > I have a question on your draft: > In Sec. 3.2, page 11, you say > In step (15), the EPC-E advertises routes to upstream routers ... > > Are these routes static/host routes? > > Regards, > > Behcet > --001a113f2c5a67866f0516328e77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bechet-san,

Thank you for your quest= ion.
In step (15), I meant that EPC-E advertises prefix including= UE assigned prefixes.

For example, in the case of= /64 prefixes assigned to UEs from a /56 space, that /56
is adver= tised by EPC-E to upstream routers. So the advertised route isn't host = routes.

Depends on configuration policy, but one c= ase is that the source of that advertised=C2=A0
/56 route might b= e statically configured in EPC-E.

Regards,
--satoru



On Wed, May 13, 2015 at 4:51 AM, Behcet= Sarikaya <sarikaya2012@gmail.com> wrote:
=C2=A0Hi Matsushima-san,

I have a question on your draft:
In Sec. 3.2, page 11, you say
In step (15), the EPC-E advertises routes to upstream routers ...

Are these routes static/host routes?

Regards,

Behcet

--001a113f2c5a67866f0516328e77-- From nobody Tue May 19 10:37:23 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171CE1A1ABB for ; Tue, 19 May 2015 10:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5OxxazAyepI for ; Tue, 19 May 2015 10:37:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2153D1A039A for ; Tue, 19 May 2015 10:37:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSS70133; Tue, 19 May 2015 17:37:06 +0000 (GMT) Received: from SZXEML425-HUB.china.huawei.com (10.82.67.180) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 May 2015 18:37:06 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.62]) by szxeml425-hub.china.huawei.com ([10.82.67.180]) with mapi id 14.03.0158.001; Wed, 20 May 2015 01:37:02 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: Enhanced mobility anchoring Thread-Index: AQHQZ+2Q2EAkZ5QP+UmZfjSKm6JQuZ0vC9KAgCEBEbCALHlOoIAA/GEQgAZg00A= Date: Tue, 19 May 2015 17:37:01 +0000 Message-ID: <6E31144C030982429702B11D6746B98C521FD4D9@szxeml557-mbx.china.huawei.com> References: <6E31144C030982429702B11D6746B98C521F2EF5@szxeml557-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.209] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C521FD4D9szxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] Enhanced mobility anchoring X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 17:37:23 -0000 --_000_6E31144C030982429702B11D6746B98C521FD4D9szxeml557mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGV0IHVzIHNjaGVkdWxlIDIgdGVsZWNvbmZlcmVuY2VzIChvbmUgaG91ciBlYWNoKSB0byBhY2Nv bW1vZGF0ZSBldmVyeW9uZSBpbiB0aGUgZG9vZGxlIGxpc3Q6DQoNCjFzdCB0ZWxlY29uZmVyZW5j ZTogRnJpZGF5IE1heSAyMiBhdCA5OjMwLTEwOjMwQU0gVVMgQ2VudHJhbCBUaW1lDQoNCjJuZCB0 ZWxlY29uZmVyZW5jZTogV2VkbmVzZGF5IE1heSAyNyBhdCA5OjMwLTEwOjMwQU0gVVMgQ2VudHJh bCBUaW1lDQoNClRoYW5rcy4NCg0KSCBBbnRob255IENoYW4NCg0KRnJvbTogaCBjaGFuDQpTZW50 OiBGcmlkYXksIE1heSAxNSwgMjAxNSAxMTowOCBBTQ0KVG86IGRtbUBpZXRmLm9yZw0KU3ViamVj dDogRW5oYW5jZWQgbW9iaWxpdHkgYW5jaG9yaW5nDQoNClBsZWFzZSBjaGVjayB5b3VyIGF2YWls YWJpbGl0eSBmb3IgYSB0ZWxlY29uZmVyZW5jZSB0byBkaXNjdXNzIGVuaGFuY2VkIG1vYmlsaXR5 IGFuY2hvcmluZy4gVGhhbmtzLg0KDQpodHRwOi8vZG9vZGxlLmNvbS9maWJmYnd5Yndod3M2NWdi DQoNCkggQW50aG9ueSBDaGFuDQoNCg== --_000_6E31144C030982429702B11D6746B98C521FD4D9szxeml557mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TGV0IHVzIHNjaGVk dWxlIDIgdGVsZWNvbmZlcmVuY2VzIChvbmUgaG91ciBlYWNoKSB0byBhY2NvbW1vZGF0ZSBldmVy eW9uZSBpbiB0aGUgZG9vZGxlIGxpc3Q6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4xc3QgdGVsZWNvbmZlcmVuY2U6IEZy aWRheSBNYXkgMjIgYXQgOTozMC0xMDozMEFNIFVTIENlbnRyYWwgVGltZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Mm5k IHRlbGVjb25mZXJlbmNlOiBXZWRuZXNkYXkgTWF5IDI3IGF0IDk6MzAtMTA6MzBBTSBVUyBDZW50 cmFsIFRpbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkggQW50aG9ueSBD aGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBoIGNoYW4NCjxicj4NCjxiPlNlbnQ6PC9i PiBGcmlkYXksIE1heSAxNSwgMjAxNSAxMTowOCBBTTxicj4NCjxiPlRvOjwvYj4gZG1tQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IEVuaGFuY2VkIG1vYmlsaXR5IGFuY2hvcmluZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QbGVhc2UgY2hlY2sgeW91ciBhdmFpbGFiaWxp dHkgZm9yIGEgdGVsZWNvbmZlcmVuY2UgdG8gZGlzY3VzcyBlbmhhbmNlZCBtb2JpbGl0eSBhbmNo b3JpbmcuIFRoYW5rcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cDovL2Rvb2RsZS5jb20vZmli ZmJ3eWJ3aHdzNjVnYiI+aHR0cDovL2Rvb2RsZS5jb20vZmliZmJ3eWJ3aHdzNjVnYjwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5IIEFudGhvbnkgQ2hhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6E31144C030982429702B11D6746B98C521FD4D9szxeml557mbxchi_-- From nobody Tue May 19 12:07:46 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19951A015F for ; Tue, 19 May 2015 10:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-1uMQCNOihj for ; Tue, 19 May 2015 10:43:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB921A0115 for ; Tue, 19 May 2015 10:43:13 -0700 (PDT) Received: from localhost ([::1]:41500 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YulXr-0006ae-Iv; Tue, 19 May 2015 10:43:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dmm issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dmm-ondemand-mobility@tools.ietf.org, seiljeon@av.it.pt X-Trac-Project: dmm Date: Tue, 19 May 2015 17:43:11 -0000 X-URL: http://tools.ietf.org/dmm/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dmm/trac/ticket/49 Message-ID: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> X-Trac-Ticket-ID: 49 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dmm-ondemand-mobility@tools.ietf.org, seiljeon@av.it.pt, dmm@ietf.org X-SA-Exim-Mail-From: trac+dmm@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20150519174313.7DB921A0115@ietfa.amsl.com> Resent-Date: Tue, 19 May 2015 10:43:13 -0700 (PDT) Resent-From: trac+dmm@tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 19 May 2015 12:07:40 -0700 Cc: dmm@ietf.org Subject: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 17:43:19 -0000 #49: full on-demand mobility support The three proposed flags express a “type” of source IP address an application wants to get to the IP stack. Particularly, the sustained IP address is proposed to provide on-demand IP session continuity, which activates IP mobility once the terminal moves across other access network. While the terminal stays at the same network where the session is initiated, regular IP routing is applied. The on-demand draft does not assure provide the full on-demand mobility for all scenarios by merely indicating the Socket API, IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned issue is as follows; 0. The MN is configured with one or more Nomadic IP addresses. 1. Once an app. requests “sustained IP address” to the IP stack, and it will obtain a sustained IP address through a protocol procedure between the terminal and network. 2. Other app. initiated over the same access network will use the same sustained IP address while the terminal remains connected at the same access network. 3. The terminal moves to another access network and a new app. requests a sustained IP address with the Socket API to the IP stack. Since a sustained IP address is already available in the IP stack, the sustained IP address is assigned to the new app. Besides, in case sustained IP address allocation is used default, there may be multiple sustained IP addresses including newly obtained sustained IP address over the new access network in the IP stack. However, when an app. is initiated, the IP stack may not select the new one in the context of the default source IP address selection mechanism [RFC6724][RFC5014]. For providing the full on-demand mobility, a new flag is needed, letting the IP stack request a new sustained IP address or choose a sustained IP address not requiring IP mobility anchoring when an application is initiated, among the existing ones in the IP stack. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-dmm-ondemand- seiljeon@av.it.pt | mobility@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: Component: ondemand- | Version: mobility | Keywords: on-demand mobility Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: dmm From nobody Wed May 20 01:43:07 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD0A1B35A2 for ; Wed, 20 May 2015 01:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-fZMYhRg9ln for ; Wed, 20 May 2015 01:43:03 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id D2C161B359F for ; Wed, 20 May 2015 01:43:02 -0700 (PDT) Received: from [192.168.29.121] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77693778 for dmm@ietf.org; Wed, 20 May 2015 09:43:00 +0100 From: "Seil Jeon" To: References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> In-Reply-To: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> Date: Wed, 20 May 2015 09:43:00 +0100 Message-ID: <001501d092d8$fae22420$f0a66c60$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXyJVonWC/jWHjoPLHEPQMMWOBzJz2IByQ Content-Language: ko Archived-At: Subject: [DMM] FW: [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 08:43:05 -0000 Hi DMM folks, Yesterday, I created a ticket on the on-demand mobility issue. I believe = this is critical to be essentially implemented in the on-demand WG = draft. We can start a discussion based on the raised description. Best Regards, Seil Jeon=20 -----Original Message----- From: dmm issue tracker [mailto:trac+dmm@tools.ietf.org]=20 Sent: Tuesday, May 19, 2015 6:43 PM To: draft-ietf-dmm-ondemand-mobility@tools.ietf.org; seiljeon@av.it.pt Cc: dmm@ietf.org Subject: [dmm] #49 (ondemand-mobility): full on-demand mobility support #49: full on-demand mobility support The three proposed flags express a =E2=80=9Ctype=E2=80=9D of source IP = address an application wants to get to the IP stack. Particularly, the = sustained IP address is proposed to provide on-demand IP session = continuity, which activates IP mobility once the terminal moves across = other access network. While the terminal stays at the same network where the session is = initiated, regular IP routing is applied. The on-demand draft does not assure provide the full on-demand mobility = for all scenarios by merely indicating the Socket API, = IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned = issue is as follows; 0. The MN is configured with one or more Nomadic IP addresses. 1. Once an app. requests =E2=80=9Csustained IP address=E2=80=9D to the = IP stack, and it will obtain a sustained IP address through a protocol = procedure between the terminal and network. 2. Other app. initiated over the same access network will use the same = sustained IP address while the terminal remains connected at the same = access network. 3. The terminal moves to another access network and a new app. requests = a sustained IP address with the Socket API to the IP stack. Since a = sustained IP address is already available in the IP stack, the sustained = IP address is assigned to the new app. Besides, in case sustained IP address allocation is used default, there = may be multiple sustained IP addresses including newly obtained = sustained IP address over the new access network in the IP stack. = However, when an app. is initiated, the IP stack may not select the new = one in the context of the default source IP address selection mechanism = [RFC6724][RFC5014]. For providing the full on-demand mobility, a new flag is needed, = letting the IP stack request a new sustained IP address or choose a = sustained IP address not requiring IP mobility anchoring when an = application is initiated, among the existing ones in the IP stack. --=20 -------------------------+---------------------------------------------- -------------------------+--- Reporter: | Owner: draft-ietf-dmm-ondemand- seiljeon@av.it.pt | mobility@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: Component: ondemand- | Version: mobility | Keywords: on-demand mobility Severity: Submitted | WG Document | -------------------------+---------------------------------------------- -------------------------+--- Ticket URL: dmm From nobody Thu May 21 09:01:06 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181611B29FA for ; Thu, 21 May 2015 09:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zom--mv75grA for ; Thu, 21 May 2015 09:01:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E821A88F9 for ; Thu, 21 May 2015 09:00:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWJ04804; Thu, 21 May 2015 16:00:57 +0000 (GMT) Received: from SZXEML425-HUB.china.huawei.com (10.82.67.180) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 May 2015 17:00:57 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.62]) by szxeml425-hub.china.huawei.com ([10.82.67.180]) with mapi id 14.03.0158.001; Fri, 22 May 2015 00:00:33 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: Enhanced mobility anchoring Thread-Index: AQHQZ+2Q2EAkZ5QP+UmZfjSKm6JQuZ0vC9KAgCEBEbCALHlOoIAA/GEQgAZg00CAAwWtIA== Date: Thu, 21 May 2015 16:00:32 +0000 Message-ID: <6E31144C030982429702B11D6746B98C521FD744@szxeml557-mbx.china.huawei.com> References: <6E31144C030982429702B11D6746B98C521F2EF5@szxeml557-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.161] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C521FD744szxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [DMM] Enhanced mobility anchoring X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 16:01:04 -0000 --_000_6E31144C030982429702B11D6746B98C521FD744szxeml557mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGJyaWRnZSBudW1iZXIgZm9yIEZyaWRheSBNYXkgMjIgOTozMC0xMDozMCBDZW50cmFsIERh eWxpZ2h0IFRpbWU6DQoNClVTQSBUb2xsLUZyZWU6DQoNCjg4OC04NTgtNjE4Mg0KDQpVU0EgQ2Fs bGVyIFBhaWQ6DQoNCjY0Ni03NDYtMzAyOQ0KDQpGb3IgT3RoZXIgQ291bnRyaWVzOg0KDQpDbGlj ayBIZXJlIHRvIFZpZXcgR2xvYmFsIENvbmZlcmVuY2UgQWNjZXNzIE51bWJlcnM8aHR0cHM6Ly93 d3cudGVsZWNvbmZlcmVuY2UuYXR0LmNvbS9zZXJ2bGV0L2dsYkFjY2Vzcz9wcm9jZXNzPTEmYWNj ZXNzQ29kZT0xMTM2Njk0JmFjY2Vzc051bWJlcj02NDY3NDYzMDI5I0MyPg0KDQpBY2Nlc3MgQ29k ZToNCg0KODc3NDY1MQ0KDQoNClNlaWwgd2lsbCBnaXZlIHNob3J0IHByZXNlbnRhdGlvbiBiYXNl ZCBvbiB0aGUgZHJhZnQNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15aGtpbS1k bW0tZW5oYW5jZWQtYW5jaG9yaW5nLTAxDQoNCmZvbGxvd2VkIGJ5IGZlZWRiYWNrIGFuZCBkaXNj dXNzaW9ucyBvbiB0aGUgd29yayBvbiBlbmhhbmNlZCBtb2JpbGl0eSBhbmNob3JpbmcuDQoNCkgg QW50aG9ueSBDaGFuDQoNCkZyb206IGggY2hhbg0KU2VudDogVHVlc2RheSwgTWF5IDE5LCAyMDE1 IDEyOjM3IFBNDQpUbzogJ2RtbUBpZXRmLm9yZycNClN1YmplY3Q6IFJFOiBFbmhhbmNlZCBtb2Jp bGl0eSBhbmNob3JpbmcNCg0KTGV0IHVzIHNjaGVkdWxlIDIgdGVsZWNvbmZlcmVuY2VzIChvbmUg aG91ciBlYWNoKSB0byBhY2NvbW1vZGF0ZSBldmVyeW9uZSBpbiB0aGUgZG9vZGxlIGxpc3Q6DQoN CjFzdCB0ZWxlY29uZmVyZW5jZTogRnJpZGF5IE1heSAyMiBhdCA5OjMwLTEwOjMwQU0gVVMgQ2Vu dHJhbCBUaW1lDQoNCjJuZCB0ZWxlY29uZmVyZW5jZTogV2VkbmVzZGF5IE1heSAyNyBhdCA5OjMw LTEwOjMwQU0gVVMgQ2VudHJhbCBUaW1lDQoNClRoYW5rcy4NCg0KSCBBbnRob255IENoYW4NCg0K RnJvbTogaCBjaGFuDQpTZW50OiBGcmlkYXksIE1heSAxNSwgMjAxNSAxMTowOCBBTQ0KVG86IGRt bUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0KU3ViamVjdDogRW5oYW5jZWQgbW9iaWxp dHkgYW5jaG9yaW5nDQoNClBsZWFzZSBjaGVjayB5b3VyIGF2YWlsYWJpbGl0eSBmb3IgYSB0ZWxl Y29uZmVyZW5jZSB0byBkaXNjdXNzIGVuaGFuY2VkIG1vYmlsaXR5IGFuY2hvcmluZy4gVGhhbmtz Lg0KDQpodHRwOi8vZG9vZGxlLmNvbS9maWJmYnd5Yndod3M2NWdiDQoNCkggQW50aG9ueSBDaGFu DQoNCg== --_000_6E31144C030982429702B11D6746B98C521FD744szxeml557mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHls ZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgYnJpZGdl IG51bWJlciBmb3IgRnJpZGF5IE1heSAyMiA5OjMwLTEwOjMwIENlbnRyYWwgRGF5bGlnaHQgVGlt ZToNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFj aW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjU0NyIgc3R5bGU9IndpZHRoOjMyOC4wcHQ7 Ym9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1 LjBwdCI+DQo8dGQgd2lkdGg9IjE5NiIgc3R5bGU9IndpZHRoOjExNy4zcHQ7cGFkZGluZzowaW4g MGluIDBpbiAwaW47aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5VU0EgVG9sbC1GcmVlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv dGQ+DQo8dGQgd2lkdGg9IjM1MSIgc3R5bGU9IndpZHRoOjIxMC43cHQ7cGFkZGluZzowaW4gMGlu IDBpbiAwaW47aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj44ODgtODU4LTYxODI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0K PC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGlu IDBpbiAwaW4gMGluO2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+VVNBIENhbGxlciBQYWlkOg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW47aGVpZ2h0OjE1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj42NDYtNzQ2 LTMwMjk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVp Z2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluO2hlaWdodDox NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Rm9y IE90aGVyIENvdW50cmllczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbjtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vd3d3LnRlbGVj b25mZXJlbmNlLmF0dC5jb20vc2VydmxldC9nbGJBY2Nlc3M/cHJvY2Vzcz0xJmFtcDthY2Nlc3ND b2RlPTExMzY2OTQmYW1wO2FjY2Vzc051bWJlcj02NDY3NDYzMDI5I0MyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDt0ZXh0LWRlY29yYXRpb246bm9uZSI+Q2xpY2sNCiBI ZXJlIHRvIFZpZXcgR2xvYmFsIENvbmZlcmVuY2UgQWNjZXNzIE51bWJlcnM8L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUu MHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW47aGVpZ2h0OjE1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BY2Nlc3Mg Q29kZTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluO2hlaWdodDox NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ ODc3NDY1MTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlaWwgd2lsbCBnaXZlIHNob3J0 IHByZXNlbnRhdGlvbiBiYXNlZCBvbiB0aGUgZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteWhraW0tZG1tLWVuaGFuY2VkLWFuY2hvcmlu Zy0wMSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXloa2ltLWRtbS1lbmhhbmNl ZC1hbmNob3JpbmctMDE8L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmZvbGxvd2VkIGJ5IGZlZWRiYWNrIGFuZCBkaXNjdXNzaW9u cyBvbiB0aGUgd29yayBvbiBlbmhhbmNlZCBtb2JpbGl0eSBhbmNob3JpbmcuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5I IEFudGhvbnkgQ2hhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gaCBjaGFuDQo8YnI+DQo8 Yj5TZW50OjwvYj4gVHVlc2RheSwgTWF5IDE5LCAyMDE1IDEyOjM3IFBNPGJyPg0KPGI+VG86PC9i PiAnZG1tQGlldGYub3JnJzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogRW5oYW5jZWQgbW9iaWxp dHkgYW5jaG9yaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxldCB1cyBzY2hl ZHVsZSAyIHRlbGVjb25mZXJlbmNlcyAob25lIGhvdXIgZWFjaCkgdG8gYWNjb21tb2RhdGUgZXZl cnlvbmUgaW4gdGhlIGRvb2RsZSBsaXN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MXN0IHRlbGVjb25mZXJlbmNlOiBG cmlkYXkgTWF5IDIyIGF0IDk6MzAtMTA6MzBBTSBVUyBDZW50cmFsIFRpbWU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjJu ZCB0ZWxlY29uZmVyZW5jZTogV2VkbmVzZGF5IE1heSAyNyBhdCA5OjMwLTEwOjMwQU0gVVMgQ2Vu dHJhbCBUaW1lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IIEFudGhvbnkg Q2hhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gaCBjaGFuDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gRnJpZGF5LCBNYXkgMTUsIDIwMTUgMTE6MDggQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9 Im1haWx0bzpkbW1AaWV0Zi5vcmciPmRtbUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gRW5oYW5jZWQgbW9iaWxpdHkgYW5jaG9yaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlBsZWFzZSBjaGVjayB5b3VyIGF2YWlsYWJpbGl0eSBmb3IgYSB0ZWxlY29uZmVyZW5j ZSB0byBkaXNjdXNzIGVuaGFuY2VkIG1vYmlsaXR5IGFuY2hvcmluZy4gVGhhbmtzLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48YSBocmVmPSJodHRwOi8vZG9vZGxlLmNvbS9maWJmYnd5Yndod3M2NWdiIj5odHRwOi8v ZG9vZGxlLmNvbS9maWJmYnd5Yndod3M2NWdiPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkggQW50aG9u eSBDaGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_6E31144C030982429702B11D6746B98C521FD744szxeml557mbxchi_-- From nobody Thu May 21 21:49:22 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1764E1A9109 for ; Thu, 21 May 2015 21:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmZvOD_ev7yf for ; Thu, 21 May 2015 21:49:19 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361D31A9108 for ; Thu, 21 May 2015 21:49:19 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so4916086lbb.2 for ; Thu, 21 May 2015 21:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EZVdkdb7doOVXU7+DkMbjUkCSUl/1Ns/BEIj3VoYMwo=; b=FVCeSC8xUOZPic99+HHqZV5neub3yVzIzbahDQFAp0fTAE+WPnD9alRhHimyNRJW1R ZqRu8/CKWSx0MV0hAp/nnIk/FsKg542HuEltu4PqOpbBXWGDhvc7J+8HX7iw9xBVtMX5 o3DPA7q8Ds6LeODUbItNj2DCTaN87cuJPGrPTeyHSCd6YnIr4g9aRK/A1FyjzO2U6+Rn 8lnzoBXgUoUXvVYj1A3jAbxTdX8sEvWaJZyMe4REnSJmCS+3HymGtopj1/mYuCq0p1LY jDpO4ZBXzdgnWLTPpv/DbsnbXDVpODkJup4Hb7YBvf86oxg64OkIPJAZQsmfu4y8cQH8 IBLw== MIME-Version: 1.0 X-Received: by 10.152.203.162 with SMTP id kr2mr4933865lac.68.1432270157671; Thu, 21 May 2015 21:49:17 -0700 (PDT) Received: by 10.25.82.4 with HTTP; Thu, 21 May 2015 21:49:17 -0700 (PDT) In-Reply-To: <6E31144C030982429702B11D6746B98C521FD4D9@szxeml557-mbx.china.huawei.com> References: <6E31144C030982429702B11D6746B98C521F2EF5@szxeml557-mbx.china.huawei.com> <6E31144C030982429702B11D6746B98C521FD4D9@szxeml557-mbx.china.huawei.com> Date: Fri, 22 May 2015 12:49:17 +0800 Message-ID: From: Dapeng Liu To: h chan Content-Type: multipart/alternative; boundary=001a11346326f874620516a46152 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] Enhanced mobility anchoring X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 04:49:21 -0000 --001a11346326f874620516a46152 Content-Type: text/plain; charset=UTF-8 2015-05-20 1:37 GMT+08:00 h chan : > Let us schedule 2 teleconferences (one hour each) to accommodate > everyone in the doodle list: > > > > 1st teleconference: Friday May 22 at 9:30-10:30AM US Central Time > > > Hi Anthony and all, I will be on a business travel at this time Friday. I may not be able to attend the this meeting. Dapeng Liu > 2nd teleconference: Wednesday May 27 at 9:30-10:30AM US Central Time > > > > Thanks. > > > > H Anthony Chan > > > > *From:* h chan > *Sent:* Friday, May 15, 2015 11:08 AM > *To:* dmm@ietf.org > *Subject:* Enhanced mobility anchoring > > > > Please check your availability for a teleconference to discuss enhanced > mobility anchoring. Thanks. > > > > http://doodle.com/fibfbwybwhws65gb > > > > H Anthony Chan > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > -- ------ Best Regards, Dapeng Liu --001a11346326f874620516a46152 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-05-20 1:37 GMT+08:00 h chan <h.anthony.chan@huawei.com>:

Let us schedule 2 telecon= ferences (one hour each) to accommodate everyone in the doodle list:=

=C2=A0

1st teleconference: Frida= y May 22 at 9:30-10:30AM US Central Time

=C2=A0

<= /div>

Hi Anthony and all,
<= br>
I will be on a business travel at this time Friday.=C2=A0
I may not be able to attend the this meeting.


Dapeng Liu

=C2=A0

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm




--

------
Best Regards,
Dapeng Liu
--001a11346326f874620516a46152-- From nobody Fri May 22 03:08:41 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4A91B2AB7 for ; Fri, 22 May 2015 03:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkUhMiu7sGH6 for ; Fri, 22 May 2015 03:08:39 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4191B2AC1 for ; Fri, 22 May 2015 03:08:38 -0700 (PDT) Received: from [192.168.2.3] ([85.97.23.108]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0MTheY-1Yn2iO1NKq-00QVWm; Fri, 22 May 2015 12:08:32 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <001501d092d8$fae22420$f0a66c60$@av.it.pt> Date: Fri, 22 May 2015 13:08:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt> To: Seil Jeon X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:IjwZPimz3RQa5mkNmSb0F88BoKmpLZ3/HG5rdvTOzErfz+DxBYP 6iMWTd26fXjJdFltzIZYLu6ncPW86/H8ReN4/uJ3aUmLnG1ouSCVQuifq4yGRy85pKptxfF 2fFkXpYjNZAMKPpUIhsIoOt94GDuzawAqJbUg5+oDDq5KejSaqVTqrm2PjsVXOS7NoL+PfZ nStnLXTSZ3P3A7IRfhBdg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 10:08:41 -0000 Hi Seil, Thanks for creating the ticket. Please see below. >=20 > #49: full on-demand mobility support >=20 > The three proposed flags express a =93type=94 of source IP address an = application wants to get to the IP stack. Particularly, the sustained IP = address is proposed to provide on-demand IP session continuity, which = activates IP mobility once the terminal moves across other access = network. > While the terminal stays at the same network where the session is = initiated, regular IP routing is applied. >=20 > The on-demand draft does not assure provide the full on-demand = mobility for all scenarios by merely indicating the Socket API, = IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned = issue is as follows; >=20 > 0. The MN is configured with one or more Nomadic IP addresses. >=20 > 1. Once an app. requests =93sustained IP address=94 to the IP stack, = and it will obtain a sustained IP address through a protocol procedure = between the terminal and network. >=20 > 2. Other app. initiated over the same access network will use the same = sustained IP address while the terminal remains connected at the same = access network. >=20 > 3. The terminal moves to another access network and a new app. = requests a sustained IP address with the Socket API to the IP stack. = Since a sustained IP address is already available in the IP stack, the = sustained IP address is assigned to the new app. >=20 Yes, that's what happens. You are not pointing to an issue up until this point, right? Because, = you continuing your email with a "Besides" gives the impression that you = are pointing to an issue, but I don't see any issue captured in the = above text. > Besides, in case sustained IP address allocation is used default, = there may be multiple sustained IP addresses including newly obtained = sustained IP address over the new access network in the IP stack. = However, when an app. is initiated, the IP stack may not select the new = one in the context of the default source IP address selection mechanism = [RFC6724][RFC5014]. >=20 OK, is the issue following: When there are multiple sustained IP = addresses, how does the IP stack pick one among them? > For providing the full on-demand mobility, a new flag is needed, = letting the IP stack request a new sustained IP address or choose a = sustained IP address not requiring IP mobility anchoring when an = application is initiated, among the existing ones in the IP stack. >=20 Your flag is not a solution to what I captured above. It does something = else: Instruct the IP stack to go get a new sustained IP address whether = there is already one or more configured on the stack or not. Alper > --=20 > = -------------------------+---------------------------------------------- > -------------------------+--- > Reporter: | Owner: draft-ietf-dmm-ondemand- > seiljeon@av.it.pt | mobility@tools.ietf.org > Type: defect | Status: new > Priority: critical | Milestone: > Component: ondemand- | Version: > mobility | Keywords: on-demand mobility > Severity: Submitted | > WG Document | > = -------------------------+---------------------------------------------- > -------------------------+--- >=20 > Ticket URL: > dmm >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Fri May 22 04:26:59 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88A21B2BA3 for ; Fri, 22 May 2015 04:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvg1EyiFqEph for ; Fri, 22 May 2015 04:26:55 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED121A8AB5 for ; Fri, 22 May 2015 04:26:54 -0700 (PDT) Received: from [193.136.93.210] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77708065; Fri, 22 May 2015 12:26:52 +0100 From: "Seil Jeon" To: "'Alper Yegin'" References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt> In-Reply-To: Date: Fri, 22 May 2015 12:26:53 +0100 Message-ID: <000c01d09482$34031160$9c093420$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXyJVonWC/jWHjoPLHEPQMMWOBzAGkZzt5AU1BkT2c4eIuEA== Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 11:26:58 -0000 Hi Alper, Thanks for your reply. Please see inline ">>". Regards, Seil Jeon -----Original Message----- From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Friday, May 22, 2015 11:08 AM To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support Hi Seil, Thanks for creating the ticket. Please see below. > > #49: full on-demand mobility support > > The three proposed flags express a "type" of source IP address an application wants to get to the IP stack. Particularly, the sustained IP address is proposed to provide on-demand IP session continuity, which activates IP mobility once the terminal moves across other access network. > While the terminal stays at the same network where the session is initiated, regular IP routing is applied. > > The on-demand draft does not assure provide the full on-demand mobility for all scenarios by merely indicating the Socket API, IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned issue is as follows; > > 0. The MN is configured with one or more Nomadic IP addresses. > > 1. Once an app. requests "sustained IP address" to the IP stack, and it will obtain a sustained IP address through a protocol procedure between the terminal and network. > > 2. Other app. initiated over the same access network will use the same sustained IP address while the terminal remains connected at the same access network. > > 3. The terminal moves to another access network and a new app. requests a sustained IP address with the Socket API to the IP stack. Since a sustained IP address is already available in the IP stack, the sustained IP address is assigned to the new app. > Yes, that's what happens. You are not pointing to an issue up until this point, right? Because, you continuing your email with a "Besides" gives the impression that you are pointing to an issue, but I don't see any issue captured in the above text. >> There is an issue. Maybe, we need to be synchronized how have you thought and defined the meaning of "on-demand mobility". As far as I know, there are two meanings; one is that by imposing capability among IP address reachability and IP session continuity, needed for an application, into a source IP address, on-demand mobility could be achieved; as the other meaning, it can be rephrased and detailed with dynamic mobility, which should be applied in the use of sustained IP address. A new application needs to have non-anchored sustained IP address. This is our consistent claim. Non-optimal routing issue has been raised in DMM Requirement document in RFC 7333, which should be critically considered in the solutions. > Besides, in case sustained IP address allocation is used default, there may be multiple sustained IP addresses including newly obtained sustained IP address over the new access network in the IP stack. However, when an app. is initiated, the IP stack may not select the new one in the context of the default source IP address selection mechanism [RFC6724][RFC5014]. > OK, is the issue following: When there are multiple sustained IP addresses, how does the IP stack pick one among them? >> As mentioned and specified in our draft http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00, if there is no additional preference, we can leave selection to the default source address selection mechanism. BUT if we have specific preference among multiple sustained IP addresses and an initiated application wants to have non-anchored sustained IP address over currently attached access network, the proposed flag is essential. > For providing the full on-demand mobility, a new flag is needed, letting the IP stack request a new sustained IP address or choose a sustained IP address not requiring IP mobility anchoring when an application is initiated, among the existing ones in the IP stack. > Your flag is not a solution to what I captured above. It does something else: Instruct the IP stack to go get a new sustained IP address whether there is already one or more configured on the stack or not. >> Answered in the above. Alper > -- > -------------------------+---------------------------------------------- > -------------------------+--- > Reporter: | Owner: draft-ietf-dmm-ondemand- > seiljeon@av.it.pt | mobility@tools.ietf.org > Type: defect | Status: new > Priority: critical | Milestone: > Component: ondemand- | Version: > mobility | Keywords: on-demand mobility > Severity: Submitted | > WG Document | > -------------------------+---------------------------------------------- > -------------------------+--- > > Ticket URL: > dmm > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Fri May 22 07:35:52 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C581B2C03 for ; Fri, 22 May 2015 07:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4cj9ACPOLHr for ; Fri, 22 May 2015 07:35:49 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 433BF1B2C05 for ; Fri, 22 May 2015 07:35:47 -0700 (PDT) Received: from [192.168.29.121] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77709152 for dmm@ietf.org; Fri, 22 May 2015 15:35:46 +0100 From: "Seil Jeon" To: Date: Fri, 22 May 2015 15:35:46 +0100 Message-ID: <000001d0949c$979aad90$c6d008b0$@av.it.pt> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01D094A4.F9609C30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCUnHBaU58fOq7DSpKwZc9Hx1IiFA== Content-Language: ko Archived-At: Subject: [DMM] FW: Enhanced mobility anchoring (slides) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 14:35:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D094A4.F9609C30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01D094A4.F9609C30" ------=_NextPart_001_0002_01D094A4.F9609C30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Here goes my link for the presentation in the teleconference. =20 https://www.dropbox.com/s/rpy6gfxon76qwhm/2015.05.22_enhanced%20mobility%= 20anchoring_%28Seil_Jeon%29.pdf?dl=3D0 =20 =20 Regards, Seil Jeon =20 =20 From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of h chan Sent: Thursday, May 21, 2015 5:01 PM To: dmm@ietf.org Subject: [DMM] Enhanced mobility anchoring =20 The bridge number for Friday May 22 9:30-10:30 Central Daylight Time:=20 =20 USA Toll-Free: 888-858-6182 USA Caller Paid:=20 646-746-3029 For Other Countries: = Click Here to View Global = Conference Access Numbers Access Code: 8774651 =20 Seil will give short presentation based on the draft https://tools.ietf.org/html/draft-yhkim-dmm-enhanced-anchoring-01 =20 followed by feedback and discussions on the work on enhanced mobility = anchoring. =20 H Anthony Chan =20 From: h chan=20 Sent: Tuesday, May 19, 2015 12:37 PM To: 'dmm@ietf.org' Subject: RE: Enhanced mobility anchoring =20 Let us schedule 2 teleconferences (one hour each) to accommodate = everyone in the doodle list: =20 1st teleconference: Friday May 22 at 9:30-10:30AM US Central Time =20 2nd teleconference: Wednesday May 27 at 9:30-10:30AM US Central Time =20 Thanks.=20 =20 H Anthony Chan =20 From: h chan=20 Sent: Friday, May 15, 2015 11:08 AM To: dmm@ietf.org Subject: Enhanced mobility anchoring =20 Please check your availability for a teleconference to discuss enhanced = mobility anchoring. Thanks.=20 =20 http://doodle.com/fibfbwybwhws65gb =20 H Anthony Chan =20 ------=_NextPart_001_0002_01D094A4.F9609C30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Here goes my link for the presentation in the = teleconference.

 

https://www.dropbox.com/s= /rpy6gfxon76qwhm/2015.05.22_enhanced%20mobility%20anchoring_%28Seil_Jeon%= 29.pdf?dl=3D0

 

 

Regards,

Seil Jeon

 

 

From:= = dmm [mailto:dmm-bounces@ietf.org] On Behalf Of h = chan
Sent: Thursday, May 21, 2015 5:01 PM
To: = dmm@ietf.org
Subject: [DMM] Enhanced mobility = anchoring

 

The bridge number for Friday May 22 9:30-10:30 Central Daylight Time: =

 

USA = Toll-Free:

888-858-6182

USA Caller = Paid:

646-746-3029

For Other = Countries:

Click Here to View Global Conference Access = Numbers

Access = Code:

8774651

 

Seil will give short presentation based on the = draft

https://tools.ietf.org/html/draft-yhkim-dmm-enhanced-anchoring-01

 

followed by feedback and discussions on the work on enhanced mobility = anchoring.

 

H Anthony Chan

 

From:= = h chan
Sent: Tuesday, May 19, 2015 12:37 PM
To: = 'dmm@ietf.org'
Subject: RE: Enhanced mobility = anchoring

 

Let us schedule 2 teleconferences (one hour each) to accommodate = everyone in the doodle list:

 

1st teleconference: Friday May 22 at 9:30-10:30AM US Central = Time

 

2nd teleconference: Wednesday May 27 at 9:30-10:30AM US Central = Time

 

Thanks.

 

H Anthony Chan

 

From:= = h chan
Sent: Friday, May 15, 2015 11:08 AM
To: dmm@ietf.org
Subject: = Enhanced mobility anchoring

 

Please check your availability for a teleconference to discuss = enhanced mobility anchoring. Thanks.

 

http://doodle.com/fibfbwybwhw= s65gb

 

H Anthony Chan

 

------=_NextPart_001_0002_01D094A4.F9609C30-- ------=_NextPart_000_0001_01D094A4.F9609C30 Content-Type: text/plain; name="Untitled attachment 00019.sdx" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Untitled attachment 00019.sdx" _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ------=_NextPart_000_0001_01D094A4.F9609C30-- From nobody Fri May 22 08:24:53 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115E31A008F for ; Fri, 22 May 2015 08:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q--gvc5tFDnB for ; Fri, 22 May 2015 08:24:49 -0700 (PDT) Received: from smtp5.altran.com (smtp4.altran.com [194.98.79.92]) by ietfa.amsl.com (Postfix) with ESMTP id BA4D91A000F for ; Fri, 22 May 2015 08:24:49 -0700 (PDT) Received: from XCH-20V-DCFR-02.europe.corp.altran.com (unknown [10.0.6.16]) by Websense Email Security Gateway with ESMTPS id 9C075E8953A32; Fri, 22 May 2015 17:24:44 +0200 (CEST) Received: from XMB-DCFR-37.europe.corp.altran.com ([fe80::80ba:99a3:be27:fa11]) by XCH-20V-DCFR-02.europe.corp.altran.com ([fe80::b83b:261b:fc4b:b000%12]) with mapi id 14.03.0235.001; Fri, 22 May 2015 17:24:48 +0200 From: FIGUEIREDO Sergio To: Alper Yegin , Seil Jeon Thread-Topic: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support Thread-Index: AQHQlHdRZ+FmkYNUqEeEbX0uB+zceJ2IGOCA Date: Fri, 22 May 2015 15:24:47 +0000 Message-ID: References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt> In-Reply-To: Accept-Language: pt-BR, fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.6.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 15:24:52 -0000 Hi Alper, As Seil wrote, the problem which this ticket intends to reflect is that of = non-optimal routing as a result of not being able to request a non-anchored= (or local) source IP address.=20 This might be a problem in any scenario where new Sustained IP addresses ar= e not assigned by default at the new network. The intention of the flag is = not to request a new prefix, but to assure a source address associated to a= local network is used. Which, in cases where it is not available, leads to= the configuration of a new one. Best regards, Sergio 2, rue Paul Vaillant-Couturier 92300 Levallois-Perret=20 FRANCE Tel. : +33 (0)1 46 17 46 17 -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin Sent: sexta-feira, 22 de Maio de 2015 12:08 To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility s= upport Hi Seil, Thanks for creating the ticket. Please see below. >=20 > #49: full on-demand mobility support >=20 > The three proposed flags express a "type" of source IP address an applic= ation wants to get to the IP stack. Particularly, the sustained IP address= is proposed to provide on-demand IP session continuity, which activates I= P mobility once the terminal moves across other access network. > While the terminal stays at the same network where the session is initia= ted, regular IP routing is applied. >=20 > The on-demand draft does not assure provide the full on-demand mobility = for all scenarios by merely indicating the Socket API, IPV6_REQ_SUSTAINED_= IP. An example scenario raising the aforementioned issue is as follows; >=20 > 0. The MN is configured with one or more Nomadic IP addresses. >=20 > 1. Once an app. requests "sustained IP address" to the IP stack, and it = will obtain a sustained IP address through a protocol procedure between th= e terminal and network. >=20 > 2. Other app. initiated over the same access network will use the same s= ustained IP address while the terminal remains connected at the same acces= s network. >=20 > 3. The terminal moves to another access network and a new app. requests a= sustained IP address with the Socket API to the IP stack. Since a sustai= ned IP address is already available in the IP stack, the sustained IP addr= ess is assigned to the new app. >=20 Yes, that's what happens. You are not pointing to an issue up until this point, right? Because, you c= ontinuing your email with a "Besides" gives the impression that you are poi= nting to an issue, but I don't see any issue captured in the above text. > Besides, in case sustained IP address allocation is used default, there = may be multiple sustained IP addresses including newly obtained sustained = IP address over the new access network in the IP stack. However, when an a= pp. is initiated, the IP stack may not select the new one in the context o= f the default source IP address selection mechanism [RFC6724][RFC5014]. >=20 OK, is the issue following: When there are multiple sustained IP addresses,= how does the IP stack pick one among them? > For providing the full on-demand mobility, a new flag is needed, letting = the IP stack request a new sustained IP address or choose a sustained IP = address not requiring IP mobility anchoring when an application is initiat= ed, among the existing ones in the IP stack. >=20 Your flag is not a solution to what I captured above. It does something els= e: Instruct the IP stack to go get a new sustained IP address whether there= is already one or more configured on the stack or not. Alper > --=20 > -------------------------+---------------------------------------------- > -------------------------+--- > Reporter: | Owner: draft-ietf-dmm-ondemand- > seiljeon@av.it.pt | mobility@tools.ietf.org > Type: defect | Status: new > Priority: critical | Milestone: > Component: ondemand- | Version: > mobility | Keywords: on-demand mobility > Severity: Submitted | > WG Document | > -------------------------+---------------------------------------------- > -------------------------+--- >=20 > Ticket URL: > dmm >=20 >=20 > _______________________________________________ > 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 From nobody Tue May 26 08:06:46 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D29D1A8952 for ; Tue, 26 May 2015 08:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqQrkKkfYtFK for ; Tue, 26 May 2015 08:06:41 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD151A895C for ; Tue, 26 May 2015 08:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4279; q=dns/txt; s=iport; t=1432652785; x=1433862385; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=KjYGbEft2ZolwEAGg3YQYlfAa5tjkfWfrLvpqz4lzDk=; b=mT/7H+n81Y5OiX4gjK5xhrvyR+r20aY4boP6uAmcXgWFLSFmR29mX+/a U1FdXlcg5sGhASLGoXzEF56Lpl3IHECwQJspsQSKUI2piEPPUdmT7ixFX lJFXGFgbYryCG+1eXgUVqhztFgH047hjrM6nOLVxd4Z03DQLpamn8cbLV 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AfBAD2imRV/4wNJK1cgkVLgTjCNmYJh1ACgUY4FAEBAQEBAQGBCoQlBIELAYEAJQIEiD+gM7NCAQEBAQYBAQEBAQEckEaELQWTCIsPly8jggocgVKCNYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,498,1427760000"; d="scan'208,217";a="153413815" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP; 26 May 2015 15:06:25 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t4QF6Nj2012981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 May 2015 15:06:23 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.121]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Tue, 26 May 2015 10:06:23 -0500 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: WT#4 - Conf Call Thread-Index: AQHQl8WHDVUGSiqe30qIt7g4BX1sng== Date: Tue, 26 May 2015 15:06:23 +0000 Message-ID: In-Reply-To: <000001d0949c$979aad90$c6d008b0$@av.it.pt> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.211] Content-Type: multipart/alternative; boundary="_000_D189D8431C0D86sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: [DMM] WT#4 - Conf Call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 15:06:45 -0000 --_000_D189D8431C0D86sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Folks: I=92m trying to schedule one or two calls to discuss the work items under W= T#4. We did have few discussions including f2f meetings in the past, but no= w doing it more formally. Scope of WT#4 per chairs suggestion was to cover, architectural/deployment = models and to tie the different work items under the overall DMM scope. If = you have any topics to present in this call, send me a note and we can cove= r that. I will schedule these calls for the weeks of June 15 and June 27th. I will = send out a poll. Regards Sri --_000_D189D8431C0D86sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <87F42296CB606243A9FF9A012A42C1AA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Folks:

I=92m trying to schedule one or two calls to discuss the work items un= der WT#4. We did have few discussions including f2f meetings in the past, b= ut now doing it more formally.

Scope of WT#4 per chairs suggestion was to cover, architectural/deploy= ment models and to tie the different work items under the overall DMM scope= . If you have any topics to present in this call, send me a note and we can= cover that.

I will schedule these calls for the weeks of June 15 and June 27th. I = will send out a poll.


Regards
Sri





--_000_D189D8431C0D86sgundaveciscocom_-- From nobody Tue May 26 08:17:46 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F1F1A89A0 for ; Tue, 26 May 2015 08:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUIBax2BWE51 for ; Tue, 26 May 2015 08:17:44 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDFC21A89AE for ; Tue, 26 May 2015 08:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6085; q=dns/txt; s=iport; t=1432653464; x=1433863064; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=Fqs6+TtStBSQgAKQ7PgpZRUsrwzLRHk+R72DbV2V0NM=; b=DPpsfOKuzLPbcS134Ujn92rEEXInQxhsCOX3IIeFhg/A9faylxEPx4y2 Yzaa4goVLEu4RIxfidPKs8mDnyesaNjAYrktNRSoWduECV9AiyIxQ3o3Q 7N5aQVWEGba8IyKbotjWrqTjdREq6yIFUy27iB17PrGYvaJ97lSBcH5ic k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AiBABajWRV/40NJK1cgkVLVF4GwjdmCYFVhXsCgUY4FAEBAQEBAQGBCoQiAQIEgQsBGQMBAig5FAkIAgQTiCwNoBmzQgEBAQEGAQEBAQEBHI4Rgh0YhC0FkEyCPIQ1hlqBZ4sJij8jYYEpHIFSb4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,498,1427760000"; d="scan'208,217";a="153438468" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 May 2015 15:17:43 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t4QFHhZa009220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 May 2015 15:17:43 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.121]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 26 May 2015 10:17:43 -0500 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: [DMM] WT#4 - Conf Call Timing Poll Thread-Index: AQHQl8ccGtsMNZB8i0aEVMZ+uosnIQ== Date: Tue, 26 May 2015 15:17:42 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.211] Content-Type: multipart/alternative; boundary="_000_D189DB3D1C0D9Esgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: [DMM] WT#4 - Conf Call Timing Poll X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 15:17:45 -0000 --_000_D189DB3D1C0D9Esgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Links to the poll. Call-1: http://doodle.com/ipcwup5wpin3un59 Call-2: http://doodle.com/5iq3g4nit6qnhmch From: Sri Gundavelli > Date: Tuesday, May 26, 2015 at 8:06 AM To: "dmm@ietf.org" > Subject: [DMM] WT#4 - Conf Call Folks: I=92m trying to schedule one or two calls to discuss the work items under W= T#4. We did have few discussions including f2f meetings in the past, but no= w doing it more formally. Scope of WT#4 per chairs suggestion was to cover, architectural/deployment = models and to tie the different work items under the overall DMM scope. If = you have any topics to present in this call, send me a note and we can cove= r that. I will schedule these calls for the weeks of June 15 and June 27th. I will = send out a poll. Regards Sri --_000_D189DB3D1C0D9Esgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1CDB2D53D772864CB58684AA90FAADA2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Links to the poll.

Call-1:


Call-2:





From: Sri Gundavelli <sgundave@cisco.com>
Date: Tuesday, May 26, 2015 at 8:06= AM
To: "dmm@ietf.org" <dmm@ietf.= org>
Subject: [DMM] WT#4 - Conf Call

Folks:

I=92m trying to schedule one or two calls to discuss the work items un= der WT#4. We did have few discussions including f2f meetings in the past, b= ut now doing it more formally.

Scope of WT#4 per chairs suggestion was to cover, architectural/deploy= ment models and to tie the different work items under the overall DMM scope= . If you have any topics to present in this call, send me a note and we can= cover that.

I will schedule these calls for the weeks of June 15 and June 27th. I = will send out a poll.


Regards
Sri





 --_000_D189DB3D1C0D9Esgundaveciscocom_-- From nobody Tue May 26 08:31:51 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C3F1A8A7C for ; Tue, 26 May 2015 08:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9T9Au4xziR6 for ; Tue, 26 May 2015 08:31:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C271A8A83 for ; Tue, 26 May 2015 08:31:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWN55741; Tue, 26 May 2015 15:31:40 +0000 (GMT) Received: from SZXEML428-HUB.china.huawei.com (10.82.67.183) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 May 2015 16:31:37 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.62]) by szxeml428-hub.china.huawei.com ([10.82.67.183]) with mapi id 14.03.0158.001; Tue, 26 May 2015 23:30:50 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: Enhanced mobility anchoring Thread-Index: AQHQZ+2Q2EAkZ5QP+UmZfjSKm6JQuZ0vC9KAgCEBEbCALHlOoIAA/GEQgAZg00CAAwWtIIACAMCAgAXX4iA= Date: Tue, 26 May 2015 15:30:49 +0000 Message-ID: <6E31144C030982429702B11D6746B98C521FEF52@szxeml557-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.174] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C521FEF52szxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [DMM] Enhanced mobility anchoring X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 15:31:46 -0000 --_000_6E31144C030982429702B11D6746B98C521FEF52szxeml557mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGJyaWRnZSBudW1iZXIgZm9yIFdlZG5lc2RheSBNYXkgMjcgOTozMC0xMDozMCBDZW50cmFs IERheWxpZ2h0IFRpbWU6DQpBVCZUIENvbm5lY3QNClVTQSBUb2xsLUZyZWU6DQoNCjg4OC04NTgt NjE4Mg0KDQpVU0EgQ2FsbGVyIFBhaWQ6DQoNCjY0Ni03NDYtMzAyOQ0KDQpGb3IgT3RoZXIgQ291 bnRyaWVzOg0KDQpDbGljayBIZXJlIHRvIFZpZXcgR2xvYmFsIENvbmZlcmVuY2UgQWNjZXNzIE51 bWJlcnM8aHR0cHM6Ly93d3cudGVsZWNvbmZlcmVuY2UuYXR0LmNvbS9zZXJ2bGV0L2dsYkFjY2Vz cz9wcm9jZXNzPTEmYWNjZXNzQ29kZT0xMTM2Njk0JmFjY2Vzc051bWJlcj02NDY3NDYzMDI5I0My Pg0KDQpBY2Nlc3MgQ29kZToNCg0KMzEwMTUzNQ0KDQoNCg0KQ29udGludWUgZGlzY3Vzc2lvbnMg b24gdGhlIGVuaGFuY2VkIG1vYmlsaXR5IGFuY2hvcmluZy4NCg0KSCBBbnRob255IENoYW4NCg0K RnJvbTogaCBjaGFuDQpTZW50OiBUdWVzZGF5LCBNYXkgMTksIDIwMTUgMTI6MzcgUE0NClRvOiAn ZG1tQGlldGYub3JnJw0KU3ViamVjdDogUkU6IEVuaGFuY2VkIG1vYmlsaXR5IGFuY2hvcmluZw0K DQpMZXQgdXMgc2NoZWR1bGUgMiB0ZWxlY29uZmVyZW5jZXMgKG9uZSBob3VyIGVhY2gpIHRvIGFj Y29tbW9kYXRlIGV2ZXJ5b25lIGluIHRoZSBkb29kbGUgbGlzdDoNCg0KMXN0IHRlbGVjb25mZXJl bmNlOiBGcmlkYXkgTWF5IDIyIGF0IDk6MzAtMTA6MzBBTSBVUyBDZW50cmFsIFRpbWUNCg0KMm5k IHRlbGVjb25mZXJlbmNlOiBXZWRuZXNkYXkgTWF5IDI3IGF0IDk6MzAtMTA6MzBBTSBVUyBDZW50 cmFsIFRpbWUNCg0KVGhhbmtzLg0KDQpIIEFudGhvbnkgQ2hhbg0KDQpGcm9tOiBoIGNoYW4NClNl bnQ6IEZyaWRheSwgTWF5IDE1LCAyMDE1IDExOjA4IEFNDQpUbzogZG1tQGlldGYub3JnPG1haWx0 bzpkbW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBFbmhhbmNlZCBtb2JpbGl0eSBhbmNob3JpbmcNCg0K UGxlYXNlIGNoZWNrIHlvdXIgYXZhaWxhYmlsaXR5IGZvciBhIHRlbGVjb25mZXJlbmNlIHRvIGRp c2N1c3MgZW5oYW5jZWQgbW9iaWxpdHkgYW5jaG9yaW5nLiBUaGFua3MuDQoNCmh0dHA6Ly9kb29k bGUuY29tL2ZpYmZid3lid2h3czY1Z2INCg0KSCBBbnRob255IENoYW4NCg0K --_000_6E31144C030982429702B11D6746B98C521FEF52szxeml557mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0Fj ZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgYnJpZGdlIG51bWJl ciBmb3IgV2VkbmVzZGF5IE1heSAyNyA5OjMwLTEwOjMwIENlbnRyYWwgRGF5bGlnaHQgVGltZToN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPkFUJmFtcDtUIENvbm5lY3Q8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAi IGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjU0NyIgc3R5bGU9IndpZHRo OjMyOC4wcHQ7Ym9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0i aGVpZ2h0OjE1LjBwdCI+DQo8dGQgd2lkdGg9IjE5NiIgc3R5bGU9IndpZHRoOjExNy4zcHQ7cGFk ZGluZzowaW4gMGluIDBpbiAwaW47aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5VU0EgVG9sbC1GcmVlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjM1MSIgc3R5bGU9IndpZHRoOjIxMC43cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiAwaW47aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj44ODgtODU4LTYxODI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBh ZGRpbmc6MGluIDBpbiAwaW4gMGluO2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VVNBIENhbGxlciBQYWlkOg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW47aGVp Z2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij42NDYtNzQ2LTMwMjk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBz dHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGlu O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Rm9yIE90aGVyIENvdW50cmllczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0K PHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbjtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8v d3d3LnRlbGVjb25mZXJlbmNlLmF0dC5jb20vc2VydmxldC9nbGJBY2Nlc3M/cHJvY2Vzcz0xJmFt cDthY2Nlc3NDb2RlPTExMzY2OTQmYW1wO2FjY2Vzc051bWJlcj02NDY3NDYzMDI5I0MyIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ Q2xpY2sNCiBIZXJlIHRvIFZpZXcgR2xvYmFsIENvbmZlcmVuY2UgQWNjZXNzIE51bWJlcnM8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJo ZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW47aGVpZ2h0 OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5BY2Nlc3MgQ29kZTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGlu O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+MzEwMTUzNTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkNvbnRpbnVlIGRpc2N1c3Npb25zIG9uIHRoZSBlbmhhbmNlZCBt b2JpbGl0eSBhbmNob3JpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IIEFudGhvbnkgQ2hhbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gaCBjaGFuDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWF5IDE5 LCAyMDE1IDEyOjM3IFBNPGJyPg0KPGI+VG86PC9iPiAnZG1tQGlldGYub3JnJzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSRTogRW5oYW5jZWQgbW9iaWxpdHkgYW5jaG9yaW5nPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkxldCB1cyBzY2hlZHVsZSAyIHRlbGVjb25mZXJlbmNlcyAob25l IGhvdXIgZWFjaCkgdG8gYWNjb21tb2RhdGUgZXZlcnlvbmUgaW4gdGhlIGRvb2RsZSBsaXN0Ojxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+MXN0IHRlbGVjb25mZXJlbmNlOiBGcmlkYXkgTWF5IDIyIGF0IDk6MzAtMTA6MzBB TSBVUyBDZW50cmFsIFRpbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjJuZCB0ZWxlY29uZmVyZW5jZTogV2VkbmVzZGF5 IE1heSAyNyBhdCA5OjMwLTEwOjMwQU0gVVMgQ2VudHJhbCBUaW1lPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3Mu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5IIEFudGhvbnkgQ2hhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gaCBjaGFuDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXkgMTUsIDIwMTUgMTE6 MDggQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciPmRtbUBp ZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gRW5oYW5jZWQgbW9iaWxpdHkgYW5jaG9y aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBjaGVjayB5b3VyIGF2 YWlsYWJpbGl0eSBmb3IgYSB0ZWxlY29uZmVyZW5jZSB0byBkaXNjdXNzIGVuaGFuY2VkIG1vYmls aXR5IGFuY2hvcmluZy4gVGhhbmtzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwOi8vZG9vZGxl LmNvbS9maWJmYnd5Yndod3M2NWdiIj5odHRwOi8vZG9vZGxlLmNvbS9maWJmYnd5Yndod3M2NWdi PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkggQW50aG9ueSBDaGFuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6E31144C030982429702B11D6746B98C521FEF52szxeml557mbxchi_-- From nobody Tue May 26 13:34:13 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CDE1B3138 for ; Tue, 26 May 2015 13:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU1nP1Vo3cyc for ; Tue, 26 May 2015 13:34:11 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2C11B3137 for ; Tue, 26 May 2015 13:34:11 -0700 (PDT) Received: by lalw1 with SMTP id w1so8414056lal.0 for ; Tue, 26 May 2015 13:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BBB7W9cHRxnJ773AoFplATT9jlhNM+Xbmj9dzY/pKF4=; b=Dr5BZNbPEUmRBd30I4ziFzad4Kn2JnHI48tVOyGOPFhbMLoiH7SLE/57KzCsBU9O3H oLpbN1zXY26/epnT3zJYl4B9AcLWxBbs53+v41uKS2BsXCARbRUTOt3Vfar6tE5T1Yrv VJbevNot5oOAArrvYHtBKM6rGsIl6P5TKb5+8avJedu4+kzZPM3A4JT9dM6P3bPHh8hr DOjC+Rgoe72sRN3pClG1Um3tEB4yewqoZfOcqeegTygcVjfPLvD9XjA2k1HNYTc95FVf g5FvwvNQyDxfxVkqQklAq6kj4Uxv1rjID9NrwoV+AzjDWZ95Cjgpd2ZzhVHp7jJjGNbt iU0Q== MIME-Version: 1.0 X-Received: by 10.112.158.103 with SMTP id wt7mr5693399lbb.5.1432672449821; Tue, 26 May 2015 13:34:09 -0700 (PDT) Received: by 10.114.74.225 with HTTP; Tue, 26 May 2015 13:34:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 May 2015 15:34:09 -0500 Message-ID: From: Behcet Sarikaya To: Satoru Matsushima Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] vepc draft Rev. 04 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 20:34:12 -0000 Hi Satoru, Thanks for your reply. Let me continue the discussion with your text in Section 3.2 where you mention vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) that defines FPCP Agent function and Client function. I don't understand how you could justify defining a new forwarding policy configuration protocol to do this Agent/Client functionality? Why not use similar Agent/Client models that are being defined rather than defining a new protocol? I think this point requires much stronger justification which I could not see in Section 3.2. Are you that we have to to reinvent the wheel, rather than reusing something that is already available? How are we going to reinvent that wheel also remains to be seen, I think. Regards, Behcet On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima wrote: > Hi Bechet-san, > > Thank you for your question. > In step (15), I meant that EPC-E advertises prefix including UE assigned > prefixes. > > For example, in the case of /64 prefixes assigned to UEs from a /56 space, > that /56 > is advertised by EPC-E to upstream routers. So the advertised route isn't > host routes. > > Depends on configuration policy, but one case is that the source of that > advertised > /56 route might be statically configured in EPC-E. > > Regards, > --satoru > > > > On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya > wrote: >> >> Hi Matsushima-san, >> >> I have a question on your draft: >> In Sec. 3.2, page 11, you say >> In step (15), the EPC-E advertises routes to upstream routers ... >> >> Are these routes static/host routes? >> >> Regards, >> >> Behcet > > From nobody Wed May 27 04:31:14 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334BE1ACDFB for ; Wed, 27 May 2015 04:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0zKVgoPE3D8 for ; Wed, 27 May 2015 04:31:10 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2496E1ACDFA for ; Wed, 27 May 2015 04:31:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t4RBV81d025897 for ; Wed, 27 May 2015 13:31:08 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BAC49205D2A for ; Wed, 27 May 2015 13:33:23 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B188D20517D for ; Wed, 27 May 2015 13:33:23 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t4RBV74T025712 for ; Wed, 27 May 2015 13:31:07 +0200 Message-ID: <5565AAFB.9030100@gmail.com> Date: Wed, 27 May 2015 13:31:07 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dmm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 11:31:12 -0000 Hi, In addition to what Behcet says. I read the example below. I think it is just an example, but just to make sure. Please - do not allocate /64s to end users in a cellular network. Allocate at least /62s to end users. This is to allow the smartphone to perform tethering (small network of wifi devices connecting through the smartphone to the Internet). The assumption of /64 to end user is not good at all. (and yes, I agree that these /62s may be aggregated into a larger prefix and advertised upstream as a single prefix instead of multiple host-based routes). Yours, Alex Petrescu Le 26/05/2015 22:34, Behcet Sarikaya a crit : > Hi Satoru, > > Thanks for your reply. > > Let me continue the discussion with your text in Section 3.2 where you mention > vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) > that defines FPCP Agent function and Client function. > > I don't understand how you could justify defining a new forwarding > policy configuration protocol to do this Agent/Client functionality? > Why not use similar Agent/Client models that are being defined rather > than defining a new protocol? > I think this point requires much stronger justification which I could > not see in Section 3.2. > > Are you that we have to to reinvent the wheel, rather than reusing > something that is already available? How are we going to reinvent that > wheel also remains to be seen, I think. > > Regards, > > Behcet > > > > On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima > wrote: >> Hi Bechet-san, >> >> Thank you for your question. >> In step (15), I meant that EPC-E advertises prefix including UE assigned >> prefixes. >> >> For example, in the case of /64 prefixes assigned to UEs from a /56 space, >> that /56 >> is advertised by EPC-E to upstream routers. So the advertised route isn't >> host routes. >> >> Depends on configuration policy, but one case is that the source of that >> advertised >> /56 route might be statically configured in EPC-E. >> >> Regards, >> --satoru >> >> >> >> On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya >> wrote: >>> >>> Hi Matsushima-san, >>> >>> I have a question on your draft: >>> In Sec. 3.2, page 11, you say >>> In step (15), the EPC-E advertises routes to upstream routers ... >>> >>> Are these routes static/host routes? >>> >>> Regards, >>> >>> Behcet >> >> > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > From nobody Thu May 28 09:32:38 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B851B2C3D for ; Thu, 28 May 2015 09:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00RY9sX4WgRW for ; Thu, 28 May 2015 09:32:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0125.outbound.protection.outlook.com [65.55.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B521A001B for ; Thu, 28 May 2015 09:32:34 -0700 (PDT) Received: from BN1AFFO11FD028.protection.gbl (10.58.52.32) by BN1AFFO11HUB035.protection.gbl (10.58.52.146) with Microsoft SMTP Server (TLS) id 15.1.172.14; Thu, 28 May 2015 16:32:32 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.32.80) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from preapdm1.corp.sprint.com (144.230.32.80) by BN1AFFO11FD028.mail.protection.outlook.com (10.58.52.88) with Microsoft SMTP Server (TLS) id 15.1.184.11 via Frontend Transport; Thu, 28 May 2015 16:32:32 +0000 Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t4SGPXNh039760 for ; Thu, 28 May 2015 12:32:31 -0400 Received: from prewe13m02.ad.sprint.com (prewe13m02.corp.sprint.com [144.226.128.21]) by preapdm1.corp.sprint.com with ESMTP id 1ujp19eb40-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 28 May 2015 12:32:31 -0400 Received: from PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) by PREWE13M02.ad.sprint.com (2002:90e2:8015::90e2:8015) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 28 May 2015 12:32:30 -0400 Received: from PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9]) by PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9%15]) with mapi id 15.00.1044.021; Thu, 28 May 2015 11:32:30 -0500 From: "Laporte, Laurent [CTO]" To: "dmm@ietf.org" Thread-Topic: FPC carrier ID and network ID question Thread-Index: AdCZY8eSHKVtCkFuS16oqfq1KLDiYg== Date: Thu, 28 May 2015 16:32:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.20] Content-Type: multipart/alternative; boundary="_000_d35a39c8edb44ee597716a4b69ee2c9ePLSWE13M01adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD028; 1:JcZDPph/jpyfMpSJdg09klHCjJpAW30pJ/hnmffFgg+q7isMFRHI6kgQJdK9AXHWOxMVuuWoBdpLsCMNuWGcJTWPqeuPbVpIR0jWAzjOwCl47gfUU4CQp2ZFh7VVTxUOttOlYpY0MsRG3qTgtLlHcRROfUsHxowiA1K1SBIls9oyi2BQPZFchMqzMtt2sLDR4VjQdQ4dmEfnVd6FF+5uIz9RFPiHG2+krhIetvEquqRHQt63BRG4tzRz9tYJXICUGpzvSyrig90CFnj7FrKPmRNK2BwAzIXycO9OB9kYTro= X-Forefront-Antispam-Report: CIP:144.230.32.80; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(448002)(164054003)(199003)(189002)(512954002)(19625215002)(62966003)(450100001)(5001960100002)(5001860100001)(19580395003)(77156002)(50986999)(229853001)(2351001)(4546004)(107886002)(85326001)(5001830100001)(189998001)(54356999)(64706001)(92566002)(110136002)(87936001)(86362001)(2656002)(102836002)(15975445007)(68736005)(97736004)(106466001)(108616004)(16236675004)(81156007)(33646002)(84326002)(24736003)(5250100002)(2900100001)(19300405004)(2501003)(46102003)(4001540100001)(6806004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB035; H:preapdm1.corp.sprint.com; FPR:; SPF:PermError; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB035; 2:JIlk0GP8OreawjAE5hBFSVxwkiynCl99T9SIXAXh39G1Kmal5WETmUDggpdkvDur; 2:HZJzuOSHv8ULXbepY5Ut96P8lff7GBF9gdzFVSRdYIKfviB1AFxeflSV0SNUk7KmKUbsaKQ1cADl5mQxljE9izWYzdS6drruBpyLfTAEEsm/y3KKWFU2ONUyfd8aKZ9KF0dnGzNhE99N3Z5l7J2HhHbVF4yFoTTm5eOytkz7F0eaJz0j0VPCWflNI/A6egrnC8EBrds/s4uDBdTmChsB793vE0qpK9blcR7geF314js=; 6:DhTxCxh4z73Sd18qWlYBs0R/a5A1WmeCiRhF7XqBovJ5Fuxjt+u6zudc1fq6iBuye5u0ShXz5+dCq5kXirD2HI8tfVeUmNnwo5EzkpgAWwWEr/Qjf+m6OoC3/GcvamU+ykc1OGvKlDp26YhpPJAK70t3eoThjIFIib4ErSZY+ZOMua52DlfDmCZrdwcnj7uYTfKkflDuIKDT8v6Cklmp42JYt5s+ZIpeayqyvYyM0eGBAa1s5eWe0wAmsg86J6JV; 3:hLqRNybZPfVrkmFXwHz1pFqJKBR8KxLiJOYudVK2v6qvVvLSJYtr/iX2EcCu80BiwcJxsLt1FhyJJyz0SAhUROJmX62v+55h7mJVDPfrRD+Um/OrZYx6HsirC08wua5nvSHifqT4ilFvhfuOEgnZI1uxn3qJ1cJWYdmUySmSqPzHfr6o7/L6zOwMcewdknVYYnaxq44EFnzfHUsePmS603MFyfRzHqtQbaozYhbgoffjaqO0c04OjpShoWMTlGYXt5gxv4ufyI558D7yxp/in5/oEDcIWbtSk95lbuMTaLQ4PILQ3VDqd28slcoZkhZE X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB035; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BN1AFFO11HUB035; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB035; X-Forefront-PRVS: 0590BBCCBC X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB035; 9:6QL0ZbyPrLjwU61YlFvAQQBDV8IhQdFu1450jlN+?= =?us-ascii?Q?ezkXEOHSxzyoJ0l+ews4m83K92o0dbCMkbuEOpecel42xyyjeW+EoTOwY4Xl?= =?us-ascii?Q?E8sRFZMsdTwcGzQ4gR8klDBfEtqZc8j/ZQWDLM3BmtzCpmv/bzxAncBAT2gp?= =?us-ascii?Q?6OcJZ28ntVLc0+d/psCBLNf04Rkd3dNoj2LrZaaUaZp8qV2gbv0AmrHk8Erk?= =?us-ascii?Q?tNvEo9lnVAmOr/TzcI0+LjZkN6liAdw7ebYzSSWsODim98LPpRprfbOZyzgV?= =?us-ascii?Q?kmoqCDpNmpP57BFHd5BvRPSbvzwP0veYQ0jFI9DKj4G2qSNVLfuBOsmtycSY?= =?us-ascii?Q?MyMnWn4QZ+COK6Q7tzW3xH1ALz9cAdeDgbBxFntKMLu2vWJv5oBIYv/Gj67U?= =?us-ascii?Q?oifcYKI54tWdngyVM7+GfafV2T+YucwTltjQUEwgET8OZxT66Zyc9e6/g7JL?= =?us-ascii?Q?RpUiZ/5KlKmlA8OIT+qdSZ91dqZKIjzZOH+HbglR9Fwlu6oW88A70+b4Thro?= =?us-ascii?Q?5fxvQJ8TaoQhm6ez9E9U1SRdrKoUsDp65yoM4dnzejyGTzddTRZv+9n1P6h7?= =?us-ascii?Q?Uyg7n9sWY2h2q1yWJv1WymI0RQvLBsRaFPDjdvk3+v6gJ2tpeI0l+0ch2Nk3?= =?us-ascii?Q?FQXDlC+2EuZ5Ik3x74NCWn90O9G28KrVEhvWCvIOD9H9Dsni87XC0jAEhFWj?= =?us-ascii?Q?ssbdmwNkeerhUFfiyO9dsEOfP0/JAsAT5GNOmGLlo8nBF8SNbPLDMJRlV7eB?= =?us-ascii?Q?PHmrlK/2gZMaZcjN0hFAxTTvXBCJfFhlvFEbRnXfrd15VIV4AuiQK3YcaiDE?= =?us-ascii?Q?omYD2thPteO5sMScuH3qJ+6ifFukQ7lKXjYS/QhiDa9d+5GaW/3e/9eNrRMO?= =?us-ascii?Q?VUkA9U0p+jmGbXxf+V4iNE0u0ZU4PCplV04IxwWZw4Mn0OHrlpLTNt2B9QmW?= =?us-ascii?Q?McOfnUG3+S+JVRq4s86wcWR93X73JvUoqFSvhSiEURVvhyOBGPw9QfiH09Gv?= =?us-ascii?Q?FhVCfzo6K2MZZwS8S29pxmgDc+BvJeRnCnDae7uapMoXburDGqd4ZEfv3QXD?= =?us-ascii?Q?NswaQ1xv9EwLd90gyECTnLLiiWBude2W6Grqv696ik2h6P34Ho6yZQRU6p1g?= =?us-ascii?Q?8O6qiIfFJaBQ4oYFcE37tywfm/qWVQL1LWbt2Gy0cRQZwbEYEbs91bhmz8n6?= =?us-ascii?Q?gOWmOf4dTvS9BbuwQljL11i5G9eoUTUEMfwx?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB035; 3:Yto8Y2jyOu3yAcPgrwz+bSGE3z0opAxSQg/D/k4KHwyrW7akaQKzQabBzbcEjLyB3TkGZR4h6h0FFxk8i2KHx6/v94gVzZ9J/ZGeBZ6ZdVJAJj0m3ZmDvyYOJB8T8N4VKogej7WfUlbsnMsrfF7EIA==; 10:TqC7Ibb6AgTSLQIF5fKC8QYaIMgh4OsIaPeXTcruydZnbrGqa5Gz6M9hzwZ3rLIWWwln1DtiUK8BHSKUHJ0op2ulKhV42obiOKoJBz2mU18= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2015 16:32:32.1620 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.80]; Helo=[preapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB035 Archived-At: Subject: [DMM] FPC carrier ID and network ID question X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 16:32:37 -0000 --_000_d35a39c8edb44ee597716a4b69ee2c9ePLSWE13M01adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have a question regarding the Carrier ID and Network ID elements proposed= in the DMM FPC protocol. I am trying to a) understand the meaning intend= ed for Carrier and Network; and, b) reconcile these names with what is fami= liar to me as someone who works for a mobile service provider. The problem= that I'm basically running into is that there are only 8 bits assigned eac= h for Carrier ID and Network ID. I am accustomed to utilizing a PLMN, whic= h is composed of an MCC and MNC, each having allowed values up to 999. Wit= h only eight bits, there are fewer values than required for either MCC or M= NC. Eight bits for Carrier ID and Network ID seems to be quite constrained= to me. I suspect that something else is meant, but I cannot readily surmise what i= t might be. Thanks, Larry Laporte ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_d35a39c8edb44ee597716a4b69ee2c9ePLSWE13M01adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have a question regarding the Carrier ID and Netwo= rk ID elements proposed in the DMM FPC protocol.  I am trying to  = ;a) understand the meaning intended for Carrier and Network; and, b) reconc= ile these names with what is familiar to me as someone who works for a mobile service provider.  The problem that= I’m basically running into is that there are only 8 bits assigned ea= ch for Carrier ID and Network ID.  I am accustomed to utilizing a PLMN= , which is composed of an MCC and MNC, each having allowed values up to 999.  With only eight bits, there are fewer valu= es than required for either MCC or MNC.  Eight bits for Carrier ID and= Network ID seems to be quite constrained to me.

 

I suspect that something else is meant, but I cannot= readily surmise what it might be. 

 

Thanks,

 

Larry Laporte

 



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_d35a39c8edb44ee597716a4b69ee2c9ePLSWE13M01adsprintcom_-- From nobody Fri May 29 06:24:30 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2951A8AA6 for ; Fri, 29 May 2015 06:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTM7GhWbMF0u for ; Fri, 29 May 2015 06:24:28 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EE2F1A8AA9 for ; Fri, 29 May 2015 06:24:28 -0700 (PDT) Received: by ieczm2 with SMTP id zm2so62571121iec.1 for ; Fri, 29 May 2015 06:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vQYEX9ejP9l3nrx1xcpxh4XnFL3v1XJd/+ZCmnWyac4=; b=kZSo2DDVCpQ3LW1i1eWyfd50fowcv65q+UtgjojVv57Uk7IWtkAiEgXuRlneOWJ+iM V9iqncR6oSMj/KWb4YTlu00iEV5yov3hGFrckG9u/PO/q1A7836/vBoKbrMfVZXuQYw8 Ojbx6/sKEuccrXQmvkfnKsAoEl7IWGKzsUMMiWN3HAgJ+Wz4vikvKf4L/UBO8FJT03Km HMZVpzFUe9k3YFHYtDf4gAzqq+O4Y6pI/7dlgQ2pJkugTshWac0eAbHR0IptSm2ozJTR +Ttp2c8Zh/Sc4DYSNkYdl6xMMsuINP/Q3XVt5d2In9BXhY+xk3AS3+K3RxhR2lMAIHFW wJmg== MIME-Version: 1.0 X-Received: by 10.107.26.207 with SMTP id a198mr10111122ioa.5.1432905867791; Fri, 29 May 2015 06:24:27 -0700 (PDT) Received: by 10.36.64.79 with HTTP; Fri, 29 May 2015 06:24:27 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 May 2015 22:24:27 +0900 Message-ID: From: Satoru Matsushima To: "sarikaya@ieee.org" Content-Type: multipart/alternative; boundary=001a113feeb63f166305173865d6 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] vepc draft Rev. 04 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 13:24:30 -0000 --001a113feeb63f166305173865d6 Content-Type: text/plain; charset=UTF-8 Hi Behcet-san, On Wed, May 27, 2015 at 5:34 AM, Behcet Sarikaya wrote: > Hi Satoru, > > Thanks for your reply. > > Let me continue the discussion with your text in Section 3.2 where you > mention > vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) > that defines FPCP Agent function and Client function. > > I don't understand how you could justify defining a new forwarding > policy configuration protocol to do this Agent/Client functionality? > Why not use similar Agent/Client models that are being defined rather > than defining a new protocol? > I think this point requires much stronger justification which I could > not see in Section 3.2. > > The text just describes about a part of where FPCP may be applicable in vEPC. > Are you that we have to to reinvent the wheel, rather than reusing > something that is already available? How are we going to reinvent that > wheel also remains to be seen, I think. > > Point taken. Which kind of wheel do you have in mind? cheers, --satoru --001a113feeb63f166305173865d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Behcet-san,

On Wed, May 27, 2015 at = 5:34 AM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote= :
Hi Satoru,

Thanks for your reply.

Let me continue the discussion with your text in Section 3.2 where you ment= ion
vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP)
that defines FPCP Agent function and Client function.

I don't understand how you could justify defining a new forwarding
policy configuration protocol to do this Agent/Client functionality?
Why not use similar Agent/Client models that are being defined rather
than defining a new protocol?
I think this point requires much stronger justification which I could
not see in Section 3.2.


The text just describes about a part o= f where FPCP may be applicable in vEPC.


=C2=A0
Are you that we have to to reinvent the wheel, rather than reusing
something that is already available? How are we going to reinvent that
wheel also remains to be seen, I think.


Point taken. Which kind of wheel = do you have in mind?

cheers,
--sat= oru

--001a113feeb63f166305173865d6-- From nobody Fri May 29 06:30:40 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872661A8ADE for ; Fri, 29 May 2015 06:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoQFjEovrtjL for ; Fri, 29 May 2015 06:30:36 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1821A8ADF for ; Fri, 29 May 2015 06:30:36 -0700 (PDT) Received: by iesa3 with SMTP id a3so62728470ies.2 for ; Fri, 29 May 2015 06:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=quwtDOLjYYMxw486iVLgurNEIEsj78rpVu4Fjn+hyUI=; b=NSDC2AHHI0MOC5d5bRHOGZh3gHo8Uikp2zflQrGPlV7IuAoxXldWN8a7ZjInk+9gdi FiaxTewAOzrfc7/w98IZFycatC+qrL1J0FlqCmvAeDrUdpRm86SMNIB941wWum6DRxA+ YqFYoI767ppKR9hViNy7cW/5ym6uc3DAxwWBPn+BNiIN5Rq5YETw5n7XkF6hbfqLis/B b9dmU7oVjcs+/AO98xyI/8azlYwzVfLCAyzzTRgFj8CzVukS8b3uyZoTDPfdxISoI9bY HDvISWq8H3UCesXTJcQuZxdpy7YFrp0RWmQTvsO4zI6v090+U1yl+5I8C14uIwqrdFen Xxkw== MIME-Version: 1.0 X-Received: by 10.107.26.207 with SMTP id a198mr10147608ioa.5.1432906235761; Fri, 29 May 2015 06:30:35 -0700 (PDT) Received: by 10.36.64.79 with HTTP; Fri, 29 May 2015 06:30:35 -0700 (PDT) In-Reply-To: <5565AAFB.9030100@gmail.com> References: <5565AAFB.9030100@gmail.com> Date: Fri, 29 May 2015 22:30:35 +0900 Message-ID: From: Satoru Matsushima To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=001a113feeb62ddad90517387bae Archived-At: Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 13:30:38 -0000 --001a113feeb62ddad90517387bae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ah OK. thanks. Slightly off-topic, I think that there is still chance for tethering with single /64 if it is allocated as a off-link prefix. But yes, I agree with you. cheers, --satoru On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Hi, > > In addition to what Behcet says. > > I read the example below. I think it is just an example, but just to mak= e > sure. > > Please - do not allocate /64s to end users in a cellular network. Allocat= e > at least /62s to end users. > > This is to allow the smartphone to perform tethering (small network of > wifi devices connecting through the smartphone to the Internet). > > The assumption of /64 to end user is not good at all. > > (and yes, I agree that these /62s may be aggregated into a larger prefix > and advertised upstream as a single prefix instead of multiple host-based > routes). > > Yours, > > Alex Petrescu > > Le 26/05/2015 22:34, Behcet Sarikaya a =C3=A9crit : > >> Hi Satoru, >> >> Thanks for your reply. >> >> Let me continue the discussion with your text in Section 3.2 where you >> mention >> vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) >> that defines FPCP Agent function and Client function. >> >> I don't understand how you could justify defining a new forwarding >> policy configuration protocol to do this Agent/Client functionality? >> Why not use similar Agent/Client models that are being defined rather >> than defining a new protocol? >> I think this point requires much stronger justification which I could >> not see in Section 3.2. >> >> Are you that we have to to reinvent the wheel, rather than reusing >> something that is already available? How are we going to reinvent that >> wheel also remains to be seen, I think. >> >> Regards, >> >> Behcet >> >> >> >> On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima >> wrote: >> >>> Hi Bechet-san, >>> >>> Thank you for your question. >>> In step (15), I meant that EPC-E advertises prefix including UE assigne= d >>> prefixes. >>> >>> For example, in the case of /64 prefixes assigned to UEs from a /56 >>> space, >>> that /56 >>> is advertised by EPC-E to upstream routers. So the advertised route isn= 't >>> host routes. >>> >>> Depends on configuration policy, but one case is that the source of tha= t >>> advertised >>> /56 route might be statically configured in EPC-E. >>> >>> Regards, >>> --satoru >>> >>> >>> >>> On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya >> > >>> wrote: >>> >>>> >>>> Hi Matsushima-san, >>>> >>>> I have a question on your draft: >>>> In Sec. 3.2, page 11, you say >>>> In step (15), the EPC-E advertises routes to upstream routers ... >>>> >>>> Are these routes static/host routes? >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>> >>> >>> >> _______________________________________________ >> 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 > --001a113feeb62ddad90517387bae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah OK. thanks.
Slightly off-topic, I think that there = is still chance for tethering with single /64 if it is allocated as a off-l= ink prefix.

But yes, I agree with you.
<= br>
cheers,
--satoru

=
On Wed, May 27, 2015 at 8:31 PM, Alexandru Petre= scu <alexandru.petrescu@gmail.com> wrote:
Hi,

In addition to what Behcet says.

I read the example below.=C2=A0 I think it is just an example, but just to = make sure.

Please - do not allocate /64s to end users in a cellular network. Allocate = at least /62s to end users.

This is to allow the smartphone to perform tethering (small network of wifi= devices connecting through the smartphone to the Internet).

The assumption of /64 to end user is not good at all.

(and yes, I agree that these /62s may be aggregated into a larger prefix an= d advertised upstream as a single prefix instead of multiple host-based rou= tes).

Yours,

Alex Petrescu

Le 26/05/2015 22:34, Behcet Sarikaya a =C3=A9crit :
Hi Satoru,

Thanks for your reply.

Let me continue the discussion with your text in Section 3.2 where you ment= ion
vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP)
that defines FPCP Agent function and Client function.

I don't understand how you could justify defining a new forwarding
policy configuration protocol to do this Agent/Client functionality?
Why not use similar Agent/Client models that are being defined rather
than defining a new protocol?
I think this point requires much stronger justification which I could
not see in Section 3.2.

Are you that we have to to reinvent the wheel, rather than reusing
something that is already available? How are we going to reinvent that
wheel also remains to be seen, I think.

Regards,

Behcet



On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima
<satoru= .matsushima@gmail.com> wrote:
Hi Bechet-san,

Thank you for your question.
In step (15), I meant that EPC-E advertises prefix including UE assigned prefixes.

For example, in the case of /64 prefixes assigned to UEs from a /56 space,<= br> that /56
is advertised by EPC-E to upstream routers. So the advertised route isn'= ;t
host routes.

Depends on configuration policy, but one case is that the source of that advertised
/56 route might be statically configured in EPC-E.

Regards,
--satoru



On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya <sarikaya2012@gmail.com>
wrote:

=C2=A0 Hi Matsushima-san,

I have a question on your draft:
In Sec. 3.2, page 11, you say
In step (15), the EPC-E advertises routes to upstream routers ...

Are these routes static/host routes?

Regards,

Behcet



_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm




_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm

--001a113feeb62ddad90517387bae-- From nobody Fri May 29 06:34:39 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24DF1A8ADC for ; Fri, 29 May 2015 06:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWeVs7W4s7JQ for ; Fri, 29 May 2015 06:34:35 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ADD01A8A85 for ; Fri, 29 May 2015 06:34:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 86215109D5B; Fri, 29 May 2015 15:34:33 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkd6rp0AamQx; Fri, 29 May 2015 15:34:33 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 64501109DDB; Fri, 29 May 2015 15:34:29 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.25]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Fri, 29 May 2015 15:34:29 +0200 From: Marco Liebsch To: "Laporte, Laurent [CTO]" , "dmm@ietf.org" Thread-Topic: FPC carrier ID and network ID question Thread-Index: AdCZY8eSHKVtCkFuS16oqfq1KLDiYgAsFxug Date: Fri, 29 May 2015 13:34:28 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D99AD9C54@PALLENE.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D99AD9C54PALLENEofficehd_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] FPC carrier ID and network ID question X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 13:34:39 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D99AD9C54PALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Larry, thanks for your feedback and valid doubts, as you pointed out an important = point to discuss. First of all, the space for a certain field in the ID can be increased. We = may have a preceding discussion about how the identifier format should look like; as proposed in= this version of the draft or differently. The rationale behind the Client-ID, Agent-ID and DPN-ID to allow unambiguou= s identification of a function instance associated with FPC and its location. 'Location' mea= ns to identify the network, e.g. a certain datacenter, where a function is instantiated and op= erational. Example: An IP switch, which can serve as Data Plane Node for mobility mana= gement, is located in a local POP/datacenter. The datacenter can be identified in the = Network ID field of the complete identifier and should be unique within the carrier's network t= opology. In the example you brought, the Network Code (MNC) identifies rather the carrier instead o= f a certain spot of a single carrier's network topology. In terms of FPC deployment, we may omit the Carrier-ID field in identifiers= in case we do not expose and use these identifiers outside of a single carrier. But= it may be useful to identify the carrier as well in case, for example, a Client of ca= rrier 1 connects to an Agent of Carrier 2. In case we need to keep a Carrier-ID field, it may comprise t= he complete tuple of MCC/MNC as you refer to. I hope that clarifies your question and we can follow up on that thread to = find a suitable format for the complete identifier. Thanks, Marco From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Laporte, Laurent [CTO] Sent: Donnerstag, 28. Mai 2015 18:33 To: dmm@ietf.org Subject: [DMM] FPC carrier ID and network ID question Hello, I have a question regarding the Carrier ID and Network ID elements proposed= in the DMM FPC protocol. I am trying to a) understand the meaning intend= ed for Carrier and Network; and, b) reconcile these names with what is fami= liar to me as someone who works for a mobile service provider. The problem= that I'm basically running into is that there are only 8 bits assigned eac= h for Carrier ID and Network ID. I am accustomed to utilizing a PLMN, whic= h is composed of an MCC and MNC, each having allowed values up to 999. Wit= h only eight bits, there are fewer values than required for either MCC or M= NC. Eight bits for Carrier ID and Network ID seems to be quite constrained= to me. I suspect that something else is meant, but I cannot readily surmise what i= t might be. Thanks, Larry Laporte ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_69756203DDDDE64E987BC4F70B71A26D99AD9C54PALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Larry,

thanks for your feedback and valid doubts, as you pointed out an important = point to discuss.

First of all, the spac= e for a certain field in the ID can be increased. We may have a preceding discussion about how the identifier format should look like; as proposed in= this version of
the draft or differently.

 

The rationale behind t= he Client-ID, Agent-ID and DPN-ID to allow unambiguous identification
of a function instance associated with FPC and its location. ‘Locatio= n’ means to identify the
network, e.g. a certain datacenter, where a function is instantiated and op= erational.

 

Example: An IP switch,= which can serve as Data Plane Node for mobility management, is
located in a local POP/datacenter. The datacenter can be identified in the = Network ID field of
the complete identifier and should be unique within the carrier’s net= work topology. In the example
you brought, the Network Code (MNC) identifies rather the carrier instead o= f a certain
spot of a single carrier’s network topology.

 

In terms of FPC deploy= ment, we may omit the Carrier-ID field in identifiers in case
we do not expose and use these identifiers outside of a single carrier. But= it may be
useful to identify the carrier as well in case, for example, a Client of ca= rrier 1 connects to an Agent
of Carrier 2. In case we need to keep a Carrier-ID field, it may comprise t= he complete
tuple of MCC/MNC as you refer to.

 

I hope that clarifies = your question and we can follow up on that thread to find a suitable
format for the complete identifier.

 

Thanks,

Marco

 

 

 

From: dmm [mai= lto:dmm-bounces@ietf.org] On Behalf Of Laporte, Laurent [CTO]
Sent: Donnerstag, 28. Mai 2015 18:33
To: dmm@ietf.org
Subject: [DMM] FPC carrier ID and network ID question

 

Hello,

 

I have a question regarding the Carrier ID and Netwo= rk ID elements proposed in the DMM FPC protocol.  I am trying to  = ;a) understand the meaning intended for Carrier and Network; and, b) reconc= ile these names with what is familiar to me as someone who works for a mobile service provider.  The problem that= I’m basically running into is that there are only 8 bits assigned ea= ch for Carrier ID and Network ID.  I am accustomed to utilizing a PLMN= , which is composed of an MCC and MNC, each having allowed values up to 999.  With only eight bits, there are fewer valu= es than required for either MCC or MNC.  Eight bits for Carrier ID and= Network ID seems to be quite constrained to me.

 

I suspect that something else is meant, but I cannot= readily surmise what it might be. 

 

Thanks,

 

Larry Laporte

 

 


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

--_000_69756203DDDDE64E987BC4F70B71A26D99AD9C54PALLENEofficehd_-- From nobody Fri May 29 10:58:53 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4641AD17F for ; Fri, 29 May 2015 10:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CPbt3Nrts6W for ; Fri, 29 May 2015 10:58:45 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5411AD1A3 for ; Fri, 29 May 2015 10:58:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t4THwgCL025780; Fri, 29 May 2015 19:58:42 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B545D20C93B; Fri, 29 May 2015 20:01:01 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A9AF120C846; Fri, 29 May 2015 20:01:01 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.56]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t4THwfjA029164; Fri, 29 May 2015 19:58:42 +0200 Message-ID: <5568A8D1.7030908@gmail.com> Date: Fri, 29 May 2015 19:58:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Satoru Matsushima References: <5565AAFB.9030100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 17:58:51 -0000 Le 29/05/2015 15:30, Satoru Matsushima a écrit : > Ah OK. thanks. > Slightly off-topic, I think that there is still chance for tethering > with single /64 if it is allocated as a off-link prefix. Yes, there is still such a chance. But it can not tether more than one single subnet. Connected vehicles need several subnets. Alex > > But yes, I agree with you. > > cheers, > --satoru > > On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu > > wrote: > > Hi, > > In addition to what Behcet says. > > I read the example below. I think it is just an example, but just > to make sure. > > Please - do not allocate /64s to end users in a cellular network. > Allocate at least /62s to end users. > > This is to allow the smartphone to perform tethering (small network > of wifi devices connecting through the smartphone to the Internet). > > The assumption of /64 to end user is not good at all. > > (and yes, I agree that these /62s may be aggregated into a larger > prefix and advertised upstream as a single prefix instead of > multiple host-based routes). > > Yours, > > Alex Petrescu > > Le 26/05/2015 22:34, Behcet Sarikaya a écrit : > > Hi Satoru, > > Thanks for your reply. > > Let me continue the discussion with your text in Section 3.2 > where you mention > vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) > that defines FPCP Agent function and Client function. > > I don't understand how you could justify defining a new forwarding > policy configuration protocol to do this Agent/Client functionality? > Why not use similar Agent/Client models that are being defined > rather > than defining a new protocol? > I think this point requires much stronger justification which I > could > not see in Section 3.2. > > Are you that we have to to reinvent the wheel, rather than reusing > something that is already available? How are we going to > reinvent that > wheel also remains to be seen, I think. > > Regards, > > Behcet > > > > On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima > > wrote: > > Hi Bechet-san, > > Thank you for your question. > In step (15), I meant that EPC-E advertises prefix including > UE assigned > prefixes. > > For example, in the case of /64 prefixes assigned to UEs > from a /56 space, > that /56 > is advertised by EPC-E to upstream routers. So the > advertised route isn't > host routes. > > Depends on configuration policy, but one case is that the > source of that > advertised > /56 route might be statically configured in EPC-E. > > Regards, > --satoru > > > > On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya > > > wrote: > > > Hi Matsushima-san, > > I have a question on your draft: > In Sec. 3.2, page 11, you say > In step (15), the EPC-E advertises routes to upstream > routers ... > > Are these routes static/host routes? > > Regards, > > Behcet > > > > > _______________________________________________ > 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 > > From nobody Fri May 29 11:21:39 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C4F1B2BAA for ; Fri, 29 May 2015 11:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDdtjcC0VVb5 for ; Fri, 29 May 2015 11:21:34 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F111B2BA4 for ; Fri, 29 May 2015 11:21:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t4TILXvS017134; Fri, 29 May 2015 13:21:33 -0500 Received: from XCH-BLV-503.nw.nos.boeing.com (xch-blv-503.nw.nos.boeing.com [130.247.25.192]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t4TILPRt017083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 29 May 2015 13:21:26 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.238]) by XCH-BLV-503.nw.nos.boeing.com ([169.254.3.178]) with mapi id 14.03.0235.001; Fri, 29 May 2015 11:21:24 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , Satoru Matsushima Thread-Topic: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Thread-Index: AQHQmjkkJI//M3dql0O3DI0sVGxml52TQ0XQ Date: Fri, 29 May 2015 18:21:24 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> In-Reply-To: <5568A8D1.7030908@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 18:21:37 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkbW0gW21h aWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsZXhhbmRydSBQZXRyZXNj dQ0KPiBTZW50OiBGcmlkYXksIE1heSAyOSwgMjAxNSAxMDo1OSBBTQ0KPiBUbzogU2F0b3J1IE1h dHN1c2hpbWENCj4gQ2M6IGRtbQ0KPiBTdWJqZWN0OiBSZTogW0RNTV0gdmVwYyBkcmFmdCBSZXYu IDA0IC0gLzYycyB0byBVRSwgbm90IC82NHMNCj4gDQo+IExlIDI5LzA1LzIwMTUgMTU6MzAsIFNh dG9ydSBNYXRzdXNoaW1hIGEgw6ljcml0IDoNCj4gPiBBaCBPSy4gdGhhbmtzLg0KPiA+IFNsaWdo dGx5IG9mZi10b3BpYywgSSB0aGluayB0aGF0IHRoZXJlIGlzIHN0aWxsIGNoYW5jZSBmb3IgdGV0 aGVyaW5nDQo+ID4gd2l0aCBzaW5nbGUgLzY0IGlmIGl0IGlzIGFsbG9jYXRlZCBhcyBhIG9mZi1s aW5rIHByZWZpeC4NCj4gDQo+IFllcywgdGhlcmUgaXMgc3RpbGwgc3VjaCBhIGNoYW5jZS4gIEJ1 dCBpdCBjYW4gbm90IHRldGhlciBtb3JlIHRoYW4gb25lDQo+IHNpbmdsZSBzdWJuZXQuICBDb25u ZWN0ZWQgdmVoaWNsZXMgbmVlZCBzZXZlcmFsIHN1Ym5ldHMuDQoNCkhvdyB3b3VsZCBpdCBiZSBp ZiB0aGUgdmVoaWNsZSByZWNlaXZlZCBhIHNpbmdsZSBwcmVmaXgsIGJ1dCBpdCBjb3VsZCBiZQ0K c2hvcnRlciB0aGFuIC82NCAoZS5nLiwgLzU2LCAvNDguIGV0Yy4pPyBXb3VsZCB0aGUgdmVoaWNs ZSBzdWJuZXR0aW5nDQpiZSBzYXRpc2ZpZWQgaWYgaXQgcmVjZWl2ZWQgYSBzaG9ydGVyIHByZWZp eCBmcm9tIHdoaWNoIG1hbnkgLzY0cw0KY291bGQgYmUgYWxsb2NhdGVkPw0KDQpUaGFua3MgLSBG cmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQoNCg0KPiANCj4gQWxleA0KPiANCj4gPg0K PiA+IEJ1dCB5ZXMsIEkgYWdyZWUgd2l0aCB5b3UuDQo+ID4NCj4gPiBjaGVlcnMsDQo+ID4gLS1z YXRvcnUNCj4gPg0KPiA+IE9uIFdlZCwgTWF5IDI3LCAyMDE1IGF0IDg6MzEgUE0sIEFsZXhhbmRy dSBQZXRyZXNjdQ0KPiA+IDxhbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tIDxtYWlsdG86YWxl eGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbT4+IHdyb3RlOg0KPiA+DQo+ID4gICAgIEhpLA0KPiA+ DQo+ID4gICAgIEluIGFkZGl0aW9uIHRvIHdoYXQgQmVoY2V0IHNheXMuDQo+ID4NCj4gPiAgICAg SSByZWFkIHRoZSBleGFtcGxlIGJlbG93LiAgSSB0aGluayBpdCBpcyBqdXN0IGFuIGV4YW1wbGUs IGJ1dCBqdXN0DQo+ID4gICAgIHRvIG1ha2Ugc3VyZS4NCj4gPg0KPiA+ICAgICBQbGVhc2UgLSBk byBub3QgYWxsb2NhdGUgLzY0cyB0byBlbmQgdXNlcnMgaW4gYSBjZWxsdWxhciBuZXR3b3JrLg0K PiA+ICAgICBBbGxvY2F0ZSBhdCBsZWFzdCAvNjJzIHRvIGVuZCB1c2Vycy4NCj4gPg0KPiA+ICAg ICBUaGlzIGlzIHRvIGFsbG93IHRoZSBzbWFydHBob25lIHRvIHBlcmZvcm0gdGV0aGVyaW5nIChz bWFsbCBuZXR3b3JrDQo+ID4gICAgIG9mIHdpZmkgZGV2aWNlcyBjb25uZWN0aW5nIHRocm91Z2gg dGhlIHNtYXJ0cGhvbmUgdG8gdGhlIEludGVybmV0KS4NCj4gPg0KPiA+ICAgICBUaGUgYXNzdW1w dGlvbiBvZiAvNjQgdG8gZW5kIHVzZXIgaXMgbm90IGdvb2QgYXQgYWxsLg0KPiA+DQo+ID4gICAg IChhbmQgeWVzLCBJIGFncmVlIHRoYXQgdGhlc2UgLzYycyBtYXkgYmUgYWdncmVnYXRlZCBpbnRv IGEgbGFyZ2VyDQo+ID4gICAgIHByZWZpeCBhbmQgYWR2ZXJ0aXNlZCB1cHN0cmVhbSBhcyBhIHNp bmdsZSBwcmVmaXggaW5zdGVhZCBvZg0KPiA+ICAgICBtdWx0aXBsZSBob3N0LWJhc2VkIHJvdXRl cykuDQo+ID4NCj4gPiAgICAgWW91cnMsDQo+ID4NCj4gPiAgICAgQWxleCBQZXRyZXNjdQ0KPiA+ DQo+ID4gICAgIExlIDI2LzA1LzIwMTUgMjI6MzQsIEJlaGNldCBTYXJpa2F5YSBhIMOpY3JpdCA6 DQo+ID4NCj4gPiAgICAgICAgIEhpIFNhdG9ydSwNCj4gPg0KPiA+ICAgICAgICAgVGhhbmtzIGZv ciB5b3VyIHJlcGx5Lg0KPiA+DQo+ID4gICAgICAgICBMZXQgbWUgY29udGludWUgdGhlIGRpc2N1 c3Npb24gd2l0aCB5b3VyIHRleHQgaW4gU2VjdGlvbiAzLjINCj4gPiAgICAgICAgIHdoZXJlIHlv dSBtZW50aW9uDQo+ID4gICAgICAgICB2RVBDIG1heSB1dGlsaXplcyBGb3J3YXJkaW5nIFBvbGlj eSBDb25maWd1cmF0aW9uIFByb3RvY29sIChGUENQKQ0KPiA+ICAgICAgICAgdGhhdCBkZWZpbmVz IEZQQ1AgQWdlbnQgZnVuY3Rpb24gYW5kIENsaWVudCBmdW5jdGlvbi4NCj4gPg0KPiA+ICAgICAg ICAgSSBkb24ndCB1bmRlcnN0YW5kIGhvdyB5b3UgY291bGQganVzdGlmeSBkZWZpbmluZyBhIG5l dyBmb3J3YXJkaW5nDQo+ID4gICAgICAgICBwb2xpY3kgY29uZmlndXJhdGlvbiBwcm90b2NvbCB0 byBkbyB0aGlzIEFnZW50L0NsaWVudCBmdW5jdGlvbmFsaXR5Pw0KPiA+ICAgICAgICAgV2h5IG5v dCB1c2Ugc2ltaWxhciBBZ2VudC9DbGllbnQgbW9kZWxzIHRoYXQgYXJlIGJlaW5nIGRlZmluZWQN Cj4gPiAgICAgICAgIHJhdGhlcg0KPiA+ICAgICAgICAgdGhhbiBkZWZpbmluZyBhIG5ldyBwcm90 b2NvbD8NCj4gPiAgICAgICAgIEkgdGhpbmsgdGhpcyBwb2ludCByZXF1aXJlcyBtdWNoIHN0cm9u Z2VyIGp1c3RpZmljYXRpb24gd2hpY2ggSQ0KPiA+ICAgICAgICAgY291bGQNCj4gPiAgICAgICAg IG5vdCBzZWUgaW4gU2VjdGlvbiAzLjIuDQo+ID4NCj4gPiAgICAgICAgIEFyZSB5b3UgdGhhdCB3 ZSBoYXZlIHRvIHRvIHJlaW52ZW50IHRoZSB3aGVlbCwgcmF0aGVyIHRoYW4gcmV1c2luZw0KPiA+ ICAgICAgICAgc29tZXRoaW5nIHRoYXQgaXMgYWxyZWFkeSBhdmFpbGFibGU/IEhvdyBhcmUgd2Ug Z29pbmcgdG8NCj4gPiAgICAgICAgIHJlaW52ZW50IHRoYXQNCj4gPiAgICAgICAgIHdoZWVsIGFs c28gcmVtYWlucyB0byBiZSBzZWVuLCBJIHRoaW5rLg0KPiA+DQo+ID4gICAgICAgICBSZWdhcmRz LA0KPiA+DQo+ID4gICAgICAgICBCZWhjZXQNCj4gPg0KPiA+DQo+ID4NCj4gPiAgICAgICAgIE9u IFNhdCwgTWF5IDE2LCAyMDE1IGF0IDg6MDEgQU0sIFNhdG9ydSBNYXRzdXNoaW1hDQo+ID4gICAg ICAgICA8c2F0b3J1Lm1hdHN1c2hpbWFAZ21haWwuY29tDQo+ID4gICAgICAgICA8bWFpbHRvOnNh dG9ydS5tYXRzdXNoaW1hQGdtYWlsLmNvbT4+IHdyb3RlOg0KPiA+DQo+ID4gICAgICAgICAgICAg SGkgQmVjaGV0LXNhbiwNCj4gPg0KPiA+ICAgICAgICAgICAgIFRoYW5rIHlvdSBmb3IgeW91ciBx dWVzdGlvbi4NCj4gPiAgICAgICAgICAgICBJbiBzdGVwICgxNSksIEkgbWVhbnQgdGhhdCBFUEMt RSBhZHZlcnRpc2VzIHByZWZpeCBpbmNsdWRpbmcNCj4gPiAgICAgICAgICAgICBVRSBhc3NpZ25l ZA0KPiA+ICAgICAgICAgICAgIHByZWZpeGVzLg0KPiA+DQo+ID4gICAgICAgICAgICAgRm9yIGV4 YW1wbGUsIGluIHRoZSBjYXNlIG9mIC82NCBwcmVmaXhlcyBhc3NpZ25lZCB0byBVRXMNCj4gPiAg ICAgICAgICAgICBmcm9tIGEgLzU2IHNwYWNlLA0KPiA+ICAgICAgICAgICAgIHRoYXQgLzU2DQo+ ID4gICAgICAgICAgICAgaXMgYWR2ZXJ0aXNlZCBieSBFUEMtRSB0byB1cHN0cmVhbSByb3V0ZXJz LiBTbyB0aGUNCj4gPiAgICAgICAgICAgICBhZHZlcnRpc2VkIHJvdXRlIGlzbid0DQo+ID4gICAg ICAgICAgICAgaG9zdCByb3V0ZXMuDQo+ID4NCj4gPiAgICAgICAgICAgICBEZXBlbmRzIG9uIGNv bmZpZ3VyYXRpb24gcG9saWN5LCBidXQgb25lIGNhc2UgaXMgdGhhdCB0aGUNCj4gPiAgICAgICAg ICAgICBzb3VyY2Ugb2YgdGhhdA0KPiA+ICAgICAgICAgICAgIGFkdmVydGlzZWQNCj4gPiAgICAg ICAgICAgICAvNTYgcm91dGUgbWlnaHQgYmUgc3RhdGljYWxseSBjb25maWd1cmVkIGluIEVQQy1F Lg0KPiA+DQo+ID4gICAgICAgICAgICAgUmVnYXJkcywNCj4gPiAgICAgICAgICAgICAtLXNhdG9y dQ0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgICAgICAgICAgIE9uIFdlZCwgTWF5IDEzLCAyMDE1IGF0 IDQ6NTEgQU0sIEJlaGNldCBTYXJpa2F5YQ0KPiA+ICAgICAgICAgICAgIDxzYXJpa2F5YTIwMTJA Z21haWwuY29tIDxtYWlsdG86c2FyaWtheWEyMDEyQGdtYWlsLmNvbT4+DQo+ID4gICAgICAgICAg ICAgd3JvdGU6DQo+ID4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICBIaSBNYXRzdXNoaW1h LXNhbiwNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICBJIGhhdmUgYSBxdWVzdGlvbiBvbiB5b3Vy IGRyYWZ0Og0KPiA+ICAgICAgICAgICAgICAgICBJbiBTZWMuIDMuMiwgcGFnZSAxMSwgeW91IHNh eQ0KPiA+ICAgICAgICAgICAgICAgICBJbiBzdGVwICgxNSksIHRoZSBFUEMtRSBhZHZlcnRpc2Vz IHJvdXRlcyB0byB1cHN0cmVhbQ0KPiA+ICAgICAgICAgICAgICAgICByb3V0ZXJzIC4uLg0KPiA+ DQo+ID4gICAgICAgICAgICAgICAgIEFyZSB0aGVzZSByb3V0ZXMgc3RhdGljL2hvc3Qgcm91dGVz Pw0KPiA+DQo+ID4gICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQo+ID4NCj4gPiAgICAgICAgICAg ICAgICAgQmVoY2V0DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiAgICAgICAgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gICAgICAgICBkbW0gbWFp bGluZyBsaXN0DQo+ID4gICAgICAgICBkbW1AaWV0Zi5vcmcgPG1haWx0bzpkbW1AaWV0Zi5vcmc+ DQo+ID4gICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0K PiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gICAgIGRtbSBtYWlsaW5nIGxpc3QNCj4gPiAgICAgZG1t QGlldGYub3JnIDxtYWlsdG86ZG1tQGlldGYub3JnPg0KPiA+ICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KPiA+DQo+ID4NCj4gDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkbW0gbWFpbGluZyBsaXN0 DQo+IGRtbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RtbQ0K From nobody Fri May 29 13:42:17 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA561A88BC for ; Fri, 29 May 2015 13:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTqZto_5vOdg for ; Fri, 29 May 2015 13:42:14 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45EA1A88B1 for ; Fri, 29 May 2015 13:42:13 -0700 (PDT) Received: from [192.168.2.5] ([85.97.51.111]) by mrelay.perfora.net (mreueus003) with ESMTPA (Nemesis) id 0McXfq-1YgljG3RvU-00Hi9E; Fri, 29 May 2015 22:42:11 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <000c01d09482$34031160$9c093420$@av.it.pt> Date: Fri, 29 May 2015 23:41:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt> <000c01d09482$34031160$9c093420$@av.it.pt> To: Seil Jeon X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:pEWn9teet6S7f992eW7CxiZjIq6eo8KMC9ec/C3uoMGXpe3NJ++ wXvNG4UhwBz8hpxKGJtf5W1xIWuj3vHwoyhck75bAyfzIA6EbJDDlUCbNvpiqJ8qDh0H7yR UV8XNnAYaAkpOc+8AKQL5Efb0RYECJMAO+8NyVNEKWZcnyzy7xSVTYJMx9RBNwZSjkJlmms SDLEo4fuGR2BRn9GYK/Zg== X-UI-Out-Filterresults: notjunk:1;V01:K0:ou+8i5lh+sg=:ZYi8ouMxvM8kvCjzFU8LaG 4B2IzXQtiD/iAnuh+CeuOjFh3dwxeT8NO0oMlK/keiTV0xKYCeuoYkePFqno9IqnPVHI0iOE+ rHt1GLDi2ERbPWvoGCx0LjC7U1pFxvD17y0d3tI4UMIYk/kJY1Xncq1sGI+lzV87jIMHszs49 TOijnJo929yRAufWXqaEGxlyOnhZakjvyhm4nP+w7B+7wx5dl5sg+ICe8TT2mx6MF+DnpYljY 1Sv9yzicDscWDW8O+/J4CKdPnHIbvXEhWKLq7neL8b60F/Wh/R2SDt2/rdhkdvl8gtlBeG64t kIZ3zSP/Jg6AD3PLgRPKKv1TAsa/n5qUTw/tDGWhQ8p3GeLfmrR0AlhX3z1xtPDTLD/6cWrMu ampxGdeFVcd5ekcbgtkwZxHhREWN49RqcQvKExU0k0G3WVO6y7IjqlFrWW3oI12dZLPPoTAVA tKzLYQW6MbvSbUscYjUXm5jjjl8t7egYuIbY6aNjt3G4dHxDNk/PAkPm/EbGAL9fpl7WwHWI/ UtCOtfuB7VAjYIK1S8NvIQRolKk/lO/gWX1Le9pfIR8RceWlokElq84XOA18E6aybZbm5kWUz rGe5Mie99Uwt+B120vaMCiQ3tCKu/yv9kXZ1GYYAvTj6AyJrlmgQtabakkO8otlxrxnp/kPRP qTYX70uib8f4nr90yNzNnh+sKvp7XNNJV58YW64I5duCm9Q== Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 20:42:16 -0000 Hello Seil, >=20 >>=20 >> #49: full on-demand mobility support >>=20 >> The three proposed flags express a "type" of source IP address an > application wants to get to the IP stack. Particularly, the sustained = IP > address is proposed to provide on-demand IP session continuity, which > activates IP mobility once the terminal moves across other access = network. >> While the terminal stays at the same network where the session is > initiated, regular IP routing is applied. >>=20 >> The on-demand draft does not assure provide the full on-demand = mobility > for all scenarios by merely indicating the Socket API, > IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned = issue > is as follows; >>=20 >> 0. The MN is configured with one or more Nomadic IP addresses. >>=20 >> 1. Once an app. requests "sustained IP address" to the IP stack, and = it > will obtain a sustained IP address through a protocol procedure = between the > terminal and network. >>=20 >> 2. Other app. initiated over the same access network will use the = same > sustained IP address while the terminal remains connected at the same > access network. >>=20 >> 3. The terminal moves to another access network and a new app. = requests a > sustained IP address with the Socket API to the IP stack. Since a = sustained > IP address is already available in the IP stack, the sustained IP = address > is assigned to the new app. >>=20 >=20 > Yes, that's what happens. > You are not pointing to an issue up until this point, right? Because, = you > continuing your email with a "Besides" gives the impression that you = are > pointing to an issue, but I don't see any issue captured in the above = text. >=20 >>> There is an issue. Maybe, we need to be synchronized how have you = thought > and defined the meaning of "on-demand mobility". As far as I know, = there are > two meanings; one is that by imposing capability among IP address > reachability and IP session continuity, needed for an application, = into a > source IP address, on-demand mobility could be achieved; as the other > meaning, it can be rephrased and detailed with dynamic mobility, which > should be applied in the use of sustained IP address. A new = application > needs to have non-anchored sustained IP address. This is our = consistent > claim. Non-optimal routing issue has been raised in DMM Requirement = document > in RFC 7333, which should be critically considered in the solutions. >=20 Sorry, I don't understand what you meant here. >> Besides, in case sustained IP address allocation is used default, = there > may be multiple sustained IP addresses including newly obtained = sustained > IP address over the new access network in the IP stack. However, when = an > app. is initiated, the IP stack may not select the new one in the = context > of the default source IP address selection mechanism = [RFC6724][RFC5014]. >>=20 >=20 > OK, is the issue following: When there are multiple sustained IP = addresses, > how does the IP stack pick one among them? (*) >=20 >>> As mentioned and specified in our draft > http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00, = if > there is no additional preference, we can leave selection to the = default > source address selection mechanism. BUT if we have specific preference = among > multiple sustained IP addresses and an initiated application wants to = have > non-anchored sustained IP address over currently attached access = network, > the proposed flag is essential. >=20 I think you are meaning the same thing as I said above (*). Do you agree? >> For providing the full on-demand mobility, a new flag is needed, = letting > the IP stack request a new sustained IP address or choose a sustained = IP > address not requiring IP mobility anchoring when an application is > initiated, among the existing ones in the IP stack. >>=20 >=20 > Your flag is not a solution to what I captured above. It does = something > else: Instruct the IP stack to go get a new sustained IP address = whether > there is already one or more configured on the stack or not. (**) >=20 >>> Answered in the above.=20 >=20 There's a discrepancy between (*) and your solution (**). Are we talking about (*), (**), or something else? Alper > Alper >=20 >=20 >=20 >> --=20 >> = -------------------------+---------------------------------------------- >> -------------------------+--- >> Reporter: | Owner: draft-ietf-dmm-ondemand- >> seiljeon@av.it.pt | mobility@tools.ietf.org >> Type: defect | Status: new >> Priority: critical | Milestone: >> Component: ondemand- | Version: >> mobility | Keywords: on-demand mobility >> Severity: Submitted | >> WG Document | >> = -------------------------+---------------------------------------------- >> -------------------------+--- >>=20 >> Ticket URL: >> dmm >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 From nobody Fri May 29 13:44:52 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC1C1A88B1 for ; Fri, 29 May 2015 13:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN7Qnsseor_R for ; Fri, 29 May 2015 13:44:50 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58371A88BC for ; Fri, 29 May 2015 13:44:49 -0700 (PDT) Received: from [192.168.2.5] ([85.97.51.111]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0Lxv8M-1ZCZno3OZo-015Gcx; Fri, 29 May 2015 22:44:41 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Fri, 29 May 2015 23:44:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9917C9E6-73D4-408E-8BA2-A5D0FDA92B71@yegin.org> References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt> To: FIGUEIREDO Sergio X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:DGILkMNrBW718BbFZzu3X3dZv+cccB7DscpOmf73IkXBBPsddAf ptyTmuKRJU+iAtfkCszBSrDyRbhcV4hzPyhyaPajqAVni/c3gBb7Kcq6iuGfY2cgjUNJ06n izV/BvC0rPlRS9rOnaYbXyStfjb+xNsKmkEec5WU+KKU2ApuCC7N07EurkxuzkKR3UV93xO O0nPgVo+Ablcqv3gYSs0g== X-UI-Out-Filterresults: notjunk:1;V01:K0:+CItODgsZEA=:UanPbjTkL7iowwNXaVLvZr nhm4WwXTq7Ge7sf2IEqhoF9aqIz3zTeiR4fCvV8a68gLZFjjQmAUXpayPQhcnmbIQEk40ofSb 3zL7jVX/BVw8XwimyvMgQ+ar7iM1jh/wy8XO2jxygcXEbz3TZym49MR2yrhsFo4CRYkNh+IYm FMnQlAeQSRrgjAE5F5K3X+/NIDMV6iIKqQiUIT6vjBs51Q2CASShyUVL4poNiZ6+MMJSzPxl9 a3zubeyUZkgPaX/nxZFWg/imdYnAMte+2s8cKtqzSuQKttDl9o4QLk9F9dsZaCmTioV42eGzO zQK/axoN+NqRZ6g99GXAVk7qo+IOU5TXtLhvXJViUsgptsL6W6sS9j1985rWLUAz6kLe8v4Qc fyLoff1DAn6nKgVL+jyWp/eJZ0g3CH9kj7Z1H/2MJP7eJ9/Fc9P3aMJBlKuceKMf328JtjXep OMqa2RvKu+iKhgK1aX6r6H3UjM6XCmqFP34iIws/Fj+wK/BuKEaJpihSTbq9ST9B2g3cdAVDp +AIgjWNJ5B6kDlU15fHhMtkncjB95nHX0g3PM/GLyhm1H6oyqjuKbe51hRG0KfBH4cO2/mvQa 0TcRDLG9nVDioHyjiwCX1tv5M35/YksvnMwbhxA0SwPXOiLDG+4IA0nYPmSM7Qs2ONyaHjq9V +tFPEq68DeMlFQM0FTRo5HSvpfSrjNAVLBRam+NCPyCMdKg== Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 20:44:51 -0000 Hello Sergio, On May 22, 2015, at 6:24 PM, FIGUEIREDO Sergio wrote: > Hi Alper, >=20 > As Seil wrote, the problem which this ticket intends to reflect is = that of non-optimal routing as a result of not being able to request a = non-anchored (or local) source IP address.=20 A non-anchored (local) address is called Nomadic IP Address. If the app needs one such address, then it can ask one and get one.=20 API already supports that. > This might be a problem in any scenario where new Sustained IP = addresses are not assigned by default at the new network. The intention = of the flag is not to request a new prefix, but to assure a source = address associated to a local network is used. Which, in cases where it = is not available, leads to the configuration of a new one. >=20 Alper > Best regards, > Sergio >=20 >=20 > 2, rue Paul Vaillant-Couturier > 92300 Levallois-Perret=20 > FRANCE > Tel. : +33 (0)1 46 17 46 17 > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin > Sent: sexta-feira, 22 de Maio de 2015 12:08 > To: Seil Jeon > Cc: dmm@ietf.org > Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand = mobility support >=20 > Hi Seil, >=20 > Thanks for creating the ticket. >=20 > Please see below. >=20 >=20 >>=20 >> #49: full on-demand mobility support >>=20 >> The three proposed flags express a "type" of source IP address an = application wants to get to the IP stack. Particularly, the sustained IP = address is proposed to provide on-demand IP session continuity, which = activates IP mobility once the terminal moves across other access = network. >> While the terminal stays at the same network where the session is = initiated, regular IP routing is applied. >>=20 >> The on-demand draft does not assure provide the full on-demand = mobility for all scenarios by merely indicating the Socket API, = IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned = issue is as follows; >>=20 >> 0. The MN is configured with one or more Nomadic IP addresses. >>=20 >> 1. Once an app. requests "sustained IP address" to the IP stack, and = it will obtain a sustained IP address through a protocol procedure = between the terminal and network. >>=20 >> 2. Other app. initiated over the same access network will use the = same sustained IP address while the terminal remains connected at the = same access network. >>=20 >> 3. The terminal moves to another access network and a new app. = requests a sustained IP address with the Socket API to the IP stack. = Since a sustained IP address is already available in the IP stack, the = sustained IP address is assigned to the new app. >>=20 >=20 > Yes, that's what happens. > You are not pointing to an issue up until this point, right? Because, = you continuing your email with a "Besides" gives the impression that you = are pointing to an issue, but I don't see any issue captured in the = above text. >=20 >=20 >> Besides, in case sustained IP address allocation is used default, = there may be multiple sustained IP addresses including newly obtained = sustained IP address over the new access network in the IP stack. = However, when an app. is initiated, the IP stack may not select the new = one in the context of the default source IP address selection mechanism = [RFC6724][RFC5014]. >>=20 >=20 > OK, is the issue following: When there are multiple sustained IP = addresses, how does the IP stack pick one among them? >=20 >> For providing the full on-demand mobility, a new flag is needed, = letting the IP stack request a new sustained IP address or choose a = sustained IP address not requiring IP mobility anchoring when an = application is initiated, among the existing ones in the IP stack. >>=20 >=20 > Your flag is not a solution to what I captured above. It does = something else: Instruct the IP stack to go get a new sustained IP = address whether there is already one or more configured on the stack or = not. >=20 >=20 > Alper >=20 >=20 >=20 >> --=20 >> = -------------------------+---------------------------------------------- >> -------------------------+--- >> Reporter: | Owner: draft-ietf-dmm-ondemand- >> seiljeon@av.it.pt | mobility@tools.ietf.org >> Type: defect | Status: new >> Priority: critical | Milestone: >> Component: ondemand- | Version: >> mobility | Keywords: on-demand mobility >> Severity: Submitted | >> WG Document | >> = -------------------------+---------------------------------------------- >> -------------------------+--- >>=20 >> Ticket URL: >> dmm >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Fri May 29 14:35:08 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF931A1A0B for ; Fri, 29 May 2015 14:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8O5gRzPFOWQ for ; Fri, 29 May 2015 14:35:03 -0700 (PDT) Received: from smtp5.altran.com (smtp4.altran.com [194.98.79.92]) by ietfa.amsl.com (Postfix) with ESMTP id 467241B2DA1 for ; Fri, 29 May 2015 14:35:01 -0700 (PDT) Received: from XCH-20V-DCFR-01.europe.corp.altran.com (unknown [10.0.6.15]) by Websense Email Security Gateway with ESMTPS id 0C5FD3DA239B9; Fri, 29 May 2015 23:34:56 +0200 (CEST) Received: from XMB-DCFR-37.europe.corp.altran.com ([fe80::80ba:99a3:be27:fa11]) by XCH-20V-DCFR-01.europe.corp.altran.com ([fe80::1c20:d485:89b1:a288%13]) with mapi id 14.03.0235.001; Fri, 29 May 2015 23:35:00 +0200 From: FIGUEIREDO Sergio To: Alper Yegin Thread-Topic: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support Thread-Index: AQHQlHdRZ+FmkYNUqEeEbX0uB+zceJ2IGOCAgAs9JgCAACf7AA== Date: Fri, 29 May 2015 21:34:59 +0000 Message-ID: References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt> <9917C9E6-73D4-408E-8BA2-A5D0FDA92B71@yegin.org> In-Reply-To: <9917C9E6-73D4-408E-8BA2-A5D0FDA92B71@yegin.org> Accept-Language: pt-BR, fr-FR, en-US Content-Language: pt-BR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-imapappendstamp: XCH-20V-DCFR-01.europe.corp.altran.com (14.03.0227.000) x-originating-ip: [172.16.254.21] Content-Type: multipart/alternative; boundary="_000_F73A2DEE6F32DA4C80138FB0DF24F642ED9BD9XMBDCFR37europeco_" MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 21:35:07 -0000 --_000_F73A2DEE6F32DA4C80138FB0DF24F642ED9BD9XMBDCFR37europeco_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alper, Thanks for the answer. Please check inline. On 29-05-2015 22:44, Alper Yegin wrote: Hello Sergio, On May 22, 2015, at 6:24 PM, FIGUEIREDO Sergio wrote: Hi Alper, As Seil wrote, the problem which this ticket intends to reflect is that of = non-optimal routing as a result of not being able to request a non-anchored= (or local) source IP address. A non-anchored (local) address is called Nomadic IP Address. If the app needs one such address, then it can ask one and get one. API already supports that. This might be a problem in any scenario where new Sustained IP addresses ar= e not assigned by default at the new network. The intention of the flag is = not to request a new prefix, but to assure a source address associated to a= local network is used. Which, in cases where it is not available, leads to= the configuration of a new one. Alper Best regards, Sergio 2, rue Paul Vaillant-Couturier 92300 Levallois-Perret FRANCE Tel. : +33 (0)1 46 17 46 17 -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin Sent: sexta-feira, 22 de Maio de 2015 12:08 To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility s= upport Hi Seil, Thanks for creating the ticket. Please see below. #49: full on-demand mobility support The three proposed flags express a "type" of source IP address an applicat= ion wants to get to the IP stack. Particularly, the sustained IP address i= s proposed to provide on-demand IP session continuity, which activates IP = mobility once the terminal moves across other access network. While the terminal stays at the same network where the session is initiate= d, regular IP routing is applied. The on-demand draft does not assure provide the full on-demand mobility fo= r all scenarios by merely indicating the Socket API, IPV6_REQ_SUSTAINED_IP= . An example scenario raising the aforementioned issue is as follows; 0. The MN is configured with one or more Nomadic IP addresses. 1. Once an app. requests "sustained IP address" to the IP stack, and it wi= ll obtain a sustained IP address through a protocol procedure between the = terminal and network. 2. Other app. initiated over the same access network will use the same sus= tained IP address while the terminal remains connected at the same access = network. 3. The terminal moves to another access network and a new app. requests a = sustained IP address with the Socket API to the IP stack. Since a sustaine= d IP address is already available in the IP stack, the sustained IP addres= s is assigned to the new app. Yes, that's what happens. You are not pointing to an issue up until this point, right? Because, you c= ontinuing your email with a "Besides" gives the impression that you are poi= nting to an issue, but I don't see any issue captured in the above text. Besides, in case sustained IP address allocation is used default, there ma= y be multiple sustained IP addresses including newly obtained sustained IP= address over the new access network in the IP stack. However, when an app= . is initiated, the IP stack may not select the new one in the context of = the default source IP address selection mechanism [RFC6724][RFC5014]. OK, is the issue following: When there are multiple sustained IP addresses,= how does the IP stack pick one among them? For providing the full on-demand mobility, a new flag is needed, letting t= he IP stack request a new sustained IP address or choose a sustained IP ad= dress not requiring IP mobility anchoring when an application is initiated= , among the existing ones in the IP stack. Your flag is not a solution to what I captured above. It does something els= e: Instruct the IP stack to go get a new sustained IP address whether there= is already one or more configured on the stack or not. Alper -- -------------------------+---------------------------------------------- -------------------------+--- Reporter: | Owner: draft-ietf-dmm-ondemand- seiljeon@av.it.pt | mobility@tools.ietf.org= Type: defect | Status: new Priority: critical | Milestone: Component: ondemand- | Version: mobility | Keywords: on-demand mobility Severity: Submitted | WG Document | -------------------------+---------------------------------------------- -------------------------+--- Ticket URL: dmm _______________________________________________ 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 --_000_F73A2DEE6F32DA4C80138FB0DF24F642ED9BD9XMBDCFR37europeco_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <01C76B2B0B0F134898981F99D577DAC0@altran.com> Content-Transfer-Encoding: quoted-printable
Hi Alper,

Thanks for the answer. Please check inline.

On 29-05-2015 22:44, Alper Yegin wrote:
Hello Sergio,=0A=
=0A=
On May 22, 2015, at 6:24 PM, FIGUEIREDO Sergio wrote:=0A=
=0A=

Hi Alper,=0A=
=0A=
As Seil wrote, the problem which this ticket intends to reflect is that of =
non-optimal routing as a result of not being able to request a non-anchored=
 (or local) source IP address. =0A=

A non-anchored (local) address is called Nomadic IP Address.=0A=
If the app needs one such address, then it can ask one and get one. =0A=
API already supports that.


=0A=
=0A=

This might be a problem in any scenario where new Sustained IP address=
es are not assigned by default at the new network. The intention of the fla=
g is not to request a new prefix, but to assure a source address associated=
 to a local network is used. Which, in cases where it is not available, lea=
ds to the configuration of a new one.=0A=
=0A=

Alper=0A=
=0A=
=0A=

Best regards,=0A=
Sergio=0A=
=0A=
=0A=
2, rue Paul Vaillant-Couturier=0A=
92300 Levallois-Perret =0A=
FRANCE=0A=
Tel. : +33 (0)1 46 17 46 17=0A=
-----Original Message-----=0A=
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alp=
er Yegin=0A=
Sent: sexta-feira, 22 de Maio de 2015 12:08=0A=
To: Seil Jeon=0A=
Cc: dmm@ietf.org=0A=
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility s=
upport=0A=
=0A=
Hi Seil,=0A=
=0A=
Thanks for creating the ticket.=0A=
=0A=
Please see below.=0A=
=0A=
=0A=

#49: full on-demand mobility support=0A=
=0A=
The three proposed flags express a "type" of source IP address an=
  application wants to get to the IP stack. Particularly, the sustained IP =
 address is proposed to provide on-demand IP session continuity, which  act=
ivates IP mobility once the terminal moves across other access network.=0A=
While the terminal stays at the same network where the session is  initiate=
d, regular IP routing is applied.=0A=
=0A=
The on-demand draft does not assure provide the full on-demand mobility  fo=
r all scenarios by merely indicating the Socket API,  IPV6_REQ_SUSTAINED_IP=
. An example scenario raising the aforementioned  issue is as follows;=0A=
=0A=
0. The MN is configured with one or more Nomadic IP addresses.=0A=
=0A=
1. Once an app. requests "sustained IP address" to the IP stack, =
and it  will obtain a sustained IP address through a protocol procedure bet=
ween  the terminal and network.=0A=
=0A=
2. Other app. initiated over the same access network will use the same  sus=
tained IP address while the terminal remains connected at the same  access =
network.=0A=
=0A=
3. The terminal moves to another access network and a new app. requests a  =
sustained IP address with the Socket API to the IP stack. Since a  sustaine=
d IP address is already available in the IP stack, the sustained  IP addres=
s is assigned to the new app.=0A=
=0A=

Yes, that's what happens.=0A=
You are not pointing to an issue up until this point, right? Because, you c=
ontinuing your email with a "Besides" gives the impression that y=
ou are pointing to an issue, but I don't see any issue captured in the abov=
e text.=0A=
=0A=
=0A=

Besides, in case sustained IP address allocation is used default, ther=
e  may be multiple sustained IP addresses including newly obtained sustaine=
d  IP address over the new access network in the IP stack. However, when an=
  app. is initiated, the IP stack may not select the new one in the context=
  of the default source IP address selection mechanism [RFC6724][RFC5014].=
=0A=
=0A=

OK, is the issue following: When there are multiple sustained IP addre=
sses, how does the IP stack pick one among them?=0A=
=0A=

For providing the full on-demand mobility, a new flag is needed, letti=
ng  the IP stack request a new sustained IP address or choose a sustained I=
P  address not requiring IP mobility anchoring when an application is  init=
iated, among the existing ones in the IP stack.=0A=
=0A=

Your flag is not a solution to what I captured above. It does somethin=
g else: Instruct the IP stack to go get a new sustained IP address whether =
there is already one or more configured on the stack or not.=0A=
=0A=
=0A=
Alper=0A=
=0A=
=0A=
=0A=

-- =0A=
-------------------------+---------------------------------------------=
-=0A=
-------------------------+---=0A=
Reporter:               |      Owner:  draft-ietf-dmm-ondemand-=0A=
seiljeon@av.it.pt      |  mobility@=
tools.ietf.org=0A=
   Type:  defect       |     Status:  new=0A=
Priority:  critical     |  Milestone:=0A=
Component:  ondemand-    |    Version:=0A=
mobility               |   Keywords:  on-demand mobility=0A=
Severity:  Submitted    |=0A=
WG Document            |=0A=
-------------------------+---------------------------------------------=
-=0A=
-------------------------+---=0A=
=0A=
Ticket URL: <http://trac.tools.ietf.=
org/wg/dmm/trac/ticket/49>=0A=
dmm <http://tools.ietf.org/dmm/>=0A=
=0A=
=0A=
_______________________________________________=0A=
dmm mailing list=0A=
dmm@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/dmm=
=0A=

_______________________________________________=0A=
dmm mailing list=0A=
dmm@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/dmm=
=0A=











--_000_F73A2DEE6F32DA4C80138FB0DF24F642ED9BD9XMBDCFR37europeco_--


From nobody Fri May 29 14:41:43 2015
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD771A8A9E for ; Fri, 29 May 2015 14:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rz1ZyYfnHbdq for ; Fri, 29 May 2015 14:41:38 -0700 (PDT)
Received: from smtp5.altran.com (smtp4.altran.com [194.98.79.92]) by ietfa.amsl.com (Postfix) with ESMTP id 69C211A88A9 for ; Fri, 29 May 2015 14:41:38 -0700 (PDT)
Received: from XCH-DCFR-33.europe.corp.altran.com (unknown [10.0.6.13]) by Websense Email Security Gateway with ESMTPS id 774BE14E43C2B; Fri, 29 May 2015 23:41:33 +0200 (CEST)
Received: from XMB-DCFR-37.europe.corp.altran.com ([fe80::80ba:99a3:be27:fa11]) by XCH-DCFR-33.europe.corp.altran.com ([10.0.6.13]) with mapi id 14.03.0235.001; Fri, 29 May 2015 23:41:37 +0200
From: FIGUEIREDO Sergio 
To: Alper Yegin 
Thread-Topic: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support
Thread-Index: AQHQlHdRZ+FmkYNUqEeEbX0uB+zceJ2IGOCAgAs9JgCAACf7AIAACObO
Date: Fri, 29 May 2015 21:41:36 +0000
Message-ID: 
References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt>   <9917C9E6-73D4-408E-8BA2-A5D0FDA92B71@yegin.org>, 
In-Reply-To: 
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.254.21]
Content-Type: multipart/alternative; boundary="_000_F73A2DEE6F32DA4C80138FB0DF24F642EDBC13XMBDCFR37europeco_"
MIME-Version: 1.0
Archived-At: 
Cc: "dmm@ietf.org" 
Subject: [DMM] RES: [dmm] #49 (ondemand-mobility): full on-demand mobility support
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 21:41:41 -0000

--_000_F73A2DEE6F32DA4C80138FB0DF24F642EDBC13XMBDCFR37europeco_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'm sorry but I had problems sending the previous message. Hope I succeed t=
his time, my response is inline.



________________________________
De: dmm [dmm-bounces@ietf.org] em nome de FIGUEIREDO Sergio [sergio.figueir=
edo@altran.com]
Enviado: sexta-feira, 29 de maio de 2015 23:34
Para: Alper Yegin
Cc: dmm@ietf.org
Assunto: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility s=
upport

Hi Alper,

Thanks for the answer. Please check inline.

On 29-05-2015 22:44, Alper Yegin wrote:

Hello Sergio,

On May 22, 2015, at 6:24 PM, FIGUEIREDO Sergio wrote:



Hi Alper,

As Seil wrote, the problem which this ticket intends to reflect is that of =
non-optimal routing as a result of not being able to request a non-anchored=
 (or local) source IP address.


A non-anchored (local) address is called Nomadic IP Address.
If the app needs one such address, then it can ask one and get one.
API already supports that.

SF: You are right. But I didn't mean a Nomadic IP address, but a Sustained =
IP address assigned by the current network. So, a description closer to wha=
t I meant would be:

"...this ticket intends to reflect is that of non-optimal routing as a resu=
lt of not being able to request a Sustained IP address assigned by the loca=
l network".

Best regards,
S=E9rgio


This might be a problem in any scenario where new Sustained IP addresses ar=
e not assigned by default at the new network. The intention of the flag is =
not to request a new prefix, but to assure a source address associated to a=
 local network is used. Which, in cases where it is not available, leads to=
 the configuration of a new one.



Alper




Best regards,
Sergio


2, rue Paul Vaillant-Couturier
92300 Levallois-Perret
FRANCE
Tel. : +33 (0)1 46 17 46 17
-----Original Message-----
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: sexta-feira, 22 de Maio de 2015 12:08
To: Seil Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility s=
upport

Hi Seil,

Thanks for creating the ticket.

Please see below.




#49: full on-demand mobility support

The three proposed flags express a "type" of source IP address an  applicat=
ion wants to get to the IP stack. Particularly, the sustained IP  address i=
s proposed to provide on-demand IP session continuity, which  activates IP =
mobility once the terminal moves across other access network.
While the terminal stays at the same network where the session is  initiate=
d, regular IP routing is applied.

The on-demand draft does not assure provide the full on-demand mobility  fo=
r all scenarios by merely indicating the Socket API,  IPV6_REQ_SUSTAINED_IP=
. An example scenario raising the aforementioned  issue is as follows;

0. The MN is configured with one or more Nomadic IP addresses.

1. Once an app. requests "sustained IP address" to the IP stack, and it  wi=
ll obtain a sustained IP address through a protocol procedure between  the =
terminal and network.

2. Other app. initiated over the same access network will use the same  sus=
tained IP address while the terminal remains connected at the same  access =
network.

3. The terminal moves to another access network and a new app. requests a  =
sustained IP address with the Socket API to the IP stack. Since a  sustaine=
d IP address is already available in the IP stack, the sustained  IP addres=
s is assigned to the new app.



Yes, that's what happens.
You are not pointing to an issue up until this point, right? Because, you c=
ontinuing your email with a "Besides" gives the impression that you are poi=
nting to an issue, but I don't see any issue captured in the above text.




Besides, in case sustained IP address allocation is used default, there  ma=
y be multiple sustained IP addresses including newly obtained sustained  IP=
 address over the new access network in the IP stack. However, when an  app=
. is initiated, the IP stack may not select the new one in the context  of =
the default source IP address selection mechanism [RFC6724][RFC5014].



OK, is the issue following: When there are multiple sustained IP addresses,=
 how does the IP stack pick one among them?



For providing the full on-demand mobility, a new flag is needed, letting  t=
he IP stack request a new sustained IP address or choose a sustained IP  ad=
dress not requiring IP mobility anchoring when an application is  initiated=
, among the existing ones in the IP stack.



Your flag is not a solution to what I captured above. It does something els=
e: Instruct the IP stack to go get a new sustained IP address whether there=
 is already one or more configured on the stack or not.


Alper





--
-------------------------+----------------------------------------------
-------------------------+---
Reporter:               |      Owner:  draft-ietf-dmm-ondemand-
seiljeon@av.it.pt      |  mobility@tools.ietf.org=

   Type:  defect       |     Status:  new
Priority:  critical     |  Milestone:
Component:  ondemand-    |    Version:
mobility               |   Keywords:  on-demand mobility
Severity:  Submitted    |
WG Document            |
-------------------------+----------------------------------------------
-------------------------+---

Ticket URL: 
dmm 


_______________________________________________
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



--_000_F73A2DEE6F32DA4C80138FB0DF24F642EDBC13XMBDCFR37europeco_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










I'm sorry but I had problems sending =
the previous message. Hope I succeed this time, my response is inline.















De: dmm [dmm-bounces@ietf.org] em nome de=
 FIGUEIREDO Sergio [sergio.figueiredo@altran.com]

Enviado: sexta-feira, 29 de maio de 2015 23:34

Para: Alper Yegin

Cc: dmm@ietf.org

Assunto: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mob=
ility support










Hi Alper,



Thanks for the answer. Please check inline.




On 29-05-2015 22:44, Alper Yegin wrote:






Hello Sergio,=0A=
=0A=
On May 22, 2015, at 6:24 PM, FIGUEIREDO Sergio wrote:=0A=
=0A=





Hi Alper,=0A=
=0A=
As Seil wrote, the problem which this ticket intends to reflect is that of =
non-optimal routing as a result of not being able to request a non-anchored=
 (or local) source IP address. =0A=





A non-anchored (local) address is called Nomadic IP Address.=0A=
If the app needs one such address, then it can ask one and get one. =0A=
API already supports that.



SF: You are right. But I didn't mean a Nomadic IP address, but a Sustained =
IP address assigned by the current network. So, a description closer to wha=
t I meant would be:


"...this ticket intends to reflect is that of non-optimal routing=
 as a result of not being able to request a Sustained IP address assigned b=
y the local network".



Best regards,

S=E9rgio














This might be a problem in any scenario where new Sustained IP address=
es are not assigned by default at the new network. The intention of the fla=
g is not to request a new prefix, but to assure a source address associated=
 to a local network is used. Which, in cases where it is not available, lea=
ds to the configuration of a new one.=0A=
=0A=





Alper=0A=
=0A=
=0A=





Best regards,=0A=
Sergio=0A=
=0A=
=0A=
2, rue Paul Vaillant-Couturier=0A=
92300 Levallois-Perret =0A=
FRANCE=0A=
Tel. : +33 (0)1 46 17 46 17=0A=
-----Original Message-----=0A=
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alp=
er Yegin=0A=
Sent: sexta-feira, 22 de Maio de 2015 12:08=0A=
To: Seil Jeon=0A=
Cc: dmm@ietf.org=0A=
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility s=
upport=0A=
=0A=
Hi Seil,=0A=
=0A=
Thanks for creating the ticket.=0A=
=0A=
Please see below.=0A=
=0A=
=0A=





#49: full on-demand mobility support=0A=
=0A=
The three proposed flags express a "type" of source IP address an=
  application wants to get to the IP stack. Particularly, the sustained IP =
 address is proposed to provide on-demand IP session continuity, which  act=
ivates IP mobility once the terminal moves across other access network.=0A=
While the terminal stays at the same network where the session is  initiate=
d, regular IP routing is applied.=0A=
=0A=
The on-demand draft does not assure provide the full on-demand mobility  fo=
r all scenarios by merely indicating the Socket API,  IPV6_REQ_SUSTAINED_IP=
. An example scenario raising the aforementioned  issue is as follows;=0A=
=0A=
0. The MN is configured with one or more Nomadic IP addresses.=0A=
=0A=
1. Once an app. requests "sustained IP address" to the IP stack, =
and it  will obtain a sustained IP address through a protocol procedure bet=
ween  the terminal and network.=0A=
=0A=
2. Other app. initiated over the same access network will use the same  sus=
tained IP address while the terminal remains connected at the same  access =
network.=0A=
=0A=
3. The terminal moves to another access network and a new app. requests a  =
sustained IP address with the Socket API to the IP stack. Since a  sustaine=
d IP address is already available in the IP stack, the sustained  IP addres=
s is assigned to the new app.=0A=
=0A=





Yes, that's what happens.=0A=
You are not pointing to an issue up until this point, right? Because, you c=
ontinuing your email with a "Besides" gives the impression that y=
ou are pointing to an issue, but I don't see any issue captured in the abov=
e text.=0A=
=0A=
=0A=





Besides, in case sustained IP address allocation is used default, ther=
e  may be multiple sustained IP addresses including newly obtained sustaine=
d  IP address over the new access network in the IP stack. However, when an=
  app. is initiated, the IP stack may not select the new one in the context=
  of the default source IP address selection mechanism [RFC6724][RFC5014].=
=0A=
=0A=





OK, is the issue following: When there are multiple sustained IP addre=
sses, how does the IP stack pick one among them?=0A=
=0A=





For providing the full on-demand mobility, a new flag is needed, letti=
ng  the IP stack request a new sustained IP address or choose a sustained I=
P  address not requiring IP mobility anchoring when an application is  init=
iated, among the existing ones in the IP stack.=0A=
=0A=





Your flag is not a solution to what I captured above. It does somethin=
g else: Instruct the IP stack to go get a new sustained IP address whether =
there is already one or more configured on the stack or not.=0A=
=0A=
=0A=
Alper=0A=
=0A=
=0A=
=0A=





-- =0A=
-------------------------+---------------------------------------------=
-=0A=
-------------------------+---=0A=
Reporter:               |      Owner:  draft-ietf-dmm-ondemand-=0A=
seiljeon@av.it.pt      |  mobility@=
tools.ietf.org=0A=
   Type:  defect       |     Status:  new=0A=
Priority:  critical     |  Milestone:=0A=
Component:  ondemand-    |    Version:=0A=
mobility               |   Keywords:  on-demand mobility=0A=
Severity:  Submitted    |=0A=
WG Document            |=0A=
-------------------------+---------------------------------------------=
-=0A=
-------------------------+---=0A=
=0A=
Ticket URL: <http://trac.tools.ietf.=
org/wg/dmm/trac/ticket/49>=0A=
dmm <http://tools.ietf.org/dmm/>=0A=
=0A=
=0A=
_______________________________________________=0A=
dmm mailing list=0A=
dmm@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/dmm=
=0A=





_______________________________________________=0A=
dmm mailing list=0A=
dmm@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/dmm=
=0A=

























--_000_F73A2DEE6F32DA4C80138FB0DF24F642EDBC13XMBDCFR37europeco_--


From nobody Sat May 30 03:18:22 2015
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9E61A1B7F for ; Sat, 30 May 2015 03:18:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_60v9-v6bz9 for ; Sat, 30 May 2015 03:18:18 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A78A31A1B67 for ; Sat, 30 May 2015 03:18:18 -0700 (PDT)
Received: from [192.168.2.5] ([85.97.51.111]) by mrelay.perfora.net (mreueus002) with ESMTPA (Nemesis) id 0LrLdC-1Z6II72vbY-0135ih; Sat, 30 May 2015 12:18:17 +0200
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C8F0B1F6-60FD-4522-BAC0-365A6132A69E"
From: Alper Yegin 
In-Reply-To: 
Date: Sat, 30 May 2015 13:18:00 +0300
Message-Id: 
References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt>   <9917C9E6-73D4-408E-8BA2-A5D0FDA92B71@yegin.org>,  
To: FIGUEIREDO Sergio 
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V03:K0:iYW06wiYLRZIBycxuzU4PL2PGw+prTO78r+KPovH+UWBkorpoyG 69ZAENphuqvEj0bl0gHeJNf8t/dMFXHJ1kI1CoenXi0NSamt+U/104KK8sShKSjrY4IkYwj D4MRgbhqJeMKkPs8HSJ9IU1JO9TgK42MSegH6mR0G0JJ1PnCMPjtEYYaTvryfyRUhgTmN+1 AALN4r3kqrNFqIMa72E3A==
X-UI-Out-Filterresults: notjunk:1;V01:K0:NKxZCZp2tKk=:0Nt+Gxw8OVFf+o5cjiPc2I qv21melG6jaRvt93+WojcjMsJSfoqE9SRr2UBJOMxxalFBglxgnKv4lYx8rXhQWvd6l1Gboie Y2WGrMJADNs8R024unUIZXC4E4Hpx1pZmTOHywxUqDzsJpW/Q1pLVkaLwc8imfaYYPB0gTB2L n4e7/lMylG03nBEZXhHz0qBcrO55Av8UWBfYvSyJ3j4yfXj3uBaALlamzRUDz/i7o2d412Qx9 JQm8ykS7Zhf3uMJp7pEQdp8o6XvbzyB91qHpfMZ1y9mbt0sDCkhqU4sRrpgWT6MhnqPdwTMtN R5L3Yj9CI01vATl3OBMQIkeRsOR53yc/HQRrCAlbwoJDqQOvhgm/XU95O8wIxyjEuMOHdSxYb 2ppnCjyTb4vNuDBHshxYi1ib1baYvI6zzRB3v4lbf05Ad00goMQMp3xb9uH0kTBr6HbZDyec4 r7i74OGweHk68U0ZEEIEhHk4kPjuCPfMNMT62iCj/gwLWEdsKQQdMHquNE2tV47f8OseTpbkj gg2ZFakX9WVWlN3t1tQUrpihkYwKItxQgGRFxyJlPoboGJdGiGiJAFeWG3Pdnt98eCP1s6Z0w Lnykj+qmxHJdVbNyp6j10FfK9/IjYXkaaY/lCrflluQUQVr1KA6rLtX754/DQjzpjMig1jrvZ 4rrAz+R2YRG/w2yQMqp4+TTiIXr85max6/BCoDT3oyBxsDw==
Archived-At: 
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] RES: [dmm] #49 (ondemand-mobility): full on-demand mobility support
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 May 2015 10:18:21 -0000

--Apple-Mail=_C8F0B1F6-60FD-4522-BAC0-365A6132A69E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Sergio,

>>> As Seil wrote, the problem which this ticket intends to reflect is =
that of non-optimal routing as a result of not being able to request a =
non-anchored (or local) source IP address.=20
>> A non-anchored (local) address is called Nomadic IP Address.
>> If the app needs one such address, then it can ask one and get one.=20=

>> API already supports that.
> SF: You are right. But I didn't mean a Nomadic IP address, but a =
Sustained IP address assigned by the current network. So, a description =
closer to what I meant would be:
> "...this ticket intends to reflect is that of non-optimal routing as a =
result of not being able to request a Sustained IP address assigned by =
the local network".
>=20


OK, this I understand!=20
But I understood this not from the ticket text but from the solution.
Hence I've been extremely suffering trying to connect the solution back =
to the ticket definition :-(

OK, if Seil also agrees with this, I hope you guys go back and clean up =
the ticket, so everyone can understand this the same way.
Meanwhile, we can seek input from the WG members on the "issue" first =
(and then the solution).

Alper






> Best regards,
> S=E9rgio
>=20
>>> This might be a problem in any scenario where new Sustained IP =
addresses are not assigned by default at the new network. The intention =
of the flag is not to request a new prefix, but to assure a source =
address associated to a local network is used. Which, in cases where it =
is not available, leads to the configuration of a new one.
>>>=20
>> Alper
>>=20
>>=20
>>> Best regards,
>>> Sergio
>>>=20
>>>=20
>>> 2, rue Paul Vaillant-Couturier
>>> 92300 Levallois-Perret=20
>>> FRANCE
>>> Tel. : +33 (0)1 46 17 46 17
>>> -----Original Message-----
>>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
>>> Sent: sexta-feira, 22 de Maio de 2015 12:08
>>> To: Seil Jeon
>>> Cc: dmm@ietf.org
>>> Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand =
mobility support
>>>=20
>>> Hi Seil,
>>>=20
>>> Thanks for creating the ticket.
>>>=20
>>> Please see below.
>>>=20
>>>=20
>>>> #49: full on-demand mobility support
>>>>=20
>>>> The three proposed flags express a "type" of source IP address an  =
application wants to get to the IP stack. Particularly, the sustained IP =
 address is proposed to provide on-demand IP session continuity, which  =
activates IP mobility once the terminal moves across other access =
network.
>>>> While the terminal stays at the same network where the session is  =
initiated, regular IP routing is applied.
>>>>=20
>>>> The on-demand draft does not assure provide the full on-demand =
mobility  for all scenarios by merely indicating the Socket API,  =
IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned  =
issue is as follows;
>>>>=20
>>>> 0. The MN is configured with one or more Nomadic IP addresses.
>>>>=20
>>>> 1. Once an app. requests "sustained IP address" to the IP stack, =
and it  will obtain a sustained IP address through a protocol procedure =
between  the terminal and network.
>>>>=20
>>>> 2. Other app. initiated over the same access network will use the =
same  sustained IP address while the terminal remains connected at the =
same  access network.
>>>>=20
>>>> 3. The terminal moves to another access network and a new app. =
requests a  sustained IP address with the Socket API to the IP stack. =
Since a  sustained IP address is already available in the IP stack, the =
sustained  IP address is assigned to the new app.
>>>>=20
>>> Yes, that's what happens.
>>> You are not pointing to an issue up until this point, right? =
Because, you continuing your email with a "Besides" gives the impression =
that you are pointing to an issue, but I don't see any issue captured in =
the above text.
>>>=20
>>>=20
>>>> Besides, in case sustained IP address allocation is used default, =
there  may be multiple sustained IP addresses including newly obtained =
sustained  IP address over the new access network in the IP stack. =
However, when an  app. is initiated, the IP stack may not select the new =
one in the context  of the default source IP address selection mechanism =
[RFC6724][RFC5014].
>>>>=20
>>> OK, is the issue following: When there are multiple sustained IP =
addresses, how does the IP stack pick one among them?
>>>=20
>>>> For providing the full on-demand mobility, a new flag is needed, =
letting  the IP stack request a new sustained IP address or choose a =
sustained IP  address not requiring IP mobility anchoring when an =
application is  initiated, among the existing ones in the IP stack.
>>>>=20
>>> Your flag is not a solution to what I captured above. It does =
something else: Instruct the IP stack to go get a new sustained IP =
address whether there is already one or more configured on the stack or =
not.
>>>=20
>>>=20
>>> Alper
>>>=20
>>>=20
>>>=20
>>>> --=20
>>>> =
-------------------------+----------------------------------------------
>>>> -------------------------+---
>>>> Reporter:               |      Owner:  draft-ietf-dmm-ondemand-
>>>> seiljeon@av.it.pt      |  mobility@tools.ietf.org
>>>>    Type:  defect       |     Status:  new
>>>> Priority:  critical     |  Milestone:
>>>> Component:  ondemand-    |    Version:
>>>> mobility               |   Keywords:  on-demand mobility
>>>> Severity:  Submitted    |
>>>> WG Document            |
>>>> =
-------------------------+----------------------------------------------
>>>> -------------------------+---
>>>>=20
>>>> Ticket URL: 
>>>> dmm 
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> 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
>=20
>=20


--Apple-Mail=_C8F0B1F6-60FD-4522-BAC0-365A6132A69E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

Sergio,

As Seil wrote, the problem =
which this ticket intends to reflect is that of non-optimal routing as a =
result of not being able to request a non-anchored (or local) source IP =
address.=20

A non-anchored (local) address is called Nomadic =
IP Address.
If the app needs one such address, then it can ask one and get one.=20
API already supports that.
SF: You are right. But I =
didn't mean a Nomadic IP address, but a Sustained IP address assigned by =
the current network. So, a description closer to what I meant would =
be:
"...this ticket intends to reflect is that of non-optimal =
routing as a result of not being able to request a Sustained IP address =
assigned by the local =
network".



OK, this I =
understand! 
But I understood this not from the ticket =
text but from the solution.
Hence I've been extremely =
suffering trying to connect the solution back to the ticket definition =
:-(

OK, if Seil also agrees with this, I hope =
you guys go back and clean up the ticket, so everyone can understand =
this the same way.
Meanwhile, we can seek input from the WG =
members on the "issue" first (and then the =
solution).

Alper






Best =
regards,
This might be a problem in any scenario where new =
Sustained IP addresses are not assigned by default at the new network. =
The intention of the flag is not to request a new prefix, but to assure =
a source address associated to a local network is used. Which, in cases =
where it is not available, leads to the configuration of a new one.


Alper



Best regards,
Sergio


2, rue Paul Vaillant-Couturier
92300 Levallois-Perret=20
FRANCE
Tel. : +33 (0)1 46 17 46 17
-----Original Message-----
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper =
Yegin
Sent: sexta-feira, 22 de Maio de 2015 12:08
To: Seil Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand =
mobility support

Hi Seil,

Thanks for creating the ticket.

Please see below.



#49: full on-demand mobility =
support

The three proposed flags express a "type" of source IP address an  =
application wants to get to the IP stack. Particularly, the sustained IP =
 address is proposed to provide on-demand IP session continuity, which  =
activates IP mobility once the terminal moves across other access =
network.
While the terminal stays at the same network where the session is  =
initiated, regular IP routing is applied.

The on-demand draft does not assure provide the full on-demand mobility  =
for all scenarios by merely indicating the Socket API,  =
IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned  =
issue is as follows;

0. The MN is configured with one or more Nomadic IP addresses.

1. Once an app. requests "sustained IP address" to the IP stack, and it  =
will obtain a sustained IP address through a protocol procedure between  =
the terminal and network.

2. Other app. initiated over the same access network will use the same  =
sustained IP address while the terminal remains connected at the same  =
access network.

3. The terminal moves to another access network and a new app. requests =
a  sustained IP address with the Socket API to the IP stack. Since a  =
sustained IP address is already available in the IP stack, the sustained =
 IP address is assigned to the new app.


Yes, that's what happens.
You are not pointing to an issue up until this point, right? Because, =
you continuing your email with a "Besides" gives the impression that you =
are pointing to an issue, but I don't see any issue captured in the =
above text.



Besides, in case sustained IP =
address allocation is used default, there  may be multiple sustained IP =
addresses including newly obtained sustained  IP address over the new =
access network in the IP stack. However, when an  app. is initiated, the =
IP stack may not select the new one in the context  of the default =
source IP address selection mechanism [RFC6724][RFC5014].


OK, is the issue following: When there are =
multiple sustained IP addresses, how does the IP stack pick one among =
them?


For providing the full on-demand =
mobility, a new flag is needed, letting  the IP stack request a new =
sustained IP address or choose a sustained IP  address not requiring IP =
mobility anchoring when an application is  initiated, among the existing =
ones in the IP stack.


Your flag is not a solution to what I captured =
above. It does something else: Instruct the IP stack to go get a new =
sustained IP address whether there is already one or more configured on =
the stack or not.


Alper




--=20
-------------------------+----------------------------------------------
-------------------------+---
Reporter:               |      Owner:  draft-ietf-dmm-ondemand-
seiljeon@av.it.pt      |  mobility@tools.ietf.org
   Type:  defect       |     Status:  new
Priority:  critical     |  Milestone:
Component:  ondemand-    |    Version:
mobility               |   Keywords:  on-demand mobility
Severity:  Submitted    |
WG Document            |
-------------------------+----------------------------------------------
-------------------------+---

Ticket URL: <http://trac.tools.ietf.org/wg/dmm/trac/ticket/49>=

dmm <http://tools.ietf.org/dmm/>


_______________________________________________
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
=




=

--Apple-Mail=_C8F0B1F6-60FD-4522-BAC0-365A6132A69E--