From internet-drafts@ietf.org Tue Oct 8 09:54:24 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDC421E8278; Tue, 8 Oct 2013 09:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25GPLZXsnWRY; Tue, 8 Oct 2013 09:54:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BB621E8273; Tue, 8 Oct 2013 09:54:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131008165423.25649.36252.idtracker@ietfa.amsl.com> Date: Tue, 08 Oct 2013 09:54:23 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-update-notifications-11.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 16:54:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Update Notifications for Proxy Mobile IPv6 Author(s) : Suresh Krishnan Sri Gundavelli Marco Liebsch Hidetoshi Yokota Jouni Korhonen Filename : draft-ietf-netext-update-notifications-11.txt Pages : 20 Date : 2013-10-08 Abstract: This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These update notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-update-notifications-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-update-notifications-11 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 internet-drafts@ietf.org Tue Oct 8 09:54:26 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA61E21E827D for ; Tue, 8 Oct 2013 09:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyG1OoVuuiRn; Tue, 8 Oct 2013 09:54:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6759721E827A; Tue, 8 Oct 2013 09:54:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: netext-chairs@tools.ietf.org, draft-ietf-netext-update-notifications@tools.ietf.org, netext@ietf.org, brian@innovationslab.net X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131008165425.25649.44575.idtracker@ietfa.amsl.com> Date: Tue, 08 Oct 2013 09:54:25 -0700 Subject: [netext] New Version Notification - draft-ietf-netext-update-notifications-11.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 16:54:27 -0000 A new version (-11) has been submitted for draft-ietf-netext-update-notific= ations: http://www.ietf.org/internet-drafts/draft-ietf-netext-update-notifications-= 11.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-update-notifications-11 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. IETF Secretariat. From internet-drafts@ietf.org Tue Oct 8 16:00:48 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF83C21F99FB; Tue, 8 Oct 2013 16:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tTJM8drhbse; Tue, 8 Oct 2013 16:00:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E76821F9123; Tue, 8 Oct 2013 16:00:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131008230031.28645.65762.idtracker@ietfa.amsl.com> Date: Tue, 08 Oct 2013 16:00:31 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pd-pmip-10.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 23:00:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Prefix Delegation Support for Proxy Mobile IPv6 Author(s) : Xingyue Zhou Jouni Korhonen Carl Williams Sri Gundavelli Carlos J. Bernardos Filename : draft-ietf-netext-pd-pmip-10.txt Pages : 26 Date : 2013-10-08 Abstract: This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain IP prefixes for its attached mobile networks using DHCPv6 prefix delegation. Network-based mobility management support is provided for those delegated IP prefixes just as it is provided for the mobile node's home address. Even if the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pd-pmip-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pd-pmip-10 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 cjbc@it.uc3m.es Tue Oct 8 16:00:58 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BE521E80BD for ; Tue, 8 Oct 2013 16:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxznNCbM1bVn for ; Tue, 8 Oct 2013 16:00:51 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 1D43121F9E6A for ; Tue, 8 Oct 2013 16:00:44 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 42569CD4B98; Wed, 9 Oct 2013 01:00:42 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [172.18.76.226] (unknown [81.253.52.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id BAC71CD5D56; Wed, 9 Oct 2013 01:00:41 +0200 (CEST) Message-ID: <1381273240.4024.18.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Brian Haberman Date: Wed, 09 Oct 2013 01:00:40 +0200 In-Reply-To: <520BE5D5.7030801@innovationslab.net> References: <520BE5D5.7030801@innovationslab.net> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-4+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20206.003 Cc: "netext@ietf.org" , draft-ietf-netext-pd-pmip@tools.ietf.org Subject: Re: [netext] AD Review : draft-ietf-netext-pd-pmip X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 23:00:58 -0000 Hi Brian, all, Apologies for the late reaction on this. We have just posted a new revision (-10) of the draft, addressing your comments. Please see inline below some answers. On Wed, 2013-08-14 at 16:17 -0400, Brian Haberman wrote: > All, > I have performed my AD review of draft-ietf-netext-pd-pmip. I > apologize for it taking as long as it did. Overall, I am supportive of > this work, but I have some concerns. I *think* most of my concerns have > to do with a lack of clarity in the spec caused by the layout of the > draft. Of particular concern is the overabundance of bullet lists in > sections 5.1.2. [Authors] We have tried to reduce the use of the bullet lists, as well as to reorganize a bit the text. > > Please let me know if you need additional detail on any of these > comments. Otherwise, I will await a revised version that the WG is > happy with. > We would like to ask the WG to check whether they are happy with current revision of the document. > > 1. In the Abstract, mention that prefix delegation is being described in > relation to DHCPv6-PD [Authors] Done. > > 2. The Introduction says prefix delegation via DHCPv6 or through other > mechanisms. Later, the draft says DHCPv6 or static configuration. I > can see how both of those could be made to work, but I am leery of > mentioning some future PD protocol. How would that work? How would you > know which mechanism is being used? Will the same PMIPv6 > signaling suffice for a future PD protocol? I think it makes sense to > stick to what we know how to do today. [Authors] The specification focuses on DHCPv6-PD, but also allows for static configuration or access technology specific mechanisms. We have clarified the text, so we do not mention any future PD protocol. > > 3. Figures 2-4 are never referenced in the text. [Authors] Fixed. > > 4. Intro uses MAG without expansion or definition. [Authors] Fixed. > > 5. Introduction defines egress and ingress interfaces, but should > explicitly state these terms are defined from the perspective of the > mobile network. I would actually move these definitions to section 2 > and describe the MR function in relation to the mobile network and the > point-of-attachment. [Authors] Done. > > 6. How do the definitions in section 2 relate to the definitions in RFC > 4885? [Authors] We have clarified this. > > 7. Section 3.1 - any additional assumptions about how an MR knows which > interface to use when making DHCPv6 requests? [Authors] We assume the egress interface is used. We have explicitly added this in the text. > > 8. Sections 3.2.1 and 3.2.2 are rather sparse in descriptive text. It > would be good to briefly describe the steps outlined in the > corresponding figures. [Authors] Done. > > 9. Section 5.1.2 - Fourth bullet says the MAG MAY choose to send PBA > after getting a DMNP_IN_USE return code. Why would it (or not) do that? [Authors] This was a typo. It should say "PBU". We have fixed it. > > 10. The bullet lists in 5.1.2/5.2.2 (and child sections) are confusing. > The high-level bullets read like they should just be paragraphs. The > sub-list in bullet two and five are items that need to > be considered if stated conditions are met, correct?. And am I correct > in that there must be 3 instances of the DMNP option in the PBU? [Authors] We have made some changes there to make this more clear. > > 11. Structure of 5.1.2.1 is confusing. Can DHCP-MAG Interactions be > promoted to 5.1.3 and then have 5.1.3.1 describe when MAG is DR and > 5.1.3.2 describe when LMA is DR? [Authors] Done. > > 12. Bullet 2 of the DR at the MAG scenario is confusing. If the DR and > MAG are co-located, what interactions are beyond the scope of this > document? Or is this more of the interactions between two processes > running on the same platform? [Authors] It is more on the interactions between the two processes. We have rewritten that piece of text to make it more clear. > > 13. If the MR roams to a MAG that does not support PD, is there specific > behavior the MR needs to exhibit wrt the LFNs? [Authors] We have added some text on this. Basically, we assume that all MAGs supports PD. If not, that would make the MR loose the delegated prefixes, and therefore the LFNs would loose them. We mention that the MR may explicitly deprecate the addresses used by the LFNs or just leave them expire. > > 14. Is there a preference (operational issues) for running the DR at the > LMA rather than the MAG, or vice versa? If so, should that be noted? [Authors] Although we do not have a super strong preference, it is simpler to run the DR on the MAG. so a single protocol interface is used between the MAG and the LMA. We have added some text on this. > > > Regards, > Brian From internet-drafts@ietf.org Tue Oct 8 21:31:49 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629B921F8E51; Tue, 8 Oct 2013 21:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMiZP7pyjtNK; Tue, 8 Oct 2013 21:31:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F18B521E80C1; Tue, 8 Oct 2013 21:31:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131009043143.28645.58522.idtracker@ietfa.amsl.com> Date: Tue, 08 Oct 2013 21:31:43 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-update-notifications-12.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 04:31:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Update Notifications for Proxy Mobile IPv6 Author(s) : Suresh Krishnan Sri Gundavelli Marco Liebsch Hidetoshi Yokota Jouni Korhonen Filename : draft-ietf-netext-update-notifications-12.txt Pages : 20 Date : 2013-10-08 Abstract: This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These update notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-update-notifications-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-update-notifications-12 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 internet-drafts@ietf.org Tue Oct 8 21:31:50 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2604C21E80CD for ; Tue, 8 Oct 2013 21:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBedz5dcZLim; Tue, 8 Oct 2013 21:31:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E47421E80C6; Tue, 8 Oct 2013 21:31:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: netext-chairs@tools.ietf.org, draft-ietf-netext-update-notifications@tools.ietf.org, netext@ietf.org, brian@innovationslab.net X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131009043145.28645.93944.idtracker@ietfa.amsl.com> Date: Tue, 08 Oct 2013 21:31:45 -0700 Subject: [netext] New Version Notification - draft-ietf-netext-update-notifications-12.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 04:31:50 -0000 A new version (-12) has been submitted for draft-ietf-netext-update-notific= ations: http://www.ietf.org/internet-drafts/draft-ietf-netext-update-notifications-= 12.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-update-notifications-12 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. IETF Secretariat. From iesg-secretary@ietf.org Wed Oct 9 13:43:45 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6117C21E81C0; Wed, 9 Oct 2013 13:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.38 X-Spam-Level: X-Spam-Status: No, score=-102.38 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glEb2N3t2+qd; Wed, 9 Oct 2013 13:43:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5512521E81CC; Wed, 9 Oct 2013 13:43:24 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131009204324.15919.194.idtracker@ietfa.amsl.com> Date: Wed, 09 Oct 2013 13:43:24 -0700 Cc: netext mailing list , netext chair , RFC Editor Subject: [netext] Protocol Action: 'Update Notifications for Proxy Mobile IPv6' to Proposed Standard (draft-ietf-netext-update-notifications-12.txt) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 20:43:45 -0000 The IESG has approved the following document: - 'Update Notifications for Proxy Mobile IPv6' (draft-ietf-netext-update-notifications-12.txt) as Proposed Standard This document is the product of the Network-Based Mobility Extensions Working Group. The IESG contact persons are Brian Haberman and Ted Lemon. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ Technical Summary: This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These update notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose. Working Group Summary: The extension to Proxy Mobile IPv6 was viewed as essential to the protocol and hence was adopted by the working group and progressed with no issues. Document Quality: The document has been reviewed by multiple experts within the working group and has been updated based on the feedback received. The quality of the document itself is good and ready for IESG review. All reviewers have been acknowledged in the I-D. The extension is relevant and has been requested by 3GPP as an enhancement to the protocol. Multiple vendors are likely to implement this extension to Proxy Mobile IPv6. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Basavaraj Patil Responsible AD: Brian Haberman From brian@innovationslab.net Thu Oct 10 07:24:25 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663C111E817B for ; Thu, 10 Oct 2013 07:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sS26GiaFUsO for ; Thu, 10 Oct 2013 07:24:15 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 290AD11E8173 for ; Thu, 10 Oct 2013 07:24:07 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id E1D09880F3 for ; Thu, 10 Oct 2013 07:24:03 -0700 (PDT) Received: from 10252297.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8C57A1368105 for ; Thu, 10 Oct 2013 07:24:03 -0700 (PDT) Message-ID: <5256B87F.4090004@innovationslab.net> Date: Thu, 10 Oct 2013 10:23:59 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "netext@ietf.org" References: <520BE5D5.7030801@innovationslab.net> <1381273240.4024.18.camel@acorde.it.uc3m.es> In-Reply-To: <1381273240.4024.18.camel@acorde.it.uc3m.es> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Q7tDdmF4i26DeTqHoV4uMmQ1RLMPdriRw" Subject: Re: [netext] AD Review : draft-ietf-netext-pd-pmip X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 14:24:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Q7tDdmF4i26DeTqHoV4uMmQ1RLMPdriRw Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, I would like the WG to review these changes and speak up if they have any concerns with them. Regards, Brian On 10/8/13 7:00 PM, Carlos Jes=FAs Bernardos Cano wrote: > Hi Brian, all, >=20 > Apologies for the late reaction on this. >=20 > We have just posted a new revision (-10) of the draft, addressing your > comments. Please see inline below some answers. >=20 > On Wed, 2013-08-14 at 16:17 -0400, Brian Haberman wrote: >> All, >> I have performed my AD review of draft-ietf-netext-pd-pmip. I=20 >> apologize for it taking as long as it did. Overall, I am supportive o= f=20 >> this work, but I have some concerns. I *think* most of my concerns ha= ve=20 >> to do with a lack of clarity in the spec caused by the layout of the=20 >> draft. Of particular concern is the overabundance of bullet lists in = >> sections 5.1.2. >=20 > [Authors] We have tried to reduce the use of the bullet lists, as well > as to reorganize a bit the text. >=20 >> >> Please let me know if you need additional detail on any of these= =20 >> comments. Otherwise, I will await a revised version that the WG is=20 >> happy with. >> >=20 > We would like to ask the WG to check whether they are happy with curren= t > revision of the document. >=20 >> >> 1. In the Abstract, mention that prefix delegation is being described = in=20 >> relation to DHCPv6-PD >=20 > [Authors] Done. >=20 >> >> 2. The Introduction says prefix delegation via DHCPv6 or through other= =20 >> mechanisms. Later, the draft says DHCPv6 or static configuration. I = >> can see how both of those could be made to work, but I am leery of=20 >> mentioning some future PD protocol. How would that work? How would y= ou=20 >> know which mechanism is being used? Will the same PMIPv6 >> signaling suffice for a future PD protocol? I think it makes sense to= =20 >> stick to what we know how to do today. >=20 > [Authors] The specification focuses on DHCPv6-PD, but also allows for > static configuration or access technology specific mechanisms. We have > clarified the text, so we do not mention any future PD protocol. >=20 >> >> 3. Figures 2-4 are never referenced in the text. >=20 > [Authors] Fixed. >=20 >> >> 4. Intro uses MAG without expansion or definition. >=20 > [Authors] Fixed. >=20 >> >> 5. Introduction defines egress and ingress interfaces, but should=20 >> explicitly state these terms are defined from the perspective of the=20 >> mobile network. I would actually move these definitions to section 2 = >> and describe the MR function in relation to the mobile network and the= =20 >> point-of-attachment. >=20 > [Authors] Done. >=20 >> >> 6. How do the definitions in section 2 relate to the definitions in RF= C=20 >> 4885? >=20 > [Authors] We have clarified this. >=20 >> >> 7. Section 3.1 - any additional assumptions about how an MR knows whic= h=20 >> interface to use when making DHCPv6 requests? >=20 > [Authors] We assume the egress interface is used. We have explicitly > added this in the text. >=20 >> >> 8. Sections 3.2.1 and 3.2.2 are rather sparse in descriptive text. It= =20 >> would be good to briefly describe the steps outlined in the=20 >> corresponding figures. >=20 > [Authors] Done. >=20 >> >> 9. Section 5.1.2 - Fourth bullet says the MAG MAY choose to send PBA=20 >> after getting a DMNP_IN_USE return code. Why would it (or not) do tha= t? >=20 > [Authors] This was a typo. It should say "PBU". We have fixed it. >=20 >> >> 10. The bullet lists in 5.1.2/5.2.2 (and child sections) are confusing= =2E=20 >> The high-level bullets read like they should just be paragraphs. Th= e=20 >> sub-list in bullet two and five are items that need to >> be considered if stated conditions are met, correct?. And am I correc= t=20 >> in that there must be 3 instances of the DMNP option in the PBU? >=20 > [Authors] We have made some changes there to make this more clear. >=20 >> >> 11. Structure of 5.1.2.1 is confusing. Can DHCP-MAG Interactions be=20 >> promoted to 5.1.3 and then have 5.1.3.1 describe when MAG is DR and=20 >> 5.1.3.2 describe when LMA is DR? >=20 > [Authors] Done. >=20 >> >> 12. Bullet 2 of the DR at the MAG scenario is confusing. If the DR and= =20 >> MAG are co-located, what interactions are beyond the scope of this=20 >> document? Or is this more of the interactions between two processes=20 >> running on the same platform? >=20 > [Authors] It is more on the interactions between the two processes. We > have rewritten that piece of text to make it more clear. >=20 >> >> 13. If the MR roams to a MAG that does not support PD, is there specif= ic=20 >> behavior the MR needs to exhibit wrt the LFNs? >=20 > [Authors] We have added some text on this. Basically, we assume that al= l > MAGs supports PD. If not, that would make the MR loose the delegated > prefixes, and therefore the LFNs would loose them. We mention that the > MR may explicitly deprecate the addresses used by the LFNs or just leav= e > them expire. >=20 >> >> 14. Is there a preference (operational issues) for running the DR at t= he=20 >> LMA rather than the MAG, or vice versa? If so, should that be noted? >=20 > [Authors] Although we do not have a super strong preference, it is > simpler to run the DR on the MAG. so a single protocol interface is use= d > between the MAG and the LMA. We have added some text on this. >=20 >> >> >> Regards, >> Brian >=20 --Q7tDdmF4i26DeTqHoV4uMmQ1RLMPdriRw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSVriAAAoJEBOZRqCi7goqf+gH/im4Cps5Hg8ki7knvgrtDLA9 sO85of5DRJaK4/aonL2oYa+NdqWz8eLMtLaCl+odYM7e/aaN43kiY3H0/TS0/o33 ZummhEgy5gN5mKlqNFYluXcRixIqyo4WMhypdQuxhckGp7nq4meZ/Q1G3RWF7dkr UZthP4CVq9dH14Ziam9PMSsXKvN6Vie6ZU26bRGWDqAvTexRC3SCN07FvfP86zay VBdjVin7QSorGtcTy3Hf/DqCduSFreLL978t3I6Qb/dWVzzF8pA8enc8U8R2f5+o QN++6akyiVmuvseX1rywG5MKBjaIl/U3HkVBTDbK+hVw42mKAVQO+mI64sK44P4= =6jlm -----END PGP SIGNATURE----- --Q7tDdmF4i26DeTqHoV4uMmQ1RLMPdriRw-- From rkoodli@cisco.com Thu Oct 10 11:24:11 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C0521F9FBC for ; Thu, 10 Oct 2013 11:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDzT6q7SbWf1 for ; Thu, 10 Oct 2013 11:24:04 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2935721E8097 for ; Thu, 10 Oct 2013 11:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1939; q=dns/txt; s=iport; t=1381429435; x=1382639035; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=UR/sufJDYVPgybDRUbgaWV1vzBENcMUsHa3diG+ibMo=; b=OqNB/LSTV8waLVKGTpOW5YKPvnQ9MdqyPIuSQfusybDo0I4oam/Vh8TD KI9kNRgQkd23iHd3gf3UtqziQt5o3x/IwThufmS+dE7LrQvIY7PdC4B54 1rAmfTE+L4pRj1dxC5ucHoIQ8TQV+c2O/V2pqsK+7lIaP5HURkZwzFvCR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQFAB7wVlKtJV2Z/2dsb2JhbABZgwc4UsBgS4EjFm0HgiUBAQEEAQEBNzEDCRQBCCIUBTILGwEGAwIEEwiHfgyYVqE5jxY4gx+BBAOZNJBTgWaBPoIq X-IronPort-AV: E=Sophos;i="4.90,1073,1371081600"; d="scan'208";a="270641452" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 10 Oct 2013 18:23:53 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9AINrji018045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 10 Oct 2013 18:23:53 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 10 Oct 2013 13:23:53 -0500 From: "Rajeev Koodli (rkoodli)" To: "netext@ietf.org" Thread-Topic: [netext] Protocol Action: 'Update Notifications for Proxy Mobile IPv6' to Proposed Standard (draft-ietf-netext-update-notifications-12.txt) Thread-Index: AQHOxeXfVOSpCXVgbkak+RBZ9c933g== Date: Thu, 10 Oct 2013 18:23:52 +0000 Message-ID: <7C52FDEBC843C44DBAF2CA6A30662C6D0161DA74@xmb-aln-x04.cisco.com> In-Reply-To: <20131009204324.15919.194.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.80.213] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [netext] FW: Protocol Action: 'Update Notifications for Proxy Mobile IPv6' to Proposed Standard (draft-ietf-netext-update-notifications-12.txt) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 18:24:11 -0000 Thanks everyone in the WG! And, thanks to authors for the hard work. Regards, -Chairs On 10/9/13 1:43 PM, "The IESG" wrote: >The IESG has approved the following document: >- 'Update Notifications for Proxy Mobile IPv6' > (draft-ietf-netext-update-notifications-12.txt) as Proposed Standard > >This document is the product of the Network-Based Mobility Extensions >Working Group. > >The IESG contact persons are Brian Haberman and Ted Lemon. > >A URL of this Internet Draft is: >http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ > > > > >Technical Summary: > >This document specifies protocol enhancements for allowing the local >mobility anchor in a Proxy Mobile IPv6 domain to asynchronously >notify the mobile access gateway about changes related to a mobility >session. These update notification messages are exchanged using a >new Mobility Header message type specifically designed for this >purpose. > >Working Group Summary: > >The extension to Proxy Mobile IPv6 was viewed as essential to the >protocol and hence was adopted by the working group and progressed >with no issues. > >Document Quality: > >The document has been reviewed by multiple experts within the working >group and has been updated based on the feedback received. The quality >of the document itself is good and ready for IESG review. All >reviewers have been acknowledged in the I-D. The extension is relevant >and has been requested by 3GPP as an enhancement to the >protocol. Multiple vendors are likely to implement this extension to >Proxy Mobile IPv6. > >Personnel: > >Who is the Document Shepherd? Who is the Responsible Area Director? > >Document Shepherd: Basavaraj Patil >Responsible AD: Brian Haberman >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From iesg-secretary@ietf.org Thu Oct 17 05:45:54 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E030511E81AD; Thu, 17 Oct 2013 05:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHdcO2ULYnbO; Thu, 17 Oct 2013 05:45:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D9811E8133; Thu, 17 Oct 2013 05:45:45 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131017124545.21841.33200.idtracker@ietfa.amsl.com> Date: Thu, 17 Oct 2013 05:45:45 -0700 Cc: netext@ietf.org Subject: [netext] Last Call: (Prefix Delegation Support for Proxy Mobile IPv6) to Proposed Standard X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 12:45:54 -0000 The IESG has received a request from the Network-Based Mobility Extensions WG (netext) to consider the following document: - 'Prefix Delegation Support for Proxy Mobile IPv6' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-10-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain IP prefixes for its attached mobile networks using DHCPv6 prefix delegation. Network-based mobility management support is provided for those delegated IP prefixes just as it is provided for the mobile node's home address. Even if the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2121/ From michal.hoeft@gmail.com Fri Oct 18 03:24:00 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D746511E81BC for ; Fri, 18 Oct 2013 03:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKrU0l4WK9GI for ; Fri, 18 Oct 2013 03:23:59 -0700 (PDT) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 79A4611E81D5 for ; Fri, 18 Oct 2013 03:23:51 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id h10so1776701vbh.34 for ; Fri, 18 Oct 2013 03:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FVP5pBMnnC4Q7+5Rc1kI8Cf3tuaxuftOOqBtdRvhdqg=; b=xg3duACwZ3zCChBWEsTJl94Awo2SKHikIXB/vgEMNlLHHW2BrALnTh1F/ciiiOym9n JMToo06JCSZat0Q3R/g+Mq8e/QTU01qDDbpZ3NHHlLml3uQJRqErzzu1AfJUQcorrvy8 Tw5Wu6xPhe+zgCKxjI3AdhaGNXoX5JxxQEDnCRVelJSGQdGb7EGIBKqZUn45w4C0+7kc 397GWb3mzYu59GJEwtYC18xtyRfncSEbwekTwXXQrInLQgGObTQn0k9KxgbAP/XcOPBP GwOcdCirEEJL6Khu8eroRxYUBNGTCjdsleUvwaGKvg3DlsQIsuLEbvvOm1MlnjiW1BGx E4HA== MIME-Version: 1.0 X-Received: by 10.221.58.212 with SMTP id wl20mr738305vcb.19.1382091822427; Fri, 18 Oct 2013 03:23:42 -0700 (PDT) Received: by 10.52.160.9 with HTTP; Fri, 18 Oct 2013 03:23:42 -0700 (PDT) Date: Fri, 18 Oct 2013 12:23:42 +0200 Message-ID: From: =?ISO-8859-2?Q?Micha=B3_Hoeft?= To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=001a11335e5c1f810204e90154eb Subject: [netext] Review: draft-ietf-netext-pd-pmip-10 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 10:24:01 -0000 --001a11335e5c1f810204e90154eb Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Hello I am a researcher at Gda=F1sk University of Technology interested in mobili= ty management protocols, especially in PMIPv6. I would be very thankful if authors of draft-ietf-netext-pd-pmip-10 could clarify my doubt. I wonder, why Section 3 is not more general, why only three deployment models are described in the draft and titled after DR location. It seams that, DR don't have to be co-located with LMA (Section 3.2.2). In this case, it can be run on an external server and it does not change message flow. It is similar in Section 3.2.1, in which LMA provides to DR prefixes by means of DMNP option. It is very interesting protocol integrating solution. However I'm a little confused considering implementation of DR co-located with MAG. I can imagine a deployment model, in that DR is co-located with MAG but obtains prefixes using more common methods e.g. Delegated-IPv6-Prefix AVP (RFC 4818). Especially, if it could be aggregated with other MAG-to-HAAA AVPs (RFC 5779). In my opinion, titles of Sections 3.2.1-3.2.3 should be changed to be more accurate and to describe MAG-LMA interaction instead of DR co-location. For example: 3.2.1 DMNP provided during registration 3.2.2 Separated AR and DMNP registration 3.2.3 Aggregated AR and DMNP registration In accordance with RFC5213, PBU/PBA messages have few mandatory options (MNI,HNP,HI,AAT). Although some of them are easy to set (MNI with MNI of AR, HI with 5. Handoff state not changed, AAT depends on access technology - please correct me if I'm wrong), I see the problem with HNP in separate AD and DMNP registration scenario. In my opinion, it should be defined how to fill this option - either ALL_ZERO or HNP of AR. Please, consider also revision of following typos: page 4: is enabled is for =3D> is enabled for page 7,9: proxy binding acknowledgment =3D> Proxy Binding Acknowledgment proxy binding update =3D> Proxy Binding Update page 9. Figure 2: Message 4): PBU =3D>PBU(DMNP) page 11: from the mobile router from registering =3D> from the mobile router for registering If you need any additional detail on my comments, please, do not hesitate to contact me. Best regards Michal Hoeft --001a11335e5c1f810204e90154eb Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable
Hello

