From ietf@meetecho.com Thu Aug 1 02:07: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 9C5DC21F9F8E for ; Thu, 1 Aug 2013 02:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.022 X-Spam-Level: * X-Spam-Status: No, score=1.022 tagged_above=-999 required=5 tests=[AWL=-0.859, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 0Z4xmBArJaHZ for ; Thu, 1 Aug 2013 02:07:16 -0700 (PDT) Received: from smtpdg6.aruba.it (smtpdg224.aruba.it [62.149.158.224]) by ietfa.amsl.com (Postfix) with ESMTP id B3F8E21F9BC2 for ; Thu, 1 Aug 2013 02:06:43 -0700 (PDT) Received: from dell-tcastaldi ([130.129.65.11]) by smtpcmd02.ad.aruba.it with bizsmtp id 7M6i1m00u0EaGCq01M6jDb; Thu, 01 Aug 2013 11:06:43 +0200 Date: Thu, 1 Aug 2013 11:06:40 +0200 (CEST) From: Meetecho Team To: netext@ietf.org Message-ID: <403097963.25.1375348000874.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_24_1206330470.1375348000872" Subject: [netext] NETEXT session recording available 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, 01 Aug 2013 09:07:24 -0000 ------=_Part_24_1206330470.1375348000872 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the NETEXT WG session at IETF 87 is available at the following URL: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#NETEXT For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_24_1206330470.1375348000872-- From brian@innovationslab.net Wed Aug 14 13:17:33 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 6185511E8118 for ; Wed, 14 Aug 2013 13:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 Ka8L4EEufR4f for ; Wed, 14 Aug 2013 13:17:27 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 35E1A21E80D6 for ; Wed, 14 Aug 2013 13:17:27 -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 DCFCA880A9; Wed, 14 Aug 2013 13:17:26 -0700 (PDT) Received: from clemson.local (c-69-140-213-249.hsd1.md.comcast.net [69.140.213.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 806FA130003; Wed, 14 Aug 2013 13:17:26 -0700 (PDT) Message-ID: <520BE5D5.7030801@innovationslab.net> Date: Wed, 14 Aug 2013 16:17:25 -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: draft-ietf-netext-pd-pmip@tools.ietf.org, "netext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [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: Wed, 14 Aug 2013 20:17:33 -0000 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. 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. 1. In the Abstract, mention that prefix delegation is being described in relation to DHCPv6-PD 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. 3. Figures 2-4 are never referenced in the text. 4. Intro uses MAG without expansion or definition. 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. 6. How do the definitions in section 2 relate to the definitions in RFC 4885? 7. Section 3.1 - any additional assumptions about how an MR knows which interface to use when making DHCPv6 requests? 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. 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? 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? 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? 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? 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? 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? Regards, Brian From cjbc@it.uc3m.es Wed Aug 14 18:39: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 4CE1D21E8056 for ; Wed, 14 Aug 2013 18:39:01 -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 cUEuCQMThvRI for ; Wed, 14 Aug 2013 18:38:55 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 1A72711E80E0 for ; Wed, 14 Aug 2013 18:38:54 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AC940CD5373; Thu, 15 Aug 2013 03:38:53 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.203.119] (unknown [163.117.203.119]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id F26CECD52B2; Thu, 15 Aug 2013 03:38:52 +0200 (CEST) Message-ID: <1376530727.4277.1.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Brian Haberman Date: Thu, 15 Aug 2013 03:38:47 +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-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20082.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: Thu, 15 Aug 2013 01:39:02 -0000 Hi Brian, Thanks a lot for the review. We'll come back to you with our responses & comments, and a revised version of the I-D for the WG to check soon. Thanks, Carlos 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. > > 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. > > > 1. In the Abstract, mention that prefix delegation is being described in > relation to DHCPv6-PD > > 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. > > 3. Figures 2-4 are never referenced in the text. > > 4. Intro uses MAG without expansion or definition. > > 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. > > 6. How do the definitions in section 2 relate to the definitions in RFC > 4885? > > 7. Section 3.1 - any additional assumptions about how an MR knows which > interface to use when making DHCPv6 requests? > > 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. > > 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? > > 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? > > 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? > > 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? > > 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? > > 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? > > > Regards, > Brian From internet-drafts@ietf.org Wed Aug 14 22:59: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 D5B0421F9A78; Wed, 14 Aug 2013 22:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, 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 XZlnHBjYTENS; Wed, 14 Aug 2013 22:59:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2845B21F99F4; Wed, 14 Aug 2013 22:59:40 -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.70.p1 Message-ID: <20130815055940.11829.36881.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 22:59:40 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-update-notifications-06.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, 15 Aug 2013 05:59:41 -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-06.txt Pages : 18 Date : 2013-08-14 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-update-notifications-06 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 Wed Aug 14 22:59:41 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 4155621F9A04 for ; Wed, 14 Aug 2013 22:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, 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 JZXpnJHd-ZsT; Wed, 14 Aug 2013 22:59:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F1621F9A19; Wed, 14 Aug 2013 22:59:40 -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.70.p1 Message-ID: <20130815055940.11829.94483.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 22:59:40 -0700 Subject: [netext] New Version Notification - draft-ietf-netext-update-notifications-06.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, 15 Aug 2013 05:59:41 -0000 A new version (-06) has been submitted for draft-ietf-netext-update-notific= ations: http://www.ietf.org/internet-drafts/draft-ietf-netext-update-notifications-= 06.txt Sub state has been changed to AD Followup from Revised ID Needed 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-06 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 sgundave@cisco.com Wed Aug 14 23:09: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 AA89A21F8FCE for ; Wed, 14 Aug 2013 23:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 8n7jFp3n61lx for ; Wed, 14 Aug 2013 23:09:37 -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 B0FF621F8E40 for ; Wed, 14 Aug 2013 23:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3661; q=dns/txt; s=iport; t=1376546976; x=1377756576; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=NWw6LH/0xlNo7plXGlHVymCNiwRJrhH+ZIvDDbU7xLs=; b=Y2b0PG2EwYnCnZZsPk0FNW8H4cqBkkeLlS5sECCDvs8kSTmF72at/6lZ vNU0wk4JdUevJ1YMNR2tTQoMFslyoxZXws46NqPYgXwk666qi6ZWcuRE+ ZqJR/vTZRUlvFKnnBjz2YLylC+J3clS7rsxAE24Hich8m+FHCmqULNTmO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAFJwDFKtJXHB/2dsb2JhbABbgwaBBb8LgR8WdIIkAQEBAQM6PQISAQgYChRCJQIEDgUIiAi6AZAdAjEHgxt3A6k2gxuBaAc7 X-IronPort-AV: E=Sophos;i="4.89,882,1367971200"; d="scan'208";a="247565665" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 15 Aug 2013 06:09:33 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7F69XdG008230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Aug 2013 06:09:33 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 15 Aug 2013 01:09:32 -0500 From: "Sri Gundavelli (sgundave)" To: Brian Haberman Thread-Topic: [netext] Fwd: AD Evaluation : draft-ietf-netext-update-notifications Thread-Index: AQHOmX4CvKHqCux6oE2mcSkhuTXL9g== Date: Thu, 15 Aug 2013 06:09:32 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA8103FDA1B@xmb-aln-x03.cisco.com> In-Reply-To: <51F61D33.6070408@innovationslab.net> 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.210] Content-Type: text/plain; charset="us-ascii" Content-ID: <3110AF4F97980641A4079873351C34B4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] Fwd: AD Evaluation : draft-ietf-netext-update-notifications 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, 15 Aug 2013 06:09:42 -0000 Hi Brian, We've posted the updated doc. Some comments below. 1. >>Potentially some some new work items that we can point to. If there are Active I-D's will add a reference. >That would be useful. Just make sure they are informative references so >that this spec does not get held up on a reference to an I-D. Did not find any new items that we can reference here. 2. Some changes in normative language Earlier text was bit loose on the use of "SHOULD", as supposed to "MUST", fixed it. 3. - I would like to see some more guidance given to IANA on where the new registries should be placed in their protocol hierarchy. On cross checking, this seemed OK. But, may be we mis-understood the comment. 4. Made other changes as agreed Please let me know if this is OK. Regards Sri On 7/29/13 12:43 AM, "Brian Haberman" wrote: >Hi Sri, > I have deleted those points where there is no additional >discussion needed... > >On 7/27/13 7:09 PM, Sri Gundavelli (sgundave) wrote: >>> * Section 4 >>> >>> - Is there any guidance needed on managing the wrapping of the Sequence >>> #'s? >> >> We just require some random number, without collusions. We can add some >> text to say how to manage that field. >> > >Ok. Just ensure that the descriptive text does not impact the Sequence ># usage defined in the base PMIPv6 spec. > >>> >>> - Are there informative references that could be added for mobility >>> options other than the vendor-specific ones? >> >> >> Potentially some some new work items that we can point to. If there are >> Active I-D's will add a reference. >> > >That would be useful. Just make sure they are informative references so >that this spec does not get held up on a reference to an I-D. > >>> >>> - Can you provide an example of where an LMA would not request an ACK >>> for a UPN? >> >> >> Message String extension. LMA sending some status messages related to >>the >> service its offering. These service message may not need Ack's. >> >> Also, a UPN message with NR=3DRE-register may not need a Ack messages. T= he >> LMA after sending the UPN message with that NR code can wait the PBU >> message. >> > >So, is it worth mentioning these in the draft? It seems that the LMA is >in full control of whether an ACK is needed, but it *could* be useful to >describe the *types* of options that do not need an ACK. > >I am not insisting on this. Just trying to see if such an addition >would make the spec easier to understand/implement. > >>> >>> * Section 5.2 >>> >>> - I am surprised by the use of SHOULD (SHOULD NOT) for re-transmission >>> rules. When would you expect these rules to be ignored? >> >> >> >> Ok. Will review this again. >> > >If the SHOULDs are appropriate, it would be good to describe a scenario >(or type of scenaro) where the SHOULD would be ignored. > >>> >>> * Section 6.1 >>> >>> - The 2nd bullet is useless. If an implementation does not support >>> these messages, they wouldn't know to look here for responses. The >>>base >>> PMIPv6 spec covers the response message for unknown message types. >> >> This is about LMA sending a UPN message to a MAG that does not support >>and >> how to deal with that scenario. >> If the response to a UPN message is a Binding Error message, then the >>LMA >> can be forced not to send any more UPN messages. >> > >Given that section 6.1 talks about MAG considerations, it seemed odd to >describe how the MAG is supposed to respond if it doesn't support this >function. > >Regards, >Brian > From brian@innovationslab.net Thu Aug 15 06:11:27 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 807F821E8087 for ; Thu, 15 Aug 2013 06:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 9+7emQ++tTOa for ; Thu, 15 Aug 2013 06:11:22 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 541D021E811F for ; Thu, 15 Aug 2013 06:11:22 -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 295C6880FA; Thu, 15 Aug 2013 06:11:22 -0700 (PDT) Received: from 102526207.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 D5CA6130003; Thu, 15 Aug 2013 06:11:21 -0700 (PDT) Message-ID: <520CD378.8070205@innovationslab.net> Date: Thu, 15 Aug 2013 09:11:20 -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: "Sri Gundavelli (sgundave)" References: <24C0F3E22276D9438D6F366EB89FAEA8103FDA1B@xmb-aln-x03.cisco.com> In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA8103FDA1B@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" Subject: Re: [netext] Fwd: AD Evaluation : draft-ietf-netext-update-notifications 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, 15 Aug 2013 13:11:27 -0000 Hi Sri, On 8/15/13 2:09 AM, Sri Gundavelli (sgundave) wrote: > > 3. - I would like to see some more guidance given to IANA on where the new > registries should be placed in their protocol hierarchy. > > On cross checking, this seemed OK. But, may be we mis-understood the > comment. > I just want the document to be explicit that IANA actions 3 and 4 will create registries under the "Mobile IPv6 Parameters" registry (https://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml). Regards, Brian From sgundave@cisco.com Thu Aug 15 07:30: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 AF66311E8152 for ; Thu, 15 Aug 2013 07:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 ts62Akj4wlON for ; Thu, 15 Aug 2013 07:29:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E7AEE21F9E34 for ; Thu, 15 Aug 2013 07:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=769; q=dns/txt; s=iport; t=1376576996; x=1377786596; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TFez49fJkWrXZIhDEMEUPkj7ZqN5Y6JTkfO7RbiwbhA=; b=QRVP4VINkWukavy+y3/qSC6yKiYkbxZihvc8ZUGCYN7x6Yt4ylgZ64mO EZAPl9w2ZEylvp+jT3iFPY6G1mWwybkZC17pG2cocKjKU7jfuNznC64ZA LnxHF/XEpWOo51AiW9iNdGy/VUMICsOalhPXR0Oxu7QNoqi79eobl4O+P g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowFAD7lDFKtJV2b/2dsb2JhbABbgwY1UIJSvECBIRZ0giQBAQEEOj0CEgEIGAoUQiUCBA4FCIgIDLlwBJAfMQeDG3cDqTaDG4Iq X-IronPort-AV: E=Sophos;i="4.89,885,1367971200"; d="scan'208";a="247503818" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 15 Aug 2013 14:29:55 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7FETt3Y022075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Aug 2013 14:29:55 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 15 Aug 2013 09:29:55 -0500 From: "Sri Gundavelli (sgundave)" To: Brian Haberman Thread-Topic: [netext] Fwd: AD Evaluation : draft-ietf-netext-update-notifications Thread-Index: AQHOmcPoM004WIq4m06Xy+Z7Qbs27Q== Date: Thu, 15 Aug 2013 14:29:54 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA8103FE03E@xmb-aln-x03.cisco.com> In-Reply-To: <520CD378.8070205@innovationslab.net> 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.210] Content-Type: text/plain; charset="us-ascii" Content-ID: <95087A373B17ED43BC31EDCFAD2CB6E8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] Fwd: AD Evaluation : draft-ietf-netext-update-notifications 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, 15 Aug 2013 14:30:08 -0000 Hi Brian, Thanks for the clarification. That will make IANA related text complete. We will make that change. Regards Sri On 8/15/13 6:11 AM, "Brian Haberman" wrote: >Hi Sri, > >On 8/15/13 2:09 AM, Sri Gundavelli (sgundave) wrote: >> >> 3. - I would like to see some more guidance given to IANA on where the >>new >> registries should be placed in their protocol hierarchy. >> >> On cross checking, this seemed OK. But, may be we mis-understood the >> comment. >> > >I just want the document to be explicit that IANA actions 3 and 4 will >create registries under the "Mobile IPv6 Parameters" registry >(https://www.iana.org/assignments/mobility-parameters/mobility-parameters. >xhtml). > >Regards, >Brian > From internet-drafts@ietf.org Thu Aug 15 07:31: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 43C1521E8156; Thu, 15 Aug 2013 07:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, 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 4YXmBVqmOgQN; Thu, 15 Aug 2013 07:31:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6628721E814A; Thu, 15 Aug 2013 07:31:25 -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.70.p1 Message-ID: <20130815143125.26037.64292.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2013 07:31:25 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-update-notifications-07.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, 15 Aug 2013 14: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-07.txt Pages : 18 Date : 2013-08-15 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-update-notifications-07 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 Thu Aug 15 07:31:51 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 DDF8C21E8166 for ; Thu, 15 Aug 2013 07:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, 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 n-M99A6YVuCm; Thu, 15 Aug 2013 07:31:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC1B11E8152; Thu, 15 Aug 2013 07:31:44 -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.70.p1 Message-ID: <20130815143144.26037.59339.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2013 07:31:44 -0700 Subject: [netext] New Version Notification - draft-ietf-netext-update-notifications-07.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, 15 Aug 2013 14:31:51 -0000 A new version (-07) has been submitted for draft-ietf-netext-update-notific= ations: http://www.ietf.org/internet-drafts/draft-ietf-netext-update-notifications-= 07.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-07 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 Thu Aug 15 11:32:39 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 C444711E821D; Thu, 15 Aug 2013 11:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.123, 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 o50M3EYOq6rf; Thu, 15 Aug 2013 11:32:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6280911E8178; Thu, 15 Aug 2013 11:32:38 -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.70.p1 Sender: Message-ID: <20130815183238.16338.76789.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2013 11:32:38 -0700 Cc: netext@ietf.org Subject: [netext] Last Call: (Update Notifications for Proxy Mobile IPv6) to Proposed Standard X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Aug 2013 18:32:40 -0000 The IESG has received a request from the Network-Based Mobility Extensions WG (netext) to consider the following document: - 'Update Notifications 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-08-29. 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 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ballot/ No IPR declarations have been submitted directly on this I-D. From alper.yegin@yegin.org Fri Aug 16 06:19: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 3D3FE21F9B60 for ; Fri, 16 Aug 2013 06:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=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 r+2cs6SgMRke for ; Fri, 16 Aug 2013 06:19:52 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7AE11E8110 for ; Fri, 16 Aug 2013 06:19:52 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MO8WC-1VDdK90fIK-005cnd; Fri, 16 Aug 2013 09:19:46 -0400 From: Alper Yegin Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_C7A5A138-084A-43AC-A382-121D912DE5E4" Date: Fri, 16 Aug 2013 16:19:44 +0300 In-Reply-To: <403097963.25.1375348000874.JavaMail.tcastaldi@dell-tcastaldi> To: netext@ietf.org References: <403097963.25.1375348000874.JavaMail.tcastaldi@dell-tcastaldi> Message-Id: <519C700B-A14D-49ED-995A-DCCE5712B919@yegin.org> X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:uDxP8Hb38sD9QBRpvUc+gzJw+J0uj1+ojjqPp8My22g 4isd9km6cTMhl4SZ3bSKKUaeMNoYNzf5ISO5UCwDY2Z+TFeaUG I94XK1xrmAI+MzDfqvKKHeXNVVdiDMyVh4ZUETcrN6eVEg7Iir JfWHZNNrXwfdsRzITcVRYdE2HxH50Gy3vZobOyEnvfcAkrQef8 ijvfVb3Mx+emY3U+vNN5feCjfGBwnc7q3j7AErV5lIoosdwzpG hG9YHGsadmcVXUs6/KAfK7fHzWM9WFp7qnCmUOXjRAN/mloL/c mFhvMvVq+VJWP31A+sAnU33JqSKaajUlP/xII+wqmgcZIlnzi1 RxvS5C79Qmcrz+tZia14vmxZipmFvqiuoI8bSlpfZLiSmRB66T NOG41zMHN/zXA== Subject: [netext] pmip-cp-up-separation 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, 16 Aug 2013 13:19:58 -0000 --Apple-Mail=_C7A5A138-084A-43AC-A382-121D912DE5E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii LMA User Plane Address Mobility Option is only used with the PBA. If the MAG has prior info about the LMA-UPA, it could also provide that = in PBU. Should we allow that new option with PBU as well? Alper --Apple-Mail=_C7A5A138-084A-43AC-A382-121D912DE5E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 
LMA User Plane Address Mobility Option is only used with the =
PBA.
If the MAG has prior =
info about the LMA-UPA, it could also provide that in PBU.
Should we allow that new option with PBU as well?

To: Alper Yegin , "netext@ietf.org" 
Thread-Topic: [netext] pmip-cp-up-separation
Thread-Index: AQHOmplBzk2/SqVe1066/BsvA2k0LQ==
Date: Fri, 16 Aug 2013 15:57:05 +0000
Message-ID: <24C0F3E22276D9438D6F366EB89FAEA8103FFEE2@xmb-aln-x03.cisco.com>
In-Reply-To: <519C700B-A14D-49ED-995A-DCCE5712B919@yegin.org>
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.210]
Content-Type: multipart/alternative; boundary="_000_24C0F3E22276D9438D6F366EB89FAEA8103FFEE2xmbalnx03ciscoc_"
MIME-Version: 1.0
Subject: Re: [netext] pmip-cp-up-separation
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, 16 Aug 2013 15:57:12 -0000

--_000_24C0F3E22276D9438D6F366EB89FAEA8103FFEE2xmbalnx03ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Alper,

We were thinking of allowing the option to be carried in the PBU with 0.0.0=
.0/0::0 to indicate capability and also to keep it aligned with the other m=
obility options that we have defined recently. So, in that sense the option=
 may be present in the PBU, but I'm wondering in what cases, the MAG would =
have more specific information. In general, the LMA-CP identity may be know=
n to the MAG, but may be not the DP identity; there the broader goal is to =
have the DP identity be dynamically allocated by LMA-CP and have that expos=
ed to the MAG as part of the signaling exchange.




Regards
Sri







From: Alper Yegin >
Date: Friday, August 16, 2013 6:19 AM
To: "netext@ietf.org" >
Subject: [netext] pmip-cp-up-separation


LMA User Plane Address Mobility Option is only used with the PBA.

If the MAG has prior info about the LMA-UPA, it could also provide that in =
PBU.

Should we allow that new option with PBU as well?


Alper


--_000_24C0F3E22276D9438D6F366EB89FAEA8103FFEE2xmbalnx03ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <8C4DB8AB28B4C741B882414438D6F273@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Hi Alper,







We were thinking of allowing the option to be carried in the PBU with =
0.0.0.0/0::0 to indicate capability and also to keep it aligned with the ot=
her mobility options that we have defined recently. So, in that sense the o=
ption may be present in the PBU,
 but I'm wondering in what cases, the MAG would have more specific informat=
ion. In general, the LMA-CP identity may be known to the MAG, but may be no=
t the DP identity; there the broader goal is to have the DP identity be dyn=
amically allocated by LMA-CP and
 have that exposed to the MAG as part of the signaling exchange.






















Regards


Sri







































From: Alper Yegin <alper.yegin@yegin.org>

Date: Friday, August 16, 2013 6:19 =
AM

To: "netext@ietf.org" <=
netext@ietf.org>

Subject: [netext] pmip-cp-up-separa=
tion













LMA User Pla=
ne Address Mobility Option is only used with the PBA.


If the MAG h=
as prior info about the LMA-UPA, it could also provide that in PBU.


Should we al=
low that new option with PBU as well?





Alper














--_000_24C0F3E22276D9438D6F366EB89FAEA8103FFEE2xmbalnx03ciscoc_--

From sgundave@cisco.com  Fri Aug 16 08:59: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 E028711E82A4 for ; Fri, 16 Aug 2013 08:59:50 -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 svM46kMiZxUp for ; Fri, 16 Aug 2013 08:59:45 -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 D3BFA21F9C4A for ; Fri, 16 Aug 2013 08:59:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7657; q=dns/txt; s=iport; t=1376668785; x=1377878385; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=5BCRtbfj3Cr1X3P7PuziWXYyidfspIX9R4VlbP6PhHw=; b=Xe7z9kbU6S8cqp9+K3gdWAwLgdU/UqcLlmEzTyTB6F7nm16GlqzBIoWt uoIExEut1pRs6jLliNFLNvMTQLb/fMhGPYxjmq+Wei8pATSW+rm58FHjG AmWsNOB8XkGcwiYbzO2ia2D4Xv7Pai9cgXX1ZyOfx/qcTGalQCo30zsOR s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwFANtLDlKtJXG+/2dsb2JhbABSCYJCRIEGvx+BKxZ0giQBAQEEZyQBCBEDAQILHTkUCQgCBAESCIgIuhaPCoEVIBiDG3cDqTmDHIIq
X-IronPort-AV: E=Sophos;i="4.89,895,1367971200";  d="scan'208,217";a="248198246"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 16 Aug 2013 15:59:44 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7GFxhXX016952 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Aug 2013 15:59:43 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Fri, 16 Aug 2013 10:59:43 -0500
From: "Sri Gundavelli (sgundave)" 
To: Alper Yegin , "netext@ietf.org" 
Thread-Topic: [netext] pmip-cp-up-separation
Thread-Index: AQHOmpmeRDMx9JXmgESNpc+6UBD3EQ==
Date: Fri, 16 Aug 2013 15:59:42 +0000
Message-ID: <24C0F3E22276D9438D6F366EB89FAEA8103FFF1A@xmb-aln-x03.cisco.com>
In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA8103FFEE2@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.2.3.120616
x-originating-ip: [10.32.246.210]
Content-Type: multipart/alternative; boundary="_000_24C0F3E22276D9438D6F366EB89FAEA8103FFF1Axmbalnx03ciscoc_"
MIME-Version: 1.0
Subject: Re: [netext] pmip-cp-up-separation
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, 16 Aug 2013 15:59:51 -0000

--_000_24C0F3E22276D9438D6F366EB89FAEA8103FFF1Axmbalnx03ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Also, if I see the use-cases from Ryuji, his interest is for dynamic DP all=
ocation.

Sri



From: Sri Gundavelli >
Date: Friday, August 16, 2013 8:57 AM
To: Alper Yegin >, "net=
ext@ietf.org" >
Subject: Re: [netext] pmip-cp-up-separation

Hi Alper,

We were thinking of allowing the option to be carried in the PBU with 0.0.0=
.0/0::0 to indicate capability and also to keep it aligned with the other m=
obility options that we have defined recently. So, in that sense the option=
 may be present in the PBU, but I'm wondering in what cases, the MAG would =
have more specific information. In general, the LMA-CP identity may be know=
n to the MAG, but may be not the DP identity; there the broader goal is to =
have the DP identity be dynamically allocated by LMA-CP and have that expos=
ed to the MAG as part of the signaling exchange.




Regards
Sri







From: Alper Yegin >
Date: Friday, August 16, 2013 6:19 AM
To: "netext@ietf.org" >
Subject: [netext] pmip-cp-up-separation


LMA User Plane Address Mobility Option is only used with the PBA.

If the MAG has prior info about the LMA-UPA, it could also provide that in =
PBU.

Should we allow that new option with PBU as well?


Alper


--_000_24C0F3E22276D9438D6F366EB89FAEA8103FFF1Axmbalnx03ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <7A89898CDCA7F84AB090300ED05247A9@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Also, if I see the use-cases from Ryuji, his interest is for dynamic D=
P allocation.







Sri



















From: Sri Gundavelli <sgundave@cisco.com>

Date: Friday, August 16, 2013 8:57 =
AM

To: Alper Yegin <alper.yegin@yegin.org>, "netext@ietf.org" <netext@ietf.org>

Subject: Re: [netext] pmip-cp-up-se=
paration













Hi Alper,







We were thinking of allowing the option to be carried in the PBU with =
0.0.0.0/0::0 to indicate capability and also to keep it aligned with the ot=
her mobility options that we have defined recently. So, in that sense the o=
ption may be present in the PBU,
 but I'm wondering in what cases, the MAG would have more specific informat=
ion. In general, the LMA-CP identity may be known to the MAG, but may be no=
t the DP identity; there the broader goal is to have the DP identity be dyn=
amically allocated by LMA-CP and
 have that exposed to the MAG as part of the signaling exchange.






















Regards


Sri







































From: Alper Yegin <alper.yegin@yegin.org>

Date: Friday, August 16, 2013 6:19 =
AM

To: "netext@ietf.org" <=
netext@ietf.org>

Subject: [netext] pmip-cp-up-separa=
tion













LMA User Pla=
ne Address Mobility Option is only used with the PBA.


If the MAG h=
as prior info about the LMA-UPA, it could also provide that in PBU.


Should we al=
low that new option with PBU as well?





Alper


















--_000_24C0F3E22276D9438D6F366EB89FAEA8103FFF1Axmbalnx03ciscoc_--

From rjsparks@nostrum.com  Thu Aug 22 11:05:31 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 7485211E8100; Thu, 22 Aug 2013 11:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.216
X-Spam-Level: 
X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-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 nz5Ivs39-Mia; Thu, 22 Aug 2013 11:05:30 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 236FD21F9E7E; Thu, 22 Aug 2013 11:05:29 -0700 (PDT)
Received: from unnumerable.local (pool-173-71-53-173.dllstx.fios.verizon.net [173.71.53.173]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r7MI5KIL084756 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Thu, 22 Aug 2013 13:05:22 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Message-ID: <521652E0.8030300@nostrum.com>
Date: Thu, 22 Aug 2013 13:05:20 -0500
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: General Area Review Team , netext@ietf.org, draft-ietf-netext-update-notifications@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------040800040901010008090007"
Received-SPF: pass (shaman.nostrum.com: 173.71.53.173 is authenticated by a trusted mechanism)
Subject: [netext] Gen-ART LC review: draft-ietf-netext-update-notifications-07
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, 22 Aug 2013 18:05:31 -0000

This is a multi-part message in MIME format.
--------------040800040901010008090007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-netext-update-notifications-07
Reviewer: Robert Sparks
Review Date: 2013-08-22
IETF LC End Date: 2013-08-29
IESG Telechat date: not scheduled

Summary: This draft is ready for publication as Proposed Standard

I had to read through this text several times to convince myself 
implementers could figure out what order they were required to take 
steps in vs where they had flexibility:

    o  Upon accepting the Update Notification message, the mobile access
       gateway MUST process the message and perform the actions based on
       the Notification Reason.
       *  If the (A) flag in the message is set to a value of (1), the
          mobile access gateway MUST first send an Update Notification
          Acknowledgement message and set the status code field according
          to the result of processing the Update Notification message.

In particular, it's not immediately obvious if there is tension between 
that "MUST first" and having "the result of processing" available.
Please consider rewording to make it clearer that this "result of 
processing" is not intended to include waiting for the result of some 
action processing this notification message might trigger.

It might help readers understand the intended usual case retransmission 
mechanics if the expected default values listed in section 7 were called 
out earlier in the document.

--------------040800040901010008090007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    I am the assigned Gen-ART reviewer for this draft. For background on
    

    Gen-ART, please see the FAQ at
    

    

    <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
    

    

Please resolve these comments along with any other Last Call comments
    

    you may receive.
    

    

    Document: draft-ietf-netext-update-notifications-07

    Reviewer: Robert Sparks
    

    Review Date: 2013-08-22

    IETF LC End Date: 2013-08-29

    IESG Telechat date: not scheduled

    

    Summary: This draft is ready for publication as Proposed Standard

    

    I had to read through this text several times to convince myself
    implementers could figure out what order they were required to take
    steps in vs where they had flexibility:

    
    
   o  Upon accepting the Update Notification message, the mobile access
      gateway MUST process the message and perform the actions based on
      the Notification Reason.
      *  If the (A) flag in the message is set to a value of (1), the
         mobile access gateway MUST first send an Update Notification
         Acknowledgement message and set the status code field according
         to the result of processing the Update Notification message.



    In particular, it's not immediately obvious if there is tension
    between that "MUST first" and having "the result of processing"
    available.

    Please consider rewording to make it clearer that this "result of
    processing" is not intended to include waiting for the result of
    some action processing this notification message might trigger.

    

    It might help readers understand the intended usual case
    retransmission mechanics if the expected default values listed in
    section 7 were called out earlier in the document.

  


--------------040800040901010008090007--

From suresh.krishnan@ericsson.com  Thu Aug 22 14:09:34 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 BCF2511E81F8; Thu, 22 Aug 2013 14:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 Skf9UoqItuAF; Thu, 22 Aug 2013 14:09:29 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 39E4311E8131; Thu, 22 Aug 2013 14:09:27 -0700 (PDT)
X-AuditID: c6180641-b7fe28e000000d82-a2-52167e0640d1
Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 30.42.03458.60E76125; Thu, 22 Aug 2013 23:09:26 +0200 (CEST)
Received: from [142.133.113.185] (147.117.188.134) by smtps-am.internal.ericsson.com (147.117.188.90) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 22 Aug 2013 17:09:25 -0400
Message-ID: <52167D67.2010103@ericsson.com>
Date: Thu, 22 Aug 2013 17:06:47 -0400
From: Suresh Krishnan 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Robert Sparks 
References: <521652E0.8030300@nostrum.com>
In-Reply-To: <521652E0.8030300@nostrum.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [147.117.188.134]
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyuXRPlC5bnViQwc9LShYPNixhtLj66jOL xbWfT9ktrs1pZHNg8Viy5CeTx6ydT1g8vlz+zBbAHMVlk5Kak1mWWqRvl8CVsbzhLEvBJpGK 1TeKGxh7BLoYOTkkBEwkFm/5ywZhi0lcuLcezBYSOMoocWBKaRcjF5C9k1Fi1pWbzF2MHBy8 AtoSb064g9SwCKhKTFv5DqyeDWjOhp2fmUBsUYEwifvnDoHZvAKCEidnPmEBsUUENCSuLVnC DmIzC9RKnOp5wAhiCwsESUzfP58JYq+WRO/vy8wgNifQqmk//jFB3CYpsW3RMahePYkpV1sY IWx5ie1v5zBD9GpKbF3znRWiXlni37sVLBMYhWchOWMWkvZZSNoXMDKvYuQoLU4ty003MtzE CAzvYxJsjjsYF3yyPMQozcGiJM67Qe9MoJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGUKNW R78bD7Z27fx6Y+E27fot1zWf7Zh1iM1QnGs645/0FTeu7P3v8eb1H0nhN62yieFdJa3iD3dm CL5uuPVhfve2feZ7+n5M2Brt+e3gq4bi1JblLDZxXletz23iLddbECR/4Xk7845f7pLr1a0m a3b+X8uXxmzH/2nh3IvNMtFJ5yXVP7bPVGIpzkg01GIuKk4EAGPVpu89AgAA
Cc: netext@ietf.org, General Area Review Team , draft-ietf-netext-update-notifications@tools.ietf.org
Subject: Re: [netext] Gen-ART LC review: draft-ietf-netext-update-notifications-07
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, 22 Aug 2013 21:09:34 -0000

Hi Robert,
  Thanks a lot for the review. We will include the changes in the next
revision we submit. Please see proposed changes inline.

On 08/22/2013 02:05 PM, Robert Sparks wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> .
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-netext-update-notifications-07
> Reviewer: Robert Sparks
> Review Date: 2013-08-22
> IETF LC End Date: 2013-08-29
> IESG Telechat date: not scheduled
> 
> Summary: This draft is ready for publication as Proposed Standard
> 
> I had to read through this text several times to convince myself
> implementers could figure out what order they were required to take
> steps in vs where they had flexibility:
> 
>    o  Upon accepting the Update Notification message, the mobile access
>       gateway MUST process the message and perform the actions based on
>       the Notification Reason.
>       *  If the (A) flag in the message is set to a value of (1), the
>          mobile access gateway MUST first send an Update Notification
>          Acknowledgement message and set the status code field according
>          to the result of processing the Update Notification message.
> 
> In particular, it's not immediately obvious if there is tension between
> that "MUST first" and having "the result of processing" available.
> Please consider rewording to make it clearer that this "result of
> processing" is not intended to include waiting for the result of some
> action processing this notification message might trigger.

I think we can lose the word first without losing anything. Does the
following rewording work for you?

OLD:
If the (A) flag in the message is set to a value of (1), the mobile
access gateway MUST first send an Update Notification Acknowledgement
message and set the status code field according to the result of
processing the Update Notification message.

NEW:
If the (A) flag in the message is set to a value of (1), the mobile
access gateway MUST send an Update Notification Acknowledgement message
with the status code field set based on the result of processing the
Update Notification message.

> 
> It might help readers understand the intended usual case retransmission
> mechanics if the expected default values listed in section 7 were called
> out earlier in the document.

Sure. Will call out the defaults at first use.

Thanks
Suresh


From rjsparks@nostrum.com  Thu Aug 22 14:51:16 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 3870E21F9F0A; Thu, 22 Aug 2013 14:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.14
X-Spam-Level: 
X-Spam-Status: No, score=-102.14 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, SPF_PASS=-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 pah0-4iHErQ3; Thu, 22 Aug 2013 14:51:15 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4B29C21F9EED; Thu, 22 Aug 2013 14:51:15 -0700 (PDT)
Received: from unnumerable.local (pool-173-71-53-173.dllstx.fios.verizon.net [173.71.53.173]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r7MLp9lP009783 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Thu, 22 Aug 2013 16:51:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Message-ID: <521687CD.40502@nostrum.com>
Date: Thu, 22 Aug 2013 16:51:09 -0500
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Suresh Krishnan 
References: <521652E0.8030300@nostrum.com> <52167D67.2010103@ericsson.com>
In-Reply-To: <52167D67.2010103@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 173.71.53.173 is authenticated by a trusted mechanism)
Cc: netext@ietf.org, General Area Review Team , draft-ietf-netext-update-notifications@tools.ietf.org
Subject: Re: [netext] Gen-ART LC review: draft-ietf-netext-update-notifications-07
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, 22 Aug 2013 21:51:16 -0000

On 8/22/13 4:06 PM, Suresh Krishnan wrote:
> Hi Robert,
>    Thanks a lot for the review. We will include the changes in the next
> revision we submit. Please see proposed changes inline.
>
> On 08/22/2013 02:05 PM, Robert Sparks wrote:
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>>
>> .
>>
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>
>> Document: draft-ietf-netext-update-notifications-07
>> Reviewer: Robert Sparks
>> Review Date: 2013-08-22
>> IETF LC End Date: 2013-08-29
>> IESG Telechat date: not scheduled
>>
>> Summary: This draft is ready for publication as Proposed Standard
>>
>> I had to read through this text several times to convince myself
>> implementers could figure out what order they were required to take
>> steps in vs where they had flexibility:
>>
>>     o  Upon accepting the Update Notification message, the mobile access
>>        gateway MUST process the message and perform the actions based on
>>        the Notification Reason.
>>        *  If the (A) flag in the message is set to a value of (1), the
>>           mobile access gateway MUST first send an Update Notification
>>           Acknowledgement message and set the status code field according
>>           to the result of processing the Update Notification message.
>>
>> In particular, it's not immediately obvious if there is tension between
>> that "MUST first" and having "the result of processing" available.
>> Please consider rewording to make it clearer that this "result of
>> processing" is not intended to include waiting for the result of some
>> action processing this notification message might trigger.
> I think we can lose the word first without losing anything. Does the
> following rewording work for you?
Yes, thanks!
>
> OLD:
> If the (A) flag in the message is set to a value of (1), the mobile
> access gateway MUST first send an Update Notification Acknowledgement
> message and set the status code field according to the result of
> processing the Update Notification message.
>
> NEW:
> If the (A) flag in the message is set to a value of (1), the mobile
> access gateway MUST send an Update Notification Acknowledgement message
> with the status code field set based on the result of processing the
> Update Notification message.
>
>> It might help readers understand the intended usual case retransmission
>> mechanics if the expected default values listed in section 7 were called
>> out earlier in the document.
> Sure. Will call out the defaults at first use.
>
> Thanks
> Suresh
>


From cjbc@it.uc3m.es  Thu Aug 22 18:29: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 1C14F11E82B0; Thu, 22 Aug 2013 18:29:00 -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 kPMFsyXErRkA; Thu, 22 Aug 2013 18:28:54 -0700 (PDT)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB1A11E8141; Thu, 22 Aug 2013 18:28:53 -0700 (PDT)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1F90310BCE9E; Fri, 23 Aug 2013 03:28:53 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [163.117.203.84] (unknown [163.117.203.84]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 7B5791079375; Fri, 23 Aug 2013 03:28:52 +0200 (CEST)
Message-ID: <1377221316.4148.8.camel@acorde.it.uc3m.es>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano 
To: ietf@ietf.org
In-Reply-To: <20130815183238.16338.76789.idtracker@ietfa.amsl.com>
References: <20130815183238.16338.76789.idtracker@ietfa.amsl.com>
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 23 Aug 2013 03:28:36 +0200
Mime-Version: 1.0
X-Mailer: Evolution 3.4.4-3 
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20098.003
X-TM-AS-Result: No--40.936-7.0-31-1
X-imss-scan-details: No--40.936-7.0-31-1
Cc: netext@ietf.org
Subject: Re: [netext] Last Call:  (Update Notifications for Proxy Mobile IPv6) to Proposed Standard
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: Fri, 23 Aug 2013 01:29:00 -0000

Hi,

I've taken a look at the current version of the draft and I think it is
in good shape.

I have a couple of comments:

- I think it might be useful to include an additional NR
Code for obtaining Updated Access Network Identifier (ANI) parameters.
The LMA would send a UPN message to the MAG with
NR=Updated-ANI-Parameters and then the MAG would send the PBU with the
updated ANI parameters.

- In the last NETEXT session we discussed about using the update
notifications for the flow mobility solution draft
(draft-ietf-netext-pmipv6-flowmob). I think it might be good to add a
Notification Reason related to flow mobility updates, or at least a
reference to the flowmob document (we can also define the Notification
Reason in draft-ietf-netext-pmipv6-flowmob).

Thanks,

Carlos

On Thu, 2013-08-15 at 11:32 -0700, The IESG wrote:
> The IESG has received a request from the Network-Based Mobility
> Extensions WG (netext) to consider the following document:
> - 'Update Notifications 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-08-29. 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 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 file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 



From sgundave@cisco.com  Thu Aug 22 21:17:41 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 8E62921F9CAC; Thu, 22 Aug 2013 21:17:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 2QoYh5DI8TZJ; Thu, 22 Aug 2013 21:17:30 -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 B918511E8197; Thu, 22 Aug 2013 21:17:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2767; q=dns/txt; s=iport; t=1377231449; x=1378441049; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=82veYRfABG1DwGKp2Aayfr0qQKpI6zAS0GvPpkIBytM=; b=Goq4FFQ5F+rG2/BlFqbO83yay/TcRTHQ2HfYJXagbC7X3PblPFQSf+DX voJ7AhpceQo6Kcowhdftue6+Tfg+5LVTAvaS8r278h+J4IqU5bUkZrQum row3+7Mo2gCbp/Ackc3RLnm1oUDmYLcOluJwq/RTrEasjIiyNt6XeaRT3 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiwFAFLhFlKtJXHA/2dsb2JhbABagwc1UcAMgRwWdIIkAQEBBAEBAWsJAhIBCBgKGTILJQIEAQ0FCBOHdQy3FpAzAjEHgxt7A4h2kB2QLYFkgTuCKw
X-IronPort-AV: E=Sophos;i="4.89,938,1367971200"; d="scan'208";a="250839309"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 23 Aug 2013 04:17:28 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7N4HRDv011951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Aug 2013 04:17:27 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.187]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 23:17:27 -0500
From: "Sri Gundavelli (sgundave)" 
To: "cjbc@it.uc3m.es" , "ietf@ietf.org" 
Thread-Topic: [netext] Last Call:  (Update Notifications for Proxy Mobile IPv6) to Proposed Standard
Thread-Index: AQHOn7esRvgkdLK2yk2caW0kIeZhVA==
Date: Fri, 23 Aug 2013 04:17:19 +0000
Message-ID: <24C0F3E22276D9438D6F366EB89FAEA81169FEB9@xmb-aln-x03.cisco.com>
In-Reply-To: <1377221316.4148.8.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.2.3.120616
x-originating-ip: [10.32.246.211]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <246BE10AB972EB48B4C4E8AB288766ED@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netext@ietf.org" 
Subject: Re: [netext] Last Call:  (Update Notifications for Proxy Mobile IPv6) to Proposed Standard
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, 23 Aug 2013 04:17:41 -0000

Hi Carlos,

Thanks for your review comments. Please see inline.


On 8/22/13 6:28 PM, "Carlos Jes=FAs Bernardos Cano"  wrote=
:

>Hi,
>
>I've taken a look at the current version of the draft and I think it is
>in good shape.
>
>I have a couple of comments:
>
>- I think it might be useful to include an additional NR
>Code for obtaining Updated Access Network Identifier (ANI) parameters.
>The LMA would send a UPN message to the MAG with
>NR=3DUpdated-ANI-Parameters and then the MAG would send the PBU with the
>updated ANI parameters.


Yes. We discussed this, but we seem to have missed this comment. Will
include this NR  code.


>
>- In the last NETEXT session we discussed about using the update
>notifications for the flow mobility solution draft
>(draft-ietf-netext-pmipv6-flowmob). I think it might be good to add a
>Notification Reason related to flow mobility updates, or at least a
>reference to the flowmob document (we can also define the Notification
>Reason in draft-ietf-netext-pmipv6-flowmob).


Sure. Will add a reference to the spec.

Regards
Sri



>
>Thanks,
>
>Carlos
>
>On Thu, 2013-08-15 at 11:32 -0700, The IESG wrote:
>> The IESG has received a request from the Network-Based Mobility
>> Extensions WG (netext) to consider the following document:
>> - 'Update Notifications for Proxy Mobile IPv6'
>>    as Proposed Standard
>>=20
>> 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-08-29. 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.
>>=20
>> Abstract
>>=20
>>=20
>>    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.
>>=20
>>=20
>>=20
>>=20
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/
>>=20
>> IESG discussion can be tracked via
>>=20
>>http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ba
>>llot/
>>=20
>>=20
>> No IPR declarations have been submitted directly on this I-D.
>>=20
>>=20
>
>
>_______________________________________________
>netext mailing list
>netext@ietf.org
>https://www.ietf.org/mailman/listinfo/netext


From sarikaya2012@gmail.com  Fri Aug 23 14:31:32 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 15BCA11E8149 for ; Fri, 23 Aug 2013 14:31:32 -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=[AWL=0.000,  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 kzgwiAJg-KHT for ; Fri, 23 Aug 2013 14:31:31 -0700 (PDT)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id E7D9511E810A for ; Fri, 23 Aug 2013 14:31:30 -0700 (PDT)
Received: by mail-la0-f49.google.com with SMTP id ev20so885915lab.36 for ; Fri, 23 Aug 2013 14:31:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=W6g98P/U7wP9IHIvFn0h8UM1RVM0a2FkmQkzth5grhc=; b=Tuuw3ZSXRaXgnJ0nTyJqvlnJE7trTeNmFndtyeDzH0qYOOjFe4u6OvT8tMkX63FBQ8 UGNdWWJrPToNCuHJ9/y7VMAWm92L8jYzCz6XuQEYxhXqbXZvJSKSd42VZYOSFlfaZh7B JMuoRQQ1RxBobEE+fRk5R7NwJslM0541FGqgg7T0hBpu1AoBbxgAOhQU95JB72A+qs2c emUc5tEY3Pzf22GlwT92QAf7cMZ8WVBwXVb5bTVArG5G2n0EjKSiALGDse5J5AdcQGpo UPmW0MR07p056PPfH/8LhRcxtSfS5KgWG1hk/tJ3dCyO3+7r0IDBhz6bLhZbtBMK4Fo/ OANg==
MIME-Version: 1.0
X-Received: by 10.112.9.195 with SMTP id c3mr663000lbb.33.1377293489666; Fri, 23 Aug 2013 14:31:29 -0700 (PDT)
Received: by 10.114.98.227 with HTTP; Fri, 23 Aug 2013 14:31:29 -0700 (PDT)
Date: Fri, 23 Aug 2013 16:31:29 -0500
Message-ID: 
From: Behcet Sarikaya 
To: "Carlos J. Bernardos" , "netext@ietf.org" 
Content-Type: multipart/alternative; boundary=001a1135e1f634019504e4a421ed
Subject: [netext] draft-netext-pmipv6-flowmob
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: Fri, 23 Aug 2013 21:31:32 -0000

--001a1135e1f634019504e4a421ed
Content-Type: text/plain; charset=ISO-8859-1

Hi Carlos,

As per issues I placed in the issue tracker, your replies and as per Berlin
discussions, I would to clarify the issues as follows:

About BID: In RFC 5648, Each BID is generated and
      managed by a mobile node.
      In Section 5.1, it says A mobile node assigns a BID to each care-of
address when it wants to
   register them simultaneously with its home address.
   That means BID being 16 bits long is basically a short name for each
care-of address.

      In draft-netext-pmipv6-flowmob, you defined BID to be assigned and
used by the local mobility anchor to identify which
   entry of the flow mobility cache is used to decide how to route a
   given flow.
   As such, your BID is very different than RFC 5648. Simple protocol
engineering requires giving it a different name. Maybe pBID but even pBID
is not appropriate because your BID is not proxy version of rfc5648's BID.

About how to route a given flow: I don't understand why you are so much
worried about it. From RFC6089, table of flow binding entries should be
used to route the flows.
Your protocol should describe what you have in each flow binding entry,
(including MN interface care-of address) and how you manage these flow
binding entries.

I am unable to see these things in draft-netext-pmipv6-flowmob and I think
that's why you seem to be so much concerned about how to route a given flow.

About marking the interfaces: In RFC5648, Home Link and Visited Link are
very clearly distinguished. Home link is well defined in MIPv6. So other
links are visited links.

In RFC 5213, for each interface a different binding cache is created. Each
interface is a different mobility session. That effectively means each
interface is a different MN.

But in draft-netext-pmipv6-flowmob, you want to integrate binding cache
entries for the same MN into one so as not to create a separate mobility
session for each.


In that case, you need to mark these binding cache entries properly. One
suggestion is to mark the first one as Home Link and all others Visited
link and let each MAG know the marking by LMA.
Each MAG should keep HNPs assigned to its interface as well as to the home
link interface.
This enables MN to always use  source address(es) assigned to the home link
and thus MAGs can properly route these packets upwards. Downward routing is
as I mentioned above, based on flow mobility binding cache.

Regards,

Behcet

--001a1135e1f634019504e4a421ed
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Carlos,

As per issues I pla=
ced in the issue tracker, your replies and as per Berlin discussions, I wou=
ld to clarify the issues as follows:

About BID: In RFC 5648, Each BI=
D is generated and

=A0=A0=A0=A0=A0 managed by a mobile node. 
=A0=A0=A0=A0=A0 In Section 5.=
1, it says A mobile node assigns a BID to each care-of address when it want=
s to
=A0=A0 register them simultaneously with its home address.
=A0=
=A0 That means BID being 16 bits long is basically a short name for each ca=
re-of address. 

=A0=A0 
=A0=A0=A0=A0=A0 In draft-netext-pmipv6-flowmob, you defined BID =
to be assigned and used by the local mobility anchor to identify which
=
=A0=A0 entry of the flow mobility cache is used to decide how to route a=A0=A0 given flow.

=A0=A0 As such, your BID is very different than RFC 5648. Simple protocol e=
ngineering requires giving it a different name. Maybe pBID but even pBID is=
 not appropriate because your BID is not proxy version of rfc5648's BID=
.

=A0=A0 
About how to route a given flow: I don't understand why you =
are so much worried about it. From RFC6089, table of flow binding entries s=
hould be used to route the flows. 
Your protocol should describe what yo=
u have in each flow binding entry, (including MN interface care-of address)=
 and how you manage these flow binding entries.


I am unable to see these things in draft-netext-pmipv6-flowmob and I th=
ink that's why you seem to be so much concerned about how to route a gi=
ven flow.

About marking the interfaces: In RFC5648, Home Link and Vi=
sited Link are very clearly distinguished. Home link is well defined in MIP=
v6. So other links are visited links.


In RFC 5213, for each interface a different binding cache is created. E=
ach interface is a different mobility session. That effectively means each =
interface is a different MN.

But in draft-netext-pmipv6-flowmob, you=
 want to integrate binding cache entries for the same MN into one so as not=
 to create a separate mobility session for each.



In that case, you need to mark these binding cache entries properly=
. One suggestion is to mark the first one as Home Link and all others Visit=
ed link and let each MAG know the marking by LMA.
Each MAG should keep H=
NPs assigned to its interface as well as to the home link interface. 

This enables MN to always use=A0 source address(es) assigned to the home li=
nk and thus MAGs can properly route these packets upwards. Downward routing=
 is as I mentioned above, based on flow mobility binding cache.


Regards,

Behcet


--001a1135e1f634019504e4a421ed--

From bpatil1@gmail.com  Mon Aug 26 09:23:21 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 CE93421F9D55 for ; Mon, 26 Aug 2013 09:23:21 -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 cknbNiLZYJ-i for ; Mon, 26 Aug 2013 09:23:21 -0700 (PDT)
Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6C821F9D15 for ; Mon, 26 Aug 2013 09:23:21 -0700 (PDT)
Received: by mail-oa0-f45.google.com with SMTP id m1so1041502oag.18 for ; Mon, 26 Aug 2013 09:23:19 -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:cc:content-type; bh=J0OZEgc8UhrVbf2PL7IE/ft5YdyYEsqtrHSKzIvRU9o=; b=CGrmVpmGZQJOrlD5oLvShOkA5XD8WiyUlAyYkFQp01xcbsE0CN2sjhBx5BacFpb6E7 nxy409JsOY+rIrzcX8YMdNBhvRWyho+EH6/w3rF4Ehh2fqlZtWDnLwiFFBE7pYq1Nr5u s0nMxovIm6F2Zmx8NgKNtqHEY0oy9tGPIxZyTUU/TxUx1p4BYXwGdW9FljyxmawrXYsH jfG6Qy9UgWZtNXw2pKLKHfhrFCKccSg0CsOE7tX/SNWsyBZrKncapLb4gvJt4cTAO3GK 2unf7IjSj4BQrg9QQXZYvUuXpbsyvZ/dV8jjIsXY9bxkENMozaYq1ZUKyK6/YqzxCzHg wlVg==
MIME-Version: 1.0
X-Received: by 10.60.93.67 with SMTP id cs3mr15029079oeb.12.1377534198752; Mon, 26 Aug 2013 09:23:18 -0700 (PDT)
Received: by 10.182.111.138 with HTTP; Mon, 26 Aug 2013 09:23:18 -0700 (PDT)
Date: Mon, 26 Aug 2013 12:23:18 -0400
Message-ID: 
From: Basavaraj Patil 
To: "netext@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b33d176952ded04e4dc2c72
Cc: draft-wakikawa-netext-pmip-cp-up-separation@tools.ietf.org, "netext-chairs@tools.ietf.org" 
Subject: [netext] Consensus call to adopt I-D: draft-wakikawa-netext-pmip-cp-up-separation
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, 26 Aug 2013 16:23:22 -0000

--047d7b33d176952ded04e4dc2c72
Content-Type: text/plain; charset=ISO-8859-1

Hello,

This is a consensus call to adopt the following I-D as a working group
document. The I-D was discussed at IETF87 and there was consensus at the
meeting to adopt it.
This email is a followup to allow folks who were not at the meeting to
respond as well.

I-D:  Separation of Control and User Plane for Proxy Mobile IPv6

    draft-wakikawa-netext-pmip-cp-up-separation


Please respond with a Yay or Nay by September 4th, 2013.

-Chairs

--047d7b33d176952ded04e4dc2c72
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Hello,=A0

This is a consensus call to adopt the following I-D as a wor=
king group document. The I-D was discussed at IETF87 and there was consensu=
s at the meeting to adopt it.=A0


This email is a followup to allow folks who were not at the meet=
ing to respond as well.

I-D: =A0Separation of C=
ontrol and User Plane for Proxy Mobile IPv6


    draft-wakikawa-netext-pmip-cp-up-separation

Please respond with a Yay or Nay by September 4t=
h, 2013.



-Chairs



--047d7b33d176952ded04e4dc2c72--

From ryuji.wakikawa@gmail.com  Mon Aug 26 23:00:07 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 448DB21F937E for ; Mon, 26 Aug 2013 23:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 m1CDNCCabEtp for ; Mon, 26 Aug 2013 23:00:06 -0700 (PDT)
Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D1D1211E8285 for ; Mon, 26 Aug 2013 23:00:06 -0700 (PDT)
Received: by mail-pd0-f173.google.com with SMTP id p10so4401987pdj.4 for ; Mon, 26 Aug 2013 23:00:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xrVlYKmsB83H1K1r3W/s1yNkfjl2zbK+THF4H75xvJ8=; b=G36JRtK+uwrHjRJ+7yc5lFNocKhKXEHkI/fbYjk3cJVt8dKNvjxnOxYOLH4Gu3bKPv nfzBEAgE7SXcoSC2gmNsnMv2x7hfkRa7WHo0wsfnuoZVtLAQVyM6r7EIGOfdYXKWYP+W thCSZAhrMeUcgO+ZOfBsWVcF2X1vtBxoxjJNJO1Ur94TtHCPaUOUD/4kECN+rRYBksv3 VOQ0Umz4xZjGcbVX7Bg9RXAVhDHVSzZh8+fyHKBxQer/i0Jiwqbrp4IaQQWgi8sqoJU5 GKK2NWVL282Xkm29WI57+14BIDzF37EjDdXBNcLn4SONdynjtoumCcLQ8DsUcQCCYFMP Q8Xg==
X-Received: by 10.68.135.101 with SMTP id pr5mr1087459pbb.196.1377583206142; Mon, 26 Aug 2013 23:00:06 -0700 (PDT)
Received: from [10.201.86.249] ([202.45.12.142]) by mx.google.com with ESMTPSA id zi1sm22273649pbb.28.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Aug 2013 23:00:05 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ryuji Wakikawa 
In-Reply-To: 
Date: Tue, 27 Aug 2013 15:00:03 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <34715EB3-B271-46F2-9E2A-53F736C08CE6@gmail.com>
References: 
To: Basavaraj Patil 
X-Mailer: Apple Mail (2.1508)
Cc: "netext@ietf.org" , draft-wakikawa-netext-pmip-cp-up-separation@tools.ietf.org, "netext-chairs@tools.ietf.org" 
Subject: Re: [netext] Consensus call to adopt I-D: draft-wakikawa-netext-pmip-cp-up-separation
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, 27 Aug 2013 06:00:07 -0000

Hi Raj

Thanks for the consensus call.=20

My vote is Yay!=20

thanks,
ryuji

On Aug 27, 2013, at 1:23 AM, Basavaraj Patil  wrote:

>=20
> Hello,=20
>=20
> This is a consensus call to adopt the following I-D as a working group =
document. The I-D was discussed at IETF87 and there was consensus at the =
meeting to adopt it.=20
> This email is a followup to allow folks who were not at the meeting to =
respond as well.
>=20
> I-D:  Separation of Control and User Plane for Proxy Mobile IPv6
>     draft-wakikawa-netext-pmip-cp-up-separation
>=20
> Please respond with a Yay or Nay by September 4th, 2013.
>=20
> -Chairs
>=20
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext


From charliep@computer.org  Mon Aug 26 23:02:43 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 E40BD11E828A for ; Mon, 26 Aug 2013 23:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QZze-nFFGWL for ; Mon, 26 Aug 2013 23:02:39 -0700 (PDT)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3C65211E8289 for ; Mon, 26 Aug 2013 23:02:39 -0700 (PDT)
Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1VECMP-0002LH-Rz; Tue, 27 Aug 2013 02:02:38 -0400
Message-ID: <521C40EF.9080604@computer.org>
Date: Mon, 26 Aug 2013 23:02:23 -0700
From: "Charles E. Perkins" 
Organization: Saratoga Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ryuji Wakikawa 
References:  <34715EB3-B271-46F2-9E2A-53F736C08CE6@gmail.com>
In-Reply-To: <34715EB3-B271-46F2-9E2A-53F736C08CE6@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8617bba8c9360a53adbbbc708466740571350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Cc: netext@ietf.org, draft-wakikawa-netext-pmip-cp-up-separation@tools.ietf.org, Basavaraj Patil , netext-chairs@tools.ietf.org
Subject: Re: [netext] Consensus call to adopt I-D:draft-wakikawa-netext-pmip-cp-up-separation
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, 27 Aug 2013 06:02:44 -0000

Hello folks,

I agree and vote yes.

Regards,
Charlie P.


On 8/26/2013 11:00 PM, Ryuji Wakikawa wrote:
> Hi Raj
>
> Thanks for the consensus call.
>
> My vote is Yay!
>
> thanks,
> ryuji
>
> On Aug 27, 2013, at 1:23 AM, Basavaraj Patil  wrote:
>
>> Hello,
>>
>> This is a consensus call to adopt the following I-D as a working group document. The I-D was discussed at IETF87 and there was consensus at the meeting to adopt it.
>> This email is a followup to allow folks who were not at the meeting to respond as well.
>>
>> I-D:  Separation of Control and User Plane for Proxy Mobile IPv6
>>      draft-wakikawa-netext-pmip-cp-up-separation
>>
>> Please respond with a Yay or Nay by September 4th, 2013.
>>
>> -Chairs
>>
>> _______________________________________________
>> 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
>


-- 
Regards,
Charlie P.


From sgundave@cisco.com  Mon Aug 26 23: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 8126811E8158 for ; Mon, 26 Aug 2013 23:05:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.252
X-Spam-Level: 
X-Spam-Status: No, score=-10.252 tagged_above=-999 required=5 tests=[AWL=0.347, 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 9by499gEgejU for ; Mon, 26 Aug 2013 23:05:17 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 50C8811E8289 for ; Mon, 26 Aug 2013 23:05:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1111; q=dns/txt; s=iport; t=1377583517; x=1378793117; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SxwHSbp5IkVulni5SHg0tHpb9zKhP7l3ClkCfujZlR8=; b=j4NHkmDn3+9QcIz4aMBWdVH3oxA8lxIEglK9XrCkzOCRi0J3ZbTkew3N JYFTMHjSw5/Z4OiqWwFKsHG6WvNWSDRJo+wG/C/XQJl27gbQNTPxmH7lN 5hNBqy/iSrGYWBmmNXt+vYWb9zSM5s6qChseVYz7/7Ek/zDw8xelDfhhh M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAGxAHFKtJV2Y/2dsb2JhbABagwc1UcAqgSEWdIIkAQEBBAEBATc0CxIBCBgKFDEGCyUCBAENBQiHZwMPDK4dDYlmBI1/gS+BGDEHgxx9A5YFjh6FLIFjgTuBcTk
X-IronPort-AV: E=Sophos;i="4.89,966,1367971200"; d="scan'208";a="251804732"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 27 Aug 2013 06:05:16 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7R65Gbh017656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Aug 2013 06:05:16 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.187]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 27 Aug 2013 01:05:16 -0500
From: "Sri Gundavelli (sgundave)" 
To: Ryuji Wakikawa , Basavaraj Patil 
Thread-Topic: [netext] Consensus call to adopt I-D: draft-wakikawa-netext-pmip-cp-up-separation
Thread-Index: AQHOoutmjZTmEX6R0Eiu3sUpX8a5RQ==
Date: Tue, 27 Aug 2013 06:04:51 +0000
Message-ID: <24C0F3E22276D9438D6F366EB89FAEA8116A6FBA@xmb-aln-x03.cisco.com>
In-Reply-To: <34715EB3-B271-46F2-9E2A-53F736C08CE6@gmail.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.211]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <47365BEC3EA5CA4D8090E2F0C5D8CB8D@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netext@ietf.org" , "draft-wakikawa-netext-pmip-cp-up-separation@tools.ietf.org" , "netext-chairs@tools.ietf.org" 
Subject: Re: [netext] Consensus call to adopt I-D: draft-wakikawa-netext-pmip-cp-up-separation
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, 27 Aug 2013 06:05:24 -0000

Hi Raj,

I support this work.


Regards
Sri





On 8/26/13 11:00 PM, "Ryuji Wakikawa"  wrote:

>Hi Raj
>
>Thanks for the consensus call.
>
>My vote is Yay!=20
>
>thanks,
>ryuji
>
>On Aug 27, 2013, at 1:23 AM, Basavaraj Patil  wrote:
>
>>=20
>> Hello,=20
>>=20
>> This is a consensus call to adopt the following I-D as a working group
>>document. The I-D was discussed at IETF87 and there was consensus at the
>>meeting to adopt it.
>> This email is a followup to allow folks who were not at the meeting to
>>respond as well.
>>=20
>> I-D:  Separation of Control and User Plane for Proxy Mobile IPv6
>>     draft-wakikawa-netext-pmip-cp-up-separation
>>=20
>> Please respond with a Yay or Nay by September 4th, 2013.
>>=20
>> -Chairs
>>=20
>> _______________________________________________
>> 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 John.Kaippallimalil@huawei.com  Tue Aug 27 08:02: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 0EA6E11E8191 for ; Tue, 27 Aug 2013 08:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 aEJK5acyKmRs for ; Tue, 27 Aug 2013 08:02:40 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 278B511E81B7 for ; Tue, 27 Aug 2013 08:02:39 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AWQ35347; Tue, 27 Aug 2013 15:02:37 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 27 Aug 2013 16:01:49 +0100
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 27 Aug 2013 16:02:34 +0100
Received: from DFWEML511-MBB.china.huawei.com ([169.254.4.16]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Tue, 27 Aug 2013 08:02:22 -0700
From: John Kaippallimalil 
To: Basavaraj Patil , "netext@ietf.org" 
Thread-Topic: [netext] Consensus call to adopt I-D: draft-wakikawa-netext-pmip-cp-up-separation
Thread-Index: AQHOonicYvPyPzFtHUu09X2EFgRGepmpJx6g
Date: Tue, 27 Aug 2013 15:02:20 +0000
Message-ID: <6561EABF52675C45BCDACA1B4D7AA117207E00@dfweml511-mbb.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.173]
Content-Type: multipart/alternative; boundary="_000_6561EABF52675C45BCDACA1B4D7AA117207E00dfweml511mbbchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "draft-wakikawa-netext-pmip-cp-up-separation@tools.ietf.org" , "netext-chairs@tools.ietf.org" 
Subject: Re: [netext] Consensus call to adopt I-D:	draft-wakikawa-netext-pmip-cp-up-separation
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, 27 Aug 2013 15:02:45 -0000

--_000_6561EABF52675C45BCDACA1B4D7AA117207E00dfweml511mbbchina_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Raj,
I support this work.

Please respond with a Yay or Nay by September 4th, 2013:
"Yay"

John



From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of=
 Basavaraj Patil
Sent: Monday, August 26, 2013 11:23 AM
To: netext@ietf.org
Cc: draft-wakikawa-netext-pmip-cp-up-separation@tools.ietf.org; netext-chai=
rs@tools.ietf.org
Subject: [netext] Consensus call to adopt I-D: draft-wakikawa-netext-pmip-c=
p-up-separation


Hello,

This is a consensus call to adopt the following I-D as a working group docu=
ment. The I-D was discussed at IETF87 and there was consensus at the meetin=
g to adopt it.
This email is a followup to allow folks who were not at the meeting to resp=
ond as well.

I-D:  Separation of Control and User Plane for Proxy Mobile IPv6

    draft-wakikawa-netext-pmip-cp-up-separation

Please respond with a Yay or Nay by September 4th, 2013.

-Chairs


--_000_6561EABF52675C45BCDACA1B4D7AA117207E00dfweml511mbbchina_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Raj,=



I support this work.=



 <=
/p>

Please respond with a Yay or Nay by September 4th, 2=
013: 



“Yay”


 <=
/p>

John



 <=
/p>

 <=
/p>

 <=
/p>







From: netext-b=
ounces@ietf.org [mailto:netext-bounces@ietf.org]
On Behalf Of Basavaraj Patil

Sent: Monday, August 26, 2013 11:23 AM

To: netext@ietf.org

Cc: draft-wakikawa-netext-pmip-cp-up-separation@tools.ietf.org; nete=
xt-chairs@tools.ietf.org

Subject: [netext] Consensus call to adopt I-D: draft-wakikawa-netext=
-pmip-cp-up-separation






 






 






Hello, 






 






This is a consensus call to adopt the following I-D =
as a working group document. The I-D was discussed at IETF87 and there was =
consensus at the meeting to adopt it. 






This email is a followup to allow folks who were not=
 at the meeting to respond as well.






 






I-D:  Separation of Control and User Plane for Proxy Mobile IPv6<=
/o:p>




  &=
nbsp; draft-wakikawa-netext-pmip-cp-up-separation




 






Please respond with a Yay or Nay by September 4th, 2=
013.






 






-Chairs






 












--_000_6561EABF52675C45BCDACA1B4D7AA117207E00dfweml511mbbchina_--

From asmuhanna@gmail.com  Wed Aug 28 01:44: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 5EB7011E826C for ; Wed, 28 Aug 2013 01:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Level: 
X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
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 6X62rG3eUKqD for ; Wed, 28 Aug 2013 01:44:46 -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 889D411E8269 for ; Wed, 28 Aug 2013 01:44:46 -0700 (PDT)
Received: by mail-oa0-f44.google.com with SMTP id l17so2734326oag.31 for ; Wed, 28 Aug 2013 01:44:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=HQmGnsi7Bd7vRVmWaU9Ds29u6kwxuK7usSw3bOumK2Y=; b=cXHEuTO60KcNOPm4U6Vm0YTmCqSBl7FXe6YMFtFuKJrnz3nGKlbOPIjVHmZPowxA9M 5g79i1a5AbkJOpDlXbhokkZVwqJkaE+HbGB9CVh4flfwdglwpTJLTQY0KinO7j/UTILB 8J3mkirC0uj70pk/JXqRlT396DDsJCu47ndKJ/y7bM1l1p2gLg8W1A7zGM3yjprAzxpb bi32O/H5DzUdhOBMmX0Iv+r4NdfSiR2IfIPYDGW81sN7wE3zDoTRAmAqbjXVMjqVijq6 1xOWtkdwsvHRvv8tghUUfbUHAAL0iEw7ske2x/8eJnQUqRZeeXJIponaU3OiVV9xue/8 fy0g==
X-Received: by 10.182.176.67 with SMTP id cg3mr5559001obc.65.1377679486022; Wed, 28 Aug 2013 01:44:46 -0700 (PDT)
Received: from [192.168.1.66] (adsl-99-30-173-218.dsl.sfldmi.sbcglobal.net. [99.30.173.218]) by mx.google.com with ESMTPSA id xr8sm25016980obc.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 01:44:44 -0700 (PDT)
References: 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-022ED6E6-D912-42C8-9B24-2CCD6538CEAE
Content-Transfer-Encoding: 7bit
Message-Id: <08416D50-5029-4C94-B363-2F5EB095ED7C@gmail.com>
X-Mailer: iPhone Mail (10B329)
From: Ahmad Muhanna 
Date: Wed, 28 Aug 2013 03:44:42 -0500
To: Basavaraj Patil 
Cc: "netext@ietf.org" , "draft-wakikawa-netext-pmip-cp-up-separation@tools.ietf.org" , "netext-chairs@tools.ietf.org" 
Subject: Re: [netext] Consensus call to adopt I-D: draft-wakikawa-netext-pmip-cp-up-separation
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: Wed, 28 Aug 2013 08:44:47 -0000

--Apple-Mail-022ED6E6-D912-42C8-9B24-2CCD6538CEAE
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi Raj,

I support this draft to be adopted as a work group item.

Thanks!

Regards,
Ahmad Muhanna

Sent from my mobile device.

On Aug 26, 2013, at 11:23 AM, Basavaraj Patil  wrote:

>=20
> Hello,=20
>=20
> This is a consensus call to adopt the following I-D as a working group doc=
ument. The I-D was discussed at IETF87 and there was consensus at the meetin=
g to adopt it.=20
> This email is a followup to allow folks who were not at the meeting to res=
pond as well.
>=20
> I-D:  Separation of Control and User Plane for Proxy Mobile IPv6
>     draft-wakikawa-netext-pmip-cp-up-separation
>=20
> Please respond with a Yay or Nay by September 4th, 2013.
>=20
> -Chairs
>=20
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext

--Apple-Mail-022ED6E6-D912-42C8-9B24-2CCD6538CEAE
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


Hi Raj,

I support this draft to be adopted as a work group item.

Thanks!

Regards,
Ahmad Muhanna

Sent from my mobile device.

On Aug 26, 2013, at 11:23 AM, Basavaraj Patil <bpatil1@gmail.com> wrote:


Hello, 

This is a consensus call to adopt the following I-D as a working group document. The I-D was discussed at IETF87 and there was consensus at the meeting to adopt it. 


This email is a followup to allow folks who were not at the meeting to respond as well.

I-D:  Separation of Control and User Plane for Proxy Mobile IPv6


    draft-wakikawa-netext-pmip-cp-up-separation

Please respond with a Yay or Nay by September 4th, 2013.



-Chairs



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

--Apple-Mail-022ED6E6-D912-42C8-9B24-2CCD6538CEAE--

From bpatil1@gmail.com  Wed Aug 28 08:56:37 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 0589121F9EC4 for ; Wed, 28 Aug 2013 08:56:37 -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 1tR+dgXpF3Dm for ; Wed, 28 Aug 2013 08:56:35 -0700 (PDT)
Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 77ECC21F9E88 for ; Wed, 28 Aug 2013 08:56:35 -0700 (PDT)
Received: by mail-oa0-f54.google.com with SMTP id n10so2311968oag.27 for ; Wed, 28 Aug 2013 08:56:35 -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=A5EQK7wvM2xDUM4/NJK1Xbx/aFOzxsChwZ5QiEv3Y1A=; b=Kiy7Ql9W7aAsq6RXp+eFshaJh2Nd1MU+2vAye5xkxmEAMtaQIcweZelx7JaDhB51Jk YGcYUkzuuyN8irKil59m+9D9bcYvb6q/YBhoHt0+xqKsE+52yKgvCYBNnZPvopiJbNiH fItY/MWSd4WCfZhLFO/tMUbN8l3QwFrcd1NgYnvv7O1X7ESc3rP7putFAB2/Jgfsu5sx lK4klPD40fgcCtdRIz5+DrkntFABMIz9PgVndGuRjCIsDpF95WDTtg3ZRgokIjMYvveC riBYFd2VnExt2r+gzZhdZXPKpOaRRlaiaj8FCztwiyds7iTtzkS8m8M8y6TaLEeyslZo ueJg==
MIME-Version: 1.0
X-Received: by 10.182.213.133 with SMTP id ns5mr7061987obc.62.1377705394970; Wed, 28 Aug 2013 08:56:34 -0700 (PDT)
Received: by 10.182.111.138 with HTTP; Wed, 28 Aug 2013 08:56:34 -0700 (PDT)
Date: Wed, 28 Aug 2013 11:56:34 -0400
Message-ID: 
From: Basavaraj Patil 
To: "netext@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c344f4ac788b04e50408f8
Subject: [netext] IETF87 WG meeting minutes
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: Wed, 28 Aug 2013 15:56:37 -0000

--001a11c344f4ac788b04e50408f8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Minutes of the Netext (Network-Based Mobility Extensions) working
group meeting at IETF87
-----------------------------------------------------------------

TUESDAY, July 30, 2013,  Afternoon Session I (1300-1500)
Room: Tiergarten 1/2


Credits for the minutes:
1. Charles Perkins
2. Sandra Cespedes

The chairs would also like to thank Suresh Krishnan for chairing the
meeting at short notice because of travel issues faced by the current
co-chair, Basavaraj Patil who was able to make it to the meeting for
just the last 15 minutes. Rajeev Koodli (co-chair) participated
remotely via jabber/meetecho.

- Update on working group documents presented by Suresh.

Discussion of the WG documents follows:
- Revision of documents that will be on Last Call. The process will be
  on the mailing list.

Juan Carlos-> There is the WG draft pertaining to the logical
interface from 2007. It has received comments but it has been stalled
for at least a year. That's something that should be addressed.
Sri-> Julien said all the comments have been resolved. So the document
should be ready for the last call.
Suresh --> Is there something you have to present right now? If not,
then write it to the mailing list.
Sri--> The only issues that were brought up have been already
resolved. Changes will be highlighted at the mailing list.

Comment from Rajeev:
Chairs think that we need some discussion on on LIF

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

1. Proxy Mobile IPv6 Extensions to Support Flow Mobility
   I-D: draft-ietf-netext-pmipv6-flowmob
   CJ Bernardos

Charlie --> How can you tell if the policies are consistent
Carlos --> You can use many mechanisms. Depend on the deployment but
the draft doesn't defining a specific mechanism.
Suresh --> It is a difficult issue. That is way the decision is to
leave that  outside of the scope of the document
Juan Carlos --> The idea here and the reason for concern is that the
document needs to clarify the need for the policies to be consistent.

Behcet -> (Related to his comments on the draft) I'm tired of talking
about this.  There is a fundamental misunderstanding of what is this
issue. I have posted it to the list and didn't get a reply after 3
months.
Suresh --> Look for the information on the tracker.
Behcet --> I can't find it now. Maybe next week.
Carlos: I copied the description from the tracker. It is about using
the BID when you have different bindings  for different
connections. We are using the binding updates to use them with
different flows.
Suresh: Please take 5 minutes to read the comment of Behcet and
indicate if you think there is a problem.
Sri: I don't see issues about using BID. State is created on the
LMA. I don=B4t understand why are you arguing on this issue for many
months. I think the draft is fine as is.
Juan Carlos: I'm trying to read through. I don't see any issue on this
one. I don't think there is any problem.
Ruji: I didn't follow this problem. I don't see the problem here.
Marco: I don't see the issue. It's just about the identification.
Charlie: You are using the BID to identify the flow?
Carlos: No, it's for identifying the MAG, for the flow you have flow
IDs.
Charlie: You can use the BID for a flow ID.
Carlos: You need to identify the different flows to identify the
bindings.
Marco: It is only used for the identification of the binding, so the
LMA can identify it.
John: I haven't follow in detail but I don't see any problem with this.
Suresh: I personally think it's fine, but let the list decide and give
Behcet time to think more about this.



Suresh: What is the relation of this document with the logical
interface's draft. Is that required for this draft?
Carlos: There is no normative requirement.

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

2. Quality of Service Option for Proxy Mobile IPv6
     I-D: draft-ietf-netext-pmip6-qos-03
Marco Liebsch


Charlie: Bearers are not trivial to be explained.
Marco: We received the comment to clarify the role of bearers in the
document. Bearers and TFT are related to cellular environments, so
here we should not talk about those specific things but instead about
policies per-mobile node and per-flow.
Suresh: I think it's good if you receive more comments on this
draft. Volunteers: Charlie, Josh, Rajesh. Get back with comments in
three weeks.

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

3. Separation of Control and User Plane for Proxy Mobile IPv6
I-D: draft-wakikawa-netext-pmip-cp-up-separation-00
R. Wakikawa

Suresh: The goal is to gauge whether there is WG support to adopt this
draft at the end of this session.

Ryuji: separation of control plane and user plane
also need to update for the alternate CoA option
- UP and CP addresses of LMA can be co-located, not specified
- WiFi scenario (WLC =3D=3D wireless LAN controller)
- has been proposed repeatedly proposed since 2008
- Charlie has agreed to work togethero on this document

Rajeev (jabber): Is there a a need for the WLC and MAG to be collocated?
Ryuji: No, we use it here just as an example.
Marco: I think it's a useful work. How far should this extension go?
Ryuji: We are thinking on defining a single mobility option. Just the
signaling.
Suresh : Calls for voting on adopting the document.
The room agrees on adopting the draft.


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

4. Dynamic CoA Support for PMIPv6
I-D: TBA
Sri Gundavelli

Sri presenting: Indicates the draft is not ready yet.

Bulk Revocation needs a MAG identifier, which is not specified
MAG identifier proposal is close to the format in RFC 4382

No comments from the WG. Need a draft before further discussion.


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

5. Mapping PMIP Quality of Service in WiFi Network
I-D: draft-kaippallimalil-netext-pmip-qos-wifi-02
J. Kaippallimalil

John Kaippallimalil
- has been presented in [netext] before
- is complementary to the PMIP QoS draft
- WiFi AP is modeled as a PEP, as well as WLC
- QoS information from WLC to WiFI AP
- PMIP 802.11e mapping
- WiFi AP does not know how to control traffic
according to WLC / PEP parameters
- What about QoS from the client (i.e., upstream)?
- Marco Liebsch: current QoS draft should be aligned
-- John K. It is intended to be aligned
- Marco: No mechanism yet on the MAG to retrieve the QCI
- Brian: comment from Rajeev: does the draft assume a particular
802.11 implementation?



- Sri, Marco: Looks like a reasonable effort
- Charlie: What is the connection between AP <--> WLC versus
PMIP?  If IP-within-IP replaced PMIP, would anything change
- Document review: Charlie, Ashutosh, Rajesh, Marco


Meeting adjourned at 2:13pm


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


--=20
Basavaraj Patil

--001a11c344f4ac788b04e50408f8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Minutes of the Netext (Network-Based M=
obility Extensions) working
group meeting at IETF87
---=
--------------------------------------------------------------


TUESDAY, July 30, 2013, =A0Afternoon Session I (1300-1500)
=

Room: Tiergarten 1/2


Credits f=
or the minutes:
1. Charles Perkins
2. Sandra Cespedes=
=A0



The chairs would also like to thank Suresh Krishnan for=
 chairing the
meeting at short notice because of travel issues fa=
ced by the current
co-chair, Basavaraj Patil who was able to make=
 it to the meeting for


just the last 15 minutes. Rajeev Koodli (co-chair) participated
<=
div>remotely via jabber/meetecho.=A0

- Update on w=
orking group documents presented by Suresh.=A0

Dis=
cussion of the WG documents follows:


- Revision of documents that will be on Last Call. The process will be=

=A0 on the mailing list.=A0

Juan Carlos=
-> There is the WG draft pertaining to the logical
interface f=
rom 2007. It has received comments but it has been stalled


for at least a year. That's something that should be addressed. =
=A0
Sri-> Julien said all the comments have been resolved. So =
the document
should be ready for the last call.=A0
Sure=
sh --> Is there something you have to present right now? If not,


then write it to the mailing list.=A0
Sri--> The only iss=
ues that were brought up have been already
resolved. Changes will=
 be highlighted at the mailing list.=A0

Comment fr=
om Rajeev:


	Chairs think that w=
e need some discussion on on LIF

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

1. Proxy Mobile IPv6 Extensions to Supp=
ort Flow Mobility=A0


=A0 =A0I-D: draft-ietf-netext-pmipv6-flowmob =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0
=A0 =A0CJ Bernardos

Charlie --&g=
t; How can you tell if the policies are consistent
Carlos --> =
You can use many mechanisms. Depend on the deployment but


the draft doesn't defining a specific mechanism.=A0
Sure=
sh --> It is a difficult issue. That is way the decision is to
leave that =A0outside of the scope of the document =A0
Juan Carl=
os --> The idea here and the reason for concern is that the


document needs to clarify the need for the policies to be consistent.=
=A0

Behcet -> (Related to his comments on the d=
raft) I'm tired of talking
about this. =A0There is a fundamen=
tal misunderstanding of what is this


issue. I have posted it to the list and didn't get a reply after 3=

months.=A0
Suresh --> Look for the information on t=
he tracker.
Behcet --> I can't find it now. Maybe next wee=
k.


Carlos: I copied the description from the tracker. It is about using
the BID when you have different bindings =A0for different
connections. We are using the binding updates to use them with

different flows. =A0
Suresh: Please take 5 minutes to read the co=
mment of Behcet and
indicate if you think there is a problem.=A0<=
/div>
Sri: I don't see issues about using BID. State is created on =
the


LMA. I don=B4t understand why are you arguing on this issue for many
months. I think the draft is fine as is.=A0
Juan Carlos:=
 I'm trying to read through. I don't see any issue on this

one. I don't think there is any problem.=A0
Ruji: I didn'=
t follow this problem. I don't see the problem here.=A0
Marco=
: I don't see the issue. It's just about the identification. =A0

Charlie: You are using the BID to identify the flow?
Carlos:=
 No, it's for identifying the MAG, for the flow you have flow
IDs.=A0
Charlie: You can use the BID for a flow ID.

Carlos: You need to identify the different flows to identify the
=
bindings.=A0
Marco: It is only used for the identification of the=
 binding, so the
LMA can identify it.=A0
John: I haven&=
#39;t follow in detail but I don't see any problem with this.


Suresh: I personally think it's fine, but let the list decide and =
give
Behcet time to think more about this.=A0



Suresh: What is the relation of this do=
cument with the logical


interface's draft. Is that required for this draft?=A0
C=
arlos: There is no normative requirement.=A0

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

2. Quality of Service Optio=
n for Proxy Mobile IPv6


=A0 =A0 =A0I-D: draft-ietf-netext-pmip6-qos-03 	 =A0 =A0 =A0		
Marco Liebsch


Charlie: Bearers are not trivial to be explained.=A0


Marco: We received the comment to clarify the role of bearers in the
document. Bearers and TFT are related to cellular environments, so=

here we should not talk about those specific things but instead =
about


policies per-mobile node and per-flow.=A0
Suresh: I think it=
's good if you receive more comments on this
draft. Volunteer=
s: Charlie, Josh, Rajesh. Get back with comments in
three weeks.=
=A0



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

3.=
 Separation of Control and User Plane for Proxy Mobile IPv6=A0
I-=
D: draft-wakikawa-netext-pmip-cp-up-separation-00 =A0=A0
R. Wakik=
awa



Suresh: The goal is to gauge whether there is WG suppor=
t to adopt this
draft at the end of this session.=A0
Ryuji: separation of control plane and user plane

	also need to update for =
the alternate CoA option
	- UP and CP addresses of LMA can be co-located, not specified

	- WiFi scenario (WLC =3D=
=3D wireless LAN controller)
	- has been proposed repeatedly proposed since 2008
	- Charlie has agreed to=
 work togethero on this document



Rajeev (jabber): Is there a a need for the WLC and MAG =
to be collocated?
Ryuji: No, we use it here just as an example.
Marco: I think it's a useful work. How far should this extensi=
on go?


Ryuji: We are thinking on defining a single mobility option. Just the =
signaling.
Suresh : Calls for voting on adopting the document.
The room agrees on adopting the draft.



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

4. Dyna=
mic CoA Support for PMIPv6			
I-D: TBA =A0 =A0	=
 =A0 =A0 =A0 	 =A0=
 		


Sri Gundavelli

Sri presenting: Indicates the =
draft is not ready yet.

	Bulk Revocation needs a MAG identifier, which is n=
ot specified


	MAG identifier prop=
osal is close to the format in RFC 4382

No comment=
s from the WG. Need a draft before further discussion.




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

5.=
 Mapping PMIP Quality of Service in WiFi Network	
I-D: draft-kaippallimalil-netext-pmip-qo=
s-wifi-02 =A0


J. Kaippallimalil

John Kaippallimalil
	- has been presented =
in [netext] before
	- is complementary to the PMIP QoS draft


	- WiFi AP is modele=
d as a PEP, as well as WLC
	- QoS information from WLC to WiFI AP
	- PMIP 802.11e mapping


	- WiFi AP does not =
know how to control traffic
		according to WLC / PEP parameters
- What about QoS=
 from the client (i.e., upstream)?


- Marco Liebsch: current QoS draft should be aligned
	-- John K. It is intended to be=
 aligned
- Marco: No mechanism yet on the MAG to retrieve the QCI=



- Brian: comment from Rajeev: does the draft assume a particular
=

	802.11 implementati=
on?

<Basavaraj shows up finally>
<=
br>

- Sri, Marco: Looks like a reasonable effort
- Charlie=
: What is the connection between AP <--> WLC versus
	PMIP? =A0If IP-within-IP replac=
ed PMIP, would anything change=A0


- Document review: Charlie, Ashutosh, Rajesh, Marco


Meeting adjourned at 2:13pm

=

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




-- 
Basavaraj Patil



--001a11c344f4ac788b04e50408f8--

From cjbernardos@gmail.com  Wed Aug 28 13:45: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 4569521E8095 for ; Wed, 28 Aug 2013 13:45:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 rolRNKLfws+Z for ; Wed, 28 Aug 2013 13:45:47 -0700 (PDT)
Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 77E7621E8093 for ; Wed, 28 Aug 2013 13:45:44 -0700 (PDT)
Received: by mail-ob0-f170.google.com with SMTP id eh20so7331239obb.15 for ; Wed, 28 Aug 2013 13:45:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RHAhb2bSgTwuVggCgOr75v/jBYukJ8BwCDBYIIb+wtQ=; b=Br+GJfHKL9wBaNdUDF3x4l/7sJuSqSQ++QxVfWpulXFDU5m5LGUBQoh54HVfV1LYHv JQskvvDen8/mpc2Mp3StLlhYuLNfqBJuNktL7i+yZBxWOdVn9fklVIJ1WGxf6Ps0bqPs ETEukAJp+zT8//MlIngzmzB95g4DfeBj9IpuNQIJ9Y7dKrbmpWasDjLxsDVjqfBXeYhZ CANAtaFRZBIxwv0KLoxCRA95XYJ7Pnyq/oi8hhIaJ49ymHJtSc2KOqy+f5NgWCz4XtNf Usog+q85KmL4WpIXxuWwxw+ajlkcWu8U4lngbrCkHQs0+DPSqaYOxaiJIZqerSFlQgpK X+9g==
MIME-Version: 1.0
X-Received: by 10.60.124.14 with SMTP id me14mr24670872oeb.4.1377722743028; Wed, 28 Aug 2013 13:45:43 -0700 (PDT)
Sender: cjbernardos@gmail.com
Received: by 10.182.19.233 with HTTP; Wed, 28 Aug 2013 13:45:42 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 28 Aug 2013 22:45:42 +0200
X-Google-Sender-Auth: COcW79fnmhfH0ROmvPSjRBx0jAs
Message-ID: 
From: =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= 
To: Basavaraj Patil 
Content-Type: multipart/alternative; boundary=047d7b5d33d4b280ba04e50812c9
Cc: "netext@ietf.org" 
Subject: Re: [netext] IETF87 WG meeting minutes
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: Wed, 28 Aug 2013 20:45:48 -0000

--047d7b5d33d4b280ba04e50812c9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

Thanks a lot Sandra, Charlie, and Raj for collecting the minutes. One
addition on the "Proxy Mobile IPv6 Extensions to Support Flow Mobility"
part. It was decided in the meeting that the editor of the draft would be
posting the proposal resolutions for each open issue to the mailing list,
so a consensus call could be done to agree on how to close them.

BTW, I'm currently working on it. I will post a new version of the I-D soon
covering already some of them and then work on the few pending ones.

Thanks,

Carlos


On 28 August 2013 17:56, Basavaraj Patil  wrote:

>
> Minutes of the Netext (Network-Based Mobility Extensions) working
> group meeting at IETF87
> -----------------------------------------------------------------
>
> TUESDAY, July 30, 2013,  Afternoon Session I (1300-1500)
> Room: Tiergarten 1/2
>
>
> Credits for the minutes:
> 1. Charles Perkins
> 2. Sandra Cespedes
>
> The chairs would also like to thank Suresh Krishnan for chairing the
> meeting at short notice because of travel issues faced by the current
> co-chair, Basavaraj Patil who was able to make it to the meeting for
> just the last 15 minutes. Rajeev Koodli (co-chair) participated
> remotely via jabber/meetecho.
>
> - Update on working group documents presented by Suresh.
>
> Discussion of the WG documents follows:
> - Revision of documents that will be on Last Call. The process will be
>   on the mailing list.
>
> Juan Carlos-> There is the WG draft pertaining to the logical
> interface from 2007. It has received comments but it has been stalled
> for at least a year. That's something that should be addressed.
> Sri-> Julien said all the comments have been resolved. So the document
> should be ready for the last call.
> Suresh --> Is there something you have to present right now? If not,
> then write it to the mailing list.
> Sri--> The only issues that were brought up have been already
> resolved. Changes will be highlighted at the mailing list.
>
> Comment from Rajeev:
>  Chairs think that we need some discussion on on LIF
>
> ---------------------------
>
> 1. Proxy Mobile IPv6 Extensions to Support Flow Mobility
>    I-D: draft-ietf-netext-pmipv6-flowmob
>    CJ Bernardos
>
> Charlie --> How can you tell if the policies are consistent
> Carlos --> You can use many mechanisms. Depend on the deployment but
> the draft doesn't defining a specific mechanism.
> Suresh --> It is a difficult issue. That is way the decision is to
> leave that  outside of the scope of the document
> Juan Carlos --> The idea here and the reason for concern is that the
> document needs to clarify the need for the policies to be consistent.
>
> Behcet -> (Related to his comments on the draft) I'm tired of talking
> about this.  There is a fundamental misunderstanding of what is this
> issue. I have posted it to the list and didn't get a reply after 3
> months.
> Suresh --> Look for the information on the tracker.
> Behcet --> I can't find it now. Maybe next week.
> Carlos: I copied the description from the tracker. It is about using
> the BID when you have different bindings  for different
> connections. We are using the binding updates to use them with
> different flows.
> Suresh: Please take 5 minutes to read the comment of Behcet and
> indicate if you think there is a problem.
> Sri: I don't see issues about using BID. State is created on the
> LMA. I don=B4t understand why are you arguing on this issue for many
> months. I think the draft is fine as is.
> Juan Carlos: I'm trying to read through. I don't see any issue on this
> one. I don't think there is any problem.
> Ruji: I didn't follow this problem. I don't see the problem here.
> Marco: I don't see the issue. It's just about the identification.
> Charlie: You are using the BID to identify the flow?
> Carlos: No, it's for identifying the MAG, for the flow you have flow
> IDs.
> Charlie: You can use the BID for a flow ID.
> Carlos: You need to identify the different flows to identify the
> bindings.
> Marco: It is only used for the identification of the binding, so the
> LMA can identify it.
> John: I haven't follow in detail but I don't see any problem with this.
> Suresh: I personally think it's fine, but let the list decide and give
> Behcet time to think more about this.
>
>
>
> Suresh: What is the relation of this document with the logical
> interface's draft. Is that required for this draft?
> Carlos: There is no normative requirement.
>
> ---------------------------
>
> 2. Quality of Service Option for Proxy Mobile IPv6
>      I-D: draft-ietf-netext-pmip6-qos-03
> Marco Liebsch
>
>
> Charlie: Bearers are not trivial to be explained.
> Marco: We received the comment to clarify the role of bearers in the
> document. Bearers and TFT are related to cellular environments, so
> here we should not talk about those specific things but instead about
> policies per-mobile node and per-flow.
> Suresh: I think it's good if you receive more comments on this
> draft. Volunteers: Charlie, Josh, Rajesh. Get back with comments in
> three weeks.
>
> ---------------------------
>
> 3. Separation of Control and User Plane for Proxy Mobile IPv6
> I-D: draft-wakikawa-netext-pmip-cp-up-separation-00
> R. Wakikawa
>
> Suresh: The goal is to gauge whether there is WG support to adopt this
> draft at the end of this session.
>
> Ryuji: separation of control plane and user plane
>  also need to update for the alternate CoA option
> - UP and CP addresses of LMA can be co-located, not specified
>  - WiFi scenario (WLC =3D=3D wireless LAN controller)
> - has been proposed repeatedly proposed since 2008
> - Charlie has agreed to work togethero on this document
>
> Rajeev (jabber): Is there a a need for the WLC and MAG to be collocated?
> Ryuji: No, we use it here just as an example.
> Marco: I think it's a useful work. How far should this extension go?
> Ryuji: We are thinking on defining a single mobility option. Just the
> signaling.
> Suresh : Calls for voting on adopting the document.
> The room agrees on adopting the draft.
>
>
> ---------------------------
>
> 4. Dynamic CoA Support for PMIPv6
> I-D: TBA
> Sri Gundavelli
>
> Sri presenting: Indicates the draft is not ready yet.
>
> Bulk Revocation needs a MAG identifier, which is not specified
>  MAG identifier proposal is close to the format in RFC 4382
>
> No comments from the WG. Need a draft before further discussion.
>
>
> ---------------------------
>
> 5. Mapping PMIP Quality of Service in WiFi Network
> I-D: draft-kaippallimalil-netext-pmip-qos-wifi-02
> J. Kaippallimalil
>
> John Kaippallimalil
> - has been presented in [netext] before
> - is complementary to the PMIP QoS draft
>  - WiFi AP is modeled as a PEP, as well as WLC
> - QoS information from WLC to WiFI AP
> - PMIP 802.11e mapping
>  - WiFi AP does not know how to control traffic
> according to WLC / PEP parameters
> - What about QoS from the client (i.e., upstream)?
> - Marco Liebsch: current QoS draft should be aligned
> -- John K. It is intended to be aligned
> - Marco: No mechanism yet on the MAG to retrieve the QCI
> - Brian: comment from Rajeev: does the draft assume a particular
> 802.11 implementation?
>
> 
>
> - Sri, Marco: Looks like a reasonable effort
> - Charlie: What is the connection between AP <--> WLC versus
> PMIP?  If IP-within-IP replaced PMIP, would anything change
> - Document review: Charlie, Ashutosh, Rajesh, Marco
>
>
> Meeting adjourned at 2:13pm
>
>
> ---------------------------
>
>
> --
> Basavaraj Patil
>
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext
>
>

--047d7b5d33d4b280ba04e50812c9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi,

Thanks a lot Sandra, Charl=
ie, and Raj for collecting the minutes. One addition on the "Proxy Mob=
ile IPv6 Extensions to Support Flow Mobility" part. It was decided in =
the meeting that the editor of the draft would be posting the proposal reso=
lutions for each open issue to the mailing list, so a consensus call could =
be done to agree on how to close them.


BTW, I'm currently working on it. I will post a new version o=
f the I-D soon covering already some of them and then work on the few pendi=
ng ones.

Thanks,

Carlos



On 28 August 2013 17:56, Basavaraj Patil=
 <bpatil1@gmail.com> wrote:

Minutes of the Netext (Network-Based M=
obility Extensions) working
group meeting at IETF87
---=
--------------------------------------------------------------




TUESDAY, July 30, 2013, =A0Afternoon Session I (1300-1500)
=

Room: Tiergarten 1/2


Credits f=
or the minutes:
1. Charles Perkins
2. Sandra Cespedes=
=A0




The chairs would also like to thank Suresh Krishnan for=
 chairing the
meeting at short notice because of travel issues fa=
ced by the current
co-chair, Basavaraj Patil who was able to make=
 it to the meeting for



just the last 15 minutes. Rajeev Koodli (co-chair) participated
<=
div>remotely via jabber/meetecho.=A0

- Update on w=
orking group documents presented by Suresh.=A0

Dis=
cussion of the WG documents follows:



- Revision of documents that will be on Last Call. The process will be=

=A0 on the mailing list.=A0

Juan Carlos=
-> There is the WG draft pertaining to the logical
interface f=
rom 2007. It has received comments but it has been stalled



for at least a year. That's something that should be addressed. =
=A0
Sri-> Julien said all the comments have been resolved. So =
the document
should be ready for the last call.=A0
Sure=
sh --> Is there something you have to present right now? If not,



then write it to the mailing list.=A0
Sri--> The only iss=
ues that were brought up have been already
resolved. Changes will=
 be highlighted at the mailing list.=A0

Comment fr=
om Rajeev:



	Chairs think that we need=
 some discussion on on LIF

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

1. Proxy Mobile IPv6 Extensions to Support Fl=
ow Mobility=A0



=A0 =A0I-D: draft-ietf-netext-pmipv6-flowmob =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0
=A0 =A0CJ Bernardos

Charlie --&g=
t; How can you tell if the policies are consistent
Carlos --> =
You can use many mechanisms. Depend on the deployment but



the draft doesn't defining a specific mechanism.=A0
Sure=
sh --> It is a difficult issue. That is way the decision is to
leave that =A0outside of the scope of the document =A0
Juan Carl=
os --> The idea here and the reason for concern is that the



document needs to clarify the need for the policies to be consistent.=
=A0

Behcet -> (Related to his comments on the d=
raft) I'm tired of talking
about this. =A0There is a fundamen=
tal misunderstanding of what is this



issue. I have posted it to the list and didn't get a reply after 3=

months.=A0
Suresh --> Look for the information on t=
he tracker.
Behcet --> I can't find it now. Maybe next wee=
k.



Carlos: I copied the description from the tracker. It is about using
the BID when you have different bindings =A0for different
connections. We are using the binding updates to use them with


different flows. =A0
Suresh: Please take 5 minutes to read the co=
mment of Behcet and
indicate if you think there is a problem.=A0<=
/div>
Sri: I don't see issues about using BID. State is created on =
the



LMA. I don=B4t understand why are you arguing on this issue for many
months. I think the draft is fine as is.=A0
Juan Carlos:=
 I'm trying to read through. I don't see any issue on this


one. I don't think there is any problem.=A0
Ruji: I didn'=
t follow this problem. I don't see the problem here.=A0
Marco=
: I don't see the issue. It's just about the identification. =A0


Charlie: You are using the BID to identify the flow?
Carlos:=
 No, it's for identifying the MAG, for the flow you have flow
IDs.=A0
Charlie: You can use the BID for a flow ID.


Carlos: You need to identify the different flows to identify the
=
bindings.=A0
Marco: It is only used for the identification of the=
 binding, so the
LMA can identify it.=A0
John: I haven&=
#39;t follow in detail but I don't see any problem with this.



Suresh: I personally think it's fine, but let the list decide and =
give
Behcet time to think more about this.=A0



Suresh: What is the relation of this do=
cument with the logical



interface's draft. Is that required for this draft?=A0
C=
arlos: There is no normative requirement.=A0

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

2. Quality of Service Optio=
n for Proxy Mobile IPv6



=A0 =A0 =A0I-D: draft-ietf-netext-pmip6-qos-03 	 =A0 =A0 =A0		
Marco Liebsch


Charl=
ie: Bearers are not trivial to be explained.=A0



Marco: We received the comment to clarify the role of bearers in the
document. Bearers and TFT are related to cellular environments, so=

here we should not talk about those specific things but instead =
about



policies per-mobile node and per-flow.=A0
Suresh: I think it=
's good if you receive more comments on this
draft. Volunteer=
s: Charlie, Josh, Rajesh. Get back with comments in
three weeks.=
=A0




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

3.=
 Separation of Control and User Plane for Proxy Mobile IPv6=A0
I-=
D: draft-wakikawa-netext-pmip-cp-up-separation-00 =A0=A0
R. Wakik=
awa




Suresh: The goal is to gauge whether there is WG suppor=
t to adopt this
draft at the end of this session.=A0
Ryuji: separation of control plane and user plane


	also need to update for the al=
ternate CoA option
	-=
 UP and CP addresses of LMA can be co-located, not specified

	- WiFi scenario (WLC =3D=3D wi=
reless LAN controller)
	- has been proposed repeatedly proposed since 2008
	- Charlie has agreed to work togethero on=
 this document




Rajeev (jabber): Is there a a need for the WLC and MAG =
to be collocated?
Ryuji: No, we use it here just as an example.
Marco: I think it's a useful work. How far should this extensi=
on go?



Ryuji: We are thinking on defining a single mobility option. Just the =
signaling.
Suresh : Calls for voting on adopting the document.
The room agrees on adopting the draft.




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

4. Dyna=
mic CoA Support for PMIPv6			
I-D: TBA =A0 =A0	 =A0 =
=A0 =A0 	 =A0 		



Sri Gundavelli

Sri presenting: Indicates the =
draft is not ready yet.

	Bulk Revocation needs a MAG identifier, which is not spe=
cified



	MAG identifier proposal i=
s close to the format in RFC 4382

No comments from=
 the WG. Need a draft before further discussion.




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

5.=
 Mapping PMIP Quality of Service in WiFi Network	
I-D: draft-kaippallimalil-netext-pmip-qos-wifi=
-02 =A0



J. Kaippallimalil

John Kaippallimalil
	- has been presented in [ne=
text] before
	- is co=
mplementary to the PMIP QoS draft



	- WiFi AP is modeled as a=
 PEP, as well as WLC
	- QoS information from WLC to WiFI AP
	- PMIP 802.11e mapping



	- WiFi AP does not know h=
ow to control traffic
		according to WLC / PEP parameters
- What about QoS from the cl=
ient (i.e., upstream)?



- Marco Liebsch: current QoS draft should be aligned
	-- John K. It is intended to be align=
ed
- Marco: No mechanism yet on the MAG to retrieve the QCI



- Brian: comment from Rajeev: does the draft assume a particular
=

	802.11 implementation?

<Basavaraj shows up finally>




- Sri, Marco: Looks like a reasonable effort
- Charlie=
: What is the connection between AP <--> WLC versus
	PMIP? =A0If IP-within-IP replaced PMI=
P, would anything change=A0



- Document review: Charlie, Ashutosh, Rajesh, Marco


Meeting adjourned at 2:13pm

=

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





-- 
Basavaraj Patil



_______________________________________________

netext mailing list

netext@ietf.org

=
https://www.ietf.org/mailman/listinfo/netext





--047d7b5d33d4b280ba04e50812c9--

From iesg-secretary@ietf.org  Thu Aug 29 00:11:28 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 7A37D11E80F8; Thu, 29 Aug 2013 00:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.493
X-Spam-Level: 
X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.107, 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 0z4Al-XMPiv9; Thu, 29 Aug 2013 00:11:27 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA07721F9D5F; Thu, 29 Aug 2013 00:11:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: DraftTracker Mail System 
To: iesg@ietf.org, netext-chairs@tools.ietf.org, draft-ietf-netext-update-notifications@tools.ietf.org, netext@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.70.p1
Message-ID: <20130829071124.335.6247.idtracker@ietfa.amsl.com>
Date: Thu, 29 Aug 2013 00:11:24 -0700
Cc: iesg-secretary@ietf.org
Subject: [netext] Last Call Expired: 
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, 29 Aug 2013 07:11:28 -0000

Please DO NOT reply to this email.

I-D: 
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-netext-update-no=
tifications/

IETF Last Call has ended, and the state has been changed to
Waiting for Writeup.


From internet-drafts@ietf.org  Thu Aug 29 01:16: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 3E13E21E8093; Thu, 29 Aug 2013 01:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.563
X-Spam-Level: 
X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, 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 VjS4c9SnNrwk; Thu, 29 Aug 2013 01:16:25 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BB821F9FDA; Thu, 29 Aug 2013 01:16:25 -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.70.p1
Message-ID: <20130829081625.17916.31878.idtracker@ietfa.amsl.com>
Date: Thu, 29 Aug 2013 01:16:25 -0700
Cc: netext@ietf.org
Subject: [netext] I-D Action: draft-ietf-netext-update-notifications-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: Thu, 29 Aug 2013 08:16:26 -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-08.txt
	Pages           : 19
	Date            : 2013-08-29

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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-update-notifications-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 internet-drafts@ietf.org  Thu Aug 29 01:16: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 9E66121E8064 for ; Thu, 29 Aug 2013 01:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.563
X-Spam-Level: 
X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, 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 8wtjeN7Mhfw0; Thu, 29 Aug 2013 01:16:26 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D687221E8085; Thu, 29 Aug 2013 01:16:25 -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.70.p1
Message-ID: <20130829081625.17916.39872.idtracker@ietfa.amsl.com>
Date: Thu, 29 Aug 2013 01:16:25 -0700
Subject: [netext] New Version Notification -	draft-ietf-netext-update-notifications-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: Thu, 29 Aug 2013 08:16:26 -0000

A new version (-08) has been submitted for draft-ietf-netext-update-notific=
ations:
http://www.ietf.org/internet-drafts/draft-ietf-netext-update-notifications-=
08.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-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.

IETF Secretariat.


From sarikaya2012@gmail.com  Thu Aug 29 09:10:14 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 4C84621F933B for ; Thu, 29 Aug 2013 09:10:13 -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 Qpd85RB8IMR8 for ; Thu, 29 Aug 2013 09:10:11 -0700 (PDT)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id D82C421F908F for ; Thu, 29 Aug 2013 09:10:03 -0700 (PDT)
Received: by mail-lb0-f178.google.com with SMTP id z5so877333lbh.23 for ; Thu, 29 Aug 2013 09:10:00 -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=RkccIIztlm9qq6EL+ieTJ4yGFxa5+1hBf2bpRpXPXJU=; b=lYIdgs+DD/BD8waaHaFbx2jauP/hu7Jhhx0rXNB1rTq2z9NQ8V3CM3owv14Ins6NCK ASSIuInnFK6SD31wVQ39b0DF4tFLHWFVDxRuWcXLvrAsSuzYktvIJWyhgbXfToijsFxm V+Y8K+v+HEjdnk3vSz01fgXF+9bxZJw4spwfIpYn0Qcc4DY5sqg2aarPlGrzRrih1UWG 5oZPXmSERxYvPMAvjtTXxj0PHF9cbxWC/GYC4Htfx31QrVzpAEbJm8cWj/vLbFUa1Hlu /YxEFhJ8q6zkUGSV/yhiG3f5OghpLB/WMOHDejDekRd7F5XWTyG3gCodW5cNgtS3LDiP /TAg==
MIME-Version: 1.0
X-Received: by 10.112.77.134 with SMTP id s6mr2266770lbw.38.1377792599880; Thu, 29 Aug 2013 09:09:59 -0700 (PDT)
Received: by 10.114.98.227 with HTTP; Thu, 29 Aug 2013 09:09:59 -0700 (PDT)
In-Reply-To: <1377735094.4512.11.camel@acorde.it.uc3m.es>
References:  <1377735094.4512.11.camel@acorde.it.uc3m.es>
Date: Thu, 29 Aug 2013 11:09:59 -0500
Message-ID: 
From: Behcet Sarikaya 
To: "Carlos J. Bernardos" 
Content-Type: multipart/alternative; boundary=001a11c3dfba7d797904e51856cc
Cc: "netext@ietf.org" 
Subject: Re: [netext] draft-netext-pmipv6-flowmob
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: Thu, 29 Aug 2013 16:10:14 -0000

--001a11c3dfba7d797904e51856cc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Carlos,

Please see inline.

Regards,

Behcet

On Wed, Aug 28, 2013 at 7:11 PM, Carlos Jes=FAs Bernardos Cano <
cjbc@it.uc3m.es> wrote:

> Hi Behcet,
>
> On Fri, 2013-08-23 at 16:31 -0500, Behcet Sarikaya wrote:
> > Hi Carlos,
> >
> >
> > As per issues I placed in the issue tracker, your replies and as per
> > Berlin discussions, I would to clarify the issues as follows:
> >
> > About BID: In RFC 5648, Each BID is generated and
> >       managed by a mobile node.
> >       In Section 5.1, it says A mobile node assigns a BID to each
> > care-of address when it wants to
> >    register them simultaneously with its home address.
> >    That means BID being 16 bits long is basically a short name for
> > each care-of address.
> >
> >       In draft-netext-pmipv6-flowmob, you defined BID to be assigned
> > and used by the local mobility anchor to identify which
> >    entry of the flow mobility cache is used to decide how to route a
> >    given flow.
> >    As such, your BID is very different than RFC 5648. Simple protocol
> > engineering requires giving it a different name. Maybe pBID but even
> > pBID is not appropriate because your BID is not proxy version of
> > rfc5648's BID.
>
> The BID is just a binding identifier, and this is its purpose on the
> draft, to identify a binding. The intention is to avoid introducing new
> conceptual structures if possible, re-using some already defined for
> client-based flow mobility.
>
>
Here two points:
First naming, remember what RFC 5213 defined:

A Binding Update message that is sent by a mobile access gateway to a
   local mobility anchor is referred to as the "Proxy Binding Update"
   message.

 In a similar spirit maybe you should call it pBID.

Second the use of this identifier. In RFC 6089, flow binding cache is also
kept in MN and it is the MN that needs the BID. Why should LMA need it?
Does MAG need it? It does not have many Proxy-CoAs?


>
> > About how to route a given flow: I don't understand why you are so
> > much worried about it. From RFC6089, table of flow binding entries
> > should be used to route the flows.
> > Your protocol should describe what you have in each flow binding
> > entry, (including MN interface care-of address) and how you manage
> > these flow binding entries.
>
> I don't understand what you mean by "MN interface care-of address". I'll
> revise the text to ensure it is clear how the flow entries (the FMC)
> managed by the LMA is used.
>

It means Proxy-CoA. But you are not addressing my main comment here, why?


> >
> > I am unable to see these things in draft-netext-pmipv6-flowmob and I
> > think that's why you seem to be so much concerned about how to route a
> > given flow.
> >
> > About marking the interfaces: In RFC5648, Home Link and Visited Link
> > are very clearly distinguished. Home link is well defined in MIPv6. So
> > other links are visited links.
> >
> > In RFC 5213, for each interface a different binding cache is created.
> > Each interface is a different mobility session. That effectively means
> > each interface is a different MN.
> >
> > But in draft-netext-pmipv6-flowmob, you want to integrate binding
> > cache entries for the same MN into one so as not to create a separate
> > mobility session for each.
>
> Not really, the idea is to be able to identify bindings (and therefore
> the use of the BID).
>

Here is one major problem we had in defining flow mobility protocol for
PMIPv6. In mext, the problem has been divided into two issues, mcoa and
flow mobility. In Netext, we failed to do this even though the same problem
exists in PMIP.




> >
> >
> > In that case, you need to mark these binding cache entries properly.
> > One suggestion is to mark the first one as Home Link and all others
> > Visited link and let each MAG know the marking by LMA.
> > Each MAG should keep HNPs assigned to its interface as well as to the
> > home link interface.
> > This enables MN to always use  source address(es) assigned to the home
> > link and thus MAGs can properly route these packets upwards. Downward
> > routing is as I mentioned above, based on flow mobility binding cache.
> >
> I don't see the need to mark the BCEs.
>
>
Again you are staying away from the real problem with arguments like the
above.


> In any case, I'm about to submit a revision that addresses some of the
> issues raised by Pierrick. I'm still working on other changes, such as
> the use of the update-notifications, as well as trying to simplify the
> document as much as possible. I hope that this will also address some of
> your concerns. So please, wait to -08 (will be out in the next couple of
> weeks) and check if you are happier with that version.
>
>
I am responsible to be after the issues I raised.

Thanks,
>
> Carlos
> >
> > Regards,
> >
> >
> > Behcet
> >
>
>
>

--001a11c3dfba7d797904e51856cc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Carlos,

Please see inline.

Regards,=


Behcet


On Wed, Aug 28, 2013 at 7:11 PM, Carlos Jes=
=FAs Bernardos Cano <cjbc@it.uc3m.es> wrote:

Hi Behcet,




On Fri, 2013-08-23 at 16:31 -0500, Behcet Sarikaya wrote:

> Hi Carlos,

>

>

> As per issues I placed in the issue tracker, your replies and as per
> Berlin discussions, I would to clarify the issues as follows:

>

> About BID: In RFC 5648, Each BID is generated and

> =A0 =A0 =A0 managed by a mobile node.

> =A0 =A0 =A0 In Section 5.1, it says A mobile node assigns a BID to eac=
h

> care-of address when it wants to

> =A0 =A0register them simultaneously with its home address.

> =A0 =A0That means BID being 16 bits long is basically a short name for=


> each care-of address.

>

> =A0 =A0 =A0 In draft-netext-pmipv6-flowmob, you defined BID to be assi=
gned

> and used by the local mobility anchor to identify which

> =A0 =A0entry of the flow mobility cache is used to decide how to route=
 a

> =A0 =A0given flow.

> =A0 =A0As such, your BID is very different than RFC 5648. Simple proto=
col

> engineering requires giving it a different name. Maybe pBID but even
> pBID is not appropriate because your BID is not proxy version of

> rfc5648's BID.




The BID is just a binding identifier, and this is its purpose on the<=
br>
draft, to identify a binding. The intention is to avoid introducing new

conceptual structures if possible, re-using some already defined for

client-based flow mobility.




Here two point=
s:
First naming, remember what RFC 5213 defined:
A Binding Update message that is sent by a mobile access gateway to =
a
   local mobility anchor is referred to as the "Proxy Binding Update&q=
uot;
   message.
=A0In a similar spirit maybe you should call it pBID.
<=
br>
Second the use of this identifier. In RFC 6089, flow binding =
cache is also kept in MN and it is the MN that needs the BID. Why should LM=
A need it? Does MAG need it? It does not have many Proxy-CoAs?




>

> About how to route a given flow: I don't understand why you are so=


> much worried about it. From RFC6089, table of flow binding entries

> should be used to route the flows.

> Your protocol should describe what you have in each flow binding

> entry, (including MN interface care-of address) and how you manage

> these flow binding entries.




I don't understand what you mean by "MN interface care-of ad=
dress". I'll

revise the text to ensure it is clear how the flow entries (the FMC)

managed by the LMA is used.

It means Pr=
oxy-CoA. But you are not addressing my main comment here, why?
=A0



>

> I am unable to see these things in draft-netext-pmipv6-flowmob and I
> think that's why you seem to be so much concerned about how to rou=
te a

> given flow.

>

> About marking the interfaces: In RFC5648, Home Link and Visited Link
> are very clearly distinguished. Home link is well defined in MIPv6. So=


> other links are visited links.

>

> In RFC 5213, for each interface a different binding cache is created.<=
br>
> Each interface is a different mobility session. That effectively means=


> each interface is a different MN.

>

> But in draft-netext-pmipv6-flowmob, you want to integrate binding

> cache entries for the same MN into one so as not to create a separate<=
br>
> mobility session for each.




Not really, the idea is to be able to identify bindings (and therefor=
e

the use of the BID).

Here is one major =
problem we had in defining flow mobility protocol for PMIPv6. In mext, the =
problem has been divided into two issues, mcoa and flow mobility. In Netext=
, we failed to do this even though the same problem exists in PMIP.




=A0


>

>

> In that case, you need to mark these binding cache entries properly.
> One suggestion is to mark the first one as Home Link and all others
> Visited link and let each MAG know the marking by LMA.

> Each MAG should keep HNPs assigned to its interface as well as to the<=
br>
> home link interface.

> This enables MN to always use =A0source address(es) assigned to the ho=
me

> link and thus MAGs can properly route these packets upwards. Downward<=
br>
> routing is as I mentioned above, based on flow mobility binding cache.=


>


I don't see the need to mark the BCEs.



Again you are staying away from the re=
al problem with arguments like the above.
=A0


In any case, I'm about to submit a revision that addresses some of the<=
br>
issues raised by Pierrick. I'm still working on other changes, such as<=
br>
the use of the update-notifications, as well as trying to simplify the

document as much as possible. I hope that this will also address some of
your concerns. So please, wait to -08 (will be out in the next couple of
weeks) and check if you are happier with that version.



I am responsible to be after the issue=
s I raised. 



Thanks,



Carlos

>

> Regards,

>

>

> Behcet

>









--001a11c3dfba7d797904e51856cc--

From cjbc@it.uc3m.es  Thu Aug 29 20:09:05 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 F38D221E804C for ; Thu, 29 Aug 2013 20:09:04 -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 e3cg3Pe3mX1S for ; Thu, 29 Aug 2013 20:08:58 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4C321E804B for ; Thu, 29 Aug 2013 20:08:57 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DA942CB2093; Fri, 30 Aug 2013 05:08:55 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [163.117.203.89] (unknown [163.117.203.89]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 44CD2C35382; Fri, 30 Aug 2013 05:08:55 +0200 (CEST)
Message-ID: <1377832130.4300.0.camel@acorde.it.uc3m.es>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano 
To: sarikaya@ieee.org
Date: Fri, 30 Aug 2013 05:08:50 +0200
In-Reply-To: 
References: 
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.4.4-3 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20114.004
Cc: "netext@ietf.org" 
Subject: Re: [netext] draft-netext-pmipv6-flowmob
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: Fri, 30 Aug 2013 03:09:05 -0000

(resending, as I think this e-mail didn't make due to the problems with
mailman on the IETF servers)

Hi Behcet,

On Fri, 2013-08-23 at 16:31 -0500, Behcet Sarikaya wrote:
> Hi Carlos,
> 
> 
> As per issues I placed in the issue tracker, your replies and as per
> Berlin discussions, I would to clarify the issues as follows:
> 
> About BID: In RFC 5648, Each BID is generated and
>       managed by a mobile node. 
>       In Section 5.1, it says A mobile node assigns a BID to each
> care-of address when it wants to
>    register them simultaneously with its home address.
>    That means BID being 16 bits long is basically a short name for
> each care-of address. 
>    
>       In draft-netext-pmipv6-flowmob, you defined BID to be assigned
> and used by the local mobility anchor to identify which
>    entry of the flow mobility cache is used to decide how to route a
>    given flow.
>    As such, your BID is very different than RFC 5648. Simple protocol
> engineering requires giving it a different name. Maybe pBID but even
> pBID is not appropriate because your BID is not proxy version of
> rfc5648's BID.

The BID is just a binding identifier, and this is its purpose on the
draft, to identify a binding. The intention is to avoid introducing new
conceptual structures if possible, re-using some already defined for
client-based flow mobility.

>    
> About how to route a given flow: I don't understand why you are so
> much worried about it. From RFC6089, table of flow binding entries
> should be used to route the flows. 
> Your protocol should describe what you have in each flow binding
> entry, (including MN interface care-of address) and how you manage
> these flow binding entries.

I don't understand what you mean by "MN interface care-of address". I'll
revise the text to ensure it is clear how the flow entries (the FMC)
managed by the LMA is used.
> 
> I am unable to see these things in draft-netext-pmipv6-flowmob and I
> think that's why you seem to be so much concerned about how to route a
> given flow.
> 
> About marking the interfaces: In RFC5648, Home Link and Visited Link
> are very clearly distinguished. Home link is well defined in MIPv6. So
> other links are visited links.
> 
> In RFC 5213, for each interface a different binding cache is created.
> Each interface is a different mobility session. That effectively means
> each interface is a different MN.
> 
> But in draft-netext-pmipv6-flowmob, you want to integrate binding
> cache entries for the same MN into one so as not to create a separate
> mobility session for each.

Not really, the idea is to be able to identify bindings (and therefore
the use of the BID).
> 
> 
> In that case, you need to mark these binding cache entries properly.
> One suggestion is to mark the first one as Home Link and all others
> Visited link and let each MAG know the marking by LMA.
> Each MAG should keep HNPs assigned to its interface as well as to the
> home link interface. 
> This enables MN to always use  source address(es) assigned to the home
> link and thus MAGs can properly route these packets upwards. Downward
> routing is as I mentioned above, based on flow mobility binding cache.
> 
I don't see the need to mark the BCEs.

In any case, I'm about to submit a revision that addresses some of the
issues raised by Pierrick. I'm still working on other changes, such as
the use of the update-notifications, as well as trying to simplify the
document as much as possible. I hope that this will also address some of
your concerns. So please, wait to -08 (will be out in the next couple of
weeks) and check if you are happier with that version.

Thanks,

Carlos
> 
> Regards,
> 
> 
> Behcet
> 




From rkoodli@cisco.com  Thu Aug 29 21:58: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 F364F21E808C for ; Thu, 29 Aug 2013 21:58:21 -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 6uAKIzB4vthy for ; Thu, 29 Aug 2013 21:58:17 -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 A0BF421F8F6D for ; Thu, 29 Aug 2013 21:58:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1183; q=dns/txt; s=iport; t=1377838690; x=1379048290; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=vytCHPNmd44GEddKUTAkHO0KXXEabt1PUosWemR63bg=; b=TtTxBK9GFUih1iOJpmeCI1avU3wtX9Q6SyWIWDOQ0T2v6fZF/w/qdZyY uAx7O9L08V+HRd3bhZhu6CxOjQYoRRIAgHymvzKDzXFOXrzAXLDx2FwFU 8AWAZknTVvGpAElX0Zd4/0U9FuPPgqDGlhGBqmVrtenR+ElAPUp/ecDJK 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkgGAPclIFKtJXHB/2dsb2JhbABagwc1UcBPgSAWbQeCJgEEAQEBawsSAQgiSwslAgQOBQiHeQy5QQSPQQIxB4McgQADiHygXYMggio
X-IronPort-AV: E=Sophos;i="4.89,989,1367971200"; d="scan'208";a="253574458"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 30 Aug 2013 04:58:07 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7U4w7Qm025643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Aug 2013 04:58:07 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.176]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 29 Aug 2013 23:58:07 -0500
From: "Rajeev Koodli (rkoodli)" 
To: "cjbc@it.uc3m.es" 
Thread-Topic: [netext] draft-netext-pmipv6-flowmob
Thread-Index: AQHOoEglA1rPv9c0Oku85jON9Yb335mtb8EA//+pLYA=
Date: Fri, 30 Aug 2013 04:58:07 +0000
Message-ID: <7C52FDEBC843C44DBAF2CA6A30662C6D0159CEDB@xmb-aln-x04.cisco.com>
In-Reply-To: <1377832130.4300.0.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.150.225]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netext@ietf.org" 
Subject: Re: [netext] draft-netext-pmipv6-flowmob
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, 30 Aug 2013 04:58:22 -0000

Hi Carlos,

I have just a related comment (chair hat off):


On 8/29/13 8:08 PM, "Carlos Jes=FAs Bernardos Cano"  wrote=
:

>
>In any case, I'm about to submit a revision that addresses some of the
>issues raised by Pierrick. I'm still working on other changes, such as
>the use of the update-notifications, as well as trying to simplify the
>document as much as possible. I hope that this will also address some of
>your concerns. So please, wait to -08 (will be out in the next couple of
>weeks) and check if you are happier with that version.

I heard during the ID update at the Berlin meeting about the use of Update
Notification ID, in place of FMI/FMA? If that's the proposal, I am not for
it. Specifically, I do not want to overload the Update Notification (RFC
to be) with the semantics here. And, we should stick to the messages we
intended for the purpose and be self-contained.

Thanks.

-Rajeev




>
>Thanks,
>
>Carlos
>>=20
>> Regards,
>>=20
>>=20
>> Behcet
>>=20
>
>
>
>_______________________________________________
>netext mailing list
>netext@ietf.org
>https://www.ietf.org/mailman/listinfo/netext


From sarikaya2012@gmail.com  Fri Aug 30 09:34: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 35ADE21E805F for ; Fri, 30 Aug 2013 09:34:42 -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 0YfH4eIUvAfr for ; Fri, 30 Aug 2013 09:34:41 -0700 (PDT)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6417321F9E63 for ; Fri, 30 Aug 2013 09:34:40 -0700 (PDT)
Received: by mail-la0-f48.google.com with SMTP id er20so1725692lab.35 for ; Fri, 30 Aug 2013 09:34:39 -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=7W3eTYeL5fQK+wd2bod48DfeUI2g3XHyFL6DPiULTQI=; b=D9LKAsOPRp/sMKyX55Q5c0bri0XPIlFT5eXv72zHibEiqK2s74Dd3aAv7bvEa50T+f G/Ft6eUjzqR/Grh9fLu4HVmeOvsO3id/ytRB9aG+74yDdDkCARanPcdjiCPj2xPZi3+G +d1FD9sGIiXXxStb2TOcQ7pJkiPhwV9rd93eRCFfddTGZHOtKmJYhA4l+cJHiTfUy4Tw 541VeDEKc2nJI3QVm1APYH9Xnwj03+NPwmNti5Dqd12P82RGHjpDUidwpYx/Witxtaiq hFi8GBE+1VxcXYfDyS/LH2/1Us6c4eaQlSqloRjuEcAdX5V6+Le3+sWKfxMeloR7KoHH 66QA==
MIME-Version: 1.0
X-Received: by 10.152.27.202 with SMTP id v10mr1986949lag.43.1377880479262; Fri, 30 Aug 2013 09:34:39 -0700 (PDT)
Received: by 10.114.98.227 with HTTP; Fri, 30 Aug 2013 09:34:39 -0700 (PDT)
In-Reply-To: <1377832130.4300.0.camel@acorde.it.uc3m.es>
References:  <1377832130.4300.0.camel@acorde.it.uc3m.es>
Date: Fri, 30 Aug 2013 11:34:39 -0500
Message-ID: 
From: Behcet Sarikaya 
To: "Carlos J. Bernardos" 
Content-Type: multipart/alternative; boundary=089e0160a432826d4904e52ccc35
Cc: "netext@ietf.org" 
Subject: Re: [netext] draft-netext-pmipv6-flowmob
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: Fri, 30 Aug 2013 16:34:42 -0000

--089e0160a432826d4904e52ccc35
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Carlos, all,

I would like to summarize all the comments (mostly mine) in one mail and
put it here and hopefully offer a way out :-)

Here is the main problem in draft-netext-pmipv6-flowmob:

It attempts to do three things, LMA-based flow mobility, MAG-based flow
mobility and Multiple Proxy Care-of Address Registration extension in one
document and unfortunately can not deliver on any of these three. Each of
these is big issue and possibly subject of separate documents. Solutions on
each need consensus in the group.

Also, in draft-netext-pmipv6-flowmob there is too much emphasis on
the prefix assignment and not enough emphasis on the real protocol
issues. I am not convinced that playing with the way PMIPv6 assigns
HNPs is the solution to flow mobility.

Also, in draft-netext-pmipv6-flowmob there is too much emphasis on some
itsy bitsy optimizations like adopting BID from RFC 5648 and use it for LMA
which would probably lead sub-microsecond gains in LMA processing. It also
gets into naming issues that I mentioned in my previous mail.

Instead, draft-netext-pmipv6-flowmob could develop solution for one issue
instead of three, LMA-initiated flow mobility protocol using FMI/FMA and
add Multiple Proxy Care-of Address Registration to it because both are
needed.

draft-netext-pmipv6-flowmob could consider bringing back the Action field
in Flow Identification Mobility Option from draft-ietf-mext-flow-binding-09
of RFC 6089 and use it in the protocol because in PMIPv6 actions other than
forward are needed.

This will allow building the list of flow binding entries for MN which will
be used for routing.

draft-netext-pmipv6-flowmob could consider separating the solutions in two
different sections and also seek consensus on each from the WG.

Regards,

Behcet


On Thu, Aug 29, 2013 at 10:08 PM, Carlos Jes=FAs Bernardos Cano <
cjbc@it.uc3m.es> wrote:

> (resending, as I think this e-mail didn't make due to the problems with
> mailman on the IETF servers)
>
> Hi Behcet,
>
> On Fri, 2013-08-23 at 16:31 -0500, Behcet Sarikaya wrote:
> > Hi Carlos,
> >
> >
> > As per issues I placed in the issue tracker, your replies and as per
> > Berlin discussions, I would to clarify the issues as follows:
> >
> > About BID: In RFC 5648, Each BID is generated and
> >       managed by a mobile node.
> >       In Section 5.1, it says A mobile node assigns a BID to each
> > care-of address when it wants to
> >    register them simultaneously with its home address.
> >    That means BID being 16 bits long is basically a short name for
> > each care-of address.
> >
> >       In draft-netext-pmipv6-flowmob, you defined BID to be assigned
> > and used by the local mobility anchor to identify which
> >    entry of the flow mobility cache is used to decide how to route a
> >    given flow.
> >    As such, your BID is very different than RFC 5648. Simple protocol
> > engineering requires giving it a different name. Maybe pBID but even
> > pBID is not appropriate because your BID is not proxy version of
> > rfc5648's BID.
>
> The BID is just a binding identifier, and this is its purpose on the
> draft, to identify a binding. The intention is to avoid introducing new
> conceptual structures if possible, re-using some already defined for
> client-based flow mobility.
>
> >
> > About how to route a given flow: I don't understand why you are so
> > much worried about it. From RFC6089, table of flow binding entries
> > should be used to route the flows.
> > Your protocol should describe what you have in each flow binding
> > entry, (including MN interface care-of address) and how you manage
> > these flow binding entries.
>
> I don't understand what you mean by "MN interface care-of address". I'll
> revise the text to ensure it is clear how the flow entries (the FMC)
> managed by the LMA is used.
> >
> > I am unable to see these things in draft-netext-pmipv6-flowmob and I
> > think that's why you seem to be so much concerned about how to route a
> > given flow.
> >
> > About marking the interfaces: In RFC5648, Home Link and Visited Link
> > are very clearly distinguished. Home link is well defined in MIPv6. So
> > other links are visited links.
> >
> > In RFC 5213, for each interface a different binding cache is created.
> > Each interface is a different mobility session. That effectively means
> > each interface is a different MN.
> >
> > But in draft-netext-pmipv6-flowmob, you want to integrate binding
> > cache entries for the same MN into one so as not to create a separate
> > mobility session for each.
>
> Not really, the idea is to be able to identify bindings (and therefore
> the use of the BID).
> >
> >
> > In that case, you need to mark these binding cache entries properly.
> > One suggestion is to mark the first one as Home Link and all others
> > Visited link and let each MAG know the marking by LMA.
> > Each MAG should keep HNPs assigned to its interface as well as to the
> > home link interface.
> > This enables MN to always use  source address(es) assigned to the home
> > link and thus MAGs can properly route these packets upwards. Downward
> > routing is as I mentioned above, based on flow mobility binding cache.
> >
> I don't see the need to mark the BCEs.
>
> In any case, I'm about to submit a revision that addresses some of the
> issues raised by Pierrick. I'm still working on other changes, such as
> the use of the update-notifications, as well as trying to simplify the
> document as much as possible. I hope that this will also address some of
> your concerns. So please, wait to -08 (will be out in the next couple of
> weeks) and check if you are happier with that version.
>
> Thanks,
>
> Carlos
> >
> > Regards,
> >
> >
> > Behcet
> >
>
>
>
>

--089e0160a432826d4904e52ccc35
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Carlos, all,

I would like t=
o summarize all the comments (mostly mine) in one mail and put it here and =
hopefully offer a way out :-)