I am a research= er at Gda=F1sk University of Technology interested in mobility management p= rotocols, especially in PMIPv6. I would be very thankful if authors of draf= t-ietf-netext-pd-pmip-10 could clarify my doubt.

I wonder, why Section 3 is not more general, why only three deployment mode= ls are described in the draft and titled after DR location.
It seams th= at, DR don't have to be co-located with LMA (Section 3.2.2). In this ca= se, it can be run on an external server and it does not change message flow= .
It is similar in Section 3.2.1, in which LMA provides to DR pref= ixes by means of DMNP option. It is very interesting protocol integrating s= olution. However I'm a little confused considering implementation of DR= co-located with MAG. I can imagine a deployment model, in that DR is co-lo= cated with MAG but obtains prefixes using more common methods e.g. Delegate= d-IPv6-Prefix AVP (RFC 4818). Especially, if it could be aggregated with ot= her MAG-to-HAAA AVPs (RFC 5779).

In my opinion, titles of Sections 3.2.1-3.2.3 should be changed to be m= ore accurate and to describe MAG-LMA interaction instead of DR co-location.= For example:
3.2.1 DMNP provided during registration
3.2.2 Sepa= rated AR and DMNP registration
3.2.3 Aggregated AR and DMNP regis= tration

In accordance with RFC5213, PBU/PBA messag= es have few mandatory options (MNI,HNP,HI,AAT). Although some of them are e= asy to set (MNI with MNI of AR, HI with 5. Handoff state not changed, AAT d= epends on access technology - please correct me if I'm wrong), I see th= e problem with HNP in separate AD and DMNP registration scenario. In my opi= nion, it should be defined how to fill this option - either ALL_ZERO or HNP= of AR.

Please, consider also revision of following typos:
page 4:
is enabled is for =3D> is enabled for
page 7,9:
proxy binding acknowledgment =3D> Proxy Bindi= ng Acknowledgment
proxy binding update =3D> Proxy Binding Update
<= /div>
page 9. Figure 2: Message 4):
PBU =3D>PBU(DMNP)
page 11:
from the mobile router from registering =3D> from = the mobile router for registering

If you need any a= dditional detail on my comments, please, do not hesitate to contact me.

Best regards
Michal Hoeft

--001a11335e5c1f810204e90154eb-- From sgundave@cisco.com Fri Oct 18 11:05:22 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C8011E8127 for ; Fri, 18 Oct 2013 11:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-zftgbEmJAb for ; Fri, 18 Oct 2013 11:05:16 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 245C611E8297 for ; Fri, 18 Oct 2013 11:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12788; q=dns/txt; s=iport; t=1382119513; x=1383329113; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=VkgzTHx37iXegTVYcI/1QYR8sKbhrh8uOGOcRfETsqc=; b=m4YQCnFaPj8LZslNJzfESo+U3PhyoyADpXCO5WLvEcWO8MdJW/BHQW6+ lYd9ZNsVz2OSRKpCwFDdassNBbS/FpZGn1uZ4d9Uoq2PsL5ZFw3g4FdQ5 qoD/fh9f8rDaO1Xbd9Obae977uDhpURvJw3pIYXgxVGaoV4qQ2YfC/WjH E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFADV3YVKtJV2c/2dsb2JhbABagkNEgQqDKrp6gSEWdIIlAQEBAwEEHARaDQEIEQMBAgsdBCQRFAkIAgQBEggTh1kDCQaucQyINA2Ja4xmgj8gGAaCZTSBCgOWHo47hTeDJIIp X-IronPort-AV: E=Sophos;i="4.93,524,1378857600"; d="scan'208,217";a="270881508" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 18 Oct 2013 18:05:12 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9II5CkT005158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Oct 2013 18:05:12 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.192]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 13:05:11 -0500 From: "Sri Gundavelli (sgundave)" To: =?windows-1250?Q?Micha=B3_Hoeft?= , "netext@ietf.org" Thread-Topic: [netext] Review: draft-ietf-netext-pd-pmip-10 Thread-Index: AQHOzCyVbnDKzehEXkORxuqABrGyiw== Date: Fri, 18 Oct 2013 18:05:10 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA81DCB7BBA@xmb-aln-x03.cisco.com> 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_24C0F3E22276D9438D6F366EB89FAEA81DCB7BBAxmbalnx03ciscoc_" MIME-Version: 1.0 Subject: Re: [netext] Review: draft-ietf-netext-pd-pmip-10 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 18:05:22 -0000 --_000_24C0F3E22276D9438D6F366EB89FAEA81DCB7BBAxmbalnx03ciscoc_ Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Hi Michal, Thanks for the good review comments=85 some comments inline ..Carlos can ad= d/clarify more =85 From: Micha=B3 Hoeft = > Date: Friday, October 18, 2013 3:23 AM To: "netext@ietf.org" > Subject: [netext] Review: draft-ietf-netext-pd-pmip-10 Hello I am a researcher at Gda=F1sk University of Technology interested in mobili= ty management protocols, especially in PMIPv6. I would be very thankful if = authors of draft-ietf-netext-pd-pmip-10 could clarify my doubt. I wonder, why Section 3 is not more general, why only three deployment mode= ls are described in the draft and titled after DR location. It seams that, DR don't have to be co-located with LMA (Section 3.2.2). In = this case, it can be run on an external server and it does not change messa= ge flow. It is similar in Section 3.2.1, in which LMA provides to DR prefixes by mea= ns of DMNP option. It is very interesting protocol integrating solution. [Sri] We covered the key deployment models. DR function can be on the loca= ted in the home network and that is typically on the LMA. It can be certain= ly outside the LMA, but there is some interworking needed between the DR an= d the LMA and is out of scope for this spec. We did not explicitly cover th= at scenario, but a deployment can certainly make that work. But, that has n= o impact on the wire protocol between the LMA and MAG. We can add a note th= at this is certainly allowed. Carlos =96 Agree ? > However I'm a little confused considering implementation of DR co-locate= d with MAG. I can imagine a deployment model, in that DR is co-located with= MAG but obtains prefixes using more common methods e.g. Delegated-IPv6-Pre= fix AVP (RFC 4818). Especially, if it could be aggregated with other MAG-to= -HAAA AVPs (RFC 5779). [Sri] From protocol point of view, MAG can include the DMNP option, with AL= L_ZERO or with a specific value. MAG can learn about those prefixes, via AA= A (with DMNP AVP's), local config, DHCP interworking and request the same. = MAG has the ability to populate the DMNP option with a specific prefix valu= e, or a 0 to allow LMA to do the allocation. If you see the protocol sectio= n, which is more generic, you will see this. In my opinion, titles of Sections 3.2.1-3.2.3 should be changed to be more = accurate and to describe MAG-LMA interaction instead of DR co-location. For= example: 3.2.1 DMNP provided during registration 3.2.2 Separated AR and DMNP registration 3.2.3 Aggregated AR and DMNP registration [Sri] That is certainly one way to drafting and is fine. What is there in s= ection 3.2.1 to 3.2.1 are more covered along the lines of popular deploymen= t model, but the protocol section is more generic. The key point is that pr= otocol semantic clearly allow the negotiation in a flexible manner coverin= g all these variations. In accordance with RFC5213, PBU/PBA messages have few mandatory options (MN= I,HNP,HI,AAT). Although some of them are easy to set (MNI with MNI of AR, H= I with 5. Handoff state not changed, AAT depends on access technology - ple= ase correct me if I'm wrong), I see the problem with HNP in separate AD and= DMNP registration scenario. In my opinion, it should be defined how to fil= l this option - either ALL_ZERO or HNP of AR. [Sri] Carlos can add. But, the protocol is not requiring changes to the bas= e options. In all the scenarios covered by 5213, 5844, this allows a MAG to= request a additional prefix set, for delegation, as supposed to hosting th= em on the MN-AR link. Please, consider also revision of following typos: page 4: is enabled is for =3D> is enabled for page 7,9: proxy binding acknowledgment =3D> Proxy Binding Acknowledgment proxy binding update =3D> Proxy Binding Update page 9. Figure 2: Message 4): PBU =3D>PBU(DMNP) page 11: from the mobile router from registering =3D> from the mobile router for reg= istering If you need any additional detail on my comments, please, do not hesitate t= o contact me. Best regards Michal Hoeft --_000_24C0F3E22276D9438D6F366EB89FAEA81DCB7BBAxmbalnx03ciscoc_ Content-Type: text/html; charset="windows-1250" Content-ID: <021EFB395BFB6645A040A9E391E4B732@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Michal,

Thanks for the good review comments=85= some comments inline ..Carlos can add/clarify more =85



From: Micha=B3 Hoeft <michal.hoeft@gmail.com>
Date: Friday, October 18, 2013 3:23= AM
To: "netext@ietf.org" <= netext@ietf.org>
Subject: [netext] Review: draft-iet= f-netext-pd-pmip-10

Hello

I am a researcher at Gda=F1sk University of Technology interested in mobili= ty management protocols, especially in PMIPv6. I would be very thankful if = authors of draft-ietf-netext-pd-pmip-10 could clarify my doubt.

I wonder, why Section 3 is not more general, why only three deployment mode= ls are described in the draft and titled after DR location.
It seams that, DR don't have to be co-located with LMA (Section 3.2.2). In = this case, it can be run on an external server and it does not change messa= ge flow.
It is similar in Section 3.2.1, in which LMA provides to DR prefixes b= y means of DMNP option. It is very interesting protocol integrating solutio= n.

[Sri] We covered the key deployment models.  DR function can be on the located in the home network and that is typ= ically on the LMA. It can be certainly outside the LMA, but there is some i= nterworking needed between the DR and the LMA and is out of scope for this spec. We did not explicitly cover that sc= enario, but a deployment can certainly make that work. But, that has no imp= act on the wire protocol between the LMA and MAG. We can add a note that th= is is certainly allowed. Carlos =96 Agree ?


>  However I'm a little confus= ed considering implementation of DR co-located with MAG. I can imagine a de= ployment model, in that DR is co-located with MAG but obtains prefixes usin= g more common methods e.g. Delegated-IPv6-Prefix AVP (RFC 4818). Especially, if it could be aggregated with other MAG-to-HA= AA AVPs (RFC 5779). 

[Sri] From protocol point of view, MAG can include the DMN= P option, with ALL_ZERO or with a specific value. MAG can learn about those prefixes, via AAA (with DMNP AVP's), local confi= g, DHCP interworking and request the same. MAG has the ability to populate = the DMNP option with a specific prefix value, or a 0 to allow LMA to do the= allocation. If you see the protocol section, which is more generic, you will see this.


In my opinion, titles of Sections 3.2.1-3.2.3 should be changed to be more = accurate and to describe MAG-LMA interaction instead of DR co-location. For= example:
3.2.1 DMNP provided during registration
3.2.2 Separated AR and DMNP registration
3.2.3 Aggregated AR and DMNP registration

[Sri] That is certainly one way to drafting and is fine. What = is there in section 3.2.1 to 3.2.1 are more covered along the lines of popu= lar deployment model, but the protocol section is more generic. The key point is that protocol semantic clearly al= low the negotiation in  a flexible manner covering all these variation= s.


In accordance with RFC5213, PBU/PBA messages have few mandatory option= s (MNI,HNP,HI,AAT). Although some of them are easy to set (MNI with MNI of = AR, HI with 5. Handoff state not changed, AAT depends on access technology = - please correct me if I'm wrong), I see the problem with HNP in separate AD and DMNP registration scenario. = In my opinion, it should be defined how to fill this option - either ALL_ZE= RO or HNP of AR.

[Sri] Carlos can add. But, the protocol is not requiring chang= es to the base options. In all the scenarios covered by 5213, 5844, this al= lows a MAG to request a additional prefix set, for delegation, as supposed to hosting them on the MN-AR link. <= /font>



Please, consider also revision of following typos:
page 4:
is enabled is for =3D> is enabled for
page 7,9:
proxy binding acknowledgment =3D> Proxy Binding Acknowledgment
proxy binding update =3D> Proxy Binding Update
page 9. Figure 2: Message 4):
PBU =3D>PBU(DMNP)
page 11:
from the mobile router from registering =3D> from the mobile router for = registering

If you need any additional detail on my comments, please, do not hesit= ate to contact me.

Best regards
Michal Hoeft

 --_000_24C0F3E22276D9438D6F366EB89FAEA81DCB7BBAxmbalnx03ciscoc_-- From rkoodli@cisco.com Fri Oct 18 15:56:08 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C21F11E80ED for ; Fri, 18 Oct 2013 15:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rr+fbaCEZ6XE for ; Fri, 18 Oct 2013 15:56:00 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4C99711E80E3 for ; Fri, 18 Oct 2013 15:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1850; q=dns/txt; s=iport; t=1382136960; x=1383346560; h=from:to:subject:date:message-id:mime-version; bh=8VIfnIX99wtMkTNrtj9sr2iYkmX/IYaKsm0NphCuQQY=; b=lxbkEigUIr2xMb78+HJsjq2bH63ppyfiVi4+cEb0HoYhueqJrFzkZ16N kOkT/+WG7JVgHE+g4IdSStRj6QYETZl9Zjgx6QgHgKuhx1LYriPTcfLL7 4c2dX/fxBVuEHt6RdojCXmta71Hv1rwRkkUS1Dea2YbOtQ/9OYg8Iu3KD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwFAKC7YVKtJV2Z/2dsb2JhbABagkNEgQq+KIEjFm0HgicBBIELAQwBHVYnBBuHfp8zoT2PJYNXgQoDqhCDJIIp X-IronPort-AV: E=Sophos;i="4.93,525,1378857600"; d="scan'208,217";a="273968297" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 18 Oct 2013 22:56:00 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9IMtxvE000570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 18 Oct 2013 22:55:59 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 17:55:59 -0500 From: "Rajeev Koodli (rkoodli)" To: "netext@ietf.org" Thread-Topic: Soliciting Agenda Items for IETF88 Thread-Index: AQHOzFU1xQg/Uz1btUmVC9VAdR2YJQ== Date: Fri, 18 Oct 2013 22:55:58 +0000 Message-ID: <7C52FDEBC843C44DBAF2CA6A30662C6D0162181B@xmb-aln-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.155.73.38] Content-Type: multipart/alternative; boundary="_000_7C52FDEBC843C44DBAF2CA6A30662C6D0162181Bxmbalnx04ciscoc_" MIME-Version: 1.0 Subject: [netext] Soliciting Agenda Items for IETF88 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 22:56:08 -0000 --_000_7C52FDEBC843C44DBAF2CA6A30662C6D0162181Bxmbalnx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, We have a 2 hour slot allocated for the WG meeting at IETF87. Please send a request if you would like a slot on the agenda, by October 22= , 2013. Thanks. -Chairs --_000_7C52FDEBC843C44DBAF2CA6A30662C6D0162181Bxmbalnx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <56309B33495DBB498ED512EDBBF6DAD9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hello,

We have a 2 hour s= lot allocated for the WG meeting at IETF87.

Please send a requ= est if you would like a slot on the agenda, by October 22, 2013.

Thanks.


-Chairs