Here is the main problem in draft-nete=
xt-pmipv6-flowmob:


It attempts to do three things, LMA-based flow mobility, MAG-based flow=
 mobility and Multiple Proxy Care-of Address Registration extension in one =
document and unfortunately can not deliver on any of these three. Each of t=
hese is big issue and possibly subject of separate documents. Solutions on =
each need consensus in the group.


Also, in draft-netext-pmipv6-flowmob there is too much emphasis on
t=
he prefix assignment and not enough emphasis on the real protocol
issues=
. I am not convinced that playing with the way PMIPv6 assigns
HNPs is th=
e solution to flow mobility.


Also, in draft-netext-pmipv6-flowmob there is too much emphasis on some=
 itsy bitsy optimizations like adopting BID from RFC 5648 and use it for LM=
A which would probably lead sub-microsecond gains in LMA processing. It als=
o gets into naming issues that I mentioned in my previous mail.


Instead, draft-netext-pmipv6-flowmob could develop solution for one iss=
ue instead of three, LMA-initiated flow mobility protocol using FMI/FMA and=
 add Multiple Proxy Care-of Address Registration to it because both are nee=
ded.


draft-netext-pmipv6-flowmob could consider bringing back the Action fie=
ld in Flow Identification Mobility Option from draft-ietf-mext-flow-binding=
-09 of RFC 6089 and use it in the protocol because in PMIPv6 actions other =
than forward are needed.


This will allow building the list of flow binding entries for MN which =
will be used for routing.

draft-netext-pmipv6-flowmob could consider=
 separating the solutions in two different sections and also seek consensus=
 on each from the WG. 


Regards,

Behcet
=


On Thu, Aug 29, 2013 at 10:08 PM, Carlos=
 Jes=FAs Bernardos Cano <cjbc@it.uc3m.es> wrote:


(resending, as I think this e-mail didn'=
t make due to the problems with

mailman on the IETF servers)




Hi Behcet,



On Fri, 2013-08-23 at 16:31 -0500, Behcet Sarikaya wrote:


> Hi Carlos,

>

>

> As per issues I placed in the issue tracker, your replies and as per
> Berlin discussions, I would to clarify the issues as follows:

>

> About BID: In RFC 5648, Each BID is generated and

> =A0 =A0 =A0 managed by a mobile node.

> =A0 =A0 =A0 In Section 5.1, it says A mobile node assigns a BID to eac=
h

> care-of address when it wants to

> =A0 =A0register them simultaneously with its home address.

> =A0 =A0That means BID being 16 bits long is basically a short name for=


> each care-of address.

>

> =A0 =A0 =A0 In draft-netext-pmipv6-flowmob, you defined BID to be assi=
gned

> and used by the local mobility anchor to identify which