--_000_7C52FDEBC843C44DBAF2CA6A30662C6D0162181Bxmbalnx04ciscoc_-- From internet-drafts@ietf.org Fri Oct 18 19:48:20 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557A211E8115; Fri, 18 Oct 2013 19:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEyQ5dyysGIq; Fri, 18 Oct 2013 19:48:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8EF11E8136; Fri, 18 Oct 2013 19:48:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131019024818.23305.93187.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 19:48:18 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-logical-interface-support-08.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 02:48:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Logical Interface Support for multi-mode IP Hosts Author(s) : Telemaco Melia Sri Gundavelli Filename : draft-ietf-netext-logical-interface-support-08.txt Pages : 19 Date : 2013-10-18 Abstract: A Logical Interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical Interface support is required on the mobile node operating in a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical Interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in context with various mobility management features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-support There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-logical-interface-support-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-logical-interface-supp= ort-08 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 cjbc@it.uc3m.es Sun Oct 20 15:07:17 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8697E11E82A0 for ; Sun, 20 Oct 2013 15:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP+S5AZz9SMz for ; Sun, 20 Oct 2013 15:07:12 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 6137611E829B for ; Sun, 20 Oct 2013 15:07:11 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id ED3BBCD6922; Mon, 21 Oct 2013 00:07:10 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [192.168.1.3] (82.158.201.225.dyn.user.ono.com [82.158.201.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id BB877CD691C; Mon, 21 Oct 2013 00:07:10 +0200 (CEST) Message-ID: <1382306830.4098.51.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Sri Gundavelli (sgundave)" Date: Mon, 21 Oct 2013 00:07:10 +0200 In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA81DCB7BBA@xmb-aln-x03.cisco.com> References: <24C0F3E22276D9438D6F366EB89FAEA81DCB7BBA@xmb-aln-x03.cisco.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20232.002 Cc: "netext@ietf.org" Subject: Re: [netext] Review: draft-ietf-netext-pd-pmip-10 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 22:07:17 -0000 Hi Sri, Michal, Thanks a lot Michar for your comments. Adding some additional comments inline below. On Fri, 2013-10-18 at 18:05 +0000, Sri Gundavelli (sgundave) wrote: > Hi Michal, > > > Thanks for the good review comments… some comments inline ..Carlos can > add/clarify more … > > > > > > > From: Michał Hoeft > Date: Friday, October 18, 2013 3:23 AM > To: "netext@ietf.org" > Subject: [netext] Review: draft-ietf-netext-pd-pmip-10 > > > > Hello > > I am a researcher at Gdańsk University of Technology interested in > mobility management protocols, especially in PMIPv6. I would be very > thankful if authors of draft-ietf-netext-pd-pmip-10 could clarify my > doubt. > > I wonder, why Section 3 is not more general, why only three deployment > models are described in the draft and titled after DR location. > It seams that, DR don't have to be co-located with LMA (Section > 3.2.2). In this case, it can be run on an external server and it does > not change message flow. > > It is similar in Section 3.2.1, in which LMA provides to DR prefixes > by means of DMNP option. It is very interesting protocol integrating > solution. > > > [Sri] We covered the key deployment models. DR function can be on the > located in the home network and that is typically on the LMA. It can > be certainly outside the LMA, but there is some interworking needed > between the DR and the LMA and is out of scope for this spec. We did > not explicitly cover that scenario, but a deployment can certainly > make that work. But, that has no impact on the wire protocol between > the LMA and MAG. We can add a note that this is certainly allowed. > Carlos – Agree ? > [Carlos] Yes, agree. We'll add a note in -11. > > > However I'm a little confused considering implementation of DR > co-located with MAG. I can imagine a deployment model, in that DR is > co-located with MAG but obtains prefixes using more common methods > e.g. Delegated-IPv6-Prefix AVP (RFC 4818). Especially, if it could be > aggregated with other MAG-to-HAAA AVPs (RFC 5779). > > > [Sri] From protocol point of view, MAG can include the DMNP option, > with ALL_ZERO or with a specific value. MAG can learn about those > prefixes, via AAA (with DMNP AVP's), local config, DHCP interworking > and request the same. MAG has the ability to populate the DMNP option > with a specific prefix value, or a 0 to allow LMA to do the > allocation. If you see the protocol section, which is more generic, > you will see this. > > > > In my opinion, titles of Sections 3.2.1-3.2.3 should be changed to be > more accurate and to describe MAG-LMA interaction instead of DR > co-location. For example: > > 3.2.1 DMNP provided during registration > > 3.2.2 Separated AR and DMNP registration > 3.2.3 Aggregated AR and DMNP registration > > > [Sri] That is certainly one way to drafting and is fine. What is there > in section 3.2.1 to 3.2.1 are more covered along the lines of popular > deployment model, but the protocol section is more generic. The key > point is that protocol semantic clearly allow the negotiation in a > flexible manner covering all these variations. > > > > > In accordance with RFC5213, PBU/PBA messages have few mandatory > options (MNI,HNP,HI,AAT). Although some of them are easy to set (MNI > with MNI of AR, HI with 5. Handoff state not changed, AAT depends on > access technology - please correct me if I'm wrong), I see the problem > with HNP in separate AD and DMNP registration scenario. In my opinion, > it should be defined how to fill this option - either ALL_ZERO or HNP > of AR. > > > > [Sri] Carlos can add. But, the protocol is not requiring changes to > the base options. In all the scenarios covered by 5213, 5844, this > allows a MAG to request a additional prefix set, for delegation, as > supposed to hosting them on the MN-AR link. > > > [Carlos] Yes, I think it is better not to explicitly add that, so we avoid not covering some potential case. As long as what we have in the text is clear and allow for implementation of the spec, I think it is better not to add more text. > > > Please, consider also revision of following typos: > > > page 4: > > is enabled is for => is enabled for [Carlos] Fixed in -11, thanks. > > page 7,9: > > proxy binding acknowledgment => Proxy Binding Acknowledgment > proxy binding update => Proxy Binding Update [Carlos] I think the RFC Editor prefers these terms to be in lowercase, with the exception of the first time they appear and the acronym is introduced. > > page 9. Figure 2: Message 4): > PBU =>PBU(DMNP) [Carlos] Here the intention is to highlight that the prefix is delegated by the LMA and conveyed back in the PBA. Maybe we can explicitly show that the DMNP option is present but with an ALL_ZERO value. > > page 11: > > from the mobile router from registering => from the mobile router for > registering > [Carlos] Fixed in -11, thanks. > > If you need any additional detail on my comments, please, do not > hesitate to contact me. Again, thanks! Carlos > > > Best regards > > Michal Hoeft > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From internet-drafts@ietf.org Mon Oct 21 11:21:25 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAFD11E84A0; Mon, 21 Oct 2013 11:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6C7vEwELfG-U; Mon, 21 Oct 2013 11:21:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAB111E8448; Mon, 21 Oct 2013 11:21:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021182119.32482.55607.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 11:21:19 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pd-pmip-11.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 18:21:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Prefix Delegation Support for Proxy Mobile IPv6 Author(s) : Xingyue Zhou Jouni Korhonen Carl Williams Sri Gundavelli Carlos J. Bernardos Filename : draft-ietf-netext-pd-pmip-11.txt Pages : 26 Date : 2013-10-21 Abstract: This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain IP prefixes for its attached mobile networks using DHCPv6 prefix delegation. Network-based mobility management support is provided for those delegated IP prefixes just as it is provided for the mobile node's home address. Even if the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pd-pmip-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pd-pmip-11 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 cjbc@it.uc3m.es Mon Oct 21 14:14:08 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C656F11E8643 for ; Mon, 21 Oct 2013 14:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id it1t8opXxISB for ; Mon, 21 Oct 2013 14:14:04 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA7111E85C9 for ; Mon, 21 Oct 2013 14:14:03 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 05EA811C42CD; Mon, 21 Oct 2013 23:14:02 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id E267F11C42CA; Mon, 21 Oct 2013 23:14:01 +0200 (CEST) Message-ID: <1382390041.10451.21.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: netext@ietf.org Date: Mon, 21 Oct 2013 23:14:01 +0200 Organization: Universidad Carlos III de Madrid Content-Type: multipart/mixed; boundary="=-QL5pt9+LAGGd0okRD/dJ" X-Mailer: Evolution 3.8.5-2 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20234.002 X-TM-AS-Result: No--23.296-7.0-31-1 X-imss-scan-details: No--23.296-7.0-31-1 Subject: [netext] [Fwd: I-D Action: draft-ietf-netext-pd-pmip-11.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 21:14:08 -0000 --=-QL5pt9+LAGGd0okRD/dJ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hi, We have just posted a new version addressing LC comments from Michal. Thanks, Carlos --=-QL5pt9+LAGGd0okRD/dJ Content-Disposition: inline Content-Description: Forwarded message - [netext] I-D Action: draft-ietf-netext-pd-pmip-11.txt Content-Type: message/rfc822 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on antispam.uc3m.es X-Spam-Level: X-Spam-Status: No, score=1.0 required=3.0 tests=AWL,BAYES_00,NO_REAL_NAME, SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.7-deb X-Original-To: cjbc@it.uc3m.es Delivered-To: cjbc@correo02.uc3m.es Received: from smtp03.uc3m.es (pip-L01.uc3m.es [163.117.176.61]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by correo02.uc3m.es (Postfix) with ESMTPS id BCD5512E84; Mon, 21 Oct 2013 20:22:11 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by smtp03.uc3m.es (Postfix) with ESMTP id 398BB11C42C7; Mon, 21 Oct 2013 20:22:11 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 285F911E84EE; Mon, 21 Oct 2013 11:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1382379689; bh=ZqjZ1B4FJ2UsaJf659XT6/YXg1ws2tqZCdlsvZ5Z1/4=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=dhTAJS21kYvM7RBbeZQmiYTVb1JelpIqr08DHX5U4jvKKWDPtucPdSeapKnBhad1s 7GOCBmMin7M9CY58Mp/KAHINKrG2G9jQDrrTzhZOIgesheokVv32CHw9VCQmB2W6// p/KH6vCcG/7kqfAqaRC6ld454OQh84OdwIpb5z9s= X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAB111E8448; Mon, 21 Oct 2013 11:21:20 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021182119.32482.55607.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 11:21:19 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pd-pmip-11.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Sender: netext-bounces@ietf.org Errors-To: netext-bounces@ietf.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Mon, 21 Oct 2013 20:22:11 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20234.001 X-TM-AS-Result: No--14.343-7.0-31-1 X-imss-scan-details: No--14.343-7.0-31-1 Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Prefix Delegation Support for Proxy Mobile IPv6 Author(s) : Xingyue Zhou Jouni Korhonen Carl Williams Sri Gundavelli Carlos J. Bernardos Filename : draft-ietf-netext-pd-pmip-11.txt Pages : 26 Date : 2013-10-21 Abstract: This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain IP prefixes for its attached mobile networks using DHCPv6 prefix delegation. Network-based mobility management support is provided for those delegated IP prefixes just as it is provided for the mobile node's home address. Even if the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pd-pmip-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pd-pmip-11 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/ _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --=-QL5pt9+LAGGd0okRD/dJ-- From internet-drafts@ietf.org Mon Oct 21 14:41:42 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E4F11E8294; Mon, 21 Oct 2013 14:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SQGAKxxd4Vn; Mon, 21 Oct 2013 14:41:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB4411E844B; Mon, 21 Oct 2013 14:41:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021214128.32508.96843.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 14:41:28 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-04.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 21:41:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : EAP Attributes for WiFi - EPC Integration Author(s) : Ravi Valmikam Rajeev Koodli Filename : draft-ietf-netext-wifi-epc-eap-attributes-04.txt Pages : 13 Date : 2013-10-21 Abstract: With WiFi beginning to establishing itself as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in WiFi access networks. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections and seamless mobility between WiFi and 3G/4G networks. EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access authentication protocol for trusted access networks. This IETF specification is required for mobile devices to access the 3GPP Evolved Packet Core (EPC) networks. This document defines a few new EAP attributes and procedures to provide the above-mentioned functions in trusted WiFi access networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-wifi-epc-eap-attributes There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-wifi-epc-eap-attributes-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-wifi-epc-eap-attribute= s-04 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 internet-drafts@ietf.org Mon Oct 21 15:15:20 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994B711E8739; Mon, 21 Oct 2013 15:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAlWSMjzLUM7; Mon, 21 Oct 2013 15:15:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DED21F9B28; Mon, 21 Oct 2013 15:15:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021221520.32495.4556.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 15:15:20 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip6-qos-04.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:15:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Quality of Service Option for Proxy Mobile IPv6 Author(s) : Marco Liebsch Pierrick Seite Hidetoshi Yokota Jouni Korhonen Sri Gundavelli Filename : draft-ietf-netext-pmip6-qos-04.txt Pages : 43 Date : 2013-10-21 Abstract: This specification defines a new mobility option that can be used by the mobility entities [LMA and MAG] in the Proxy Mobile IPv6 domain to exchange Quality of Service parameters associated with a subscriber's IP flows. Using the QoS option, the local mobility anchor and the mobile access gateway can exchange available QoS attributes and associated values. This enables QoS policing and labeling of packets to enforce QoS differentiation on the path between the local mobility anchor and the mobile access gateway. Furthermore, making QoS parameters available on the MAG enables mapping these parameters to QoS rules that are specific to the access technology which operates below the mobile access gateway. After such mapping, QoS rules can be enforced on the access technology components, such as an IEEE 802.11e Wireless LAN controller. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-qos There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip6-qos-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pmip6-qos-04 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 internet-drafts@ietf.org Mon Oct 21 15:16:55 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BD11F0ED6; Mon, 21 Oct 2013 15:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+vHpPHaJNjG; Mon, 21 Oct 2013 15:16:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3349211E86B3; Mon, 21 Oct 2013 15:16:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021221651.32561.39538.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 15:16:51 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-08.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:16:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Proxy Mobile IPv6 Extensions to Support Flow Mobility Author(s) : Carlos J. Bernardos Filename : draft-ietf-netext-pmipv6-flowmob-08.txt Pages : 19 Date : 2013-10-21 Abstract: Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy Mobile IPv6 domain through different interfaces. This document describes extensions to the Proxy Mobile IPv6 protocol that are required to support network based flow mobility over multiple physical interfaces. The extensions described in this document consist on the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmipv6-flowmob There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmipv6-flowmob-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pmipv6-flowmob-08 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 sgundave@cisco.com Mon Oct 21 15:21:18 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B398211E843C for ; Mon, 21 Oct 2013 15:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GORMULtiH-5u for ; Mon, 21 Oct 2013 15:21:13 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E623211E84CB for ; Mon, 21 Oct 2013 15:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2624; q=dns/txt; s=iport; t=1382394069; x=1383603669; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=41sq1jPqclyDFmk4O/lhtT+8TRnrJh31NZMJBchdD30=; b=R9tSTGr0jy51lxQ7GNW/2rAbl1CySAr4p2q6vSWPKdSrnH+e1Nr57xem XgUHUndtlJTukNXhaU1tF4BEJRePyfm9CnDu4eNYBILkM4DE/sd6T8v1V OjsBp6PAc/2l4p49tK45v7Jb4XfWSY9pbG+aK/meX/3ovBHzCUB9DVhPW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcGALKnZVKtJXG//2dsb2JhbABZgwc4Tga9cUuBMBZtB4InAQQBAQE3NB0BCCIUNwslAgQTCAGHfQgFmHmhUI8qOIMfgQoDmTiQWIMkgio X-IronPort-AV: E=Sophos;i="4.93,542,1378857600"; d="scan'208";a="271838925" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 21 Oct 2013 22:21:09 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9LML91h028274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Oct 2013 22:21:09 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.192]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 17:21:08 -0500 From: "Sri Gundavelli (sgundave)" To: "netext@ietf.org" Thread-Topic: [netext] I-D Action: draft-ietf-netext-pmip6-qos-04.txt Thread-Index: AQHOzqvXKcDvpN0XFUW93Pe5kekJpw== Date: Mon, 21 Oct 2013 22:21:08 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA81DCBF1D8@xmb-aln-x03.cisco.com> In-Reply-To: <20131021221520.32495.4556.idtracker@ietfa.amsl.com> 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.214] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] I-D Action: draft-ietf-netext-pmip6-qos-04.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:21:18 -0000 WG: In preparation for the WGLC and based on solicited reviews from number of folks, we have revised the draft. Significantly improved the protocol interworking section, drafted the processing rules. Please review and comment on this version. Regards Sri On 10/21/13 3:15 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Network-Based Mobility Extensions >Working Group of the IETF. > > Title : Quality of Service Option for Proxy Mobile IPv6 > Author(s) : Marco Liebsch > Pierrick Seite > Hidetoshi Yokota > Jouni Korhonen > Sri Gundavelli > Filename : draft-ietf-netext-pmip6-qos-04.txt > Pages : 43 > Date : 2013-10-21 > >Abstract: > This specification defines a new mobility option that can be used by > the mobility entities [LMA and MAG] in the Proxy Mobile IPv6 domain > to exchange Quality of Service parameters associated with a > subscriber's IP flows. Using the QoS option, the local mobility > anchor and the mobile access gateway can exchange available QoS > attributes and associated values. This enables QoS policing and > labeling of packets to enforce QoS differentiation on the path > between the local mobility anchor and the mobile access gateway. > Furthermore, making QoS parameters available on the MAG enables > mapping these parameters to QoS rules that are specific to the access > technology which operates below the mobile access gateway. After > such mapping, QoS rules can be enforced on the access technology > components, such as an IEEE 802.11e Wireless LAN controller. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-qos > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-netext-pmip6-qos-04 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pmip6-qos-04 > > >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/ > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From cjbc@it.uc3m.es Mon Oct 21 15:24:11 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939FB11E8748 for ; Mon, 21 Oct 2013 15:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iLrWYI8W8s2 for ; Mon, 21 Oct 2013 15:24:06 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 9857B11E84BD for ; Mon, 21 Oct 2013 15:24:06 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 494E2CD6B47 for ; Tue, 22 Oct 2013 00:24:05 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 3DB73C34C6B for ; Tue, 22 Oct 2013 00:24:05 +0200 (CEST) Message-ID: <1382394245.10451.54.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: netext@ietf.org Date: Tue, 22 Oct 2013 00:24:05 +0200 Organization: Universidad Carlos III de Madrid Content-Type: multipart/mixed; boundary="=-SqLqCrLqOgKe0m+wkrz8" X-Mailer: Evolution 3.8.5-2 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20234.002 Subject: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-08.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:24:11 -0000 --=-SqLqCrLqOgKe0m+wkrz8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hi, Following the discussion during the last meeting, I've updated the draft. As requested by the WG, it now uses the Update Notifications for Proxy Mobile IPv6. Comments are welcome. I'd like to ask people that submitted an issue to the tracker to see if you are happy with the revision (and close the issue if that is the case). Thanks, Carlos --=-SqLqCrLqOgKe0m+wkrz8 Content-Disposition: inline Content-Description: Forwarded message - [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-08.txt Content-Type: message/rfc822 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on antispam.uc3m.es X-Spam-Level: X-Spam-Status: No, score=1.0 required=3.0 tests=AWL,BAYES_00,NO_REAL_NAME, SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.7-deb X-Original-To: cjbc@it.uc3m.es Delivered-To: cjbc@correo03.uc3m.es Received: from smtp01.uc3m.es (pip-L01.uc3m.es [163.117.176.61]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by correo03.uc3m.es (Postfix) with ESMTPS id B4F7A3437A; Tue, 22 Oct 2013 00:16:58 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by smtp01.uc3m.es (Postfix) with ESMTP id 0F7E7CD6B05; Tue, 22 Oct 2013 00:16:58 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B601F0ED9; Mon, 21 Oct 2013 15:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1382393817; bh=TxlIQ3C0KVVb96YJFjCgUXbRm4G0yWFHgdUGfl9hAjE=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=SDM3MZvsJo0P1+MWlUTorxy+LadKj9U+Dy/49sJzpGynnDG5aDl+Dr7yMQ3+6+yXy Yvf/ztyVoOaSE9vTf59KgLwTVWFZsAD8QtX262vK6CsD4CA5mFYpgEyM0JE41XsaPK 7NtFT38wLYQ12o61FOql/xWiNa4BPXFpM820J//Y= X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3349211E86B3; Mon, 21 Oct 2013 15:16:51 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021221651.32561.39538.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 15:16:51 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-08.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Sender: netext-bounces@ietf.org Errors-To: netext-bounces@ietf.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Tue, 22 Oct 2013 00:16:58 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20234.002 Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Proxy Mobile IPv6 Extensions to Support Flow Mobility Author(s) : Carlos J. Bernardos Filename : draft-ietf-netext-pmipv6-flowmob-08.txt Pages : 19 Date : 2013-10-21 Abstract: Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy Mobile IPv6 domain through different interfaces. This document describes extensions to the Proxy Mobile IPv6 protocol that are required to support network based flow mobility over multiple physical interfaces. The extensions described in this document consist on the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmipv6-flowmob There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmipv6-flowmob-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmipv6-flowmob-08 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/ _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --=-SqLqCrLqOgKe0m+wkrz8-- From rkoodli@cisco.com Mon Oct 21 15:31:02 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21B911E8386 for ; Mon, 21 Oct 2013 15:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzynllso4dlj for ; Mon, 21 Oct 2013 15:30:51 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6056D11E8333 for ; Mon, 21 Oct 2013 15:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=617; q=dns/txt; s=iport; t=1382394634; x=1383604234; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=OVL2GHhiZE/iWQE53BaTrbaFhlrn3bmyzZxSvPzrjug=; b=MGp0rJfeODcHuDxC2luv7d/t3Q/9hlvwHecjrVDqf+qwOKk+NGOknLtS GLJDOPlYWHRafLjRr6NQ7BzcOBn2/fnf3bmghYCeV9abQfQKvVlboy/I5 SdDwgCrspZpl8h1bEHUnsqvwg4AWnxVWUPnwB7zq54WQsH7uDjCS0apUe A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAqqZVKtJXG9/2dsb2JhbABZgweBDL48gTAWdIInAQSBCwEIIlYlAgQBEgiHfrpNjygCOIMfgQoDiQehCYMkgio X-IronPort-AV: E=Sophos;i="4.93,542,1378857600"; d="scan'208";a="274854974" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 21 Oct 2013 22:30:33 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9LMUX0D012251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 22:30:33 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 17:30:33 -0500 From: "Rajeev Koodli (rkoodli)" To: "cjbc@it.uc3m.es" , "netext@ietf.org" Thread-Topic: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-08.txt] Thread-Index: AQHOzqxG8NtGw8kbX0CbFNziK3IPz5n/m2kA Date: Mon, 21 Oct 2013 22:30:33 +0000 Message-ID: <7C52FDEBC843C44DBAF2CA6A30662C6D01621E63@xmb-aln-x04.cisco.com> In-Reply-To: <1382394245.10451.54.camel@acorde.it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.81.113] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3BEC82E2C7E8EA498F46A72DC89A7196@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-08.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:31:02 -0000 Hi Carlos, On 10/21/13 3:24 PM, "Carlos Jes=FAs Bernardos Cano" wrot= e: >Hi, > >Following the discussion during the last meeting, I've updated the >draft. As requested by the WG, it now uses the Update Notifications for >Proxy Mobile IPv6. Hmm? I don't recall any discussion on this..Perhaps I missed the response(s) to my email. We need to discuss this :) -Rajeev > >Comments are welcome. I'd like to ask people that submitted an issue to >the tracker to see if you are happy with the revision (and close the >issue if that is the case). > >Thanks, > >Carlos From cjbc@it.uc3m.es Mon Oct 21 15:32:55 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AD411E8460 for ; Mon, 21 Oct 2013 15:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8CUqj9Y8M5J for ; Mon, 21 Oct 2013 15:32:50 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id DC53211E8333 for ; Mon, 21 Oct 2013 15:32:49 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1788ECD6B47; Tue, 22 Oct 2013 00:32:46 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 0A3D0CD6B46; Tue, 22 Oct 2013 00:32:46 +0200 (CEST) Message-ID: <1382394765.10451.57.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Rajeev Koodli (rkoodli)" Date: Tue, 22 Oct 2013 00:32:45 +0200 In-Reply-To: <7C52FDEBC843C44DBAF2CA6A30662C6D0162181B@xmb-aln-x04.cisco.com> References: <7C52FDEBC843C44DBAF2CA6A30662C6D0162181B@xmb-aln-x04.cisco.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20234.002 Cc: "netext@ietf.org" Subject: Re: [netext] Soliciting Agenda Items for IETF88 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:32:55 -0000 Hi Rajeev, Raj, I've just posted a revision of the flowmob draft. I'd like to ask for a slot (5-10 mins) to present it. Thanks, Carlos On Fri, 2013-10-18 at 22:55 +0000, Rajeev Koodli (rkoodli) wrote: > > > Hello, > > > We have a 2 hour slot allocated for the WG meeting at IETF87. > > > Please send a request if you would like a slot on the agenda, by > October 22, 2013. > > > Thanks. > > > > > -Chairs > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Mon Oct 21 16:17:11 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E15411E86CB for ; Mon, 21 Oct 2013 16:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cv0oI0pBY6rB for ; Mon, 21 Oct 2013 16:17:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6035A11E844F for ; Mon, 21 Oct 2013 16:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1655; q=dns/txt; s=iport; t=1382397420; x=1383607020; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=iB1xkVI10sx2VXOUxtO+fhvJzvaHuYK75Lfj8Lr/vjM=; b=jlBo1F+ANv0BDZTFfSURkWY0tVIwK2qQSMkYytV+ElSmAlvtbRH8Ft/O QfOhigsYiixZG0Xe0jRvhNbAj4Y2CZ3ttoP1pXtrKZhTXba0OiJhotpfc 3DIbfceQR//andFQm56tYBPHiVhlDdjfwrwKTl6dbPIB7x9nBY1rQd6eu s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAMW0ZVKtJXHA/2dsb2JhbABZgwc4VL1xS4EwFnSCJwEEAQEBax0BCCJLCyUCBAESCId+DbpOBI8qOIMfgQoDiQehCYMkgio X-IronPort-AV: E=Sophos;i="4.93,543,1378857600"; d="scan'208";a="274866424" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 21 Oct 2013 23:17:00 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9LNGx9R018744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 23:16:59 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.192]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 18:16:59 -0500 From: "Sri Gundavelli (sgundave)" To: "Rajeev Koodli (rkoodli)" , "cjbc@it.uc3m.es" , "netext@ietf.org" Thread-Topic: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-08.txt] Thread-Index: AQHOzrOkuYeMLy5RnkWHKmt+Jhsq3A== Date: Mon, 21 Oct 2013 23:16:59 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA81DCBF601@xmb-aln-x03.cisco.com> In-Reply-To: <7C52FDEBC843C44DBAF2CA6A30662C6D01621E63@xmb-aln-x04.cisco.com> 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.214] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3217E21FBEE8474DB0B8333609F475E9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-08.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 23:17:11 -0000 Hi Carlos/Rajeev: I agree, we did not resolve this issue one way or the other. How about the following ? We can still the keep the FMI message, its use and the text in the spec. No changes are needed. But, under the wrappers, FMI message can be a UPN message with a NR code of "FMI". So, in the format section, we point to the UPN message. Otherwise, we have to add all the considerations around security, IPSec PAD entries, IPv4 transport, ..etc and that is not there currently in the spec. May end up duplicating lot of text. Even for implementation, its additional bit of text dealing with a new message type. This has least impact on the existing text. Else, we need to revert to the prev version. Is this a reasonable way-forward ? Regards Sri On 10/21/13 3:30 PM, "Rajeev Koodli (rkoodli)" wrote: > >Hi Carlos, > > >On 10/21/13 3:24 PM, "Carlos Jes=FAs Bernardos Cano" >wrote: > >>Hi, >> >>Following the discussion during the last meeting, I've updated the >>draft. As requested by the WG, it now uses the Update Notifications for >>Proxy Mobile IPv6. > >Hmm? I don't recall any discussion on this..Perhaps I missed the >response(s) to my email. >We need to discuss this :) > >-Rajeev > > > >> >>Comments are welcome. I'd like to ask people that submitted an issue to >>the tracker to see if you are happy with the revision (and close the >>issue if that is the case). >> >>Thanks, >> >>Carlos > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From rkoodli@cisco.com Mon Oct 21 22:22:45 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F7811E8454 for ; Mon, 21 Oct 2013 22:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Esduo1viMWWx for ; Mon, 21 Oct 2013 22:22:41 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1C10011E833C for ; Mon, 21 Oct 2013 22:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2347; q=dns/txt; s=iport; t=1382419361; x=1383628961; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=NDALL0ZseFoxbUgo+FBw939XbKwYtGxRogpjLRioz7U=; b=fFuNwbyLfwGo40yZhuHBzsDiWhJphdIHBis1cKTbF10FzNJkpI+WOENf o8k3aZbrY2rsVSNfw7B0QBAeVahVWwQv2XK3r7YhLSRevJ4ifo1K4Qo+w q9omnBkalPuPq1D6nfuXaTYPll1rYUzhISt3CTA+7FDMr8JQSnc3FZfsG k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAEQLZlKtJV2d/2dsb2JhbABZgwc4VL13S4EiFnSCJQEBAQQBAQFrHQEIGApLCyUCBAESCId+DbsHBI8qOIMfgQoDiQehCYMkgio X-IronPort-AV: E=Sophos;i="4.93,546,1378857600"; d="scan'208";a="274933049" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 22 Oct 2013 05:22:39 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9M5MdFJ011402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Oct 2013 05:22:39 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 00:22:39 -0500 From: "Rajeev Koodli (rkoodli)" To: "Sri Gundavelli (sgundave)" , "cjbc@it.uc3m.es" , "netext@ietf.org" Thread-Topic: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-08.txt] Thread-Index: AQHOzqxG8NtGw8kbX0CbFNziK3IPz5n/m2kAgACCWID///DNgA== Date: Tue, 22 Oct 2013 05:22:38 +0000 Message-ID: <7C52FDEBC843C44DBAF2CA6A30662C6D01621F8F@xmb-aln-x04.cisco.com> In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA81DCBF601@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.147.132] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2EC4E522705F024D909AFB2AB8B61155@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-08.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 05:22:46 -0000 Right, we needed to discuss this before putting text - especially I saw no response to my email about this after the last IETF meeting. In particular, I am not sure about having to implement the UPN spec for one to do FM. Let's discuss what this means; may be I don't fully follow.. Perhaps Carlos could spend some time at Vancouver on this. It would help me if the following is shown with some text for the ID. I don't see what the text duplication is. If the text is there for UPN, we can re-use it. Thanks. -Rajeev On 10/21/13 4:16 PM, "Sri Gundavelli (sgundave)" wrote: >Hi Carlos/Rajeev: > >I agree, we did not resolve this issue one way or the other. > >How about the following ? > >We can still the keep the FMI message, its use and the text in the spec. >No changes are needed. But, under the wrappers, FMI message can be a UPN >message with a NR code of "FMI". So, in the format section, we point to >the UPN message. > >Otherwise, we have to add all the considerations around security, IPSec >PAD entries, IPv4 transport, ..etc and that is not there currently in the >spec. May end up duplicating lot of text. Even for implementation, its >additional bit of text dealing with a new message type. > >This has least impact on the existing text. Else, we need to revert to the >prev version. > >Is this a reasonable way-forward ? > > > > >Regards >Sri > > > > >On 10/21/13 3:30 PM, "Rajeev Koodli (rkoodli)" wrote: > >> >>Hi Carlos, >> >> >>On 10/21/13 3:24 PM, "Carlos Jes=FAs Bernardos Cano" >>wrote: >> >>>Hi, >>> >>>Following the discussion during the last meeting, I've updated the >>>draft. As requested by the WG, it now uses the Update Notifications for >>>Proxy Mobile IPv6. >> >>Hmm? I don't recall any discussion on this..Perhaps I missed the >>response(s) to my email. >>We need to discuss this :) >> >>-Rajeev >> >> >> >>> >>>Comments are welcome. I'd like to ask people that submitted an issue to >>>the tracker to see if you are happy with the revision (and close the >>>issue if that is the case). >>> >>>Thanks, >>> >>>Carlos >> >>_______________________________________________ >>netext mailing list >>netext@ietf.org >>https://www.ietf.org/mailman/listinfo/netext > From michal.hoeft@gmail.com Mon Oct 21 23:41:09 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF35F11E8482 for ; Mon, 21 Oct 2013 23:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCgM5zQor1gG for ; Mon, 21 Oct 2013 23:41:07 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABC911E847B for ; Mon, 21 Oct 2013 23:40:22 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id 10so3960097vbe.19 for ; Mon, 21 Oct 2013 23:40:22 -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=ppN+sQqm33Vv5mNfV1O0s34BcJSvCxN1qtTp/movI3c=; b=IKpZ6PzwlqemWgF2Yj+fdYRXyhuqxrOzaAMQXxXeF3o9DllMVAo4WdNj2Ygyo6tKud zUs/tjOxFjLjT/h+ZVbezMOErGDTNjQqBIOEVMbvCZnM94s6G50mAOSPrLL7VizfZZSz K6GdFTyFGgJvprkhsm6qDHh5t+7h+vEhTml41lHYBA5fWVSJOvywM3shM3bJQhQW0rbD tgDPHT6QyJFbJqEgLjwYFNX0PoPGALcOZVFv5VYIU6l9yhPmLsUnNjGfRksy/bItpOYk JTwk8OHXGhOENZvyLAAJWsql+S6t3XKc/22sdIDtM4ryu+0KA0bu62lGpAlfRxk6TtuV hBOg== MIME-Version: 1.0 X-Received: by 10.52.34.109 with SMTP id y13mr12059512vdi.8.1382424022011; Mon, 21 Oct 2013 23:40:22 -0700 (PDT) Received: by 10.52.160.9 with HTTP; Mon, 21 Oct 2013 23:40:21 -0700 (PDT) In-Reply-To: <1382306830.4098.51.camel@acorde.it.uc3m.es> References: <24C0F3E22276D9438D6F366EB89FAEA81DCB7BBA@xmb-aln-x03.cisco.com> <1382306830.4098.51.camel@acorde.it.uc3m.es> Date: Tue, 22 Oct 2013 08:40:21 +0200 Message-ID: From: =?ISO-8859-2?Q?Micha=B3_Hoeft?= To: cjbc@it.uc3m.es Content-Type: multipart/alternative; boundary=20cf30780c5cc2f78a04e94eac98 Cc: "netext@ietf.org" Subject: Re: [netext] Review: draft-ietf-netext-pd-pmip-10 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 06:41:10 -0000 --20cf30780c5cc2f78a04e94eac98 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Hi Sri, Carlos Thank you very much for answers and clarification. Now, I see your point of view. Best regards Michal 2013/10/21 Carlos Jes=FAs Bernardos Cano > Hi Sri, Michal, > > Thanks a lot Michar for your comments. > > Adding some additional comments inline below. > > On Fri, 2013-10-18 at 18:05 +0000, Sri Gundavelli (sgundave) wrote: > > Hi Michal, > > > > > > Thanks for the good review comments... some comments inline ..Carlos ca= n > > add/clarify more ... > > > > > > > > > > > > > > From: Micha=B3 Hoeft > > Date: Friday, October 18, 2013 3:23 AM > > To: "netext@ietf.org" > > Subject: [netext] Review: draft-ietf-netext-pd-pmip-10 > > > > > > > > Hello > > > > I am a researcher at Gda=F1sk University of Technology interested in > > mobility management protocols, especially in PMIPv6. I would be very > > thankful if authors of draft-ietf-netext-pd-pmip-10 could clarify my > > doubt. > > > > I wonder, why Section 3 is not more general, why only three deployment > > models are described in the draft and titled after DR location. > > It seams that, DR don't have to be co-located with LMA (Section > > 3.2.2). In this case, it can be run on an external server and it does > > not change message flow. > > > > It is similar in Section 3.2.1, in which LMA provides to DR prefixes > > by means of DMNP option. It is very interesting protocol integrating > > solution. > > > > > > [Sri] We covered the key deployment models. DR function can be on the > > located in the home network and that is typically on the LMA. It can > > be certainly outside the LMA, but there is some interworking needed > > between the DR and the LMA and is out of scope for this spec. We did > > not explicitly cover that scenario, but a deployment can certainly > > make that work. But, that has no impact on the wire protocol between > > the LMA and MAG. We can add a note that this is certainly allowed. > > Carlos - Agree ? > > > [Carlos] Yes, agree. We'll add a note in -11. > > > > > However I'm a little confused considering implementation of DR > > co-located with MAG. I can imagine a deployment model, in that DR is > > co-located with MAG but obtains prefixes using more common methods > > e.g. Delegated-IPv6-Prefix AVP (RFC 4818). Especially, if it could be > > aggregated with other MAG-to-HAAA AVPs (RFC 5779). > > > > > > [Sri] From protocol point of view, MAG can include the DMNP option, > > with ALL_ZERO or with a specific value. MAG can learn about those > > prefixes, via AAA (with DMNP AVP's), local config, DHCP interworking > > and request the same. MAG has the ability to populate the DMNP option > > with a specific prefix value, or a 0 to allow LMA to do the > > allocation. If you see the protocol section, which is more generic, > > you will see this. > > > > > > > > In my opinion, titles of Sections 3.2.1-3.2.3 should be changed to be > > more accurate and to describe MAG-LMA interaction instead of DR > > co-location. For example: > > > > 3.2.1 DMNP provided during registration > > > > 3.2.2 Separated AR and DMNP registration > > 3.2.3 Aggregated AR and DMNP registration > > > > > > [Sri] That is certainly one way to drafting and is fine. What is there > > in section 3.2.1 to 3.2.1 are more covered along the lines of popular > > deployment model, but the protocol section is more generic. The key > > point is that protocol semantic clearly allow the negotiation in a > > flexible manner covering all these variations. > > > > > > > > > > In accordance with RFC5213, PBU/PBA messages have few mandatory > > options (MNI,HNP,HI,AAT). Although some of them are easy to set (MNI > > with MNI of AR, HI with 5. Handoff state not changed, AAT depends on > > access technology - please correct me if I'm wrong), I see the problem > > with HNP in separate AD and DMNP registration scenario. In my opinion, > > it should be defined how to fill this option - either ALL_ZERO or HNP > > of AR. > > > > > > > > [Sri] Carlos can add. But, the protocol is not requiring changes to > > the base options. In all the scenarios covered by 5213, 5844, this > > allows a MAG to request a additional prefix set, for delegation, as > > supposed to hosting them on the MN-AR link. > > > > > > > [Carlos] Yes, I think it is better not to explicitly add that, so we > avoid not covering some potential case. As long as what we have in the > text is clear and allow for implementation of the spec, I think it is > better not to add more text. > > > > > > Please, consider also revision of following typos: > > > > > > page 4: > > > > is enabled is for =3D> is enabled for > > [Carlos] Fixed in -11, thanks. > > > > page 7,9: > > > > proxy binding acknowledgment =3D> Proxy Binding Acknowledgment > > proxy binding update =3D> Proxy Binding Update > > [Carlos] I think the RFC Editor prefers these terms to be in lowercase, > with the exception of the first time they appear and the acronym is > introduced. > > > > page 9. Figure 2: Message 4): > > PBU =3D>PBU(DMNP) > > [Carlos] Here the intention is to highlight that the prefix is delegated > by the LMA and conveyed back in the PBA. Maybe we can explicitly show > that the DMNP option is present but with an ALL_ZERO value. > > > > page 11: > > > > from the mobile router from registering =3D> from the mobile router for > > registering > > > [Carlos] Fixed in -11, thanks. > > > > > If you need any additional detail on my comments, please, do not > > hesitate to contact me. > > Again, thanks! > > Carlos > > > > > > Best regards > > > > Michal Hoeft > > > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > > --20cf30780c5cc2f78a04e94eac98 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable
Hi Sri, Carlos

Thank you very = much for answers and clarification. Now, I see your point of view.
Best regards
Michal


<= div class=3D"gmail_quote"> 2013/10/21 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>
=
Hi Sri, Michal,

Thanks a lot Michar for your comments.

Adding some additional comments inline below.

On Fri, 2013-10-18 at 18:05 +0000, Sri Gundavelli (sgundave) wrote:
> Hi Michal,
>
>
> Thanks for the good review comments… some comments inline ..Car= los can
> add/clarify more …
>
>
>
>
>
>
> From: Micha=B3 Hoeft <mic= hal.hoeft@gmail.com>
> Date: Friday, October 18, 2013 3:23 AM
> To: "netext@ietf.org"= <netext@ietf.org>
> Subject: [netext] Review: draft-ietf-netext-pd-pmip-10
>
>
>
> Hello
>
> I am a researcher at Gda=F1sk University of Technology interested in > mobility management protocols, especially in PMIPv6. I would be very > thankful if authors of draft-ietf-netext-pd-pmip-10 could clarify my > doubt.
>
> I wonder, why Section 3 is not more general, why only three deployment=
> models are described in the draft and titled after DR location.
> It seams that, DR don't have to be co-located with LMA (Section > 3.2.2). In this case, it can be run on an external server and it does<= br> > not change message flow.
>
> It is similar in Section 3.2.1, in which LMA provides to DR prefixes > by means of DMNP option. It is very interesting protocol integrating > solution.
>
>
> [Sri] We covered the key deployment models.  DR function can be o= n the
> located in the home network and that is typically on the LMA. It can > be certainly outside the LMA, but there is some interworking needed > between the DR and the LMA and is out of scope for this spec. We did > not explicitly cover that scenario, but a deployment can certainly
> make that work. But, that has no impact on the wire protocol between > the LMA and MAG. We can add a note that this is certainly allowed.
> Carlos – Agree ?
>
[Carlos] Yes, agree. We'll add a note in -11.
>
> >  However I'm a little confused considering implementatio= n of DR
> co-located with MAG. I can imagine a deployment model, in that DR is > co-located with MAG but obtains prefixes using more common methods
> e.g. Delegated-IPv6-Prefix AVP (RFC 4818). Especially, if it could be<= br> > aggregated with other MAG-to-HAAA AVPs (RFC 5779).
>
>
> [Sri] From protocol point of view, MAG can include the DMNP option, > with ALL_ZERO or with a specific value. MAG can learn about those
> prefixes, via AAA (with DMNP AVP's), local config, DHCP interworki= ng
> and request the same. MAG has the ability to populate the DMNP option<= br> > with a specific prefix value, or a 0 to allow LMA to do the
> allocation. If you see the protocol section, which is more generic, > you will see this.
>
>
>
> In my opinion, titles of Sections 3.2.1-3.2.3 should be changed to be<= br> > more accurate and to describe MAG-LMA interaction instead of DR
> co-location. For example:
>
> 3.2.1 DMNP provided during registration
>
> 3.2.2 Separated AR and DMNP registration
> 3.2.3 Aggregated AR and DMNP registration
>
>
> [Sri] That is certainly one way to drafting and is fine. What is there=
> in section 3.2.1 to 3.2.1 are more covered along the lines of popular<= br> > deployment model, but the protocol section is more generic. The key > point is that protocol semantic clearly allow the negotiation in  = ;a
> flexible manner covering all these variations.
>
>
>
>
> In accordance with RFC5213, PBU/PBA messages have few mandatory
> options (MNI,HNP,HI,AAT). Although some of them are easy to set (MNI > with MNI of AR, HI with 5. Handoff state not changed, AAT depends on > access technology - please correct me if I'm wrong), I see the pro= blem
> with HNP in separate AD and DMNP registration scenario. In my opinion,=
> it should be defined how to fill this option - either ALL_ZERO or HNP<= br> > of AR.
>
>
>
> [Sri] Carlos can add. But, the protocol is not requiring changes to > the base options. In all the scenarios covered by 5213, 5844, this
> allows a MAG to request a additional prefix set, for delegation, as > supposed to hosting them on the MN-AR link.
>
>
>
[Carlos] Yes, I think it is better not to explicitly add that, = so we
avoid not covering some potential case. As long as what we have in the
text is clear and allow for implementation of the spec, I think it is
better not to add more text.
>
>
> Please, consider also revision of following typos:
>
>
> page 4:
>
> is enabled is for =3D> is enabled for

[Carlos] Fixed in -11, thanks.
>
> page 7,9:
>
> proxy binding acknowledgment =3D> Proxy Binding Acknowledgment
> proxy binding update =3D> Proxy Binding Update

[Carlos] I think the RFC Editor prefers these terms to be in lowercas= e,
with the exception of the first time they appear and the acronym is
introduced.
>
> page 9. Figure 2: Message 4):
> PBU =3D>PBU(DMNP)

[Carlos] Here the intention is to highlight that the prefix is delega= ted
by the LMA and conveyed back in the PBA. Maybe we can explicitly show
that the DMNP option is present but with an ALL_ZERO value.
>
> page 11:
>
> from the mobile router from registering =3D> from the mobile router= for
> registering
>
[Carlos] Fixed in -11, thanks.

>
> If you need any additional detail on my comments, please, do not
> hesitate to contact me.

Again, thanks!

Carlos
>
>
> Best regards
>
> Michal Hoeft
>
>
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext



--20cf30780c5cc2f78a04e94eac98-- From cjbc@it.uc3m.es Tue Oct 22 00:23:06 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5670111E84BE for ; Tue, 22 Oct 2013 00:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9Dzb7LSElbU for ; Tue, 22 Oct 2013 00:23:01 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEEA11E816B for ; Tue, 22 Oct 2013 00:23:01 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9E308C35CEC; Tue, 22 Oct 2013 09:22:59 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 91D5DC34DE6; Tue, 22 Oct 2013 09:22:59 +0200 (CEST) Message-ID: <1382426579.3908.2.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Rajeev Koodli (rkoodli)" Date: Tue, 22 Oct 2013 09:22:59 +0200 In-Reply-To: <7C52FDEBC843C44DBAF2CA6A30662C6D01621F8F@xmb-aln-x04.cisco.com> References: <7C52FDEBC843C44DBAF2CA6A30662C6D01621F8F@xmb-aln-x04.cisco.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20234.005 Cc: "netext@ietf.org" Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-08.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 07:23:06 -0000 Hi Rajeev, Apologies for not replying to your first e-mail. I added the text because it was the agreement after the discussion we had on the issue tracker and during the meeting. But I agree we can spend time at Vancouver on this. Carlos On Tue, 2013-10-22 at 05:22 +0000, Rajeev Koodli (rkoodli) wrote: > Right, we needed to discuss this before putting text - especially I saw no > response to my email about this after the last IETF meeting. > > In particular, I am not sure about having to implement the UPN spec for > one to do FM. Let's discuss what this means; may be I don't fully follow.. > Perhaps Carlos could spend some time at Vancouver on this. > > It would help me if the following is shown with some text for the ID. > I don't see what the text duplication is. If the text is there for UPN, we > can re-use it. > > Thanks. > > -Rajeev > > > On 10/21/13 4:16 PM, "Sri Gundavelli (sgundave)" > wrote: > > >Hi Carlos/Rajeev: > > > >I agree, we did not resolve this issue one way or the other. > > > >How about the following ? > > > >We can still the keep the FMI message, its use and the text in the spec. > >No changes are needed. But, under the wrappers, FMI message can be a UPN > >message with a NR code of "FMI". So, in the format section, we point to > >the UPN message. > > > >Otherwise, we have to add all the considerations around security, IPSec > >PAD entries, IPv4 transport, ..etc and that is not there currently in the > >spec. May end up duplicating lot of text. Even for implementation, its > >additional bit of text dealing with a new message type. > > > >This has least impact on the existing text. Else, we need to revert to the > >prev version. > > > >Is this a reasonable way-forward ? > > > > > > > > > >Regards > >Sri > > > > > > > > > >On 10/21/13 3:30 PM, "Rajeev Koodli (rkoodli)" wrote: > > > >> > >>Hi Carlos, > >> > >> > >>On 10/21/13 3:24 PM, "Carlos Jesús Bernardos Cano" > >>wrote: > >> > >>>Hi, > >>> > >>>Following the discussion during the last meeting, I've updated the > >>>draft. As requested by the WG, it now uses the Update Notifications for > >>>Proxy Mobile IPv6. > >> > >>Hmm? I don't recall any discussion on this..Perhaps I missed the > >>response(s) to my email. > >>We need to discuss this :) > >> > >>-Rajeev > >> > >> > >> > >>> > >>>Comments are welcome. I'd like to ask people that submitted an issue to > >>>the tracker to see if you are happy with the revision (and close the > >>>issue if that is the case). > >>> > >>>Thanks, > >>> > >>>Carlos > >> > >>_______________________________________________ > >>netext mailing list > >>netext@ietf.org > >>https://www.ietf.org/mailman/listinfo/netext > > > From cjbc@it.uc3m.es Tue Oct 22 08:18:47 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B4C11E84A9 for ; Tue, 22 Oct 2013 08:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9dYJ6DPsj6X for ; Tue, 22 Oct 2013 08:18:42 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 3CED211E8494 for ; Tue, 22 Oct 2013 08:18:41 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 93728CD6A6A; Tue, 22 Oct 2013 17:18:39 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 874E6CD580D; Tue, 22 Oct 2013 17:18:39 +0200 (CEST) Message-ID: <1382455119.3908.60.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Rajeev Koodli (rkoodli)" Date: Tue, 22 Oct 2013 17:18:39 +0200 In-Reply-To: <7C52FDEBC843C44DBAF2CA6A30662C6D01621F8F@xmb-aln-x04.cisco.com> References: <7C52FDEBC843C44DBAF2CA6A30662C6D01621F8F@xmb-aln-x04.cisco.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20236.000 Cc: "netext@ietf.org" Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-08.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 15:18:47 -0000 Hi Rajeev, On Tue, 2013-10-22 at 05:22 +0000, Rajeev Koodli (rkoodli) wrote: > Right, we needed to discuss this before putting text - especially I saw no > response to my email about this after the last IETF meeting. BTW, I presented all the proposed changes that have been incorporated in -07 and -08 during the Berlin meeting (http://www.ietf.org/proceedings/87/slides/slides-87-netext-6.pdf). You are specifically pointing to issue #15, brought by Pierrick a while ago (http://trac.tools.ietf.org/wg/netext/trac/ticket/15). This was discussed before Berlin on the mailing list and I responded to the issue. I presented the proposed changes in slide 9 of my presentation and there was consensus on going for it. All the proposed changes were agreed by the WG, so as the editor of the document I simply proceeded to apply them. Regards, Carlos > > In particular, I am not sure about having to implement the UPN spec for > one to do FM. Let's discuss what this means; may be I don't fully follow.. > Perhaps Carlos could spend some time at Vancouver on this. > > It would help me if the following is shown with some text for the ID. > I don't see what the text duplication is. If the text is there for UPN, we > can re-use it. > > Thanks. > > -Rajeev > > > On 10/21/13 4:16 PM, "Sri Gundavelli (sgundave)" > wrote: > > >Hi Carlos/Rajeev: > > > >I agree, we did not resolve this issue one way or the other. > > > >How about the following ? > > > >We can still the keep the FMI message, its use and the text in the spec. > >No changes are needed. But, under the wrappers, FMI message can be a UPN > >message with a NR code of "FMI". So, in the format section, we point to > >the UPN message. > > > >Otherwise, we have to add all the considerations around security, IPSec > >PAD entries, IPv4 transport, ..etc and that is not there currently in the > >spec. May end up duplicating lot of text. Even for implementation, its > >additional bit of text dealing with a new message type. > > > >This has least impact on the existing text. Else, we need to revert to the > >prev version. > > > >Is this a reasonable way-forward ? > > > > > > > > > >Regards > >Sri > > > > > > > > > >On 10/21/13 3:30 PM, "Rajeev Koodli (rkoodli)" wrote: > > > >> > >>Hi Carlos, > >> > >> > >>On 10/21/13 3:24 PM, "Carlos Jesús Bernardos Cano" > >>wrote: > >> > >>>Hi, > >>> > >>>Following the discussion during the last meeting, I've updated the > >>>draft. As requested by the WG, it now uses the Update Notifications for > >>>Proxy Mobile IPv6. > >> > >>Hmm? I don't recall any discussion on this..Perhaps I missed the > >>response(s) to my email. > >>We need to discuss this :) > >> > >>-Rajeev > >> > >> > >> > >>> > >>>Comments are welcome. I'd like to ask people that submitted an issue to > >>>the tracker to see if you are happy with the revision (and close the > >>>issue if that is the case). > >>> > >>>Thanks, > >>> > >>>Carlos > >> > >>_______________________________________________ > >>netext mailing list > >>netext@ietf.org > >>https://www.ietf.org/mailman/listinfo/netext > > > From rkoodli@cisco.com Tue Oct 22 09:30:44 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6A411E81D7 for ; Tue, 22 Oct 2013 09:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-7UKymRdMAu for ; Tue, 22 Oct 2013 09:30:39 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 883E511E81E6 for ; Tue, 22 Oct 2013 09:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3780; q=dns/txt; s=iport; t=1382459435; x=1383669035; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+QjnCDlo9aqXoU06fQMPmiEDINkPs+qsX2KDY2vAeQA=; b=H0Qt/M4NXNSV8cIY82Gh0KhpXE0xAx6uz5NTLucDohadrBxV69JamGDw LMfv57lDmwZ9+QvMjq49c2aVCsN/5HW3AuD6TGgaStbIwd2XylkN71SV4 m1LeJteH2a8iRdU+7uKQkHv/+7wHf80bN0/Si6ornWNdAvtz1UOEP1Zf4 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4GAPKmZlKtJV2d/2dsb2JhbABZgwc4VL1+S4ElFm0HgiUBAQECAgEBAWsLEgEIGApLCyUCBA4FCAGHfQ26RY4ffAIxB4MfgQoDiQeQMZBYgySCKg X-IronPort-AV: E=Sophos;i="4.93,549,1378857600"; d="scan'208";a="275264464" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 22 Oct 2013 16:30:35 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9MGUZWe003214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Oct 2013 16:30:35 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 11:30:34 -0500 From: "Rajeev Koodli (rkoodli)" To: "cjbc@it.uc3m.es" Thread-Topic: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-08.txt] Thread-Index: AQHOzqxG8NtGw8kbX0CbFNziK3IPz5n/m2kAgACCWID///DNgIABG+OA//+eu4A= Date: Tue, 22 Oct 2013 16:30:34 +0000 Message-ID: <7C52FDEBC843C44DBAF2CA6A30662C6D0162233E@xmb-aln-x04.cisco.com> In-Reply-To: <1382455119.3908.60.camel@acorde.it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.113.66] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1BF373A8239499418FFB3C5A64A8F2FC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-08.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 16:30:44 -0000 Carlos, I raised the issue of FMI vs UPN right after the Berlin meeting. As said, I may have missed any agreement on this.. But I did not see any response to how/when this was reached (if any). Please spend some time going on this at Vancouver. Thanks. -Rajeev On 10/22/13 8:18 AM, "Carlos Jes=FAs Bernardos Cano" wrot= e: >Hi Rajeev, > >On Tue, 2013-10-22 at 05:22 +0000, Rajeev Koodli (rkoodli) wrote: >> Right, we needed to discuss this before putting text - especially I saw >>no >> response to my email about this after the last IETF meeting. > >BTW, I presented all the proposed changes that have been incorporated in >-07 and -08 during the Berlin meeting >(http://www.ietf.org/proceedings/87/slides/slides-87-netext-6.pdf). > >You are specifically pointing to issue #15, brought by Pierrick a while >ago (http://trac.tools.ietf.org/wg/netext/trac/ticket/15). This was >discussed before Berlin on the mailing list and I responded to the >issue. I presented the proposed changes in slide 9 of my presentation >and there was consensus on going for it. > >All the proposed changes were agreed by the WG, so as the editor of the >document I simply proceeded to apply them. > >Regards, > >Carlos > >>=20 >> In particular, I am not sure about having to implement the UPN spec for >> one to do FM. Let's discuss what this means; may be I don't fully >>follow.. >> Perhaps Carlos could spend some time at Vancouver on this. >>=20 >> It would help me if the following is shown with some text for the ID. >> I don't see what the text duplication is. If the text is there for UPN, >>we >> can re-use it. >>=20 >> Thanks. >>=20 >> -Rajeev >>=20 >>=20 >> On 10/21/13 4:16 PM, "Sri Gundavelli (sgundave)" >> wrote: >>=20 >> >Hi Carlos/Rajeev: >> > >> >I agree, we did not resolve this issue one way or the other. >> > >> >How about the following ? >> > >> >We can still the keep the FMI message, its use and the text in the >>spec. >> >No changes are needed. But, under the wrappers, FMI message can be a >>UPN >> >message with a NR code of "FMI". So, in the format section, we point to >> >the UPN message. >> > >> >Otherwise, we have to add all the considerations around security, IPSec >> >PAD entries, IPv4 transport, ..etc and that is not there currently in >>the >> >spec. May end up duplicating lot of text. Even for implementation, its >> >additional bit of text dealing with a new message type. >> > >> >This has least impact on the existing text. Else, we need to revert to >>the >> >prev version. >> > >> >Is this a reasonable way-forward ? >> > >> > >> > >> > >> >Regards >> >Sri >> > >> > >> > >> > >> >On 10/21/13 3:30 PM, "Rajeev Koodli (rkoodli)" >>wrote: >> > >> >> >> >>Hi Carlos, >> >> >> >> >> >>On 10/21/13 3:24 PM, "Carlos Jes=FAs Bernardos Cano" >> >>wrote: >> >> >> >>>Hi, >> >>> >> >>>Following the discussion during the last meeting, I've updated the >> >>>draft. As requested by the WG, it now uses the Update Notifications >>for >> >>>Proxy Mobile IPv6. >> >> >> >>Hmm? I don't recall any discussion on this..Perhaps I missed the >> >>response(s) to my email. >> >>We need to discuss this :) >> >> >> >>-Rajeev >> >> >> >> >> >> >> >>> >> >>>Comments are welcome. I'd like to ask people that submitted an issue >>to >> >>>the tracker to see if you are happy with the revision (and close the >> >>>issue if that is the case). >> >>> >> >>>Thanks, >> >>> >> >>>Carlos >> >> >> >>_______________________________________________ >> >>netext mailing list >> >>netext@ietf.org >> >>https://www.ietf.org/mailman/listinfo/netext >> > >>=20 > > From rpazhyan@cisco.com Tue Oct 22 13:19:24 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325CD11E8254 for ; Tue, 22 Oct 2013 13:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik1YQNCPdDZb for ; Tue, 22 Oct 2013 13:19:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 38F5C21F9A6D for ; Tue, 22 Oct 2013 13:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7155; q=dns/txt; s=iport; t=1382473159; x=1383682759; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=DQlmMO2YDcwJspnCWtmBb4eUiiJCni12K5X2ITM4r4g=; b=cmYJo72oSHKuNEw3J8xlU/1ZWo5UfcqdggDGcnIOcGeXdntzYHEHcf07 bEadudWSp8TQyQz3Rhzcb2wdAKcdEHbgiOYVQaGRtuF0FBPbYAKHLIx7h eH/4epjWSwy3Huw1oOJ0evLnIsV5NJQaF4nhlomDRhlR5trqahv0f0G4x 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMGAEzdZlKtJV2b/2dsb2JhbABZgkNEOFSsHolmiEaBKxZ0giUBAQEELVwCAQgRBAEBCx0HMhQJCAIEARIIh34NuwyPHTcBgx+BCgOZOJBYgySCKg X-IronPort-AV: E=Sophos;i="4.93,550,1378857600"; d="scan'208,217";a="275271203" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 22 Oct 2013 20:19:16 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9MKJFUc010767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Oct 2013 20:19:15 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.202]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 15:19:15 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: "Rajeev Koodli (rkoodli)" , "netext@ietf.org" Thread-Topic: [netext] Soliciting Agenda Items for IETF88 Thread-Index: AQHOzFU1xQg/Uz1btUmVC9VAdR2YJZoBIzaQ Date: Tue, 22 Oct 2013 20:19:14 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320ECE1F4@xmb-aln-x09.cisco.com> References: <7C52FDEBC843C44DBAF2CA6A30662C6D0162181B@xmb-aln-x04.cisco.com> In-Reply-To: <7C52FDEBC843C44DBAF2CA6A30662C6D0162181B@xmb-aln-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.92.218] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320ECE1F4xmbalnx09ciscoc_" MIME-Version: 1.0 Subject: Re: [netext] Soliciting Agenda Items for IETF88 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 20:19:24 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320ECE1F4xmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello I would like to request a 10 min slot in the meeting to provide an overview= of Civic Location ANI Suboption for PMIPv6 draft-pazhyannur-netext-civic-location-ani-subopt-00 thanks regards Rajesh From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= Rajeev Koodli (rkoodli) Sent: Friday, October 18, 2013 3:56 PM To: netext@ietf.org Subject: [netext] Soliciting Agenda Items for IETF88 Hello, We have a 2 hour slot allocated for the WG meeting at IETF87. Please send a request if you would like a slot on the agenda, by October 22= , 2013. Thanks. -Chairs --_000_4ED2E36A22261145861BAB2C24088B4320ECE1F4xmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello

 

I would like to request a 10 min slot in t= he meeting to provide an overview of Civic Location ANI Subopti= on for PMIPv6

dr= aft-pazhyannur-netext-civic-location-ani-subopt-00

 

thanks

 

regards

 

Rajesh

From: netext-b= ounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Rajeev Koodli (rkoodli)
Sent: Friday, October 18, 2013 3:56 PM
To: netext@ietf.org
Subject: [netext] Soliciting Agenda Items for IETF88

 

 

Hello,

 

We have a 2 hour slot alloc= ated for the WG meeting at IETF87.

 

Please send a request if yo= u would like a slot on the agenda, by October 22, 2013.

 

Thanks.

 

 

-Chairs

 

--_000_4ED2E36A22261145861BAB2C24088B4320ECE1F4xmbalnx09ciscoc_-- From sarikaya2012@gmail.com Tue Oct 22 13:54:22 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A13711E8245 for ; Tue, 22 Oct 2013 13:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FA1lKQUB3Mgv for ; Tue, 22 Oct 2013 13:54:20 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1040D11E81CD for ; Tue, 22 Oct 2013 13:54:19 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id w7so22568lbi.4 for ; Tue, 22 Oct 2013 13:54:19 -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=AJBKdeiBZFXfHebYgrQiKa9PdD1fyeWX9DAv6ku9f0E=; b=GgWn0BwI/MraUDoIfAbKrytW4pCvkanQakgPXHEYEXYjkPeGQyAuf1Mbwg9HrT1myL bocHIpxUN1cpMvbQel+hGwJWU54arcNOTJgmVmXnx81ue5vhsYPz3c7PzKCRWsXM8ukT OmYLvWkwqprIiVGsQyFsU5ohiwFEIUShMMvA4HOtREVCrjuaU2Hw5lbDuDMoyvxD+jmo kvIGV7C5lW9E+mcXzNyHOGo8WMpn9nvB18m8l3YZJZKMigC+TR4WKngFyHLOr2wt6nsl XtMeAuPiFwdaSieITVQXyWv7GDKw2BJw9PwtOx55/0J4TUpWKYXrxRhqGKryaSRtjBLw CVrg== MIME-Version: 1.0 X-Received: by 10.112.155.70 with SMTP id vu6mr2943694lbb.41.1382475258987; Tue, 22 Oct 2013 13:54:18 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Tue, 22 Oct 2013 13:54:18 -0700 (PDT) In-Reply-To: <7C52FDEBC843C44DBAF2CA6A30662C6D0162233E@xmb-aln-x04.cisco.com> References: <1382455119.3908.60.camel@acorde.it.uc3m.es> <7C52FDEBC843C44DBAF2CA6A30662C6D0162233E@xmb-aln-x04.cisco.com> Date: Tue, 22 Oct 2013 15:54:18 -0500 Message-ID: From: Behcet Sarikaya To: "Rajeev Koodli (rkoodli)" Content-Type: multipart/alternative; boundary=089e0115fe1eb90bf004e95a9a18 Cc: "netext@ietf.org" Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-08.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 20:54:22 -0000 --089e0115fe1eb90bf004e95a9a18 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Carlos, In addition to what Rajeev said, I had many comments. In fact I don't remember at all any comment that asked to remove FM messages :-). What happened to those comments? Regards, Behcet On Tue, Oct 22, 2013 at 11:30 AM, Rajeev Koodli (rkoodli) wrote: > > Carlos, > > I raised the issue of FMI vs UPN right after the Berlin meeting. > As said, I may have missed any agreement on this.. But I did not see any > response to how/when this was reached (if any). > > Please spend some time going on this at Vancouver. > > Thanks. > > -Rajeev > > > On 10/22/13 8:18 AM, "Carlos Jes=FAs Bernardos Cano" > wrote: > > >Hi Rajeev, > > > >On Tue, 2013-10-22 at 05:22 +0000, Rajeev Koodli (rkoodli) wrote: > >> Right, we needed to discuss this before putting text - especially I sa= w > >>no > >> response to my email about this after the last IETF meeting. > > > >BTW, I presented all the proposed changes that have been incorporated in > >-07 and -08 during the Berlin meeting > >(http://www.ietf.org/proceedings/87/slides/slides-87-netext-6.pdf). > > > >You are specifically pointing to issue #15, brought by Pierrick a while > >ago (http://trac.tools.ietf.org/wg/netext/trac/ticket/15). This was > >discussed before Berlin on the mailing list and I responded to the > >issue. I presented the proposed changes in slide 9 of my presentation > >and there was consensus on going for it. > > > >All the proposed changes were agreed by the WG, so as the editor of the > >document I simply proceeded to apply them. > > > >Regards, > > > >Carlos > > > >> > >> In particular, I am not sure about having to implement the UPN spec fo= r > >> one to do FM. Let's discuss what this means; may be I don't fully > >>follow.. > >> Perhaps Carlos could spend some time at Vancouver on this. > >> > >> It would help me if the following is shown with some text for the ID. > >> I don't see what the text duplication is. If the text is there for UPN= , > >>we > >> can re-use it. > >> > >> Thanks. > >> > >> -Rajeev > >> > >> > >> On 10/21/13 4:16 PM, "Sri Gundavelli (sgundave)" > >> wrote: > >> > >> >Hi Carlos/Rajeev: > >> > > >> >I agree, we did not resolve this issue one way or the other. > >> > > >> >How about the following ? > >> > > >> >We can still the keep the FMI message, its use and the text in the > >>spec. > >> >No changes are needed. But, under the wrappers, FMI message can be a > >>UPN > >> >message with a NR code of "FMI". So, in the format section, we point = to > >> >the UPN message. > >> > > >> >Otherwise, we have to add all the considerations around security, IPS= ec > >> >PAD entries, IPv4 transport, ..etc and that is not there currently in > >>the > >> >spec. May end up duplicating lot of text. Even for implementation, it= s > >> >additional bit of text dealing with a new message type. > >> > > >> >This has least impact on the existing text. Else, we need to revert t= o > >>the > >> >prev version. > >> > > >> >Is this a reasonable way-forward ? > >> > > >> > > >> > > >> > > >> >Regards > >> >Sri > >> > > >> > > >> > > >> > > >> >On 10/21/13 3:30 PM, "Rajeev Koodli (rkoodli)" > >>wrote: > >> > > >> >> > >> >>Hi Carlos, > >> >> > >> >> > >> >>On 10/21/13 3:24 PM, "Carlos Jes=FAs Bernardos Cano" > >> >>wrote: > >> >> > >> >>>Hi, > >> >>> > >> >>>Following the discussion during the last meeting, I've updated the > >> >>>draft. As requested by the WG, it now uses the Update Notifications > >>for > >> >>>Proxy Mobile IPv6. > >> >> > >> >>Hmm? I don't recall any discussion on this..Perhaps I missed the > >> >>response(s) to my email. > >> >>We need to discuss this :) > >> >> > >> >>-Rajeev > >> >> > >> >> > >> >> > >> >>> > >> >>>Comments are welcome. I'd like to ask people that submitted an issu= e > >>to > >> >>>the tracker to see if you are happy with the revision (and close th= e > >> >>>issue if that is the case). > >> >>> > >> >>>Thanks, > >> >>> > >> >>>Carlos > >> >> > >> >>_______________________________________________ > >> >>netext mailing list > >> >>netext@ietf.org > >> >>https://www.ietf.org/mailman/listinfo/netext > >> > > >> > > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --089e0115fe1eb90bf004e95a9a18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Carlos,

In addition = to what Rajeev said, I had many comments.

In fact I don't = remember at all any comment that asked to remove FM messages :-).

What happened to those comments?

Regards,

Behcet<= br>


On T= ue, Oct 22, 2013 at 11:30 AM, Rajeev Koodli (rkoodli) <= ;rkoodli@cisco.com> wrote:

Carlos,

I raised the issue of FMI vs UPN right after the Berlin meeting.
As said, I may have missed any agreement on this.. But I did not see any response to how/when this was reached (if any).

Please spend some time going on this at Vancouver.

Thanks.

-Rajeev


On 10/22/13 8:18 AM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.es> wrote:

>Hi Rajeev,
>
>On Tue, 2013-10-22 at 05:22 +0000, Rajeev Koodli (rkoodli) wrote:
>> Right, we needed to discuss this before putting text - especially = I saw
>>no
>> response to my email about this after the last IETF meeting.
>
>BTW, I presented all the proposed changes that have been incorporated i= n
>-07 and -08 during the Berlin meeting
>(http://www.ietf.org/proceedings/87/slides/slides-8= 7-netext-6.pdf).
>
>You are specifically pointing to issue #15, brought by Pierrick a while=
>ago (http://trac.tools.ietf.org/wg/netext/trac/ticket/15). T= his was
>discussed before Berlin on the mailing list and I responded to the
>issue. I presented the proposed changes in slide 9 of my presentation >and there was consensus on going for it.
>
>All the proposed changes were agreed by the WG, so as the editor of the=
>document I simply proceeded to apply them.
>
>Regards,
>
>Carlos
>
>>
>> In particular, I am not sure about having to implement the UPN spe= c for
>> one to do FM. Let's discuss what this means; may be I don'= t fully
>>follow..
>> Perhaps Carlos could spend some time at Vancouver on this.
>>
>> It would help me if the following is shown with some text for the = ID.
>> I don't see what the text duplication is. If the text is there= for UPN,
>>we
>> can re-use it.
>>
>> Thanks.
>>
>> -Rajeev
>>
>>
>> On 10/21/13 4:16 PM, "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
>> wrote:
>>
>> >Hi Carlos/Rajeev:
>> >
>> >I agree, we did not resolve this issue one way or the other. >> >
>> >How about the following ?
>> >
>> >We can still the keep the FMI message, its use and the text in= the
>>spec.
>> >No changes are needed. =A0But, under the wrappers, FMI message= can be a
>>UPN
>> >message with a NR code of "FMI". So, in the format s= ection, we point to
>> >the UPN message.
>> >
>> >Otherwise, we have to add all the considerations around securi= ty, IPSec
>> >PAD entries, IPv4 transport, ..etc and that is not there curre= ntly in
>>the
>> >spec. May end up duplicating lot of text. Even for implementat= ion, its
>> >additional bit of text dealing with a new message type.
>> >
>> >This has least impact on the existing text. Else, we need to r= evert to
>>the
>> >prev version.
>> >
>> >Is this a reasonable way-forward ?
>> >
>> >
>> >
>> >
>> >Regards
>> >Sri
>> >
>> >
>> >
>> >
>> >On 10/21/13 3:30 PM, "Rajeev Koodli (rkoodli)" <<= a href=3D"mailto:rkoodli@cisco.com">rkoodli@cisco.com>
>>wrote:
>> >
>> >>
>> >>Hi Carlos,
>> >>
>> >>
>> >>On 10/21/13 3:24 PM, "Carlos Jes=FAs Bernardos Cano&q= uot; <cjbc@it.uc3m.es>
>> >>wrote:
>> >>
>> >>>Hi,
>> >>>
>> >>>Following the discussion during the last meeting, I= 9;ve updated the
>> >>>draft. As requested by the WG, it now uses the Update = Notifications
>>for
>> >>>Proxy Mobile IPv6.
>> >>
>> >>Hmm? I don't recall any discussion on this..Perhaps I = missed the
>> >>response(s) to my email.
>> >>We need to discuss this :)
>> >>
>> >>-Rajeev
>> >>
>> >>
>> >>
>> >>>
>> >>>Comments are welcome. I'd like to ask people that = submitted an issue
>>to
>> >>>the tracker to see if you are happy with the revision = (and close the
>> >>>issue if that is the case).
>> >>>
>> >>>Thanks,
>> >>>
>> >>>Carlos
>> >>
>> >>_______________________________________________
>> >>netext mailing list
>> >>netext@ietf.org
>> >>https://www.ietf.org/mailman/listinfo/netext
>> >
>>
>
>

_______________________________________________
netext mailing list
netext@ietf.org
= https://www.ietf.org/mailman/listinfo/netext

--089e0115fe1eb90bf004e95a9a18-- From cjbc@it.uc3m.es Tue Oct 22 14:43:40 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18F511E81FD for ; Tue, 22 Oct 2013 14:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy8bA2QgDozs for ; Tue, 22 Oct 2013 14:43:35 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id C8B9B11E81F2 for ; Tue, 22 Oct 2013 14:43:28 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D9BE2CD6BE1; Tue, 22 Oct 2013 23:43:15 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [192.168.1.190] (82.158.201.225.dyn.user.ono.com [82.158.201.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 96F6FCD6AB8; Tue, 22 Oct 2013 23:43:15 +0200 (CEST) Message-ID: <1382478194.4277.3.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: sarikaya@ieee.org Date: Tue, 22 Oct 2013 23:43:14 +0200 In-Reply-To: References: <1382455119.3908.60.camel@acorde.it.uc3m.es> <7C52FDEBC843C44DBAF2CA6A30662C6D0162233E@xmb-aln-x04.cisco.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20236.002 Cc: "netext@ietf.org" Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-08.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 21:43:40 -0000 Hi Behcet, Your comments were also discussed during the meeting and on the mailing list. I've edited the draft according to the WG consensus. Please, check the new version of the draft, and if you have new comments/issues, bring them up to the WG. Thanks! Carlos On Tue, 2013-10-22 at 15:54 -0500, Behcet Sarikaya wrote: > Carlos, > > > In addition to what Rajeev said, I had many comments. > > > In fact I don't remember at all any comment that asked to remove FM > messages :-). > > > What happened to those comments? > > > Regards, > > > Behcet > > > > On Tue, Oct 22, 2013 at 11:30 AM, Rajeev Koodli (rkoodli) > wrote: > > Carlos, > > I raised the issue of FMI vs UPN right after the Berlin > meeting. > As said, I may have missed any agreement on this.. But I did > not see any > response to how/when this was reached (if any). > > Please spend some time going on this at Vancouver. > > Thanks. > > -Rajeev > > > On 10/22/13 8:18 AM, "Carlos Jesús Bernardos Cano" > wrote: > > >Hi Rajeev, > > > >On Tue, 2013-10-22 at 05:22 +0000, Rajeev Koodli (rkoodli) > wrote: > >> Right, we needed to discuss this before putting text - > especially I saw > >>no > >> response to my email about this after the last IETF > meeting. > > > >BTW, I presented all the proposed changes that have been > incorporated in > >-07 and -08 during the Berlin meeting > >(http://www.ietf.org/proceedings/87/slides/slides-87-netext-6.pdf). > > > >You are specifically pointing to issue #15, brought by > Pierrick a while > >ago (http://trac.tools.ietf.org/wg/netext/trac/ticket/15). > This was > >discussed before Berlin on the mailing list and I responded > to the > >issue. I presented the proposed changes in slide 9 of my > presentation > >and there was consensus on going for it. > > > >All the proposed changes were agreed by the WG, so as the > editor of the > >document I simply proceeded to apply them. > > > >Regards, > > > >Carlos > > > >> > >> In particular, I am not sure about having to implement the > UPN spec for > >> one to do FM. Let's discuss what this means; may be I don't > fully > >>follow.. > >> Perhaps Carlos could spend some time at Vancouver on this. > >> > >> It would help me if the following is shown with some text > for the ID. > >> I don't see what the text duplication is. If the text is > there for UPN, > >>we > >> can re-use it. > >> > >> Thanks. > >> > >> -Rajeev > >> > >> > >> On 10/21/13 4:16 PM, "Sri Gundavelli (sgundave)" > > >> wrote: > >> > >> >Hi Carlos/Rajeev: > >> > > >> >I agree, we did not resolve this issue one way or the > other. > >> > > >> >How about the following ? > >> > > >> >We can still the keep the FMI message, its use and the > text in the > >>spec. > >> >No changes are needed. But, under the wrappers, FMI > message can be a > >>UPN > >> >message with a NR code of "FMI". So, in the format > section, we point to > >> >the UPN message. > >> > > >> >Otherwise, we have to add all the considerations around > security, IPSec > >> >PAD entries, IPv4 transport, ..etc and that is not there > currently in > >>the > >> >spec. May end up duplicating lot of text. Even for > implementation, its > >> >additional bit of text dealing with a new message type. > >> > > >> >This has least impact on the existing text. Else, we need > to revert to > >>the > >> >prev version. > >> > > >> >Is this a reasonable way-forward ? > >> > > >> > > >> > > >> > > >> >Regards > >> >Sri > >> > > >> > > >> > > >> > > >> >On 10/21/13 3:30 PM, "Rajeev Koodli (rkoodli)" > > >>wrote: > >> > > >> >> > >> >>Hi Carlos, > >> >> > >> >> > >> >>On 10/21/13 3:24 PM, "Carlos Jesús Bernardos Cano" > > >> >>wrote: > >> >> > >> >>>Hi, > >> >>> > >> >>>Following the discussion during the last meeting, I've > updated the > >> >>>draft. As requested by the WG, it now uses the Update > Notifications > >>for > >> >>>Proxy Mobile IPv6. > >> >> > >> >>Hmm? I don't recall any discussion on this..Perhaps I > missed the > >> >>response(s) to my email. > >> >>We need to discuss this :) > >> >> > >> >>-Rajeev > >> >> > >> >> > >> >> > >> >>> > >> >>>Comments are welcome. I'd like to ask people that > submitted an issue > >>to > >> >>>the tracker to see if you are happy with the revision > (and close the > >> >>>issue if that is the case). > >> >>> > >> >>>Thanks, > >> >>> > >> >>>Carlos > >> >> > >> >>_______________________________________________ > >> >>netext mailing list > >> >>netext@ietf.org > >> >>https://www.ietf.org/mailman/listinfo/netext > >> > > >> > > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > From bpatil1@gmail.com Thu Oct 24 07:10:46 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B1011E821C for ; Thu, 24 Oct 2013 07:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV9UKn4FLt9v for ; Thu, 24 Oct 2013 07:10:45 -0700 (PDT) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E205221F9DBD for ; Thu, 24 Oct 2013 07:10:30 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id l20so2418338oag.17 for ; Thu, 24 Oct 2013 07:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bktGwg3eK8nukuyEawJgi0oXIFQqp8WJw1/ZFmiHYWE=; b=grgSGXyZiYj1nR5tJo+ICGOPmxEU6olvZxg2+zwFbjY9Wei1QVlfcxunr6kvMeQZaQ sqgGMQ/vNWksUW58x/qQYSkCoGNVGNVcVaQHoYUskRjzH5/R6Um9XaLxaGGkuONYUh17 s+XVMbHJz9z6qvWZALFnWRq0GOjabT8krWRXLfVfgZEPh3Mmj+ljXF8Xq6QMCULjJ9bf OwOwgihSG9bmmP6elzw/Jedg3pwU0r2eChjSjHJ/5xxPWLi2Tgly3CWMhEaae4oRmiSA 2+rshysvXTX8DMISy8K89s9wJbQ/lgnq5KKfm8mwN5Y1xeJ/KqkYA+vaVHUf1iWLbsY0 qExA== MIME-Version: 1.0 X-Received: by 10.182.135.194 with SMTP id pu2mr2416442obb.38.1382623830463; Thu, 24 Oct 2013 07:10:30 -0700 (PDT) Received: by 10.182.16.226 with HTTP; Thu, 24 Oct 2013 07:10:30 -0700 (PDT) Date: Thu, 24 Oct 2013 09:10:30 -0500 Message-ID: From: Basavaraj Patil To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=089e0122a6c045da4d04e97d327d Subject: [netext] WG meeting agenda for IETF88 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 14:10:46 -0000 --089e0122a6c045da4d04e97d327d Content-Type: text/plain; charset=ISO-8859-1 Rev: 0 Network-Based Mobility Extensions (NetExt) WG meeting MONDAY, November 4, 2013 1740-1940 Afternoon Session III ----------------------------------------------------------------- 1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mins 2. WG Status update Chairs 5 Mins 3. Proxy Mobile IPv6 Extensions to Support Flow Mobility 15 Mins draft-ietf-netext-pmipv6-flowmob-08 Carlos B. 4. Civic Location ANI Suboption for PMIPv 10 Mins draft-pazhyannur-netext-civic-location-ani-subopt-00 Rajesh P. 5. Mapping Wi-Fi QoS in a PMIPv6 Mobility Domain 15 Mins draft-kaippallimalil-netext-pmip-qos-wifi-03 John K. 6. EAP Attributes for WiFi - EPC Integration 10 Mins draft-ietf-netext-wifi-epc-eap-attributes-04 Rajeev K. 7. Summary and Next Steps 5 Mins Chairs -- Basavaraj Patil --089e0122a6c045da4d04e97d327d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Rev: 0

Network-Based Mobilit= y Extensions (NetExt) WG meeting

MONDAY, November = 4, 2013
1740-1940 =A0Afternoon Session III


------------------------------------------------------------= -----

1. Logistics (Bluesheets, minutes takers, ja= bber, agenda bashing) 5 mins

2. WG Status update =A0Chairs =A0 =A05 Mins

3. Proxy Mobile IPv6 Extensions to Support Flow Mobilit= y 15 Mins
=A0 =A0draft-ietf-netext-pmipv6-flowmob-08 =A0 =A0 Carl= os B.=A0

4. Civic Location ANI Suboption for PMIPv= =A0 =A010 Mins
=A0 =A0draft-pazhyannur-netext-civic-location-ani-subopt-00 =A0Rajesh = P.

5. Mapping Wi-Fi QoS in a PMIPv6 Mobility Domai= n =A0 15 Mins
=A0 =A0draft-kaippallimalil-netext-pmip-qos-wifi-03= =A0 John K.

6. EAP Attributes for WiFi - EPC Integration =A0 =A0 10= Mins
=A0 =A0draft-ietf-netext-wifi-epc-eap-attributes-04 =A0 Raj= eev K.

7. Summary and Next Steps 5 Mins Chairs


--
Basavaraj Patil
--089e0122a6c045da4d04e97d327d-- From rkoodli@cisco.com Thu Oct 31 12:44:08 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B64311E8195 for ; Thu, 31 Oct 2013 12:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.766 X-Spam-Level: X-Spam-Status: No, score=-109.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzl+v1+D9Jd7 for ; Thu, 31 Oct 2013 12:43:58 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A1CEC11E8192 for ; Thu, 31 Oct 2013 12:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4787; q=dns/txt; s=iport; t=1383248635; x=1384458235; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=vY7j1SxNrDZbAUWj/xH2Hg01yu6zaRxJVlenOHIHDNw=; b=JDD78HR58jGPh8e4W6gLoHMmhzEB28fDaTarevgBnPURWuo4lPjlXKAK UCbsx6rdDwZwkV4RrSwAlzRUf4pqGGuJpxvCe8v7naFb3D76+dacnQhOj xObpahuj6bTwc2jd+T5RNNuPV5g0+SctWL+sq+zrMMFigBt2/0lytcgpe Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoGAKWxclKtJXHA/2dsb2JhbABZgkNEgQy/aoEoFm0HgiUBAQEEgQsBCAQNAwECCx0oERQJCAIEEwiHbQMPmxmXZg2Ja4xfgj8gGIMggQ4Dlh+OPYU3gyaCKg X-IronPort-AV: E=Sophos;i="4.93,611,1378857600"; d="scan'208,217";a="279203668" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 31 Oct 2013 19:43:55 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9VJhrop025663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 31 Oct 2013 19:43:53 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 31 Oct 2013 14:43:53 -0500 From: "Rajeev Koodli (rkoodli)" To: "netext@ietf.org" Thread-Topic: [netext] WG meeting agenda for IETF88 Thread-Index: AQHO0MLYyx+2K3XiBUefz90RmNgIj5oPH/+A Date: Thu, 31 Oct 2013 19:43:53 +0000 Message-ID: <7C52FDEBC843C44DBAF2CA6A30662C6D01625F44@xmb-aln-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.93.199] Content-Type: multipart/alternative; boundary="_000_7C52FDEBC843C44DBAF2CA6A30662C6D01625F44xmbalnx04ciscoc_" MIME-Version: 1.0 Subject: Re: [netext] WG meeting agenda for IETF88 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 19:44:09 -0000 --_000_7C52FDEBC843C44DBAF2CA6A30662C6D01625F44xmbalnx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Presenters: Please send your presentations to the chairs by Sunday 5pm. Thanks. -Rajeev From: Basavaraj Patil > Date: Thursday, October 24, 2013 7:10 AM To: "netext@ietf.org" > Subject: [netext] WG meeting agenda for IETF88 Rev: 0 Network-Based Mobility Extensions (NetExt) WG meeting MONDAY, November 4, 2013 1740-1940 Afternoon Session III ----------------------------------------------------------------- 1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mins 2. WG Status update Chairs 5 Mins 3. Proxy Mobile IPv6 Extensions to Support Flow Mobility 15 Mins draft-ietf-netext-pmipv6-flowmob-08 Carlos B. 4. Civic Location ANI Suboption for PMIPv 10 Mins draft-pazhyannur-netext-civic-location-ani-subopt-00 Rajesh P. 5. Mapping Wi-Fi QoS in a PMIPv6 Mobility Domain 15 Mins draft-kaippallimalil-netext-pmip-qos-wifi-03 John K. 6. EAP Attributes for WiFi - EPC Integration 10 Mins draft-ietf-netext-wifi-epc-eap-attributes-04 Rajeev K. 7. Summary and Next Steps 5 MinsChairs -- Basavaraj Patil --_000_7C52FDEBC843C44DBAF2CA6A30662C6D01625F44xmbalnx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Presenters: Please send your presentations to the chairs by Sunday 5pm= .

Thanks.

-Rajeev


From: Basavaraj Patil <bpatil1@gmail.com>
Date: Thursday, October 24, 2013 7:= 10 AM
To: "netext@ietf.org" <= netext@ietf.org>
Subject: [netext] WG meeting agenda= for IETF88

Rev: 0

Network-Based Mobility Extensions (NetExt) WG meeting

MONDAY, November 4, 2013
1740-1940  Afternoon Session III


-----------------------------------------------------------------

1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mi= ns

2. WG Status update =  Chairs   = 5 Mins

3. Proxy Mobile IPv6 Extensions to Support Flow Mobility 15 Mins
   draft-ietf-netext-pmipv6-flowmob-08     Carlos = B. 

4. Civic Location ANI Suboption for PMIPv   10 Mins
   draft-pazhyannur-netext-civic-location-ani-subopt-00 &nbs= p;Rajesh P.

5. Mapping Wi-Fi QoS in a PMIPv6 Mobility Domain   15 Mins
   draft-kaippallimalil-netext-pmip-qos-wifi-03   John = K.

6. EAP Attributes for WiFi - EPC Integration     10 Mins
   draft-ietf-netext-wifi-epc-eap-attributes-04   Rajee= v K.

7. Summary and Next Steps <= /span>5 MinsChairs


--
Basavaraj Patil
--_000_7C52FDEBC843C44DBAF2CA6A30662C6D01625F44xmbalnx04ciscoc_--