> =A0 =A0entry of the flow mobility cache is used to decide how to route=
 a

> =A0 =A0given flow.

> =A0 =A0As such, your BID is very different than RFC 5648. Simple proto=
col

> engineering requires giving it a different name. Maybe pBID but even
> pBID is not appropriate because your BID is not proxy version of

> rfc5648's BID.




The BID is just a binding identifier, and this is i=
ts purpose on the

draft, to identify a binding. The intention is to avoid introducing new

conceptual structures if possible, re-using some already defined for

client-based flow mobility.



>


> About how to route a given flow: I don't u=
nderstand why you are so

> much worried about it. From RFC6089, table of flow binding entries

> should be used to route the flows.

> Your protocol should describe what you have in each flow binding

> entry, (including MN interface care-of address) and how you manage

> these flow binding entries.




I don't understand what you mean by "MN in=
terface care-of address". I'll

revise the text to ensure it is clear how the flow entries (the FMC)

managed by the LMA is used.

>


> I am unable to see these things in draft-netex=
t-pmipv6-flowmob and I

> think that's why you seem to be so much concerned about how to rou=
te a

> given flow.

>

> About marking the interfaces: In RFC5648, Home Link and Visited Link
> are very clearly distinguished. Home link is well defined in MIPv6. So=


> other links are visited links.

>

> In RFC 5213, for each interface a different binding cache is created.<=
br>
> Each interface is a different mobility session. That effectively means=


> each interface is a different MN.

>

> But in draft-netext-pmipv6-flowmob, you want to integrate binding

> cache entries for the same MN into one so as not to create a separate<=
br>
> mobility session for each.




Not really, the idea is to be able to identify bind=
ings (and therefore

the use of the BID).

>

>


> In that case, you need to mark these binding c=
ache entries properly.

> One suggestion is to mark the first one as Home Link and all others
> Visited link and let each MAG know the marking by LMA.

> Each MAG should keep HNPs assigned to its interface as well as to the<=
br>
> home link interface.

> This enables MN to always use =A0source address(es) assigned to the ho=
me

> link and thus MAGs can properly route these packets upwards. Downward<=
br>
> routing is as I mentioned above, based on flow mobility binding cache.=


>


I don't see the need to mark the BCEs.




In any case, I'm about to submit a revision tha=
t addresses some of the

issues raised by Pierrick. I'm still working on other changes, such as<=
br>
the use of the update-notifications, as well as trying to simplify the

document as much as possible. I hope that this will also address some of
your concerns. So please, wait to -08 (will be out in the next couple of
weeks) and check if you are happier with that version.




Thanks,



Carlos

>

> Regards,

>

>

> Behcet

>











--089e0160a432826d4904e52ccc35--