From jari.arkko@piuha.net Mon Jan 2 03:02:35 2012 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 3C62521F8C4B for ; Mon, 2 Jan 2012 03:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 iAonE93-NXwk for ; Mon, 2 Jan 2012 03:02:34 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id A907D21F8B4A for ; Mon, 2 Jan 2012 03:02:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F3B702CC4D; Mon, 2 Jan 2012 13:02:03 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjO12qy50DvE; Mon, 2 Jan 2012 13:02:03 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A12D02CC31; Mon, 2 Jan 2012 13:02:02 +0200 (EET) Message-ID: <4F018EAA.6010900@piuha.net> Date: Mon, 02 Jan 2012 13:02:02 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Sri Gundavelli References: <4ECC4150.1060706@piuha.net> In-Reply-To: <4ECC4150.1060706@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" , draft-ietf-netext-bulk-re-registration@tools.ietf.org Subject: Re: [netext] AD review of draft-ietf-netext-bulk-re-registration 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, 02 Jan 2012 11:02:35 -0000 Sri: any updates on the draft coming soon? I'd like to move the draft forward. Jari On 23.11.2011 02:41, Jari Arkko wrote: > Ok. You have clearly understood the issue, and I'll wait until you've updated the draft. Thanks. > > jari > From jari.arkko@piuha.net Mon Jan 2 03:05:29 2012 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 4D4CD21F8F17 for ; Mon, 2 Jan 2012 03:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 d5TksL10gyhE for ; Mon, 2 Jan 2012 03:05:28 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3836C21F8F15 for ; Mon, 2 Jan 2012 03:05:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7CA2A2CC4D; Mon, 2 Jan 2012 13:04:57 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpoJOu3iZq57; Mon, 2 Jan 2012 13:04:52 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 3C9052CC31; Mon, 2 Jan 2012 13:04:50 +0200 (EET) Message-ID: <4F018F51.1060908@piuha.net> Date: Mon, 02 Jan 2012 13:04:49 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Suresh Krishnan References: <4ECFDD66.2040801@piuha.net> <4EE1ADE5.3050001@ericsson.com> In-Reply-To: <4EE1ADE5.3050001@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-netext-pmip-lr@tools.ietf.org" , "netext@ietf.org" Subject: Re: [netext] AD review of draft-ietf-netext-pmip-lr 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, 02 Jan 2012 11:05:29 -0000 I was looking at the state of my drafts today, and noticed that I had missed to send a reply to your question, Suresh. > >>> All the Localized routing messages use a new mobility header type >>> (TBA1). >>> The Localized Routing Initiation, described inSection 9.1 and the >>> Localized Routing Acknowledgment, described inSection 9.2 require a >>> single Mobility Header Type (TBA1) from the Mobility Header Types >>> registry athttp://www.iana.org/assignments/mobility-parameters >>> >> This seems odd. Usually, a message and its acknowledgment have different message types. TBA1 and TBA2... I can see that you have the R flag, but this isn't the usual way to define new MH messages. > I do not have a strong preference one way or another, but the last two > MH messages for Binding Revocation (RFC5846) and Heartbeat (RFC5847) > seem to be using a shared MH type for both the request and a response. > Let me know if you want me to change this and I will do so. I think it is better to use separate message types. That was the original design from RFC 3775. Jari From jari.arkko@piuha.net Mon Jan 2 03:10:55 2012 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 02B6221F8F17 for ; Mon, 2 Jan 2012 03:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.365 X-Spam-Level: X-Spam-Status: No, score=-101.365 tagged_above=-999 required=5 tests=[AWL=-1.066, BAYES_00=-2.599, MANGLED_WILLY=2.3, 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 Nve5h3SbAvZF for ; Mon, 2 Jan 2012 03:10:54 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 11CEF21F8BBE for ; Mon, 2 Jan 2012 03:10:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5BE1B2CC4D; Mon, 2 Jan 2012 13:10:23 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVRDhFr8ru15; Mon, 2 Jan 2012 13:10:22 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 117D92CC31; Mon, 2 Jan 2012 13:10:21 +0200 (EET) Message-ID: <4F01909D.7050503@piuha.net> Date: Mon, 02 Jan 2012 13:10:21 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: jouni korhonen References: <4EE5324E.3010803@piuha.net> <436DC79F-5BF8-474A-BCEF-9D8A50B0DCC4@gmail.com> In-Reply-To: <436DC79F-5BF8-474A-BCEF-9D8A50B0DCC4@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-netext-radius-pmip6@tools.ietf.org, "netext@ietf.org" Subject: Re: [netext] AD review of draft-ietf-netext-radius-pmip6 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, 02 Jan 2012 11:10:55 -0000 Jouni, I was going through my list of drafts today and noticed that I had not responded to your reply yet: > Jari, > > Thanks for the detailed review. See my comments online. > > On Dec 12, 2011, at 12:44 AM, Jari Arkko wrote: > >> I have reviewed this specification. >> >> The draft is well written. Thanks for that. I only found a couple of minor editorial issues, and one technical issue. I would like to talk about the technical issue before we send the draft forward. Please reply to this e-mail and/or revise the draft accordingly so that I can start an IETF Last Call. >> >> Section 4.9: Shouldn't this section include some text about not including this attribute, if MIP6-Home-HN-Prefix is already present? (Like Section 4.7 had for its corresponding attribute pair.) The same problem may appear in Section 4.13 and elsewhere as well. Please check. > If I recall our (authors) discussion correctly the motivation not to add any restriction in these cases was to allow a (possible future) deployment where the MAG receives both home& visited LMA addresses and then picks based on some policy either one. For this to work, we would need address allocation also have the same functionality. No problem to add "SHOULD NOT"s there and explain the situation. OK > >> Section 4.10& 4.11: This is the technical issue that worries me. While RFC 5213 does say that there are cases where MN-HoA is known, this is certainly an exception rather than the rule: >> >> Mobile Node's Home Address (MN-HoA) >> >> MN-HoA is an address from a mobile node's home network prefix. >> The mobile node will be able to use this address as long as it is >> attached to the access network that is in the scope of that Proxy >> Mobile IPv6 domain. If the mobile node uses more than one address >> from its home network prefix(es), any one of these addresses is >> referred to as mobile node's home address. Unlike in Mobile IPv6 >> where the home agent is aware of the home address of the mobile >> node, in Proxy Mobile IPv6, the mobility entities are only aware >> of the mobile node's home network prefix(es) and are not always >> aware of the exact address(es) that the mobile node configured on >> its interface from its home network prefix(es). However, in some >> configurations and based on the enabled address configuration >> modes on the access link, the mobility entities in the network can >> be certain about the exact address(es) configured by the mobile >> node. >> >> Sections 4.10 and 4.11 talk about IIDs without any context on how they should be derived, used, and whether they can even exist on a given deployment. >> >> One approach to fix this would be to delete the subsections. Another one would be explain how the IID values are determined, when they can be determined, and how they should be used. Yet another approach is to point me (and the reader) to another RFC that describes this (as I could of course have missed something). > Right, good point. I would remove the "derivation text" and add applicability statement for links where the network actually delivers the IID to the end host (PPP, 3GPP, ...) these attributes contain the IID. Good. > >>> 4.18. Calling-Station-Id >>> >>> The Calling-Station-Id attribute (Type value 31) is of type String >>> and when used for PMIPv6 it contains the link-layer identifier of the >>> MN as defined in [RFC5213], Sections 2.2 and 8.6. >> You should refer to the RFC that originally defined Calling-Station-Id. > Ack. > >>> The User-Name attribute MUST be present in the Access-Request. It >>> SHOULD carry a valid MN identity unless the identity is being >>> suppressed for policy reasons, for example, when identity hiding is >>> in effect. The MN identity, if available, MUST be in Network Access >>> Identifier (NAI) [RFC4282] format. >> I think there is always an identifier that is of the valid form. It just may not reveal the identity of the user (at least not in an 1-1 and stable fashion). Consider making this change: >> >> ... MUST carry a correctly formed identifier that SHOULD correspond to a MN identity unless ... > Ok. Will change. > > Great. Will żou post a new draft version so that we can move this document forward? Jari From internet-drafts@ietf.org Mon Jan 2 11:10:11 2012 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 E0E9D21F84AC; Mon, 2 Jan 2012 11:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gS4VnAbrGaL6; Mon, 2 Jan 2012 11:10:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C2821F84A3; Mon, 2 Jan 2012 11:10:10 -0800 (PST) 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: 3.64p1 Message-ID: <20120102191001.4673.20881.idtracker@ietfa.amsl.com> Date: Mon, 02 Jan 2012 11:10:01 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-bulk-re-registration-09.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 19:10:12 -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 Wor= king Group of the IETF. Title : Bulk Binding Update Support for Proxy Mobile IPv6 Author(s) : Fuad Abinader Sri Gundavelli Kent Leung Suresh Krishnan Domagoj Premec Filename : draft-ietf-netext-bulk-re-registration-09.txt Pages : 22 Date : 2012-01-02 For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility anchor on a per-session basis. In the absence of signaling semantics for performing operations with group specific scope, it results in significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines an optimization to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group specific scope with the use of a group identifier. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-bulk-re-registration-= 09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-bulk-re-registration-0= 9.txt From sgundave@cisco.com Mon Jan 2 11:16:44 2012 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 3B35D1F0C36 for ; Mon, 2 Jan 2012 11:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 TsSX7hxl8wsq for ; Mon, 2 Jan 2012 11:16:43 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 67C3D21F84AE for ; Mon, 2 Jan 2012 11:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=845; q=dns/txt; s=iport; t=1325531803; x=1326741403; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=n+8O639DLLysamGg269tN2UK8nXhuo6O4KmM9G5fUoA=; b=hzydAgLKsBGP7GqJDfgvzp56VKTc2rzS9bN45p43cEToMze4+bLBh3by pmJZOrzk8ohyvbGzZ2fcSXJrx2YpMfSZPeHOE1CXCz0BmEmySYy/T+EsM gMycyhX6GJvXXaYSsJJobTFpAgeXBqbdNxOQUGTQBwS6JTAJJwoBI2XaF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYzAHICAk+rRDoH/2dsb2JhbABDggWqU4EFgXIBAQEDARIBJwIBPAUNAQgYgQUBAQQOBSKHWJZtAZ1FjA8EiDeMS5JV X-IronPort-AV: E=Sophos;i="4.71,445,1320624000"; d="scan'208";a="23330406" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 02 Jan 2012 19:16:43 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q02JGhFX012661; Mon, 2 Jan 2012 19:16:43 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Jan 2012 11:16:42 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Mon, 2 Jan 2012 19:16:42 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 02 Jan 2012 11:16:41 -0800 From: Sri Gundavelli To: Jari Arkko Message-ID: Thread-Topic: [netext] AD review of draft-ietf-netext-bulk-re-registration Thread-Index: AczJgw6d1Vm2/n6pjEKK5/vyow+n4w== In-Reply-To: <4F018EAA.6010900@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Jan 2012 19:16:42.0839 (UTC) FILETIME=[0FB60E70:01CCC983] Cc: "netext@ietf.org" , draft-ietf-netext-bulk-re-registration@tools.ietf.org Subject: Re: [netext] AD review of draft-ietf-netext-bulk-re-registration 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, 02 Jan 2012 19:16:44 -0000 Hi Jari: Sorry for the delay. This is just on time, was about to post it today and I just did (draft-ietf-netext-bulk-re-registration-09). This should address all the issues that you have identified in your review. - Clarification on MAG sending the Bulk binding update identifiers - Example call flow with details - Number of editorial changes for consistency - Updates to processing rules This should be technically correct, I'm hoping, ignoring any nits. Regards Sri On 1/2/12 3:02 AM, "Jari Arkko" wrote: > Sri: any updates on the draft coming soon? I'd like to move the draft forward. > > Jari > > On 23.11.2011 02:41, Jari Arkko wrote: >> Ok. You have clearly understood the issue, and I'll wait until you've >> updated the draft. Thanks. >> >> jari >> > From suresh.krishnan@ericsson.com Mon Jan 2 14:07:01 2012 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 0859811E80C1 for ; Mon, 2 Jan 2012 14:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.611 X-Spam-Level: X-Spam-Status: No, score=-105.611 tagged_above=-999 required=5 tests=[AWL=0.988, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 vvQvR9MY1sJ4 for ; Mon, 2 Jan 2012 14:07:00 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4571911E8083 for ; Mon, 2 Jan 2012 14:07:00 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q02M6pbv003364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Jan 2012 16:06:54 -0600 Received: from [142.133.10.25] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 2 Jan 2012 17:06:51 -0500 Message-ID: <4F022A5E.8000808@ericsson.com> Date: Mon, 2 Jan 2012 17:06:22 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jari Arkko References: <4ECFDD66.2040801@piuha.net> <4EE1ADE5.3050001@ericsson.com> <4F018F51.1060908@piuha.net> In-Reply-To: <4F018F51.1060908@piuha.net> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "draft-ietf-netext-pmip-lr@tools.ietf.org" , "netext@ietf.org" Subject: Re: [netext] AD review of draft-ietf-netext-pmip-lr 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, 02 Jan 2012 22:07:01 -0000 On 01/02/2012 06:04 AM, Jari Arkko wrote: > I was looking at the state of my drafts today, and noticed that I had missed to send a reply to your question, Suresh. > > >> >>>> All the Localized routing messages use a new mobility header type >>>> (TBA1). >>>> The Localized Routing Initiation, described inSection 9.1 and the >>>> Localized Routing Acknowledgment, described inSection 9.2 require a >>>> single Mobility Header Type (TBA1) from the Mobility Header Types >>>> registry athttp://www.iana.org/assignments/mobility-parameters >>>> >>> This seems odd. Usually, a message and its acknowledgment have different message types. TBA1 and TBA2... I can see that you have the R flag, but this isn't the usual way to define new MH messages. >> I do not have a strong preference one way or another, but the last two >> MH messages for Binding Revocation (RFC5846) and Heartbeat (RFC5847) >> seem to be using a shared MH type for both the request and a response. >> Let me know if you want me to change this and I will do so. > > I think it is better to use separate message types. That was the original design from RFC 3775. Thanks Jari. Will do. Regards Suresh From internet-drafts@ietf.org Mon Jan 2 16:27:55 2012 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 7234821F8493; Mon, 2 Jan 2012 16:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 0MMEiBOo28sg; Mon, 2 Jan 2012 16:27:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171AD21F8486; Mon, 2 Jan 2012 16:27:55 -0800 (PST) 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: 3.64p1 Message-ID: <20120103002755.27169.20612.idtracker@ietfa.amsl.com> Date: Mon, 02 Jan 2012 16:27:55 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-access-network-option-03.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 00:27:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Wor= king Group of the IETF. Title : Access Network Identifier (ANI) Option for Proxy Mobile = IPv6 Author(s) : Sri Gundavelli Jouni Korhonen Mark Grayson Kent Leung Rajesh Pazhyannur Filename : draft-ietf-netext-access-network-option-03.txt Pages : 15 Date : 2012-01-02 This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. Based on the received information, the local mobility anchor is able to provide access network and access operator specific handling or policing for the mobile node traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-access-network-option= -03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-access-network-option-= 03.txt From jari.arkko@piuha.net Tue Jan 3 00:33:48 2012 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 4D57521F850F for ; Tue, 3 Jan 2012 00:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 RJVV4pEDr904 for ; Tue, 3 Jan 2012 00:33:47 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7851E21F850C for ; Tue, 3 Jan 2012 00:33:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EA4C62CC43; Tue, 3 Jan 2012 10:33:14 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMRMncCLGoAr; Tue, 3 Jan 2012 10:33:14 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 5FD332CC31; Tue, 3 Jan 2012 10:33:14 +0200 (EET) Message-ID: <4F02BD4A.4030700@piuha.net> Date: Tue, 03 Jan 2012 10:33:14 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Sri Gundavelli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" , draft-ietf-netext-bulk-re-registration@tools.ietf.org Subject: Re: [netext] AD review of draft-ietf-netext-bulk-re-registration 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, 03 Jan 2012 08:33:48 -0000 Sri: Thanks for the update! I have reviewed the changes and they look good to me with one exception (below). I have in any case requested an IETF Last Call to be initiated and expect that you fix the remaining issues by issuing yet another draft quickly. But the changes are pretty big -- it would also be useful if members of the WG reviewed the document while it is in the Last Call. > o When sending the Mobile Node Group Identifier option in the > binding update messages related to the individual session > establishment, the Bulk-Binding-Update (B) flag in the request > MUST be set to a value of (1). However, when initiating any > binding update operations with group specific scope, the Bulk- > Binding-Update (B) flag in the request MUST always be set to a > value of (0), with the Mobile Node Group Identifier option present > in the request. There is something wrong with the above text. B must be set in the session establishment, but not with "binding update operations with group specific scope"? (And what are those?) Jari From iesg-secretary@ietf.org Tue Jan 3 07:01:01 2012 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 71A9021F851E; Tue, 3 Jan 2012 07:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 P8XDRpF-eHe9; Tue, 3 Jan 2012 07:01:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E050E21F84ED; Tue, 3 Jan 2012 07:01:00 -0800 (PST) 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: 3.64p1 Message-ID: <20120103150100.8782.7455.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 07:01:00 -0800 Cc: netext@ietf.org Subject: [netext] Last Call: (Bulk Binding Update Support 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: Tue, 03 Jan 2012 15:01:01 -0000 The IESG has received a request from the Network-Based Mobility Extensions WG (netext) to consider the following document: - 'Bulk Binding Update Support for Proxy Mobile IPv6' as a 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 2012-01-17. 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 For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility anchor on a per-session basis. In the absence of signaling semantics for performing operations with group specific scope, it results in significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines an optimization to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group specific scope with the use of a group identifier. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netext-bulk-re-registration/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netext-bulk-re-registration/ No IPR declarations have been submitted directly on this I-D. From sgundave@cisco.com Tue Jan 3 08:32:48 2012 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 2E4EC21F84DB for ; Tue, 3 Jan 2012 08:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 3tIpq9DXcSZB for ; Tue, 3 Jan 2012 08:32:43 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 19A4E11E8080 for ; Tue, 3 Jan 2012 08:32:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2946; q=dns/txt; s=iport; t=1325608363; x=1326817963; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=iDTjqHC/cC3VnVImX/Ds/oxwFjbnIrSFyaQjL+SqLzI=; b=XmL4xwrZd1rEQN2sZCE5zXsvypmSkxhLGHz2ytzWW3WPg/ebD9ReVDvo 1fkGU/1ZJn42YRl4NMnBRwKqr5pcwnMi2TD65Jh2FKieDkqX8VhmGRYUI 0tN+cvMEJwjLe+cC8yzjhNKUhwBhZ8F8j/C+sY/FwM7DVuF7gq4sd9/Rc 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsQACMtA0+rRDoJ/2dsb2JhbABEggWqW4EFgXIBAQEDARIBJwIBPAUNAQiBHQEBBA4FIodYl0kBnXCMDwSIN4xLklU X-IronPort-AV: E=Sophos;i="4.71,450,1320624000"; d="scan'208";a="23508213" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 03 Jan 2012 16:32:42 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q03GWg2E015117; Tue, 3 Jan 2012 16:32:42 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jan 2012 08:32:42 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 Jan 2012 16:32:42 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 03 Jan 2012 08:32:41 -0800 From: Sri Gundavelli To: Jari Arkko Message-ID: Thread-Topic: [netext] AD review of draft-ietf-netext-bulk-re-registration Thread-Index: AczKNU/ulq9ahQR4UUOBAi+dQqnbrw== In-Reply-To: <4F02BD4A.4030700@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Jan 2012 16:32:42.0530 (UTC) FILETIME=[50D7D020:01CCCA35] Cc: "netext@ietf.org" , draft-ietf-netext-bulk-re-registration@tools.ietf.org Subject: Re: [netext] AD review of draft-ietf-netext-bulk-re-registration 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, 03 Jan 2012 16:32:48 -0000 > > There is something wrong with the above text. B must be set in the session > establishment, but not with "binding update operations with group specific > scope"? (And what are those?) > Hi Jari: Thanks for the review. There are two cases here: 1.) Establishment of the initial session for a given mobile node as in today - the approach of group id exchange for that session to be established 2.) Performing a bulk binding operation on a group of mobile nodes/sessions that are part of a given group - Ex: Periodic BU for lifetime extension In both these cases, there is a PBU and there is the Group Identifier option. In #1, the MAG presents the group identifier for that mobile node, so the LMA can associate the group id with that session. In #2, the MAG wants the binding operation to be performed on a set of nodes/sessions identified by the group id, that was previously exchanged. The (B) flag for #1 is enabled. It serves as the means to request the LMA to enable bulk binding operation for a given mobility session. The LMA can accept the request, set the (B) flag in the PBA and return its own local group id for that session. Or, simply can decide not to enable bulk binding update feature for that session, by turning of the (B) flag in the PBA. In case of #2, once the sessions are established and associated with a group id, the Group Identifier in the option alone is sufficient, there is no need for toggling the (B) flag in the PBU/PBA. We can make the logic work, eliminating the (B) flag entirely, even for #1, but the logic gets complex, looking at individual session identifier presence (Mobile Node identifier option ..IPv4 Home Address option) ..etc. Regards Sri On 1/3/12 12:33 AM, "Jari Arkko" wrote: > Sri: > > Thanks for the update! I have reviewed the changes and they look good to me > with one exception (below). I have in any case requested an IETF Last Call to > be initiated and expect that you fix the remaining issues by issuing yet > another draft quickly. > > But the changes are pretty big -- it would also be useful if members of the WG > reviewed the document while it is in the Last Call. > >> o When sending the Mobile Node Group Identifier option in the >> binding update messages related to the individual session >> establishment, the Bulk-Binding-Update (B) flag in the request >> MUST be set to a value of (1). However, when initiating any >> binding update operations with group specific scope, the Bulk- >> Binding-Update (B) flag in the request MUST always be set to a >> value of (0), with the Mobile Node Group Identifier option present >> in the request. > > There is something wrong with the above text. B must be set in the session > establishment, but not with "binding update operations with group specific > scope"? (And what are those?) > > Jari > From internet-drafts@ietf.org Wed Jan 4 05:26:33 2012 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 2DBCB21F873D; Wed, 4 Jan 2012 05:26:33 -0800 (PST) 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 QB+QyrwjPt4m; Wed, 4 Jan 2012 05:26:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6061421F873B; Wed, 4 Jan 2012 05:26:32 -0800 (PST) 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: 3.64p1 Message-ID: <20120104132632.21056.54346.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2012 05:26:32 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-radius-pmip6-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: Wed, 04 Jan 2012 13:26:33 -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 Wor= king Group of the IETF. Title : RADIUS Support for Proxy Mobile IPv6 Author(s) : Frank Xia Behcet Sarikaya Jouni Korhonen Sri Gundavelli Damjan Damic Filename : draft-ietf-netext-radius-pmip6-06.txt Pages : 36 Date : 2012-01-04 This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol defined in this document uses Radius based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the Mobile Node attaches, authenticates and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. In addition to the mobility session setup related interactions, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-radius-pmip6-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-radius-pmip6-06.txt From jouni.nospam@gmail.com Wed Jan 4 05:27:31 2012 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 A62E021F864E for ; Wed, 4 Jan 2012 05:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_WILLY=2.3, RCVD_IN_DNSWL_LOW=-1] 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 qUMAomOjeqIE for ; Wed, 4 Jan 2012 05:27:31 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8990D21F8688 for ; Wed, 4 Jan 2012 05:27:30 -0800 (PST) Received: by laah2 with SMTP id h2so7207495laa.31 for ; Wed, 04 Jan 2012 05:27:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0y5wv0B4S7uiW9r1uXIUCBMFETzzuBBc056jR0KwwC0=; b=gCzZtFFCQ+SyfggahvdFzzUFsiTKPYuzrmhZsd4NqZdlJ9fXr7KGzEAAAVPyLyVTsZ i3FOWByxxXEdI7HEFsD5oGBvXO3KiGOX7foiiCJ75jlRTCW1O3K02MuQNEPjdX58osBr eZDgGguqHhqbVZSxY1x0TXxEwtEBNvlvF6E5M= Received: by 10.152.136.39 with SMTP id px7mr44785359lab.2.1325683648319; Wed, 04 Jan 2012 05:27:28 -0800 (PST) Received: from a83-245-210-48.elisa-laajakaista.fi (a83-245-210-48.elisa-laajakaista.fi. [83.245.210.48]) by mx.google.com with ESMTPS id ng10sm45881233lab.13.2012.01.04.05.27.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 05:27:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: <4F01909D.7050503@piuha.net> Date: Wed, 4 Jan 2012 15:27:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <66B226CA-1AD4-4E53-88A5-D90A99457854@gmail.com> References: <4EE5324E.3010803@piuha.net> <436DC79F-5BF8-474A-BCEF-9D8A50B0DCC4@gmail.com> <4F01909D.7050503@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-netext-radius-pmip6@tools.ietf.org, "netext@ietf.org" Subject: Re: [netext] AD review of draft-ietf-netext-radius-pmip6 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, 04 Jan 2012 13:27:31 -0000 Jari, Version -06 addressing your concerns has been submitted. - Jouni On Jan 2, 2012, at 1:10 PM, Jari Arkko wrote: > Jouni, >=20 > I was going through my list of drafts today and noticed that I had not = responded to your reply yet: >=20 >> Jari, >>=20 >> Thanks for the detailed review. See my comments online. >>=20 >> On Dec 12, 2011, at 12:44 AM, Jari Arkko wrote: >>=20 >>> I have reviewed this specification. >>>=20 >>> The draft is well written. Thanks for that. I only found a couple of = minor editorial issues, and one technical issue. I would like to talk = about the technical issue before we send the draft forward. Please reply = to this e-mail and/or revise the draft accordingly so that I can start = an IETF Last Call. >>>=20 >>> Section 4.9: Shouldn't this section include some text about not = including this attribute, if MIP6-Home-HN-Prefix is already present? = (Like Section 4.7 had for its corresponding attribute pair.) The same = problem may appear in Section 4.13 and elsewhere as well. Please check. >> If I recall our (authors) discussion correctly the motivation not to = add any restriction in these cases was to allow a (possible future) = deployment where the MAG receives both home& visited LMA addresses and = then picks based on some policy either one. For this to work, we would = need address allocation also have the same functionality. No problem to = add "SHOULD NOT"s there and explain the situation. >=20 > OK >=20 >>=20 >>> Section 4.10& 4.11: This is the technical issue that worries me. = While RFC 5213 does say that there are cases where MN-HoA is known, this = is certainly an exception rather than the rule: >>>=20 >>> Mobile Node's Home Address (MN-HoA) >>>=20 >>> MN-HoA is an address from a mobile node's home network prefix. >>> The mobile node will be able to use this address as long as it = is >>> attached to the access network that is in the scope of that = Proxy >>> Mobile IPv6 domain. If the mobile node uses more than one = address >>> from its home network prefix(es), any one of these addresses is >>> referred to as mobile node's home address. Unlike in Mobile = IPv6 >>> where the home agent is aware of the home address of the mobile >>> node, in Proxy Mobile IPv6, the mobility entities are only = aware >>> of the mobile node's home network prefix(es) and are not always >>> aware of the exact address(es) that the mobile node configured = on >>> its interface from its home network prefix(es). However, in = some >>> configurations and based on the enabled address configuration >>> modes on the access link, the mobility entities in the network = can >>> be certain about the exact address(es) configured by the mobile >>> node. >>>=20 >>> Sections 4.10 and 4.11 talk about IIDs without any context on how = they should be derived, used, and whether they can even exist on a given = deployment. >>>=20 >>> One approach to fix this would be to delete the subsections. Another = one would be explain how the IID values are determined, when they can be = determined, and how they should be used. Yet another approach is to = point me (and the reader) to another RFC that describes this (as I could = of course have missed something). >> Right, good point. I would remove the "derivation text" and add = applicability statement for links where the network actually delivers = the IID to the end host (PPP, 3GPP, ...) these attributes contain the = IID. >=20 > Good. >=20 >>=20 >>>> 4.18. Calling-Station-Id >>>>=20 >>>> The Calling-Station-Id attribute (Type value 31) is of type = String >>>> and when used for PMIPv6 it contains the link-layer identifier of = the >>>> MN as defined in [RFC5213], Sections 2.2 and 8.6. >>> You should refer to the RFC that originally defined = Calling-Station-Id. >> Ack. >>=20 >>>> The User-Name attribute MUST be present in the Access-Request. = It >>>> SHOULD carry a valid MN identity unless the identity is being >>>> suppressed for policy reasons, for example, when identity hiding = is >>>> in effect. The MN identity, if available, MUST be in Network = Access >>>> Identifier (NAI) [RFC4282] format. >>> I think there is always an identifier that is of the valid form. It = just may not reveal the identity of the user (at least not in an 1-1 and = stable fashion). Consider making this change: >>>=20 >>> ... MUST carry a correctly formed identifier that SHOULD correspond = to a MN identity unless ... >> Ok. Will change. >>=20 >>=20 >=20 > Great. Will =FDou post a new draft version so that we can move this = document forward? >=20 > Jari >=20 From jari.arkko@piuha.net Wed Jan 4 05:47:03 2012 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 0AA9721F8760 for ; Wed, 4 Jan 2012 05:47:03 -0800 (PST) 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 Dxvl1biBHZ6z for ; Wed, 4 Jan 2012 05:47:02 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7B68621F875E for ; Wed, 4 Jan 2012 05:47:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CB9FA2CC4D; Wed, 4 Jan 2012 15:47:01 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9anjDX06adUa; Wed, 4 Jan 2012 15:47:01 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2D6C32CC31; Wed, 4 Jan 2012 15:47:01 +0200 (EET) Message-ID: <4F045855.5080508@piuha.net> Date: Wed, 04 Jan 2012 15:47:01 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: jouni korhonen References: <4EE5324E.3010803@piuha.net> <436DC79F-5BF8-474A-BCEF-9D8A50B0DCC4@gmail.com> <4F01909D.7050503@piuha.net> <66B226CA-1AD4-4E53-88A5-D90A99457854@gmail.com> In-Reply-To: <66B226CA-1AD4-4E53-88A5-D90A99457854@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-netext-radius-pmip6@tools.ietf.org, "netext@ietf.org" Subject: Re: [netext] AD review of draft-ietf-netext-radius-pmip6 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, 04 Jan 2012 13:47:03 -0000 Thanks. I have requested Last Call to be initiated. Jari From iesg-secretary@ietf.org Wed Jan 4 06:33:05 2012 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 2622B21F8779; Wed, 4 Jan 2012 06:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 gMmUya1vPBW8; Wed, 4 Jan 2012 06:33:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE41321F8763; Wed, 4 Jan 2012 06:33:03 -0800 (PST) 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: 3.64p1 Message-ID: <20120104143303.9564.46227.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2012 06:33:03 -0800 Cc: netext@ietf.org Subject: [netext] Last Call: (RADIUS Support 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: Wed, 04 Jan 2012 14:33:05 -0000 The IESG has received a request from the Network-Based Mobility Extensions WG (netext) to consider the following document: - 'RADIUS Support for Proxy Mobile IPv6' as a 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 2012-01-18. 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 defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol defined in this document uses Radius based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the Mobile Node attaches, authenticates and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. In addition to the mobility session setup related interactions, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netext-radius-pmip6/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netext-radius-pmip6/ No IPR declarations have been submitted directly on this I-D. From Dirk.von-Hugo@telekom.de Fri Jan 6 00:51:30 2012 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 D275821F890F for ; Fri, 6 Jan 2012 00:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 Be-GNdO1iSjI for ; Fri, 6 Jan 2012 00:51:29 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id DE36F21F8908 for ; Fri, 6 Jan 2012 00:51:25 -0800 (PST) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 06 Jan 2012 09:51:21 +0100 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.122]) by he110890 ([10.134.92.131]) with mapi; Fri, 6 Jan 2012 09:51:21 +0100 From: To: , Date: Fri, 6 Jan 2012 09:51:19 +0100 Thread-Topic: [netext] AD review of draft-ietf-netext-bulk-re-registration Thread-Index: AczJ8myw5V62JQlgToCzTdEiYgtCsgB0iktw Message-ID: <05C81A773E48DD49B181B04BA21A342A2725ACB24B@HE113484.emea1.cds.t-internal.com> References: <4F02BD4A.4030700@piuha.net> In-Reply-To: <4F02BD4A.4030700@piuha.net> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-Message-Flag: Zur Nachverfolgung Reply-By: Fri, 6 Jan 2012 00:00:00 +0100 X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: netext@ietf.org, draft-ietf-netext-bulk-re-registration@tools.ietf.org Subject: Re: [netext] AD review of draft-ietf-netext-bulk-re-registration 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, 06 Jan 2012 08:51:30 -0000 Dear all, Referring to the suggested additional WG reviews of the updated draft I wan= t to share with you the minor nits I found ;-) 1. Intro provides a more optimal mechanism =3D> provides a considerably improved mec= hanism (afaik 'optimal' already denotes the best) 3.1. Motivation revocation operations on a group on mobility sessions =3D> revocation opera= tions on a group of mobility sessions 3.2. General Operation P.7 respectively, while the LMA assigns them both to the same to the bulk =3D> respectively, while the LMA assigns them both to the same bulk part of bulk binding update group, L1. =3D> part of bulk binding update g= roup, (L1). 4.1 Extensions to Proxy Binding Update Message Figure 2 =3D> Figure 2: Proxy Binding Update Message (to have consistency to 4.2.) 'bulk binding operation group' (occurs 3 times in the draft, see p.12) is n= ot defined?! Shouldn't it read =3D> 'bulk binding update group' ? group and thus any any binding update =3D> group and thus any binding updat= e 5.1 MAG Considerations identifies the list of bulk binding update group specific to each =3D> identifies the list of bulk binding update groups specific to each 5.1.1 Proxy Binding Update message. If there is no such grouping is =3D> Proxy Binding Update message. If there is no such grouping 5.2.1. given mobility session to a specific bulk binding update group is =3D> given mobility session to a specific bulk binding update group are P.16 if the if the received Proxy Binding Update from the new mobile =3D> if the received Proxy Binding Update from the new mobile 5.2.2 Currently, this specification only support sub-type value of (1) =3D> Currently, this specification only supports sub-type value of (1) 0 (Proxy Binding Update accepted). =3D> (0) (Proxy Binding Update accepted= ). 6.2. Mobile Access Gateway - Configuration Variables this flag is set to (1), indicating that the the mobile access =3D> this flag is set to (1), indicating that the mobile access 9. Acknowledgements Patil Carlos Jesus Bernardos Cano and Jari Arkko for their reviews =3D> Patil, Carlos Jesus Bernardos Cano, and Jari Arkko for their reviews Thanks and best regards Dirk Von: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] Im Auftrag vo= n Jari Arkko Gesendet: Dienstag, 3. Januar 2012 09:33 An: Sri Gundavelli Cc: netext@ietf.org; draft-ietf-netext-bulk-re-registration@tools.ietf.org Betreff: Re: [netext] AD review of draft-ietf-netext-bulk-re-registration Sri: Thanks for the update! I have reviewed the changes and they look good to me= with one exception (below). I have in any case requested an IETF Last Call= to be initiated and expect that you fix the remaining issues by issuing ye= t another draft quickly. But the changes are pretty big -- it would also be useful if members of the= WG reviewed the document while it is in the Last Call. > o When sending the Mobile Node Group Identifier option in the > binding update messages related to the individual session > establishment, the Bulk-Binding-Update (B) flag in the request > MUST be set to a value of (1). However, when initiating any > binding update operations with group specific scope, the Bulk- > Binding-Update (B) flag in the request MUST always be set to a > value of (0), with the Mobile Node Group Identifier option present > in the request. There is something wrong with the above text. B must be set in the session = establishment, but not with "binding update operations with group specific = scope"? (And what are those?) Jari _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From jari.arkko@piuha.net Fri Jan 6 02:15:34 2012 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 5C25621F875E for ; Fri, 6 Jan 2012 02:15:34 -0800 (PST) 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 b7WmUqEXzaqb for ; Fri, 6 Jan 2012 02:15:33 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id AAEC821F8735 for ; Fri, 6 Jan 2012 02:15:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F0DFC2CC43; Fri, 6 Jan 2012 12:15:30 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5z0eQhCx+Gzy; Fri, 6 Jan 2012 12:15:29 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A69932CC31; Fri, 6 Jan 2012 12:15:29 +0200 (EET) Message-ID: <4F06C9C0.3050705@piuha.net> Date: Fri, 06 Jan 2012 12:15:28 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Dirk.von-Hugo@telekom.de References: <4F02BD4A.4030700@piuha.net> <05C81A773E48DD49B181B04BA21A342A2725ACB24B@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2725ACB24B@HE113484.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org, draft-ietf-netext-bulk-re-registration@tools.ietf.org Subject: Re: [netext] AD review of draft-ietf-netext-bulk-re-registration 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, 06 Jan 2012 10:15:34 -0000 Thanks for your detailed review. Jari On 06.01.2012 10:51, Dirk.von-Hugo@telekom.de wrote: > Dear all, > > Referring to the suggested additional WG reviews of the updated draft I want to share with you the minor nits I found ;-) > > 1. Intro > > provides a more optimal mechanism => provides a considerably improved mechanism > (afaik 'optimal' already denotes the best) > > 3.1. Motivation > > revocation operations on a group on mobility sessions => revocation operations on a group of mobility sessions > > 3.2. General Operation > > P.7 > respectively, while the LMA assigns them both to the same to the > bulk > => respectively, while the LMA assigns them both to the same bulk > > part of bulk binding update group, L1. => part of bulk binding update group, (L1). > > 4.1 Extensions to Proxy Binding Update Message > > Figure 2 => Figure 2: Proxy Binding Update Message > (to have consistency to 4.2.) > > 'bulk binding operation group' (occurs 3 times in the draft, see p.12) is not defined?! Shouldn't it read => 'bulk binding update group' ? > > group and thus any any binding update => group and thus any binding update > > 5.1 MAG Considerations > > identifies the list of bulk binding update group specific to each > => identifies the list of bulk binding update groups specific to each > > 5.1.1 > > Proxy Binding Update message. If there is no such grouping is > => Proxy Binding Update message. If there is no such grouping > > 5.2.1. > > given mobility session to a specific bulk binding update group is > => given mobility session to a specific bulk binding update group are > > > P.16 > if the if the received Proxy Binding Update from the new mobile > => if the received Proxy Binding Update from the new mobile > > 5.2.2 > > Currently, this specification only support sub-type value of (1) > => Currently, this specification only supports sub-type value of (1) > > 0 (Proxy Binding Update accepted). => (0) (Proxy Binding Update accepted). > > 6.2. Mobile Access Gateway - Configuration Variables > > this flag is set to (1), indicating that the the mobile access > => this flag is set to (1), indicating that the mobile access > > 9. Acknowledgements > > Patil Carlos Jesus Bernardos Cano and Jari Arkko for their reviews > => Patil, Carlos Jesus Bernardos Cano, and Jari Arkko for their reviews > > Thanks and best regards > Dirk > > Von: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] Im Auftrag von Jari Arkko > Gesendet: Dienstag, 3. Januar 2012 09:33 > An: Sri Gundavelli > Cc: netext@ietf.org; draft-ietf-netext-bulk-re-registration@tools.ietf.org > Betreff: Re: [netext] AD review of draft-ietf-netext-bulk-re-registration > > Sri: > > Thanks for the update! I have reviewed the changes and they look good to me with one exception (below). I have in any case requested an IETF Last Call to be initiated and expect that you fix the remaining issues by issuing yet another draft quickly. > > But the changes are pretty big -- it would also be useful if members of the WG reviewed the document while it is in the Last Call. > >> o When sending the Mobile Node Group Identifier option in the >> binding update messages related to the individual session >> establishment, the Bulk-Binding-Update (B) flag in the request >> MUST be set to a value of (1). However, when initiating any >> binding update operations with group specific scope, the Bulk- >> Binding-Update (B) flag in the request MUST always be set to a >> value of (0), with the Mobile Node Group Identifier option present >> in the request. > There is something wrong with the above text. B must be set in the session establishment, but not with "binding update operations with group specific scope"? (And what are those?) > > Jari > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From sgundave@cisco.com Fri Jan 6 07:53:51 2012 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 7C77121F8919 for ; Fri, 6 Jan 2012 07:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 xuNWz5ebB-dE for ; Fri, 6 Jan 2012 07:53:50 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id DEB3321F88C1 for ; Fri, 6 Jan 2012 07:53:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=4165; q=dns/txt; s=iport; t=1325865231; x=1327074831; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=aYpGEX/0zkzmKfaqr3dzG2yvlBm8lcMPKipvhX8FTG0=; b=Q9Ib7QcHNYqKlNHrV0HUzU5YSQFN6FvfdYHYZq4WH9sRq8J9v929zZdk BS9FXim2zw3q5MqzMzDcuwUbkVvejVnaarDyS1d9WMAttL9bL0Yd+acQ2 Mat94bqhdOvlHmGtA1G2+WQHZnnLNuKUhsXfOq5cKTSER1gVzzrxkavNa U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEoYB0+rRDoI/2dsb2JhbABDrEiBBYFyAQEBAwEBAQEPAScCATELBQ0BCD8uHxEBAQQBDQUih1gImB0BnhcEjBEEiDmMTpJW X-IronPort-AV: E=Sophos;i="4.71,468,1320624000"; d="scan'208";a="24055640" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 06 Jan 2012 15:53:50 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q06Frod6025798; Fri, 6 Jan 2012 15:53:50 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 07:53:50 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Fri, 6 Jan 2012 15:53:50 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 06 Jan 2012 07:53:49 -0800 From: Sri Gundavelli To: , Message-ID: Thread-Topic: AW: [netext] AD review of draft-ietf-netext-bulk-re-registration Thread-Index: AczJ8myw5V62JQlgToCzTdEiYgtCsgB0iktwADGy1Sc= In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2725ACB24B@HE113484.emea1.cds.t-internal.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Jan 2012 15:53:50.0282 (UTC) FILETIME=[61F442A0:01CCCC8B] Cc: netext@ietf.org, draft-ietf-netext-bulk-re-registration@tools.ietf.org Subject: Re: [netext] AD review of draft-ietf-netext-bulk-re-registration 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, 06 Jan 2012 15:53:51 -0000 Hi Dirk: Thanks for the review. I'm working on an update, will fix these issues. Regards Sri On 1/6/12 12:51 AM, "Dirk.von-Hugo@telekom.de" wrote: > Dear all, > > Referring to the suggested additional WG reviews of the updated draft I want > to share with you the minor nits I found ;-) > > 1. Intro > > provides a more optimal mechanism => provides a considerably improved > mechanism > (afaik 'optimal' already denotes the best) > > 3.1. Motivation > > revocation operations on a group on mobility sessions => revocation operations > on a group of mobility sessions > > 3.2. General Operation > > P.7 > respectively, while the LMA assigns them both to the same to the > bulk > => respectively, while the LMA assigns them both to the same bulk > > part of bulk binding update group, L1. => part of bulk binding update group, > (L1). > > 4.1 Extensions to Proxy Binding Update Message > > Figure 2 => Figure 2: Proxy Binding Update Message > (to have consistency to 4.2.) > > 'bulk binding operation group' (occurs 3 times in the draft, see p.12) is not > defined?! Shouldn't it read => 'bulk binding update group' ? > > group and thus any any binding update => group and thus any binding update > > 5.1 MAG Considerations > > identifies the list of bulk binding update group specific to each > => identifies the list of bulk binding update groups specific to each > > 5.1.1 > > Proxy Binding Update message. If there is no such grouping is > => Proxy Binding Update message. If there is no such grouping > > 5.2.1. > > given mobility session to a specific bulk binding update group is > => given mobility session to a specific bulk binding update group are > > > P.16 > if the if the received Proxy Binding Update from the new mobile > => if the received Proxy Binding Update from the new mobile > > 5.2.2 > > Currently, this specification only support sub-type value of (1) > => Currently, this specification only supports sub-type value of (1) > > 0 (Proxy Binding Update accepted). => (0) (Proxy Binding Update accepted). > > 6.2. Mobile Access Gateway - Configuration Variables > > this flag is set to (1), indicating that the the mobile access > => this flag is set to (1), indicating that the mobile access > > 9. Acknowledgements > > Patil Carlos Jesus Bernardos Cano and Jari Arkko for their reviews > => Patil, Carlos Jesus Bernardos Cano, and Jari Arkko for their reviews > > Thanks and best regards > Dirk > > Von: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] Im Auftrag von > Jari Arkko > Gesendet: Dienstag, 3. Januar 2012 09:33 > An: Sri Gundavelli > Cc: netext@ietf.org; draft-ietf-netext-bulk-re-registration@tools.ietf.org > Betreff: Re: [netext] AD review of draft-ietf-netext-bulk-re-registration > > Sri: > > Thanks for the update! I have reviewed the changes and they look good to me > with one exception (below). I have in any case requested an IETF Last Call to > be initiated and expect that you fix the remaining issues by issuing yet > another draft quickly. > > But the changes are pretty big -- it would also be useful if members of the WG > reviewed the document while it is in the Last Call. > >> o When sending the Mobile Node Group Identifier option in the >> binding update messages related to the individual session >> establishment, the Bulk-Binding-Update (B) flag in the request >> MUST be set to a value of (1). However, when initiating any >> binding update operations with group specific scope, the Bulk- >> Binding-Update (B) flag in the request MUST always be set to a >> value of (0), with the Mobile Node Group Identifier option present >> in the request. > > There is something wrong with the above text. B must be set in the session > establishment, but not with "binding update operations with group specific > scope"? (And what are those?) > > Jari > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From cjbc@it.uc3m.es Fri Jan 6 11:01:18 2012 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 8B6DB21F87D7 for ; Fri, 6 Jan 2012 11:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 ASoUiGnMwnZj for ; Fri, 6 Jan 2012 11:01:17 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 7030C21F87D3 for ; Fri, 6 Jan 2012 11:01:17 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (82.158.121.177.dyn.user.ono.com [82.158.121.177]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 7C51E9CB950 for ; Fri, 6 Jan 2012 20:01:14 +0100 (CET) Message-ID: <1325876469.4085.24.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: netext@ietf.org Date: Fri, 06 Jan 2012 20:01:09 +0100 Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-1iO/6EFzOm2nkfpYyuFn" X-Mailer: Evolution 3.0.3-3 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18630.000 Subject: [netext] Review of draft-ietf-netext-access-network-option-03 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, 06 Jan 2012 19:01:18 -0000 --=-1iO/6EFzOm2nkfpYyuFn Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Dear all, I've read draft-ietf-netext-access-network-option-03. It is well written and most of my comments (for -00 version) have been addressed. Some additional comments below: - I think the names of the new defined mobility header and the options may lead to a bit of confusion. Section 3 deals with the new mobility header, but it is called "Access Network Identifier Option". I'm not sure if it'd be better to call it "Access Network Identifier Mobility Header"/"Access Network Identifier Mobility Option"/"Access Network Identifier". The (minor) problem I have is that there is also an option which has a very similar name ("Access Network Identifier Sub-option"). - Related to the former, I think Sections 3.2 to 3.4 should be moved to a lower hierarchy level (like 3.1.1 to 3.1.3), because they deal with sub-options of the Access Network Identifier Sub-Option (which is defined in Section 3.1). - The Network-Identifier Sub-option (Section 3.2) seems 802.11 specific. If that is the case, I think it'd be better to rename it so the name reflects that. - Section 4.1. I think the text may be a bit reworded, so it does not say that "Specifically, the following parameters must be defined." referring to the currently defined 3 Access Network Identifier sub-options. I think it should leave room for sub-options defined in the future. Additionally, the "must" normative term is used in lower case. The same comment applies to Section 4.2. - When the EnableANISubOptetworkIdentifier config variable is discussed, I think the per-interface example does not consider all possible cases. Maybe some text about VLAN configurations may be useful. - Section 5. I don't know if I'm missing something here (most likely), but I don't see why there is no text about the "Network-Identifier" and "Geo-Location" sub-options (Sections 3.2 and 3.3). Shouldn't be there also text for them? Nits: - "The specific details on how the local mobility anchor uses this information is out-of-scope..." --> "are out-of-scope"? - "is used to exchanged access network related information" --> "is used to exchange..." - "If the mobile access gateway is configured to support to Access..." --> I think the last "to" should be removed. Hope this helps. Kind Regards, Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-1iO/6EFzOm2nkfpYyuFn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk8HRPUACgkQNdy6TdFwT2fsOgCbBpSB0RTpsXpiWU8wOh73wQz3 pQ0AnjT3WINIjkCC1Sv+Wgqbxei0y0dX =HpnU -----END PGP SIGNATURE----- --=-1iO/6EFzOm2nkfpYyuFn-- From sgundave@cisco.com Fri Jan 6 12:06:17 2012 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 8DE0121F8632 for ; Fri, 6 Jan 2012 12:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Rcws04Fjiv0X for ; Fri, 6 Jan 2012 12:06:17 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0D84E21F8628 for ; Fri, 6 Jan 2012 12:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2699; q=dns/txt; s=iport; t=1325880367; x=1327089967; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=tBxVvdwOcOp1NTyW/g2ePMeJey155IchJ7gEkUbpTnM=; b=WbNggiqu8BUyO+juyxHML7U8qJr6WBYNdN3BiJxxO7FrFOKwCLb4UVXp VBtS3PerZEGbL4gzg63eu754D+nXMkHFYxEYmrJfX6g2DtDBZc3bGxYpL VHUdPD8oiJENH63n8oW5g1saHFHXaqfTJzNgaL/nEWIw4XXkr/5C/aDaK Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAChTB0+rRDoJ/2dsb2JhbABDrEGBBYFyAQEBAwESARQVAUENAQiBHQEBBAESIodYmB0BnhuMEQSIBjOMTpJW X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; d="scan'208";a="24182789" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 06 Jan 2012 20:06:06 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q06K65r9020949; Fri, 6 Jan 2012 20:06:05 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 12:06:05 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Fri, 6 Jan 2012 20:06:05 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 06 Jan 2012 12:06:01 -0800 From: Sri Gundavelli To: , Message-ID: Thread-Topic: [netext] Review of draft-ietf-netext-access-network-option-03 Thread-Index: AczMrpyQX1qVzCWqsECKlJvLogSC6A== In-Reply-To: <1325876469.4085.24.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 06 Jan 2012 20:06:05.0843 (UTC) FILETIME=[9F739630:01CCCCAE] Subject: Re: [netext] Review of draft-ietf-netext-access-network-option-03 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, 06 Jan 2012 20:06:17 -0000 Hi Carlos, Thanks a lot for the second review. We will address these comments and hopefully the WGLC can be initiated on this draft now. Regards Sri On 1/6/12 11:01 AM, "Carlos Jes=FAs Bernardos Cano" wrote: > Dear all, >=20 > I've read draft-ietf-netext-access-network-option-03. It is well written > and most of my comments (for -00 version) have been addressed. >=20 > Some additional comments below: >=20 > - I think the names of the new defined mobility header and the options > may lead to a bit of confusion. Section 3 deals with the new mobility > header, but it is called "Access Network Identifier Option". I'm not > sure if it'd be better to call it "Access Network Identifier Mobility > Header"/"Access Network Identifier Mobility Option"/"Access Network > Identifier". The (minor) problem I have is that there is also an option > which has a very similar name ("Access Network Identifier Sub-option"). >=20 > - Related to the former, I think Sections 3.2 to 3.4 should be moved to > a lower hierarchy level (like 3.1.1 to 3.1.3), because they deal with > sub-options of the Access Network Identifier Sub-Option (which is > defined in Section 3.1). >=20 > - The Network-Identifier Sub-option (Section 3.2) seems 802.11 specific. > If that is the case, I think it'd be better to rename it so the name > reflects that. >=20 > - Section 4.1. I think the text may be a bit reworded, so it does not > say that "Specifically, the following parameters must be defined." > referring to the currently defined 3 Access Network Identifier > sub-options. I think it should leave room for sub-options defined in the > future. Additionally, the "must" normative term is used in lower case. > The same comment applies to Section 4.2. >=20 > - When the EnableANISubOptetworkIdentifier config variable is discussed, > I think the per-interface example does not consider all possible cases. > Maybe some text about VLAN configurations may be useful. >=20 > - Section 5. I don't know if I'm missing something here (most likely), > but I don't see why there is no text about the "Network-Identifier" and > "Geo-Location" sub-options (Sections 3.2 and 3.3). Shouldn't be there > also text for them? >=20 > Nits: >=20 > - "The specific details on how the local mobility anchor uses this > information is out-of-scope..." --> "are out-of-scope"? > - "is used to exchanged access network related information" --> "is used > to exchange..." > - "If the mobile access gateway is configured to support to Access..." > --> I think the last "to" should be removed. >=20 > Hope this helps. >=20 > Kind Regards, >=20 > Carlos From internet-drafts@ietf.org Sat Jan 7 09:49:11 2012 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 E565621F84CF; Sat, 7 Jan 2012 09:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 36JMi8+Ny7+M; Sat, 7 Jan 2012 09:49:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD9D21F84B9; Sat, 7 Jan 2012 09:49:11 -0800 (PST) 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: 3.64p1 Message-ID: <20120107174911.24298.68516.idtracker@ietfa.amsl.com> Date: Sat, 07 Jan 2012 09:49:11 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-access-network-option-04.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 17:49:12 -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 Wor= king Group of the IETF. Title : Access Network Identifier (ANI) Option for Proxy Mobile = IPv6 Author(s) : Sri Gundavelli Jouni Korhonen Mark Grayson Kent Leung Rajesh Pazhyannur Filename : draft-ietf-netext-access-network-option-04.txt Pages : 16 Date : 2012-01-07 This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. Based on the received information, the local mobility anchor is able to provide access network and access operator specific handling or policing for the mobile node traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-access-network-option= -04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-access-network-option-= 04.txt From sgundave@cisco.com Sat Jan 7 10:01:01 2012 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 1624F21F8480 for ; Sat, 7 Jan 2012 10:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 JB2uSmeDF+a0 for ; Sat, 7 Jan 2012 10:01:00 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 46D7521F84EA for ; Sat, 7 Jan 2012 10:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3997; q=dns/txt; s=iport; t=1325959260; x=1327168860; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=tl2RSai+PlLc2Lu1FXl1Pc0tFnO/7bKVN1XEcayk5tk=; b=BpaZpnTS2eTDzZIJkcFKNVH72a/Bb8MSjIpKG7qxoVgcaBPB/qDfI1RD 0DvuzLdRe38gODZv9fyBgkUCEgddRNKobejldsuxQPkg0xTy+Ka6n+sds iXDg7oIBDt8hQg66B/oRJGUyE/xKd0vcxW72oQjEJNcp2c2rjdHcGO6Ki k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACuHCE+rRDoH/2dsb2JhbABDrEOBBYFyAQEBAwESARQVAUENAQiBHQEBBAESIodYl2UBnXeMEQSIBjOMUJJa X-IronPort-AV: E=Sophos;i="4.71,473,1320624000"; d="scan'208";a="24293457" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 07 Jan 2012 18:01:00 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q07I0xou014440; Sat, 7 Jan 2012 18:00:59 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 7 Jan 2012 10:00:59 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Sat, 7 Jan 2012 18:00:58 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Sat, 07 Jan 2012 10:00:57 -0800 From: Sri Gundavelli To: , Message-ID: Thread-Topic: [netext] Review of draft-ietf-netext-access-network-option-03 Thread-Index: AczNZk4+69JpoVRCRE2KpCEcR6PKSg== In-Reply-To: <1325876469.4085.24.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 07 Jan 2012 18:00:59.0884 (UTC) FILETIME=[4FF6E2C0:01CCCD66] Subject: Re: [netext] Review of draft-ietf-netext-access-network-option-03 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: Sat, 07 Jan 2012 18:01:01 -0000 Hi Carlos: Thanks for the review and good comments. Appreciated it. Posted the updated version.=20 Idnit Errors/Warnings/Spell check: Zero Comments inline. On 1/6/12 11:01 AM, "Carlos Jes=FAs Bernardos Cano" wrote: > Dear all, >=20 > I've read draft-ietf-netext-access-network-option-03. It is well written > and most of my comments (for -00 version) have been addressed. >=20 > Some additional comments below: >=20 > - I think the names of the new defined mobility header and the options > may lead to a bit of confusion. Section 3 deals with the new mobility > header, but it is called "Access Network Identifier Option". I'm not > sure if it'd be better to call it "Access Network Identifier Mobility > Header"/"Access Network Identifier Mobility Option"/"Access Network > Identifier". The (minor) problem I have is that there is also an option > which has a very similar name ("Access Network Identifier Sub-option"). >=20 We looked at it, appears Ok. The names are not ambiguous. There is one mobility option and rest sub-options in that option. But, I will wait for more inputs. Any cases, reworded where ever possible. > - Related to the former, I think Sections 3.2 to 3.4 should be moved to > a lower hierarchy level (like 3.1.1 to 3.1.3), because they deal with > sub-options of the Access Network Identifier Sub-Option (which is > defined in Section 3.1). >=20 Good point. Done > - The Network-Identifier Sub-option (Section 3.2) seems 802.11 specific. > If that is the case, I think it'd be better to rename it so the name > reflects that. >=20 We did not want to restrict the name to SSID, it could be used beyond WLAN access networks. I thought of defining a sub-type for qualifying this, but given the ATT option, I rather not define a new registry for this. I've added text to indicate SSID as an example. Does this sound reasonable ? > - Section 4.1. I think the text may be a bit reworded, so it does not > say that "Specifically, the following parameters must be defined." > referring to the currently defined 3 Access Network Identifier > sub-options. I think it should leave room for sub-options defined in the > future. Additionally, the "must" normative term is used in lower case. > The same comment applies to Section 4.2. >=20 I slightly reworded this. The spec is only identifying three ATT related parameters and that's what is defined in BUL/BCE entries. If a new draft defines new sub-options, that spec has to extend the BCE/BUL entries. > - When the EnableANISubOptetworkIdentifier config variable is discussed, > I think the per-interface example does not consider all possible cases. > Maybe some text about VLAN configurations may be useful. >=20 All of the IE's can be configured on the MAG, on a per-interface basis. Eac= h interface can be part of specific VLAN, identified by a .1q tag. I've updated the text to state, this can be these static params, or obtained through other means such as DHCP option 82, or in access specific means. > - Section 5. I don't know if I'm missing something here (most likely), > but I don't see why there is no text about the "Network-Identifier" and > "Geo-Location" sub-options (Sections 3.2 and 3.3). Shouldn't be there > also text for them? >=20 Yes. You are missing some thing, that the authors get lazy and start taking short cuts, when they hit the last sections of the document :) Fixed > Nits: >=20 > - "The specific details on how the local mobility anchor uses this > information is out-of-scope..." --> "are out-of-scope"? > - "is used to exchanged access network related information" --> "is used > to exchange..." > - "If the mobile access gateway is configured to support to Access..." > --> I think the last "to" should be removed. >=20 Fixed. Thanks !!! > Hope this helps. > Absolutely. Best Regards Sri =20 > Kind Regards, >=20 > Carlos From cjbc@it.uc3m.es Sat Jan 7 13:09:34 2012 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 1E35621F849C for ; Sat, 7 Jan 2012 13:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 up5N+95ih4FX for ; Sat, 7 Jan 2012 13:09:33 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id DE1E121F847C for ; Sat, 7 Jan 2012 13:09:32 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (82.158.121.177.dyn.user.ono.com [82.158.121.177]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id C6BBD760DB2; Sat, 7 Jan 2012 22:09:30 +0100 (CET) Message-ID: <1325970570.17869.5.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Sri Gundavelli Date: Sat, 07 Jan 2012 22:09:30 +0100 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-GORQy0B5G5VMYGDWKWtx" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18632.002 Cc: netext@ietf.org Subject: Re: [netext] Review of draft-ietf-netext-access-network-option-03 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: Sat, 07 Jan 2012 21:09:34 -0000 --=-GORQy0B5G5VMYGDWKWtx Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Sri, Thanks for taking into account my comments. Some minor comments inline below. On Sat, 2012-01-07 at 10:00 -0800, Sri Gundavelli wrote: > Hi Carlos: >=20 > Thanks for the review and good comments. Appreciated it. Posted the updat= ed > version.=20 >=20 > Idnit Errors/Warnings/Spell check: Zero >=20 >=20 > Comments inline. >=20 >=20 >=20 > On 1/6/12 11:01 AM, "Carlos Jes=FAs Bernardos Cano" wro= te: >=20 > > Dear all, > >=20 > > I've read draft-ietf-netext-access-network-option-03. It is well writte= n > > and most of my comments (for -00 version) have been addressed. > >=20 > > Some additional comments below: > >=20 > > - I think the names of the new defined mobility header and the options > > may lead to a bit of confusion. Section 3 deals with the new mobility > > header, but it is called "Access Network Identifier Option". I'm not > > sure if it'd be better to call it "Access Network Identifier Mobility > > Header"/"Access Network Identifier Mobility Option"/"Access Network > > Identifier". The (minor) problem I have is that there is also an option > > which has a very similar name ("Access Network Identifier Sub-option"). > >=20 >=20 > We looked at it, appears Ok. The names are not ambiguous. There is one > mobility option and rest sub-options in that option. But, I will wait for > more inputs. Any cases, reworded where ever possible. >=20 Well, there are no duplicated names, that's true. What I meant is that there is one mobility option/header, which has one sub-option (called very similarly), which then has sub-options. >=20 > > - Related to the former, I think Sections 3.2 to 3.4 should be moved to > > a lower hierarchy level (like 3.1.1 to 3.1.3), because they deal with > > sub-options of the Access Network Identifier Sub-Option (which is > > defined in Section 3.1). > >=20 >=20 > Good point. Done >=20 >=20 > > - The Network-Identifier Sub-option (Section 3.2) seems 802.11 specific= . > > If that is the case, I think it'd be better to rename it so the name > > reflects that. > >=20 >=20 > We did not want to restrict the name to SSID, it could be used beyond WLA= N > access networks. I thought of defining a sub-type for qualifying this, bu= t > given the ATT option, I rather not define a new registry for this. I've > added text to indicate SSID as an example. Does this sound reasonable ? Yes, thanks. >=20 >=20 > > - Section 4.1. I think the text may be a bit reworded, so it does not > > say that "Specifically, the following parameters must be defined." > > referring to the currently defined 3 Access Network Identifier > > sub-options. I think it should leave room for sub-options defined in th= e > > future. Additionally, the "must" normative term is used in lower case. > > The same comment applies to Section 4.2. > >=20 >=20 > I slightly reworded this. The spec is only identifying three ATT related > parameters and that's what is defined in BUL/BCE entries. If a new draft > defines new sub-options, that spec has to extend the BCE/BUL entries. >=20 OK. >=20 > > - When the EnableANISubOptetworkIdentifier config variable is discussed= , > > I think the per-interface example does not consider all possible cases. > > Maybe some text about VLAN configurations may be useful. > >=20 >=20 > All of the IE's can be configured on the MAG, on a per-interface basis. E= ach > interface can be part of specific VLAN, identified by a .1q tag. I've > updated the text to state, this can be these static params, or obtained > through other means such as DHCP option 82, or in access specific means. >=20 OK. >=20 > > - Section 5. I don't know if I'm missing something here (most likely), > > but I don't see why there is no text about the "Network-Identifier" and > > "Geo-Location" sub-options (Sections 3.2 and 3.3). Shouldn't be there > > also text for them? > >=20 >=20 > Yes. You are missing some thing, that the authors get lazy and start taki= ng > short cuts, when they hit the last sections of the document :) > Fixed >=20 :) >=20 > > Nits: > >=20 > > - "The specific details on how the local mobility anchor uses this > > information is out-of-scope..." --> "are out-of-scope"? > > - "is used to exchanged access network related information" --> "is use= d > > to exchange..." > > - "If the mobile access gateway is configured to support to Access..." > > --> I think the last "to" should be removed. > >=20 >=20 > Fixed. Thanks !!! >=20 > > Hope this helps. > > >=20 > Absolutely. >=20 Thanks. Kind Regards, Carlos >=20 > Best Regards > Sri >=20 >=20 >=20 > =20 > > Kind Regards, > >=20 > > Carlos >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-GORQy0B5G5VMYGDWKWtx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk8ItIoACgkQNdy6TdFwT2c6swCfZv/Jq5I8BRAvm23SpxbWt3ps oN8AoNwxzakx/uu+FHKnaZWoS5DkMvTw =FGzM -----END PGP SIGNATURE----- --=-GORQy0B5G5VMYGDWKWtx-- From internet-drafts@ietf.org Tue Jan 10 22:50:22 2012 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 62B7821F857F; Tue, 10 Jan 2012 22:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 lm0H6VFWRIn6; Tue, 10 Jan 2012 22:50:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F4021F853F; Tue, 10 Jan 2012 22:50:21 -0800 (PST) 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: 3.64p1 Message-ID: <20120111065021.24923.47802.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2012 22:50:21 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-bulk-re-registration-10.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: Wed, 11 Jan 2012 06:50:22 -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 Wor= king Group of the IETF. Title : Bulk Binding Update Support for Proxy Mobile IPv6 Author(s) : Fuad Abinader Sri Gundavelli Kent Leung Suresh Krishnan Domagoj Premec Filename : draft-ietf-netext-bulk-re-registration-10.txt Pages : 23 Date : 2012-01-10 For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility anchor on a per-session basis. In the absence of signaling semantics for performing operations with group specific scope, it results in significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines optimizations to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group specific scope with the use of a group identifier. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-bulk-re-registration-= 10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-bulk-re-registration-1= 0.txt From sgundave@cisco.com Tue Jan 10 23:01:34 2012 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 F38E721F882C for ; Tue, 10 Jan 2012 23:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 l5nVuqjDiY77 for ; Tue, 10 Jan 2012 23:01:33 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id BF25921F8823 for ; Tue, 10 Jan 2012 23:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1589; q=dns/txt; s=iport; t=1326265281; x=1327474881; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=LkcwZcpI+hNzzA/f4EcqcGQKd8T8iWZZ+qvaDEFguz0=; b=WZLlXtxB9oL7JdeROdfiB8aY/ayt3XOzLddmQSZE8+yArYrc2G9gMc9I /5L4g37og4TFwQAs6BEKsN/FazkS72qB6IUD5YEjM7cu+djI+W7eHhkI2 5LAA+to+ZagSkD6OWB/C5Tp5Ked32C+63f1EBYWQBdLoms3HQE+FQbzqV E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAG8yDU+rRDoI/2dsb2JhbABCrFyBBYFyAQEBAwESAScCATwFDQEIgR0BAQQOBSKHWJhbAZ4XjB0EiDqMUpJb X-IronPort-AV: E=Sophos;i="4.71,492,1320624000"; d="scan'208";a="24814517" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 11 Jan 2012 07:01:20 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0B71K5M010566; Wed, 11 Jan 2012 07:01:20 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 23:01:20 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Jan 2012 07:01:19 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 10 Jan 2012 23:01:16 -0800 From: Sri Gundavelli To: Jari Arkko Message-ID: Thread-Topic: [netext] AD review of draft-ietf-netext-bulk-re-registration Thread-Index: AczQLs/IXqWMicKUvEmZ0IVZ9g1Ozw== In-Reply-To: <4F02BD4A.4030700@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Jan 2012 07:01:20.0313 (UTC) FILETIME=[D25AA290:01CCD02E] Cc: "netext@ietf.org" , draft-ietf-netext-bulk-re-registration@tools.ietf.org Subject: Re: [netext] AD review of draft-ietf-netext-bulk-re-registration 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, 11 Jan 2012 07:01:34 -0000 Hi Jari: Updated doc posted. Addressed all the comments from Dirk. Mostly editorial, expect one change. Diff appears to be large, given that I touched many part of the doc. - Change from a 16-bit sub-type to a 8-bit value, and the use of reserved field, in the Mobile Node Group Identifier option - Editorial changes for consistency with some minor rewrites Regards Sri On 1/3/12 12:33 AM, "Jari Arkko" wrote: > Sri: > > Thanks for the update! I have reviewed the changes and they look good to me > with one exception (below). I have in any case requested an IETF Last Call to > be initiated and expect that you fix the remaining issues by issuing yet > another draft quickly. > > But the changes are pretty big -- it would also be useful if members of the WG > reviewed the document while it is in the Last Call. > >> o When sending the Mobile Node Group Identifier option in the >> binding update messages related to the individual session >> establishment, the Bulk-Binding-Update (B) flag in the request >> MUST be set to a value of (1). However, when initiating any >> binding update operations with group specific scope, the Bulk- >> Binding-Update (B) flag in the request MUST always be set to a >> value of (0), with the Mobile Node Group Identifier option present >> in the request. > > There is something wrong with the above text. B must be set in the session > establishment, but not with "binding update operations with group specific > scope"? (And what are those?) > > Jari > From sgundave@cisco.com Tue Jan 10 23:03:32 2012 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 BE5CF21F882E for ; Tue, 10 Jan 2012 23:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 vcL7RZs590f4 for ; Tue, 10 Jan 2012 23:03:31 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C35C521F8827 for ; Tue, 10 Jan 2012 23:03:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=5143; q=dns/txt; s=iport; t=1326265411; x=1327475011; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=7eqhjD9wDoAVvhiaUHf6cn+yp8Il9BRUKlzhm+7HZ+M=; b=gA0Zq0OGQE7hp2x2PDFLVD926WF/qrgFQOxU/KzkFmnMRV/U4UC6NNhI l8IQ3HMLABU21I0jP6R9r2U68WeYgCv4Dv+lrJNHaj/+KtYvOS16r2jOx jkBNZpFOfMjf2FuV5zn7FAG/EHyzkG1iTmuGNLX9SbVdJ6XNXDtG26f7a k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANgzDU+rRDoI/2dsb2JhbABCq2lzgQWBcgEBAQMBEgEUFQE8BQ0BCBgVcAEBBA4FIodYmF0BnhaIdYMoBIgHM4xSkls X-IronPort-AV: E=Sophos;i="4.71,492,1320624000"; d="scan'208";a="24792532" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 11 Jan 2012 07:03:30 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0B73UNh011461; Wed, 11 Jan 2012 07:03:30 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 23:03:30 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Jan 2012 07:03:29 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 10 Jan 2012 23:03:28 -0800 From: Sri Gundavelli To: Message-ID: Thread-Topic: [netext] Review of draft-ietf-netext-access-network-option-03 Thread-Index: AczQLx52axtG5xg460KSw4ZJG9MowQ== In-Reply-To: <1325970570.17869.5.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 11 Jan 2012 07:03:30.0357 (UTC) FILETIME=[1FDDC650:01CCD02F] Cc: netext@ietf.org Subject: Re: [netext] Review of draft-ietf-netext-access-network-option-03 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, 11 Jan 2012 07:03:32 -0000 Hi Carlos: Thanks. Will keep that one comment open on the sub-option name. Thanks again for the review. Regards Sri On 1/7/12 1:09 PM, "Carlos Jes=FAs Bernardos Cano" wrote: > Hi Sri, >=20 > Thanks for taking into account my comments. Some minor comments inline > below. >=20 >=20 > On Sat, 2012-01-07 at 10:00 -0800, Sri Gundavelli wrote: >> Hi Carlos: >>=20 >> Thanks for the review and good comments. Appreciated it. Posted the upda= ted >> version.=20 >>=20 >> Idnit Errors/Warnings/Spell check: Zero >>=20 >>=20 >> Comments inline. >>=20 >>=20 >>=20 >> On 1/6/12 11:01 AM, "Carlos Jes=FAs Bernardos Cano" wrot= e: >>=20 >>> Dear all, >>>=20 >>> I've read draft-ietf-netext-access-network-option-03. It is well writte= n >>> and most of my comments (for -00 version) have been addressed. >>>=20 >>> Some additional comments below: >>>=20 >>> - I think the names of the new defined mobility header and the options >>> may lead to a bit of confusion. Section 3 deals with the new mobility >>> header, but it is called "Access Network Identifier Option". I'm not >>> sure if it'd be better to call it "Access Network Identifier Mobility >>> Header"/"Access Network Identifier Mobility Option"/"Access Network >>> Identifier". The (minor) problem I have is that there is also an option >>> which has a very similar name ("Access Network Identifier Sub-option"). >>>=20 >>=20 >> We looked at it, appears Ok. The names are not ambiguous. There is one >> mobility option and rest sub-options in that option. But, I will wait fo= r >> more inputs. Any cases, reworded where ever possible. >>=20 >=20 > Well, there are no duplicated names, that's true. What I meant is that > there is one mobility option/header, which has one sub-option (called > very similarly), which then has sub-options. >=20 >>=20 >>> - Related to the former, I think Sections 3.2 to 3.4 should be moved to >>> a lower hierarchy level (like 3.1.1 to 3.1.3), because they deal with >>> sub-options of the Access Network Identifier Sub-Option (which is >>> defined in Section 3.1). >>>=20 >>=20 >> Good point. Done >>=20 >>=20 >>> - The Network-Identifier Sub-option (Section 3.2) seems 802.11 specific= . >>> If that is the case, I think it'd be better to rename it so the name >>> reflects that. >>>=20 >>=20 >> We did not want to restrict the name to SSID, it could be used beyond WL= AN >> access networks. I thought of defining a sub-type for qualifying this, b= ut >> given the ATT option, I rather not define a new registry for this. I've >> added text to indicate SSID as an example. Does this sound reasonable ? >=20 > Yes, thanks. >=20 >>=20 >>=20 >>> - Section 4.1. I think the text may be a bit reworded, so it does not >>> say that "Specifically, the following parameters must be defined." >>> referring to the currently defined 3 Access Network Identifier >>> sub-options. I think it should leave room for sub-options defined in th= e >>> future. Additionally, the "must" normative term is used in lower case. >>> The same comment applies to Section 4.2. >>>=20 >>=20 >> I slightly reworded this. The spec is only identifying three ATT related >> parameters and that's what is defined in BUL/BCE entries. If a new draft >> defines new sub-options, that spec has to extend the BCE/BUL entries. >>=20 >=20 > OK. >=20 >>=20 >>> - When the EnableANISubOptetworkIdentifier config variable is discussed= , >>> I think the per-interface example does not consider all possible cases. >>> Maybe some text about VLAN configurations may be useful. >>>=20 >>=20 >> All of the IE's can be configured on the MAG, on a per-interface basis. = Each >> interface can be part of specific VLAN, identified by a .1q tag. I've >> updated the text to state, this can be these static params, or obtained >> through other means such as DHCP option 82, or in access specific means. >>=20 >=20 > OK. >=20 >>=20 >>> - Section 5. I don't know if I'm missing something here (most likely), >>> but I don't see why there is no text about the "Network-Identifier" and >>> "Geo-Location" sub-options (Sections 3.2 and 3.3). Shouldn't be there >>> also text for them? >>>=20 >>=20 >> Yes. You are missing some thing, that the authors get lazy and start tak= ing >> short cuts, when they hit the last sections of the document :) >> Fixed >>=20 >=20 > :) >=20 >>=20 >>> Nits: >>>=20 >>> - "The specific details on how the local mobility anchor uses this >>> information is out-of-scope..." --> "are out-of-scope"? >>> - "is used to exchanged access network related information" --> "is use= d >>> to exchange..." >>> - "If the mobile access gateway is configured to support to Access..." >>> --> I think the last "to" should be removed. >>>=20 >>=20 >> Fixed. Thanks !!! >>=20 >>> Hope this helps. >>>=20 >>=20 >> Absolutely. >>=20 >=20 > Thanks. >=20 > Kind Regards, >=20 > Carlos >=20 >>=20 >> Best Regards >> Sri >>=20 >>=20 >>=20 >> =20 >>> Kind Regards, >>>=20 >>> Carlos >>=20 From jari.arkko@piuha.net Tue Jan 10 23:43:03 2012 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 A501A21F8846 for ; Tue, 10 Jan 2012 23:43:03 -0800 (PST) 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 EgqIl5zEbXc0 for ; Tue, 10 Jan 2012 23:43:03 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id F413B21F884E for ; Tue, 10 Jan 2012 23:43:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 362402CC4D; Wed, 11 Jan 2012 09:42:58 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4NxOyWjVNzR; Wed, 11 Jan 2012 09:42:57 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 4739E2CC31; Wed, 11 Jan 2012 09:42:57 +0200 (EET) Message-ID: <4F0D3D80.6020109@piuha.net> Date: Wed, 11 Jan 2012 09:42:56 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Sri Gundavelli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" , draft-ietf-netext-bulk-re-registration@tools.ietf.org Subject: Re: [netext] AD review of draft-ietf-netext-bulk-re-registration 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, 11 Jan 2012 07:43:03 -0000 Thanks for the update! Jari On 11.01.2012 09:01, Sri Gundavelli wrote: > Hi Jari: > > Updated doc posted. Addressed all the comments from Dirk. Mostly editorial, > expect one change. Diff appears to be large, given that I touched many part > of the doc. > > - Change from a 16-bit sub-type to a 8-bit value, and the use of reserved > field, in the Mobile Node Group Identifier option > - Editorial changes for consistency with some minor rewrites > > > > Regards > Sri > > > > On 1/3/12 12:33 AM, "Jari Arkko" wrote: > >> Sri: >> >> Thanks for the update! I have reviewed the changes and they look good to me >> with one exception (below). I have in any case requested an IETF Last Call to >> be initiated and expect that you fix the remaining issues by issuing yet >> another draft quickly. >> >> But the changes are pretty big -- it would also be useful if members of the WG >> reviewed the document while it is in the Last Call. >> >>> o When sending the Mobile Node Group Identifier option in the >>> binding update messages related to the individual session >>> establishment, the Bulk-Binding-Update (B) flag in the request >>> MUST be set to a value of (1). However, when initiating any >>> binding update operations with group specific scope, the Bulk- >>> Binding-Update (B) flag in the request MUST always be set to a >>> value of (0), with the Mobile Node Group Identifier option present >>> in the request. >> There is something wrong with the above text. B must be set in the session >> establishment, but not with "binding update operations with group specific >> scope"? (And what are those?) >> >> Jari >> > From jouni.nospam@gmail.com Mon Jan 16 06:13:11 2012 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 3CD2521F8601; Mon, 16 Jan 2012 06:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-1.317, BAYES_00=-2.599, MANGLED_SAVELE=2.3, RCVD_IN_DNSWL_LOW=-1] 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 PeDi4-rXd-Ii; Mon, 16 Jan 2012 06:13:10 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 227B021F85F4; Mon, 16 Jan 2012 06:13:09 -0800 (PST) Received: by lagv3 with SMTP id v3so1878029lag.31 for ; Mon, 16 Jan 2012 06:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vAQ6vx1nkDwoHokKs87TVjWFN8h8gWUyMeFPKFsb3F4=; b=xoXVeYFM0XiUjniYIIAMt3k9JCxWVyBsE2yA2H7fU8by4rzCSkT54B91T7UH4l4LNe Fmdlnoix8u0G8qAf2GqfKszhtmYi0aN4k4nzdufqZHYkzabGs42U3wlw+n/3HBL7Gey4 xkhmaDYdWDSAJYvDBjd4zi5z/fUQfAtCBzbts= Received: by 10.112.45.104 with SMTP id l8mr3010224lbm.34.1326723189099; Mon, 16 Jan 2012 06:13:09 -0800 (PST) Received: from a88-112-207-191.elisa-laajakaista.fi (a88-112-207-191.elisa-laajakaista.fi. [88.112.207.191]) by mx.google.com with ESMTPS id hl9sm8598557lab.5.2012.01.16.06.13.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Jan 2012 06:13:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <1326721461.4790.1331.camel@mightyatom.folly.org.uk> Date: Mon, 16 Jan 2012 16:13:05 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <1326721461.4790.1331.camel@mightyatom.folly.org.uk> To: Elwyn Davies X-Mailer: Apple Mail (2.1084) Cc: netext@ietf.org, General Area Review Team , draft-ietf-netext-radius-pmip6.all@tools.ietf.org Subject: Re: [netext] Gen-art: Last call review of draft-ietf-netext-radius-pmip6-06 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, 16 Jan 2012 14:13:11 -0000 Hi Elwyn, Thanks you for you detailed review. See my comments/answers inline. On Jan 16, 2012, at 3:44 PM, Elwyn Davies 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-radius-pmip6-06 > Reviewer: Elwyn Davies > Review Date: 16 January 2012 > IETF LC End Date: 19 January 2012 > IESG Telechat date: (if known) - > > Summary: Almost ready with just some minor nits. > > Major issues: - > > Minor issues: > s4.1, IP4_HOA_ONLY_SUPPORTED: Is there need to discuss what happens if > the MUST/MUST NOT conditions are not satisfied? If you mean this part of the MUST/MUST NOT: When this bit is set the PMIP6_SUPPORTED flag MUST also be set, and the IP4_HOA_SUPPORTED flag MUST NOT be set. If these conditions are not met, then e.g. AAA end points are misbehaving. I could clarify that in case of client receiving a wrong combination it treats the Access-Accept as an Access-Reject and in a case the AAA server received a wrong combination answers with an Access-Reject. Would this be ok? > > Nits/editorial comments: > s1, last para: s/visitor/visited/ > > s2, Home AAA: s/to mobile/to the mobile/ > > s3: Expand acronym PBU on first use. > > s3, para 7 (before numbered list): s/Following/The following/ > > s3, para below figure 2: s/illustrates topology where MAG/illustrates a > topologywhere the MAG/ > > s4, general: It might be helpful to replace the text 'to be defined by > IANA' in the Type specification fields with the relevant '(TBDxx)' if > that is the format that is wanted eventually. > > s4.1, para 1: "reserves a new capability bit" - I think two new bits are > reserved in this section. > > s4.1, IP4_HOA_ONLY_SUPPORTED: Expand acronym HNP on first use. > > s4.2: Expand acronyms NAI, PBA on first use. > > s4.2, et seq, Length fields: The formula '>= 3 octets' is confusing. > Suggest 'In octets, including Type and Length fields (>= 3)' > > s4.2: The abbreviated name used for this field is inconsistent: > MN-Identifier in para 1, MN-ID in last para. > > s4.5, para 2 and s4.7, para 2: s/If included by VAAA/If included by the > VAAA/ Ack for all the above. > > s4.8/s4.9/s4.12/s4.13: Is the all-zeroes case specified by prefix length > zero or 16 octets of zeroes? Not sure if an actual prefix of zero > length is meaningful here. Actually the prefix length should be 128 in this case. Thanks for spotting this. > > s4.8/s4.9: Need to specify how PrefixLength is represented (unsigned > integer). See above. > > s4.10: s/conveys 64 bits interface identifier/conveys an 8 octet long > interface identifier/ (for consistency with field definition in last > para.) > > s4.11: s/contains 64 bits interface identifier/contains an 8 octet long > interface identifier/ (for consistency with field definition in last > para.) I would say: ... conveys 64 bits (8 octets) interface identifier representing a particular MN's interface. since IIDs are always discussed as "64 bits interface ids". > > s4.16, last line of figure: s/LMA IPv6/DHCP v6 server/ > > s5.1, bullet 1: s/Home-/Home/ Ack. > > s7: I am not sure if the various must's and may's ought to be MUST's and > MAY's. > Any specific example? - Jouni From jouni.nospam@gmail.com Mon Jan 16 06:58:13 2012 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 6A87F21F85CF; Mon, 16 Jan 2012 06:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 z8zp5Lq8lrD1; Mon, 16 Jan 2012 06:58:13 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD4921F85B1; Mon, 16 Jan 2012 06:58:12 -0800 (PST) Received: by lagv3 with SMTP id v3so1908663lag.31 for ; Mon, 16 Jan 2012 06:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=uGWkC5A7Jr5k+r9oEYuKpYjRKb4FM4C9TC9O7hAilmA=; b=cldzcTdEoSE/WUnj246ZeoQT82WmdFDnUXrtoeUXcjuvJr0NxcisrWLcyTPoCQZw/P 9l1JJitbay8Wtl+sjuaX2qGV2QbnsXyKFS9ATrSTUdxzanW9/0k2dYRbaQKmOOjZ+vBb r5zRIn8nO2gd20iMEORfv4FvX5D9tpOaVvxDQ= Received: by 10.152.110.6 with SMTP id hw6mr6228891lab.37.1326725891442; Mon, 16 Jan 2012 06:58:11 -0800 (PST) Received: from a88-112-207-191.elisa-laajakaista.fi (a88-112-207-191.elisa-laajakaista.fi. [88.112.207.191]) by mx.google.com with ESMTPS id hl9sm8668469lab.5.2012.01.16.06.58.09 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Jan 2012 06:58:10 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <1326725349.4790.1345.camel@mightyatom.folly.org.uk> Date: Mon, 16 Jan 2012 16:58:08 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <1326721461.4790.1331.camel@mightyatom.folly.org.uk> <1326725349.4790.1345.camel@mightyatom.folly.org.uk> To: Elwyn Davies X-Mailer: Apple Mail (2.1084) Cc: netext@ietf.org, General Area Review Team , draft-ietf-netext-radius-pmip6.all@tools.ietf.org Subject: Re: [netext] Gen-art: Last call review of draft-ietf-netext-radius-pmip6-06 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, 16 Jan 2012 14:58:13 -0000 Hi, On Jan 16, 2012, at 4:49 PM, Elwyn Davies wrote: >>> s7: I am not sure if the various must's and may's ought to be MUST's and >>> MAY's. >>> > e.g s7.1 "This interface must support the transfer of > accounting records needed for service control and charging." > I couldn't decide whether this was a protocol requirement or statement > about what the implementation ought to do. 'must support' is ambiguous > and not being a RADIUS expert (and being too lazy today to go chase the > relevant spec) I wasn't sure whether this put any requirement on the > message structure or just required the user/implementer to send the > reklevant data using the facilities that were there. In the second case > 'must' is clearly fine. Similarly in 7.2. Hmm.. it is about statement for the implementers. Those indirectly refer to existing attributes so having a MUST there is probably a good idea. > > Thinking about it, the 'may's' in ss5.2, 6.2 and 7.3 are correct. > Ack. - Jouni > Once again thanks for the speedy turnaround. > > Regards, > Elwyn >> >> Any specific example? >> >> - Jouni >> > From elwynd@dial.pipex.com Mon Jan 16 06:48:05 2012 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 D31D321F8613; Mon, 16 Jan 2012 06:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.044 X-Spam-Level: X-Spam-Status: No, score=-101.044 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_00=-2.599, MANGLED_SAVELE=2.3, 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 aj1PTY4nyHNp; Mon, 16 Jan 2012 06:48:05 -0800 (PST) Received: from b.painless.aaisp.net.uk (b.painless.aaisp.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) by ietfa.amsl.com (Postfix) with ESMTP id DAD6F21F8607; Mon, 16 Jan 2012 06:48:03 -0800 (PST) Received: from 250.254.187.81.in-addr.arpa ([81.187.254.250]) by b.painless.aaisp.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Rmnqr-0005fo-83; Mon, 16 Jan 2012 14:48:01 +0000 From: Elwyn Davies To: jouni korhonen In-Reply-To: References: <1326721461.4790.1331.camel@mightyatom.folly.org.uk> Content-Type: text/plain Date: Mon, 16 Jan 2012 14:49:09 +0000 Message-Id: <1326725349.4790.1345.camel@mightyatom.folly.org.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 17 Jan 2012 09:36:39 -0800 Cc: netext@ietf.org, General Area Review Team , draft-ietf-netext-radius-pmip6.all@tools.ietf.org Subject: Re: [netext] Gen-art: Last call review of draft-ietf-netext-radius-pmip6-06 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, 16 Jan 2012 14:48:05 -0000 Hi. That's what I call *a speedy response*! Deleted the agreed ones. On Mon, 2012-01-16 at 16:13 +0200, jouni korhonen wrote: > .> > > Minor issues: > > s4.1, IP4_HOA_ONLY_SUPPORTED: Is there need to discuss what happens if > > the MUST/MUST NOT conditions are not satisfied? > > If you mean this part of the MUST/MUST NOT: > > When this bit is set the PMIP6_SUPPORTED flag MUST also be set, > and the IP4_HOA_SUPPORTED flag MUST NOT be set. > > If these conditions are not met, then e.g. AAA end points are misbehaving. > I could clarify that in case of client receiving a wrong combination it > treats the Access-Accept as an Access-Reject and in a case the AAA server > received a wrong combination answers with an Access-Reject. > > Would this be ok? > That sounds fine. > . > > > > s4.8/s4.9/s4.12/s4.13: Is the all-zeroes case specified by prefix length > > zero or 16 octets of zeroes? Not sure if an actual prefix of zero > > length is meaningful here. > > Actually the prefix length should be 128 in this case. Thanks for > spotting this. (or 32 for the IPv4 cases). Fine. > > > > > > s4.8/s4.9: Need to specify how PrefixLength is represented (unsigned > > integer). > > See above. > > > > > s4.10: s/conveys 64 bits interface identifier/conveys an 8 octet long > > interface identifier/ (for consistency with field definition in last > > para.) > > > > s4.11: s/contains 64 bits interface identifier/contains an 8 octet long > > interface identifier/ (for consistency with field definition in last > > para.) > > I would say: > > ... conveys 64 bits (8 octets) interface identifier representing a > particular MN's interface. > > since IIDs are always discussed as "64 bits interface ids". True. Actually it started out as just inserting 'a 64 bit (long)' until I noticed that you use 8 octets in the fields definition. Suggest you go with 'a 64 bit long interface identifier' > .> > > s7: I am not sure if the various must's and may's ought to be MUST's and > > MAY's. > > e.g s7.1 "This interface must support the transfer of accounting records needed for service control and charging." I couldn't decide whether this was a protocol requirement or statement about what the implementation ought to do. 'must support' is ambiguous and not being a RADIUS expert (and being too lazy today to go chase the relevant spec) I wasn't sure whether this put any requirement on the message structure or just required the user/implementer to send the reklevant data using the facilities that were there. In the second case 'must' is clearly fine. Similarly in 7.2. Thinking about it, the 'may's' in ss5.2, 6.2 and 7.3 are correct. Once again thanks for the speedy turnaround. Regards, Elwyn > > Any specific example? > > - Jouni > From Basavaraj.Patil@nokia.com Mon Jan 23 09:48:22 2012 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 F12F921F8540 for ; Mon, 23 Jan 2012 09:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, 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 LQjjxe2Wft5y for ; Mon, 23 Jan 2012 09:48:22 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3E58221F8531 for ; Mon, 23 Jan 2012 09:48:21 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0NHmJvJ003630 for ; Mon, 23 Jan 2012 19:48:20 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jan 2012 19:48:18 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.244]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0355.003; Mon, 23 Jan 2012 18:48:18 +0100 From: To: Thread-Topic: Review of I-D: draft-ietf-netext-access-network-option Thread-Index: AQHM2fcweADvb93F7UeJRBL3YL6aVw== Date: Mon, 23 Jan 2012 17:48:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.32] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jan 2012 17:48:18.0309 (UTC) FILETIME=[30A3C350:01CCD9F7] X-Nokia-AV: Clean Subject: [netext] Review of I-D: draft-ietf-netext-access-network-option 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, 23 Jan 2012 17:48:23 -0000 Please find my review comments for Rev 4 of the I-D (draft-ietf-netext-access-network-option) below: 1. The abstract can be improved to make it more relevant for a reader who does not know anything about Proxy MIP6. 2. In Intro section: "In many deployments there is a need for the local mobility anchor to provide differentiated services and policing to ... " What deployments are you refering to here? Deployments that have PMIP6 entities like MAG and LMA or is it applicable to any deployment? 3. I-D states: ",the geo-location of the mobile node known to the mobile access gateway..." How does the MAG know the geo-location of the MN? It is misleading since the accuracy could be less accurate if it is not coming from the MN itself. 4. In figure 1, is the geo-location info shown that of the MAG or is it that of the AP? 5. ANDSF and PCC have no explanations in the terminology section. It does not help one not familiar with 3GPP standards what these entities are. 6. The network-identifier suboption gives an example of the network name being an SSID. Would this indicate the operator ID in the case of cellular networks? Would it carry something like the MCC+MNC ? 7. SSIDs can be quite easily spoofed. Hence how useful is it to carry SSID info to the LMA. As stated in the I-D, the LMA may cause a change to the traffic based on such information. If the SSID is spoofed this could be detrimental to the traffic/service. 8. Sec 3.1.2: "This sub-option can be used for carrying the Geo-location of the network to which the mobile node is attached, as known to the mobile access gateway. " How does the MAG know the geo-location of an AP or base-station? 9. Are you reusing the format of the geo-location suboption as shown in Fig 5? 10. Can you give an example of the operator identifier specified in 3.1.3? 11. The comment in Sec 4.1: " The specific details on how the mobile access gateway obtains these information elements are access technology and deployment specific, and is out-side the scope of this document. " IMO, how the MAG gets these details is fairly relevant and cannot be out-of-scope of this I-D. 12. Provide a reference to Sec 6 for : "If the protocol configuration variable, EnableANISubOptNetworkIdentifier..." 13. Sec 4.1: "If the mobile access gateway had any of the Access Network Information mobility option included the Proxy Binding Update sent to a local mobility anchor, then the Proxy Binding Acknowledgement received from the local mobility anchor is also expected to contain the Access Network Information mobility option with the specific sub- options. If the mobile access gateway receives a Proxy Binding Acknowledgement with a successful Status Value but without an Access Network Information mobility option, then the mobile access gateway SHOULD log the event and based on its local policy MAY proceed to terminate the mobility session. In this case the mobile access gateway knows the local mobility anchor does not understand the Access Network Information mobility option and therefore MAY consider it as a misconfiguration of the Proxy Mobile IPv6 domain. " A MAG is associated with different LMAs. Hence it is possible that not all LMAs support the ANI option(s). Hence does the above behavior make sense? 14. Sec 4.2 does not explain what the LMA MUST do if it does not understand the ANI option. -Basavaraj From internet-drafts@ietf.org Tue Jan 24 05:43:46 2012 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 CBB4021F84EC; Tue, 24 Jan 2012 05:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OIpJ-Anokoz; Tue, 24 Jan 2012 05:43:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1168921F84E6; Tue, 24 Jan 2012 05:43:46 -0800 (PST) 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: 3.64p1 Message-ID: <20120124134346.12648.30614.idtracker@ietfa.amsl.com> Date: Tue, 24 Jan 2012 05:43:46 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip-lr-08.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 13:43:46 -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 Wor= king Group of the IETF. Title : Localized Routing for Proxy Mobile IPv6 Author(s) : Suresh Krishnan Rajeev Koodli Paulo Loureiro Qin Wu Ashutosh Dutta Filename : draft-ietf-netext-pmip-lr-08.txt Pages : 26 Date : 2012-01-24 Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, localized routing (LR) allows mobile nodes attached to the same or different mobile access gateways to route traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes initiation, utilization and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. It defines two new signaling messages, Localized Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), that are used to realize this mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip-lr-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-pmip-lr-08.txt From sgundave@cisco.com Tue Jan 24 11:57:38 2012 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 EE72C11E8096 for ; Tue, 24 Jan 2012 11:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 HTMlWQ6Bd3C1 for ; Tue, 24 Jan 2012 11:57:38 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2D921F8596 for ; Tue, 24 Jan 2012 11:57:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=6442; q=dns/txt; s=iport; t=1327435058; x=1328644658; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=YHjLB2cHmN6iNtiL6aGdjNWWFGWCw89TiktOBnMc/MU=; b=dZpgYVyF89rSCqKs+Q5OvoRP1KAZv0wVUB1HuLIPLcXAThKFJ/gPSn29 o6zTdliBA4K6BPPTQeX/I6Tq+B++0Wez1R+st6H7sQkOnu/aoLbE+8Aoy SxsjiXOlzhGG0AVpjnrPKp6us6J8vx1yJx1B/zGZ4kypp5rF98ZYni/Jx E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswFAAYMH0+rRDoJ/2dsb2JhbABCrjMCgQWBcgEBAQMBAQEBDwEnAgExBAwNAQhtMAIEARIbB4daCJl5AZ4WiQoBGwIBCgIUAwIBAwWDaYNPBIg/jF6OMIQ/ X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="26972377" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 24 Jan 2012 19:57:38 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0OJvbRN002450; Tue, 24 Jan 2012 19:57:37 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jan 2012 11:57:37 -0800 Received: from 171.70.241.46 ([171.70.241.46]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jan 2012 19:57:37 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 24 Jan 2012 11:57:37 -0800 From: Sri Gundavelli To: , Message-ID: Thread-Topic: [netext] Review of I-D: draft-ietf-netext-access-network-option Thread-Index: AQHM2fcweADvb93F7UeJRBL3YL6aV5Yb8OjO In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 24 Jan 2012 19:57:37.0804 (UTC) FILETIME=[6C127CC0:01CCDAD2] Subject: Re: [netext] Review of I-D: draft-ietf-netext-access-network-option 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, 24 Jan 2012 19:57:39 -0000 Hi Raj: Thanks for the review. Please see inline. On 1/23/12 9:48 AM, "Basavaraj.Patil@nokia.com" wrote: > > Please find my review comments for Rev 4 of the I-D > (draft-ietf-netext-access-network-option) below: > > > 1. The abstract can be improved to make it more relevant for a reader > who does not know anything about Proxy MIP6. > Ok. Can reword it. > 2. In Intro section: > "In many deployments there is a need for the local mobility anchor to > provide differentiated services and policing to ... > " > > What deployments are you refering to here? Deployments that have PMIP6 > entities like MAG and LMA or is it applicable to any deployment? > The reference is related to WLAN-EPC integrated (SPWIFI) architectures. We can qualify that. > 3. I-D states: ",the geo-location of the mobile node known to the > mobile access gateway..." > > How does the MAG know the geo-location of the MN? It is misleading > since the accuracy could be less accurate if it is not coming from the > MN itself. > Well, MN is an unmanaged entity, but its always the best source. But, as in most radio networks this is really the association of the mobile to an access point and the location info is derived based on that relation. Also, as in cellular networks, there is also the triangulation schemes, based on the users movement between AP's and is source for deriving that information. The information related to the location is moved between AP's and the controller over CAPWAP. > 4. In figure 1, is the geo-location info shown that of the MAG or is > it that of the AP? > Its the location of the AP, available at the MAG. This could have been delivered over CAPWAP, or over DHCP Option 82 from AP to controller, or static information configured on the MAG. We can clarify. > 5. ANDSF and PCC have no explanations in the terminology section. It > does not help one not familiar with 3GPP standards what these entities > are. > Ok. We can clarify. > 6. The network-identifier suboption gives an example of the network > name being an SSID. Would this indicate the operator ID in the case of > cellular networks? Would it carry something like the MCC+MNC ? > We have specific sub-types defined on the semantics of the identifier. But, sure it could be a VPLMN Id/MCC. We can clarify that. > 7. SSIDs can be quite easily spoofed. Hence how useful is it to carry > SSID info to the LMA. As stated in the I-D, the LMA may cause a change > to the traffic based on such information. If the SSID is spoofed this > could be detrimental to the traffic/service. > SSID information is coming to the LMA from a trusted source. There is a secure relation between MAG and LMA, between MAG and AP. Based on the security in the access network, the SSID information cannot be spoofed. The EAP messages that the MAG receives are received on a specific VLAN Id and which can map to a specific SSID, or this information can be embedded the AP in the DHCP option 82. > 8. Sec 3.1.2: > "This sub-option can be used for carrying the Geo-location of the network > to > which the mobile node is attached, as known to the mobile access > gateway. " > > How does the MAG know the geo-location of an AP or base-station? > It is statically configured information, sent over CAPWAP from AP to the MAG/controller, or send as information element in DHCP Option 82. > 9. Are you reusing the format of the geo-location suboption as shown > in Fig 5? > Yes. This is a standard format of the GEO location, in mobility option encoding. > 10. Can you give an example of the operator identifier specified in > 3.1.3? > provider1.example.com > 11. The comment in Sec 4.1: > " The specific details on > how the mobile access gateway obtains these information elements > are access technology and deployment specific, and is out-side the > scope of this document. > " > > IMO, how the MAG gets these details is fairly relevant and cannot be > out-of-scope of this I-D. > At the minimum this information can always be static information elements on the IE, which may be sufficient from this spec perspective. Additionally, we can add specific references to WLAN based access architectures and how that is tied to the north bound PMIP signaling. Generally, SPWIFI architectures has other protocol elements from the end to end solution perspective, specifically, CAPWAP based architectures are quite dominant and we may have allow room for integrating the two. > 12. Provide a reference to Sec 6 for : "If the protocol configuration > variable, > EnableANISubOptNetworkIdentifier..." > Ok. > 13. Sec 4.1: > "If the mobile access gateway had any of the Access Network > Information mobility option included the Proxy Binding Update sent to > a local mobility anchor, then the Proxy Binding Acknowledgement > received from the local mobility anchor is also expected to contain > the Access Network Information mobility option with the specific sub- > options. If the mobile access gateway receives a Proxy Binding > Acknowledgement with a successful Status Value but without an Access > Network Information mobility option, then the mobile access gateway > SHOULD log the event and based on its local policy MAY proceed to > terminate the mobility session. In this case the mobile access > gateway knows the local mobility anchor does not understand the > Access Network Information mobility option and therefore MAY consider > it as a misconfiguration of the Proxy Mobile IPv6 domain. > " > > A MAG is associated with different LMAs. Hence it is possible that not > all LMAs support the ANI option(s). Hence does the above behavior make > sense? > Typically, its a domain wide parameter, as with many other parameters that we have defined. > 14. Sec 4.2 does not explain what the LMA MUST do if it does not > understand the ANI option. > It should skip like with any other option. Will clarify this. Thanks for the review. Will take care of these comments. Regards Sri > > -Basavaraj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From internet-drafts@ietf.org Wed Jan 25 02:04:46 2012 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 807A721F861C; Wed, 25 Jan 2012 02:04:46 -0800 (PST) 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 2HwC-bOZakqn; Wed, 25 Jan 2012 02:04:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1AA21F85E1; Wed, 25 Jan 2012 02:04:46 -0800 (PST) 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: 3.64p1 Message-ID: <20120125100446.25911.48045.idtracker@ietfa.amsl.com> Date: Wed, 25 Jan 2012 02:04:46 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-radius-pmip6-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: Wed, 25 Jan 2012 10:04:46 -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 Wor= king Group of the IETF. Title : RADIUS Support for Proxy Mobile IPv6 Author(s) : Frank Xia Behcet Sarikaya Jouni Korhonen Sri Gundavelli Damjan Damic Filename : draft-ietf-netext-radius-pmip6-07.txt Pages : 37 Date : 2012-01-25 This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol defined in this document uses Radius based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the Mobile Node attaches, authenticates and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. In addition to the mobility session setup related interactions, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-radius-pmip6-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-radius-pmip6-07.txt From internet-drafts@ietf.org Thu Jan 26 13:17:51 2012 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 E2F8C21F8639; Thu, 26 Jan 2012 13:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 gghZ5RwsbBFC; Thu, 26 Jan 2012 13:17:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515FD21F85ED; Thu, 26 Jan 2012 13:17:48 -0800 (PST) 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: 3.64p1 Message-ID: <20120126211748.4377.51239.idtracker@ietfa.amsl.com> Date: Thu, 26 Jan 2012 13:17:48 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-access-network-option-05.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, 26 Jan 2012 21:17:51 -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 Wor= king Group of the IETF. Title : Access Network Identifier (ANI) Option for Proxy Mobile = IPv6 Author(s) : Sri Gundavelli Jouni Korhonen Mark Grayson Kent Leung Rajesh Pazhyannur Filename : draft-ietf-netext-access-network-option-05.txt Pages : 16 Date : 2012-01-26 This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. Based on the received information, the local mobility anchor is able to provide access network and access operator specific handling or policing for the mobile node traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-access-network-option= -05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-access-network-option-= 05.txt From internet-drafts@ietf.org Fri Jan 27 00:52:38 2012 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 BBB1821F8512; Fri, 27 Jan 2012 00:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 Ym43lJqLUUw7; Fri, 27 Jan 2012 00:52:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284A721F84C8; Fri, 27 Jan 2012 00:52:38 -0800 (PST) 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: 3.64p1 Message-ID: <20120127085238.16659.2453.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2012 00:52:38 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-sipto-option-01.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: Fri, 27 Jan 2012 08:52:38 -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 Wor= king Group of the IETF. Title : IPv4 Traffic Offload Selector Option for Proxy Mobile IP= v6 Author(s) : Sri Gundavelli Xingyue Zhou Jouni Korhonen Rajeev Koodli Filename : draft-ietf-netext-pmipv6-sipto-option-01.txt Pages : 12 Date : 2012-01-27 This specification defines a mechanism and a related mobility option for carrying IPv4 Offload traffic selectors between a mobile access gateway and a local mobility anchor in a Proxy Mobile IPv6 domain. Based on the received offload flow selectors from the local mobility anchor, a mobile access gateway can enable offload traffic rule on the selected IPv4 flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-sipto-option-0= 1.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-sipto-option-01= .txt From ahmad.muhanna@ericsson.com Mon Jan 30 08:20:01 2012 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 B02A921F8642 for ; Mon, 30 Jan 2012 08:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 0SHgnIAUV-U6 for ; Mon, 30 Jan 2012 08:20:00 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5303921F8698 for ; Mon, 30 Jan 2012 08:20:00 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q0UGJuwS031268 for ; Mon, 30 Jan 2012 10:19:59 -0600 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.2.40]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 30 Jan 2012 11:19:59 -0500 From: Ahmad Muhanna To: "netext@ietf.org" Date: Mon, 30 Jan 2012 11:19:57 -0500 Thread-Topic: Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.txt Thread-Index: Aczc0ROglE/CDUTBRuW75YlYxAYO1gCl2l/Q Message-ID: <1FCAE7B6027FE3489B8497A060C704C4443BD93B1B@EUSAACMS0714.eamcs.ericsson.se> References: <20120127085238.16659.2453.idtracker@ietfa.amsl.com> In-Reply-To: <20120127085238.16659.2453.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 16:20:01 -0000 Hello, Please find my review comments for Rev 01 of the I-D (draft-ietf-netext-pmipv6-sipto-option) below: I have mainly editorial comments that need clarification and a couple of mi= nor technical ones below. Regards, Ahmad >>>>> 1. Introduction Mobile Operators are expanding their network coverage by integrating various access technology domains into a common IP mobile core. For providing IP mobility support to a mobile node irrespective of the access network to which it is attached, the 3GPP S2/a Proxy Mobile IPv6 [TS23402] interface, specified by the 3GPP system architecture, is providing the needed protocol glue. [Ahmad-01] why we are using S2/a rather than S2a? [Ahmad-02] Please replace 'is providing' with 'provides' When this protocol interface based on Proxy Mobile IPv6 [RFC5213] is used, the mobile node is topologically anchored on the local mobility anchor [RFC5213] in the home network. [Ahmad-03] when Proxy Mobile IPv6 protocol [RFC5213] is used on this interface, the mo= bile node ... [Ahmad-04] Is it "anchored on" or "anchored at"? The mobile node's IP traffic is always tunneled back from the mobile access gateway [RFC5213] in the access network to the local mobility anchor in the home network. However, with the exponential growth in the mobile data traffic, mobile operators are exploring new ways to offload some of the IP traffic flows at the nearest access edge where ever there is an internet peering point, as supposed to carrying it all the way to the mobility anchor in the home network. Not all IP traffic needs to be routed back to the home network, some of the non-essential traffic which does not require IP mobility support can be offloaded at the mobile access gateway in the access network. This approach provides greater leverage and efficient usage of the mobile packet core with increased overall network capacity and by lowering transport costs. [Ahmad-06] I have problem with the last sentence above... what are we trying to say? May be something like follows: "With increased overall network capacity, this approach provides greater le= verage and efficient usage of the mobile packet core which help lowering tr= ansport cost" Hope it makes it read better! :-) The local mobility anchor in the home network can potentially deliver the IP flow selectors to the mobile access gateway in the access network, for identifying the IP flows that needs to be offloaded. This document defines a new mobility option, IP Traffic Offload Selector option for Proxy Mobile IPv6 (PMIPv6). This option can be used by the local mobility anchor for notifying the flow selectors for that can be used by the local mobility anchor for notifying the mobile access gateway flows that can be offloaded at the access edge. [Ahmad-07] This is a little confusing; sounds as if the notification goes to the flow = selectors. What about? "This option can be used by the local mobility anchor to notify the mobile = access gateway with the flow selectors that can be offloaded at the access = edge." Since, the mobile node's IP address topologically belongs to the home network, the offloaded IP traffic flows need to be NAT [RFC2663] translated. Given this NAT translation requirement for the offloaded traffic, this approach will be limited to mobile node's IPv4 flows. There are better ways to solve this problem for IPv6 and with the goal not to create NAT66 requirement, [Ahmad-08] Can we remove the above sentence? and start the sentence with the following= portion. This specification does not support traffic offload support for IPv6 flows. This document also does not define any new semantics for flow selectors. The flow identification and the related semantics are all leveraged from [RFC6088]. 2. Conventions and Terminology 2.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.2. Terminology All the mobility related terms used in this document are to be interpreted as defined in the base Proxy Mobile IPv6 specifications [RFC5213] and [RFC5844]. Additionally, this document uses the following abbreviations: IP Flow IP Flow represents a set of IP packets that match a traffic selector. The selector is typically based on the source IP address, destination IP address, source port, destination port and other fields in upper layer headers. Selective IP Traffic Offload (SIPTO) The approach of selecting specific IP flows and routing them to the local network, as supposed to tunneling them to the home network. NAT (Network Address Translation) Network Address Translation [RFC2663] is a method by which IP addresses are mapped from one address realm to another, providing transparent routing to end hosts. [Ahmad-09] Do we need to include this terminology? 3. Solution Overview The following illustrates the scenario where the mobile access gateway in an access network having the ability to offload some of the IPv4 traffic flows, based on the traffic selectors it received from the local mobility anchor in the home network. For example, all the HTTP flows may be be offloaded at the mobile access gateway and all the other flows for that mobility session are tunneled back to the local mobility anchor. _----_ _( )_ ( Internet ) (_ _) '----' | (IPv4 Traffic Offload Point at access edge gateway for non-essential traffic Ex: HTTP Traffic Offloaded) | ...................................................... | . +----------------+ +---+ . | Operator Value | |NAT| . | Added Services | +---+ . +----------------+ | _----_ | +-----+ _( )_ +-----+ [MN]----| MAG |=3D=3D=3D=3D=3D=3D( IP )=3D=3D=3D=3D=3D=3D| LMA |--= Internet +-----+ (_ _) +-----+ '----' ( . . . [Access Network] . [Home Network] ...................................................... Figure 1: Access Networks attached to MAG 3.1. LMA Considerations The following considerations apply to the local mobility anchor and the mobile access gateway. [Ahmad-10] Is this a common section then? Figure 1 explains the operational sequence of the IP Traffic Offload selectors between the mobile access gateway and the local mobility anchor. MN MAG(NAT) LMA |------>| | 1. Mobile Node Attach | |------->| 2. Proxy Binding Update | |<-------| 3. Proxy Binding Acknowledgement (IPTS Option) | |=3D=3D=3D=3D=3D=3D=3D=3D| 4. Tunnel/Route Setup | + | 5. Installing the traffic offload rules |------>| | 6. IPv4 packet from mobile node | | | 7. Forwarding rule - Tunnel home/offload | | | Figure 2: Exchange of IP Traffic Offload Selectors o If the received Proxy Binding Update includes the IP Traffic Offload Selector Option Section 4, but if the configuration variable, EnableIPTrafficOffloadSupport on the local mobility anchor is set to a value of (0), then the local mobility anchor MUST ignore the IP Traffic Offload Selector Option and process the rest of the packet. This would not have no effect on the operation of the rest of the protocol. o If the received Proxy Binding Update includes the IP Traffic Offload Selector Option Section 4, and if the configuration variable, EnableIPTrafficOffloadSupport on the local mobility anchor is set to a value of (1), then the local mobility anchor can construct the traffic selectors based on the offload policy and deliver those selectors in the Proxy Binding Acknowledgement message using the IP Traffic Offload Selector Option. [Ahmad-11] Why NOT use the following: "the local mobility anchor (identify/or acquire)= the traffic selectors based on.... This will encompass the possibility for= the LMA to receive the offload policy via a different infrastructure node,= e.g., PCRF. Just a suggestion. However, if the received Proxy Binding Update included a proposed Offload traffic selectors, the local mobility anchor MAY choose to honor that request and include the proposed selectors in the reply. 3.2. MAG Considerations o If the configuration variable, EnableIPTrafficOffloadSupport on the mobile access gateway is set to a value of (0), then the mobile access gateway MUST NOT include the IP Traffic Offload Selector Option Section 4 in the Proxy Binding Update message that it sends to the local mobility anchor. Otherwise, the option MUST be included in the Proxy Binding Update message. When this option is included, it is an indication to the local mobility anchor that the mobile access gateway is capable of supporting IP Traffic Offload support. The TS format field of the IP Traffic Offload [Ahmad-12] Have we defined what TS before now? Selector Option MUST be set to a value of (0), indicating that the mobile access gateway is not proposing any specific offload policy for that mobility session, but a request to the local mobility anchor to provide the IP traffic offload flow selectors for that mobility session. o The mobility access gateway MAY choose to include its proposed IP traffic offload flow selectors in the IP Traffic Offload Selector Option Section 4. Including this offload traffic spec serves as a [Ahmad-13] "Including this offload traffic selectors serves ..." proposal to the local mobility anchor, which the local mobility anchor can override with its own offload policy, or agree to the proposed policy. When including the offload traffic selectors, the TS format field of the IP Traffic Offload Selector Option MUST be set to the respective flow specification type. o If there is no IP Traffic Offload Selector Option in the corresponding Proxy Binding Acknowledgement message, that the mobile access gateway receives in response to a Proxy Binding Update, it serves as an indication that the local mobility anchor does not support IP Traffic Offload support for that mobility session, and it implies the local mobility anchor cannot deliver IP flow selectors for that mobility session. The mobility access [Ahmad-14] What the mobility access means here? is that a term that is defined somewhe= re? upon accepting the Proxy Binding Acknowledgement message MUST NOT enable any offload policy for that mobility session. All the mobile node's IP flows MUST be tunneled back to the local mobility anchor. o If there is IP Traffic Offload Selector Option in the corresponding Proxy Binding Acknowledgement message, it is an indication that the local mobility anchor has provided the IP traffic Offload selectors for that mobility session and the identified IP flows have to be offloaded. Considerations related to (M) flag MUST be applied. [Ahmad-15] what about MAG handling of the TS option in BA when the MAG has not sent it= in the BU? I believe this is a valid scenario that needs to be addressed. 4. IP Traffic Offload Selector Option A new mobility option, IP Traffic Offload Selector option, is defined for using it in Proxy Binding Update (PBU) and Proxy Binding Acknowledgement (PBA) messages exchanged between a local mobility anchor and a mobile access gateway. [Ahmad-16] "A new mobility option, IP Traffic Offload Selector option, is defined for using it in Proxy Binding Update (PBU) and Proxy Binding Acknowledgement (PBA) messages exchanged between a mobile access gateway= and a local mobility anchor." seems that the draft always mentions LMA fir= st! :-) This option is used for carrying the flow selectors for supporting IP traffic offload function at the mobile access gateway. [Ahmad-17] I think we should use the word enforcing/or enabling rather than supporting= for the sentence to read as follows: "This option is used for carrying the flow selectors for enforcing/enabling= IP traffic offload function at the mobile access gateway." The alignment requirement for this option is 4n. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Reserved | TS Format | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Selector ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: IP Traffic Offload Selector Option Type Length 8-bit unsigned integer indicating the length in octets of the option, excluding the type and length fields. Reserved [Ahmad-18] Insert line. This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. IP Traffic Offload Mode Flag [Ahmad-19] Insert line. This field indicates the offload mode. If the (M) flag value is set to a value of (1), it is an indication that all the flows except the identified IP flow(s) in this mobility option needs to be offloaded at the mobile access gateway. If the (M) flag value is set to a value of (0), it is an indication that the identified IP flow(s) needs to be offloaded at the mobile access gateway and all other IP flows associated with that mobility session needs to be tunneled to the local mobility anchor. [Ahmad-20] We need to add >>some text<< under the MAG consideration to mention that de= spite the M flag value in the TS Option in the BU, the setting by the LMA i= n the BA overrides. something like that. TS Format [Ahmad-21] Insert line. An 8-bit unsigned integer indicating the Traffic Selector Format. The value of "0" is reserved and is used when there are no selectors to carry, relevant when the option is used as a capability indicator. The value of (1) is assigned for IPv4 Binary Traffic Selector [RFC6088]. [Ahmad-22] should not we mention that all other values are reserved? TS Selector [Ahmad-23] Insert line. A variable-length opaque field for including the traffic specification identified by the TS format field. [Ahmad-24] Should not we say: " ... identified by the TS format field and the IP Traff= ic Offload Mode Flag" Just wondering. the key word here "identified" When the value of TS Format field is set to (1), the format that follows is the IPv4 Binary Traffic Selector specified in section 3.1 of [RFC6088]. From internet-drafts@ietf.org Mon Jan 30 14:07:05 2012 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 403C921F85C3; Mon, 30 Jan 2012 14:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 xogyH0Apl-ZX; Mon, 30 Jan 2012 14:07:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE6121F85AC; Mon, 30 Jan 2012 14:07:04 -0800 (PST) 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: 3.64p1 Message-ID: <20120130220704.18478.90517.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2012 14:07:04 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-radius-pmip6-08.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:07:05 -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 Wor= king Group of the IETF. Title : RADIUS Support for Proxy Mobile IPv6 Author(s) : Frank Xia Behcet Sarikaya Jouni Korhonen Sri Gundavelli Damjan Damic Filename : draft-ietf-netext-radius-pmip6-08.txt Pages : 37 Date : 2012-01-30 This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol defined in this document uses Radius based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the Mobile Node attaches, authenticates and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. In addition to the mobility session setup related interactions, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-radius-pmip6-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-radius-pmip6-08.txt From sgundave@cisco.com Mon Jan 30 16:29:49 2012 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 D3B6611E80E7 for ; Mon, 30 Jan 2012 16:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, 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 f+CJ6a3k18DO for ; Mon, 30 Jan 2012 16:29:48 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 52A7D11E80D9 for ; Mon, 30 Jan 2012 16:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=19545; q=dns/txt; s=iport; t=1327969788; x=1329179388; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=aCDPHDlk6OThfMFq/IJ9AMT7LuFdfbHhFCfXpAiieOs=; b=mgPu8eed+5Nccc6y8vhNmsmSUnvCi2MYuDBT0YPC5yqfq3xevbj5oYrw QQwcfUWv3ATvoj3t1ijjaJ8EgyAMeMeupvx+t4VutsQW/cGGlVTMl/qx+ hDOjZT6EQQHnkl2ta9vqCUwbUwBvRzsjJT5Tx/qynCh2Vwi3Rb0eAY6i1 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGM1J0+rRDoG/2dsb2JhbAA6Cq5XgQWBcgEBAQMBAQEBDwEUEwIBMRANAQgSWyIOAQEEARIbB4daCZovAZ4+BIgUgmsBKRMBCAUDAwkHAQcHAoQtg1gEiD+MW5Jy X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="26194432" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 31 Jan 2012 00:29:47 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0V0TlEp000699; Tue, 31 Jan 2012 00:29:47 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 16:29:47 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 31 Jan 2012 00:29:47 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 30 Jan 2012 16:29:46 -0800 From: Sri Gundavelli To: Ahmad Muhanna , "netext@ietf.org" Message-ID: Thread-Topic: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.txt Thread-Index: Aczc0ROglE/CDUTBRuW75YlYxAYO1gCl2l/QABG8c3w= In-Reply-To: <1FCAE7B6027FE3489B8497A060C704C4443BD93B1B@EUSAACMS0714.eamcs.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 Jan 2012 00:29:47.0823 (UTC) FILETIME=[700023F0:01CCDFAF] Subject: Re: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 00:29:49 -0000 Hi Ahmad, Thanks for the review. Please see inline. On 1/30/12 8:19 AM, "Ahmad Muhanna" wrote: > Hello, > > Please find my review comments for Rev 01 of the I-D > (draft-ietf-netext-pmipv6-sipto-option) below: > > > I have mainly editorial comments that need clarification and a couple of minor > technical ones below. > > Regards, > Ahmad > >>>>>> > > 1. Introduction > > Mobile Operators are expanding their network coverage by integrating > various access technology domains into a common IP mobile core. > > For > providing IP mobility support to a mobile node irrespective of the > access network to which it is attached, the 3GPP S2/a Proxy Mobile > IPv6 [TS23402] interface, specified by the 3GPP system architecture, > is providing the needed protocol glue. > [Ahmad-01] > why we are using S2/a rather than S2a? > Yes, it should be s2a. > [Ahmad-02] > Please replace 'is providing' with 'provides' > Ok > When this protocol interface > based on Proxy Mobile IPv6 [RFC5213] is used, the mobile node is > topologically anchored on the local mobility anchor [RFC5213] in the > home network. > > [Ahmad-03] > when Proxy Mobile IPv6 protocol [RFC5213] is used on this interface, the > mobile node ... > > [Ahmad-04] > Is it "anchored on" or "anchored at"? > I can rephrase. > The mobile node's IP traffic is always tunneled back > from the mobile access gateway [RFC5213] in the access network to the > local mobility anchor in the home network. > > However, with the exponential growth in the mobile data traffic, > mobile operators are exploring new ways to offload some of the IP > traffic flows at the nearest access edge where ever there is an > internet peering point, as supposed to carrying it all the way to the > mobility anchor in the home network. Not all IP traffic needs to be > routed back to the home network, some of the non-essential traffic > which does not require IP mobility support can be offloaded at the > mobile access gateway in the access network. This approach provides > greater leverage and efficient usage of the mobile packet core with > increased overall network capacity and by lowering transport costs. > > [Ahmad-06] > I have problem with the last sentence above... what are we trying to say? > Without offload, all the user plane traffic is going through the PGW. With the approach specified in this document, some of the non-essential traffic can be offloaded at the access edge, as supposed to carrying it through EPC. In essence this results in: - Efficient usage of the packet core; by virtue or carrying select traffic - Lowers the transport cost; if the packet core is considered as a premium resource and using it only for select traffic and offloading all the other traffic through the cheaper access, say WLAN. > May be something like follows: > "With increased overall network capacity, this approach provides greater > leverage and efficient usage of the mobile packet core which help lowering > transport cost" Hope it makes it read better! :-) > Ok. I can rephrase the text. > > The local mobility anchor in the home network can potentially deliver > the IP flow selectors to the mobile access gateway in the access > network, for identifying the IP flows that needs to be offloaded. > > This document defines a new mobility option, IP Traffic Offload > Selector option for Proxy Mobile IPv6 (PMIPv6). This option can be > used by the local mobility anchor for notifying the flow selectors > for that can be used by the local mobility anchor for notifying the > mobile access gateway flows that can be offloaded at the access edge. > > [Ahmad-07] > This is a little confusing; sounds as if the notification goes to the flow > selectors. What about? > "This option can be used by the local mobility anchor to notify the mobile > access gateway with the flow selectors that can be offloaded at the access > edge." > Ok. I can rephrase it. > > Since, the mobile node's IP address topologically belongs to the home > network, the offloaded IP traffic flows need to be NAT [RFC2663] > translated. Given this NAT translation requirement for the offloaded > traffic, this approach will be limited to mobile node's IPv4 flows. > > There are better ways to solve this problem for IPv6 and with the > goal not to create NAT66 requirement, > [Ahmad-08] > Can we remove the above sentence? and start the sentence with the following > portion. > Well, the scope of the document is only for IPv4. If we say it applies for IPv6 user flows, we need a NAT66 gateway. I'm not sure, chairs will agree :), Raj made sure we put this line. > This specification does not > support traffic offload support for IPv6 flows. This document also > does not define any new semantics for flow selectors. The flow > identification and the related semantics are all leveraged from > [RFC6088]. > > > 2. Conventions and Terminology > > 2.1. Conventions > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > 2.2. Terminology > > All the mobility related terms used in this document are to be > interpreted as defined in the base Proxy Mobile IPv6 specifications > [RFC5213] and [RFC5844]. Additionally, this document uses the > following abbreviations: > > IP Flow > > IP Flow represents a set of IP packets that match a traffic > selector. The selector is typically based on the source IP > address, destination IP address, source port, destination port and > other fields in upper layer headers. > > Selective IP Traffic Offload (SIPTO) > > The approach of selecting specific IP flows and routing them to > the local network, as supposed to tunneling them to the home > network. > > NAT (Network Address Translation) > > Network Address Translation [RFC2663] is a method by which IP > addresses are mapped from one address realm to another, providing > transparent routing to end hosts. > [Ahmad-09] > Do we need to include this terminology? > True. May be its too obvious. Can get rid of that. Fine, either way. > > 3. Solution Overview > > The following illustrates the scenario where the mobile access > gateway in an access network having the ability to offload some of > the IPv4 traffic flows, based on the traffic selectors it received > from the local mobility anchor in the home network. For example, all > the HTTP flows may be be offloaded at the mobile access gateway and > all the other flows for that mobility session are tunneled back to > the local mobility anchor. > > > > > _----_ > _( )_ > ( Internet ) > (_ _) > '----' > | > (IPv4 Traffic Offload Point > at access edge gateway for > non-essential traffic > Ex: HTTP Traffic Offloaded) > | > ...................................................... > | . +----------------+ > +---+ . | Operator Value | > |NAT| . | Added Services | > +---+ . +----------------+ > | _----_ | > +-----+ _( )_ +-----+ > [MN]----| MAG |======( IP )======| LMA |-- Internet > +-----+ (_ _) +-----+ > '----' ( > . > . > . > [Access Network] . [Home Network] > ...................................................... > > Figure 1: Access Networks attached to MAG > > > > 3.1. LMA Considerations > > The following considerations apply to the local mobility anchor and > the mobile access gateway. > [Ahmad-10] > Is this a common section then? > Oops. Copy paste error. The explanation needs to go to the main section. Thanks for pointing this. > Figure 1 explains the operational sequence of the IP Traffic Offload > selectors between the mobile access gateway and the local mobility > anchor. > > > MN MAG(NAT) LMA > |------>| | 1. Mobile Node Attach > | |------->| 2. Proxy Binding Update > | |<-------| 3. Proxy Binding Acknowledgement (IPTS Option) > | |========| 4. Tunnel/Route Setup > | + | 5. Installing the traffic offload rules > |------>| | 6. IPv4 packet from mobile node > | | | 7. Forwarding rule - Tunnel home/offload > | | | > > > > Figure 2: Exchange of IP Traffic Offload Selectors > > o If the received Proxy Binding Update includes the IP Traffic > Offload Selector Option Section 4, but if the configuration > variable, EnableIPTrafficOffloadSupport on the local mobility > anchor is set to a value of (0), then the local mobility anchor > MUST ignore the IP Traffic Offload Selector Option and process the > rest of the packet. This would not have no effect on the > operation of the rest of the protocol. > > o If the received Proxy Binding Update includes the IP Traffic > Offload Selector Option Section 4, and if the configuration > variable, EnableIPTrafficOffloadSupport on the local mobility > anchor is set to a value of (1), then the local mobility anchor > can construct the traffic selectors based on the offload policy > and deliver those selectors in the Proxy Binding Acknowledgement > message using the IP Traffic Offload Selector Option. > [Ahmad-11] > Why NOT use the following: "the local mobility anchor (identify/or acquire) > the traffic selectors based on.... This will encompass the possibility for the > LMA to receive the offload policy via a different infrastructure node, e.g., > PCRF. Just a suggestion. > That's a good point. The policy can come from PCRF. Sure. > However, if > the received Proxy Binding Update included a proposed Offload > traffic selectors, the local mobility anchor MAY choose to honor > that request and include the proposed selectors in the reply. > > 3.2. MAG Considerations > > o If the configuration variable, EnableIPTrafficOffloadSupport on > the mobile access gateway is set to a value of (0), then the > mobile access gateway MUST NOT include the IP Traffic Offload > Selector Option Section 4 in the Proxy Binding Update message that > it sends to the local mobility anchor. Otherwise, the option MUST > be included in the Proxy Binding Update message. > > When this option > is included, it is an indication to the local mobility anchor that > the mobile access gateway is capable of supporting IP Traffic > Offload support. The TS format field of the IP Traffic Offload > > [Ahmad-12] > Have we defined what TS before now? > Will add a reference to the later section, where its defined. > Selector Option MUST be set to a value of (0), indicating that the > mobile access gateway is not proposing any specific offload policy > for that mobility session, but a request to the local mobility > anchor to provide the IP traffic offload flow selectors for that > mobility session. > > o The mobility access gateway MAY choose to include its proposed IP > traffic offload flow selectors in the IP Traffic Offload Selector > Option Section 4. Including this offload traffic spec serves as a > [Ahmad-13] > "Including this offload traffic selectors serves ..." > Ok. > proposal to the local mobility anchor, which the local mobility > anchor can override with its own offload policy, or agree to the > proposed policy. When including the offload traffic selectors, > the TS format field of the IP Traffic Offload Selector Option MUST > be set to the respective flow specification type. > > o If there is no IP Traffic Offload Selector Option in the > corresponding Proxy Binding Acknowledgement message, that the > mobile access gateway receives in response to a Proxy Binding > Update, it serves as an indication that the local mobility anchor > does not support IP Traffic Offload support for that mobility > session, and it implies the local mobility anchor cannot deliver > IP flow selectors for that mobility session. > > The mobility access > [Ahmad-14] > What the mobility access means here? is that a term that is defined somewhere? > You meant "mobility session" ? Its defined in the base spec. Let me add a reference. > upon accepting the Proxy Binding Acknowledgement message MUST NOT > enable any offload policy for that mobility session. All the > mobile node's IP flows MUST be tunneled back to the local mobility > anchor. > > o If there is IP Traffic Offload Selector Option in the > corresponding Proxy Binding Acknowledgement message, it is an > indication that the local mobility anchor has provided the IP > traffic Offload selectors for that mobility session and the > identified IP flows have to be offloaded. Considerations related > to (M) flag MUST be applied. > [Ahmad-15] > what about MAG handling of the TS option in BA when the MAG has not sent it in > the BU? I believe this is a valid scenario that needs to be addressed. > > So, we used TS as a means to notify the capability and also as a means to exchange the offload flow selectors. If the capable of supporting SIPTO, it can include this option and the LMA can deliver the offload flow selectors. Now, if the MAG is not capable (Ex: a residential gateway withno scope for offload, or have internet peering points), then it will not include the TS and the LMA will not deliver those selectors. But, there is also the other question which you are pointing too. Should the LMA notify the offload flow selectors dynamically, this is an open question. > > 4. IP Traffic Offload Selector Option > > A new mobility option, IP Traffic Offload Selector option, is defined > for using it in Proxy Binding Update (PBU) and Proxy Binding > Acknowledgement (PBA) messages exchanged between a local mobility > anchor and a mobile access gateway. > > [Ahmad-16] > "A new mobility option, IP Traffic Offload Selector option, is defined > for using it in Proxy Binding Update (PBU) and Proxy Binding > Acknowledgement (PBA) messages exchanged between a mobile access gateway > and a local mobility anchor." seems that the draft always mentions LMA first! > :-) > I can switch :) > > This option is used for carrying > the flow selectors for supporting IP traffic offload function at the > mobile access gateway. > [Ahmad-17] > I think we should use the word enforcing/or enabling rather than supporting > for the sentence to read as follows: > "This option is used for carrying the flow selectors for enforcing/enabling IP > traffic offload function at the mobile access gateway." > OK. > > The alignment requirement for this option is 4n. > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M| Reserved | TS Format | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Traffic Selector ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 3: IP Traffic Offload Selector Option > > > Type > > > Length > 8-bit unsigned integer indicating the length in octets of the > option, excluding the type and length fields. > > Reserved > [Ahmad-18] Insert line. > This field is unused for now. The value MUST be > initialized to 0 by the sender and MUST be ignored by the > receiver. > Ok. > IP Traffic Offload Mode Flag > [Ahmad-19] Insert line. > Ok. > This field indicates the offload mode. > If the (M) flag value is set to a value of (1), it is an > indication that all the flows except the identified IP flow(s) in > this mobility option needs to be offloaded at the mobile access > gateway. If the (M) flag value is set to a value of (0), it is an > indication that the identified IP flow(s) needs to be offloaded at > the mobile access gateway and all other IP flows associated with > that mobility session needs to be tunneled to the local mobility > anchor. > [Ahmad-20] > We need to add >>some text<< under the MAG consideration to mention that > despite the M flag value in the TS Option in the BU, the setting by the LMA in > the BA overrides. something like that. > Sure. This is a good point. We missed few considerations on the override part. > TS Format > [Ahmad-21] Insert line. > Ok. > An 8-bit unsigned integer indicating the Traffic Selector > Format. The value of "0" is reserved and is used when there are > no selectors to carry, relevant when the option is used as a > capability indicator. The value of (1) is assigned for IPv4 > Binary Traffic Selector [RFC6088]. > [Ahmad-22] > should not we mention that all other values are reserved? > Sure > TS Selector > [Ahmad-23] Insert line. > Sure > A variable-length opaque field for including the traffic > specification identified by the TS format field. > [Ahmad-24] > Should not we say: " ... identified by the TS format field and the IP Traffic > Offload Mode Flag" Just wondering. the key word here "identified" > The selectors still apply for both the state values of the (M) flag. Its more an inverse rule, if the identified traffic is offloaded, or if the identified traffic is allowed to come in. > > When the value > of TS Format field is set to (1), the format that follows is the > IPv4 Binary Traffic Selector specified in section 3.1 of > [RFC6088]. > Thanks a lot Ahmad for the review. We will work on a revision. Let me know if these comments address all the review comments. Regards Sri > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From ahmad.muhanna@ericsson.com Mon Jan 30 20:28:34 2012 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 749B021F87A9 for ; Mon, 30 Jan 2012 20:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 c9XRWTUjeTCO for ; Mon, 30 Jan 2012 20:28:32 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id B648A21F87A7 for ; Mon, 30 Jan 2012 20:28:32 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q0V4SUki001651; Mon, 30 Jan 2012 22:28:31 -0600 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.2.40]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 30 Jan 2012 23:28:24 -0500 From: Ahmad Muhanna To: Sri Gundavelli , "netext@ietf.org" Date: Mon, 30 Jan 2012 23:28:21 -0500 Thread-Topic: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.txt Thread-Index: Aczc0ROglE/CDUTBRuW75YlYxAYO1gCl2l/QABG8c3wACCXgcA== Message-ID: <1FCAE7B6027FE3489B8497A060C704C4443BE188D4@EUSAACMS0714.eamcs.ericsson.se> References: <1FCAE7B6027FE3489B8497A060C704C4443BD93B1B@EUSAACMS0714.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 04:28:34 -0000 Thanks Sri. Just one minor follow-up: > The mobility access > [Ahmad-14] > What the mobility access means here? is that a term that is defined somew= here? > You meant "mobility session" ? Its defined in the base spec. Let me add a reference. [Ahmad] Hmmmm; it seems that there is a "gateway" word missing. The original text below. " The mobility access upon accepting the Proxy Binding Acknowledgement message MUST NOT enable any offload policy for that mobility session. All the mobile node's IP flows MUST be tunneled back to the local mobility anchor. " Thanks Sri for the quick reply. Regards, Ahmad -----Original Message----- From: Sri Gundavelli [mailto:sgundave@cisco.com] Sent: Monday, January 30, 2012 6:30 PM To: Ahmad Muhanna; netext@ietf.org Subject: Re: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-0= 1.txt Hi Ahmad, Thanks for the review. Please see inline. On 1/30/12 8:19 AM, "Ahmad Muhanna" wrote: > Hello, > > Please find my review comments for Rev 01 of the I-D > (draft-ietf-netext-pmipv6-sipto-option) below: > > > I have mainly editorial comments that need clarification and a couple > of minor technical ones below. > > Regards, > Ahmad > >>>>>> > > 1. Introduction > > Mobile Operators are expanding their network coverage by integrating > various access technology domains into a common IP mobile core. > > For > providing IP mobility support to a mobile node irrespective of the > access network to which it is attached, the 3GPP S2/a Proxy Mobile > IPv6 [TS23402] interface, specified by the 3GPP system architecture, > is providing the needed protocol glue. > [Ahmad-01] > why we are using S2/a rather than S2a? > Yes, it should be s2a. > [Ahmad-02] > Please replace 'is providing' with 'provides' > Ok > When this protocol interface > based on Proxy Mobile IPv6 [RFC5213] is used, the mobile node is > topologically anchored on the local mobility anchor [RFC5213] in the > home network. > > [Ahmad-03] > when Proxy Mobile IPv6 protocol [RFC5213] is used on this interface, > the mobile node ... > > [Ahmad-04] > Is it "anchored on" or "anchored at"? > I can rephrase. > The mobile node's IP traffic is always tunneled back > from the mobile access gateway [RFC5213] in the access network to the > local mobility anchor in the home network. > > However, with the exponential growth in the mobile data traffic, > mobile operators are exploring new ways to offload some of the IP > traffic flows at the nearest access edge where ever there is an > internet peering point, as supposed to carrying it all the way to the > mobility anchor in the home network. Not all IP traffic needs to be > routed back to the home network, some of the non-essential traffic > which does not require IP mobility support can be offloaded at the > mobile access gateway in the access network. This approach provides > greater leverage and efficient usage of the mobile packet core with > increased overall network capacity and by lowering transport costs. > > [Ahmad-06] > I have problem with the last sentence above... what are we trying to say? > Without offload, all the user plane traffic is going through the PGW. With = the approach specified in this document, some of the non-essential traffic = can be offloaded at the access edge, as supposed to carrying it through EPC= . In essence this results in: - Efficient usage of the packet core; by virtue or carrying select traffic - Lowers the transport cost; if the packet core is considered as a premium = resource and using it only for select traffic and offloading all the other = traffic through the cheaper access, say WLAN. > May be something like follows: > "With increased overall network capacity, this approach provides > greater leverage and efficient usage of the mobile packet core which > help lowering transport cost" Hope it makes it read better! :-) > Ok. I can rephrase the text. > > The local mobility anchor in the home network can potentially deliver > the IP flow selectors to the mobile access gateway in the access > network, for identifying the IP flows that needs to be offloaded. > > This document defines a new mobility option, IP Traffic Offload > Selector option for Proxy Mobile IPv6 (PMIPv6). This option can be > used by the local mobility anchor for notifying the flow selectors > for that can be used by the local mobility anchor for notifying the > mobile access gateway flows that can be offloaded at the access edge. > > [Ahmad-07] > This is a little confusing; sounds as if the notification goes to the > flow selectors. What about? > "This option can be used by the local mobility anchor to notify the > mobile access gateway with the flow selectors that can be offloaded at > the access edge." > Ok. I can rephrase it. > > Since, the mobile node's IP address topologically belongs to the home > network, the offloaded IP traffic flows need to be NAT [RFC2663] > translated. Given this NAT translation requirement for the offloaded > traffic, this approach will be limited to mobile node's IPv4 flows. > > There are better ways to solve this problem for IPv6 and with the > goal not to create NAT66 requirement, [Ahmad-08] Can we remove the > above sentence? and start the sentence with the following portion. > Well, the scope of the document is only for IPv4. If we say it applies for IPv6 user flows, we need a NAT66 gateway. I'm not sure, chairs will agree := ), Raj made sure we put this line. > This specification does not > support traffic offload support for IPv6 flows. This document also > does not define any new semantics for flow selectors. The flow > identification and the related semantics are all leveraged from > [RFC6088]. > > > 2. Conventions and Terminology > > 2.1. Conventions > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > 2.2. Terminology > > All the mobility related terms used in this document are to be > interpreted as defined in the base Proxy Mobile IPv6 specifications > [RFC5213] and [RFC5844]. Additionally, this document uses the > following abbreviations: > > IP Flow > > IP Flow represents a set of IP packets that match a traffic > selector. The selector is typically based on the source IP > address, destination IP address, source port, destination port and > other fields in upper layer headers. > > Selective IP Traffic Offload (SIPTO) > > The approach of selecting specific IP flows and routing them to > the local network, as supposed to tunneling them to the home > network. > > NAT (Network Address Translation) > > Network Address Translation [RFC2663] is a method by which IP > addresses are mapped from one address realm to another, providing > transparent routing to end hosts. > [Ahmad-09] > Do we need to include this terminology? > True. May be its too obvious. Can get rid of that. Fine, either way. > > 3. Solution Overview > > The following illustrates the scenario where the mobile access > gateway in an access network having the ability to offload some of > the IPv4 traffic flows, based on the traffic selectors it received > from the local mobility anchor in the home network. For example, all > the HTTP flows may be be offloaded at the mobile access gateway and > all the other flows for that mobility session are tunneled back to > the local mobility anchor. > > > > > _----_ > _( )_ > ( Internet ) > (_ _) > '----' > | > (IPv4 Traffic Offload Point > at access edge gateway for > non-essential traffic > Ex: HTTP Traffic Offloaded) > | > ...................................................... > | . +----------------+ > +---+ . | Operator Value | > |NAT| . | Added Services | > +---+ . +----------------+ > | _----_ | > +-----+ _( )_ +-----+ > [MN]----| MAG |=3D=3D=3D=3D=3D=3D( IP )=3D=3D=3D=3D=3D=3D| LMA |= -- Internet > +-----+ (_ _) +-----+ > '----' ( > . > . > . > [Access Network] . [Home Network] > ...................................................... > > Figure 1: Access Networks attached to MAG > > > > 3.1. LMA Considerations > > The following considerations apply to the local mobility anchor and > the mobile access gateway. > [Ahmad-10] > Is this a common section then? > Oops. Copy paste error. The explanation needs to go to the main section. Thanks for pointing this. > Figure 1 explains the operational sequence of the IP Traffic Offload > selectors between the mobile access gateway and the local mobility > anchor. > > > MN MAG(NAT) LMA > |------>| | 1. Mobile Node Attach > | |------->| 2. Proxy Binding Update > | |<-------| 3. Proxy Binding Acknowledgement (IPTS Option) > | |=3D=3D=3D=3D=3D=3D=3D=3D| 4. Tunnel/Route Setup > | + | 5. Installing the traffic offload rules > |------>| | 6. IPv4 packet from mobile node > | | | 7. Forwarding rule - Tunnel home/offload > | | | > > > > Figure 2: Exchange of IP Traffic Offload Selectors > > o If the received Proxy Binding Update includes the IP Traffic > Offload Selector Option Section 4, but if the configuration > variable, EnableIPTrafficOffloadSupport on the local mobility > anchor is set to a value of (0), then the local mobility anchor > MUST ignore the IP Traffic Offload Selector Option and process the > rest of the packet. This would not have no effect on the > operation of the rest of the protocol. > > o If the received Proxy Binding Update includes the IP Traffic > Offload Selector Option Section 4, and if the configuration > variable, EnableIPTrafficOffloadSupport on the local mobility > anchor is set to a value of (1), then the local mobility anchor > can construct the traffic selectors based on the offload policy > and deliver those selectors in the Proxy Binding Acknowledgement > message using the IP Traffic Offload Selector Option. > [Ahmad-11] > Why NOT use the following: "the local mobility anchor (identify/or > acquire) the traffic selectors based on.... This will encompass the > possibility for the LMA to receive the offload policy via a different > infrastructure node, e.g., PCRF. Just a suggestion. > That's a good point. The policy can come from PCRF. Sure. > However, if > the received Proxy Binding Update included a proposed Offload > traffic selectors, the local mobility anchor MAY choose to honor > that request and include the proposed selectors in the reply. > > 3.2. MAG Considerations > > o If the configuration variable, EnableIPTrafficOffloadSupport on > the mobile access gateway is set to a value of (0), then the > mobile access gateway MUST NOT include the IP Traffic Offload > Selector Option Section 4 in the Proxy Binding Update message that > it sends to the local mobility anchor. Otherwise, the option MUST > be included in the Proxy Binding Update message. > > When this option > is included, it is an indication to the local mobility anchor that > the mobile access gateway is capable of supporting IP Traffic > Offload support. The TS format field of the IP Traffic Offload > > [Ahmad-12] > Have we defined what TS before now? > Will add a reference to the later section, where its defined. > Selector Option MUST be set to a value of (0), indicating that the > mobile access gateway is not proposing any specific offload policy > for that mobility session, but a request to the local mobility > anchor to provide the IP traffic offload flow selectors for that > mobility session. > > o The mobility access gateway MAY choose to include its proposed IP > traffic offload flow selectors in the IP Traffic Offload Selector > Option Section 4. Including this offload traffic spec serves as > a [Ahmad-13] "Including this offload traffic selectors serves ..." > Ok. > proposal to the local mobility anchor, which the local mobility > anchor can override with its own offload policy, or agree to the > proposed policy. When including the offload traffic selectors, > the TS format field of the IP Traffic Offload Selector Option MUST > be set to the respective flow specification type. > > o If there is no IP Traffic Offload Selector Option in the > corresponding Proxy Binding Acknowledgement message, that the > mobile access gateway receives in response to a Proxy Binding > Update, it serves as an indication that the local mobility anchor > does not support IP Traffic Offload support for that mobility > session, and it implies the local mobility anchor cannot deliver > IP flow selectors for that mobility session. > > The mobility access > [Ahmad-14] > What the mobility access means here? is that a term that is defined somew= here? > You meant "mobility session" ? Its defined in the base spec. Let me add a reference. > upon accepting the Proxy Binding Acknowledgement message MUST NOT > enable any offload policy for that mobility session. All the > mobile node's IP flows MUST be tunneled back to the local mobility > anchor. > > o If there is IP Traffic Offload Selector Option in the > corresponding Proxy Binding Acknowledgement message, it is an > indication that the local mobility anchor has provided the IP > traffic Offload selectors for that mobility session and the > identified IP flows have to be offloaded. Considerations related > to (M) flag MUST be applied. > [Ahmad-15] > what about MAG handling of the TS option in BA when the MAG has not sent = it in > the BU? I believe this is a valid scenario that needs to be addressed. > > So, we used TS as a means to notify the capability and also as a means to exchange the offload flow selectors. If the capable of supporting SIPTO, it can include this option and the LMA can deliver the offload flow selectors. Now, if the MAG is not capable (Ex: a residential gateway withno scope for offload, or have internet peering points), then it will not include the TS and the LMA will not deliver those selectors. But, there is also the other question which you are pointing too. Should the LMA notify the offload flow selectors dynamically, this is an open question. > > 4. IP Traffic Offload Selector Option > > A new mobility option, IP Traffic Offload Selector option, is defined > for using it in Proxy Binding Update (PBU) and Proxy Binding > Acknowledgement (PBA) messages exchanged between a local mobility > anchor and a mobile access gateway. > > [Ahmad-16] > "A new mobility option, IP Traffic Offload Selector option, is defined > for using it in Proxy Binding Update (PBU) and Proxy Binding > Acknowledgement (PBA) messages exchanged between a mobile access gatew= ay > and a local mobility anchor." seems that the draft always mentions LMA fi= rst! > :-) > I can switch :) > > This option is used for carrying > the flow selectors for supporting IP traffic offload function at the > mobile access gateway. > [Ahmad-17] > I think we should use the word enforcing/or enabling rather than supporti= ng > for the sentence to read as follows: > "This option is used for carrying the flow selectors for enforcing/enabli= ng IP > traffic offload function at the mobile access gateway." > OK. > > The alignment requirement for this option is 4n. > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M| Reserved | TS Format | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Traffic Selector ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 3: IP Traffic Offload Selector Option > > > Type > > > Length > 8-bit unsigned integer indicating the length in octets of the > option, excluding the type and length fields. > > Reserved > [Ahmad-18] Insert line. > This field is unused for now. The value MUST be > initialized to 0 by the sender and MUST be ignored by the > receiver. > Ok. > IP Traffic Offload Mode Flag > [Ahmad-19] Insert line. > Ok. > This field indicates the offload mode. > If the (M) flag value is set to a value of (1), it is an > indication that all the flows except the identified IP flow(s) in > this mobility option needs to be offloaded at the mobile access > gateway. If the (M) flag value is set to a value of (0), it is an > indication that the identified IP flow(s) needs to be offloaded at > the mobile access gateway and all other IP flows associated with > that mobility session needs to be tunneled to the local mobility > anchor. > [Ahmad-20] > We need to add >>some text<< under the MAG consideration to mention that > despite the M flag value in the TS Option in the BU, the setting by the L= MA in > the BA overrides. something like that. > Sure. This is a good point. We missed few considerations on the override part. > TS Format > [Ahmad-21] Insert line. > Ok. > An 8-bit unsigned integer indicating the Traffic Selector > Format. The value of "0" is reserved and is used when there are > no selectors to carry, relevant when the option is used as a > capability indicator. The value of (1) is assigned for IPv4 > Binary Traffic Selector [RFC6088]. > [Ahmad-22] > should not we mention that all other values are reserved? > Sure > TS Selector > [Ahmad-23] Insert line. > Sure > A variable-length opaque field for including the traffic > specification identified by the TS format field. > [Ahmad-24] > Should not we say: " ... identified by the TS format field and the IP Tra= ffic > Offload Mode Flag" Just wondering. the key word here "identified" > The selectors still apply for both the state values of the (M) flag. Its more an inverse rule, if the identified traffic is offloaded, or if the identified traffic is allowed to come in. > > When the value > of TS Format field is set to (1), the format that follows is the > IPv4 Binary Traffic Selector specified in section 3.1 of > [RFC6088]. > Thanks a lot Ahmad for the review. We will work on a revision. Let me know if these comments address all the review comments. Regards Sri > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Mon Jan 30 21:43:03 2012 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 80EEB11E80FD for ; Mon, 30 Jan 2012 21:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.404 X-Spam-Level: X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, 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 wOJDowP0ST+W for ; Mon, 30 Jan 2012 21:43:01 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE8B21F8712 for ; Mon, 30 Jan 2012 21:43:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=21446; q=dns/txt; s=iport; t=1327988581; x=1329198181; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=pbj1IzW50S80r6sm5WA1NWshoxhJEl21FZeuSd6Uc9k=; b=kW7+cBlTLIj4DrkJyY8uDRA//UrCGlSX4SmzlgLHgfukhXOyDuYNmAVY PfX1OgAoJ4RPo8ZnZ9zuWAt6H6v05p5hNYKvLJkOP+IwKAjI+GBxCsmmI fRBPrHqXNjlXFufVM6eZICWjnJkjgURJAbN1RYu1Zs6uy9+FJgqJ8X1Sk w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIR+J0+rRDoI/2dsb2JhbAA5Cq5kgQWBcgEBAQMBAQEBDwEUEwIBMRAHBgEIEQEDAQEBJy4fAwYIAQEEARIbB4daCZo/AZ5TBIgXgmsBKRMBCAUDAwkHAQcHAoQtg1gEiECMXpJz X-IronPort-AV: E=Sophos;i="4.71,594,1320624000"; d="scan'208";a="27738956" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 31 Jan 2012 05:43:00 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0V5h0Na026754; Tue, 31 Jan 2012 05:43:00 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 21:43:00 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 31 Jan 2012 05:43:00 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 30 Jan 2012 21:42:58 -0800 From: Sri Gundavelli To: Ahmad Muhanna , "netext@ietf.org" Message-ID: Thread-Topic: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.txt Thread-Index: Aczc0ROglE/CDUTBRuW75YlYxAYO1gCl2l/QABG8c3wACCXgcAACyloY In-Reply-To: <1FCAE7B6027FE3489B8497A060C704C4443BE188D4@EUSAACMS0714.eamcs.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 Jan 2012 05:43:00.0682 (UTC) FILETIME=[316ADAA0:01CCDFDB] Subject: Re: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 05:43:04 -0000 Hi Ahmad, Thanks. I will fix that text. Thanks for the review. Regards Sri On 1/30/12 8:28 PM, "Ahmad Muhanna" wrote: > Thanks Sri. > > Just one minor follow-up: > >> The mobility access >> [Ahmad-14] >> What the mobility access means here? is that a term that is defined >> somewhere? >> > > > You meant "mobility session" ? Its defined in the base spec. Let me add a > reference. > > [Ahmad] > Hmmmm; it seems that there is a "gateway" word missing. > The original text below. > > > " > > The mobility access > upon accepting the Proxy Binding Acknowledgement message MUST NOT > enable any offload policy for that mobility session. All the > mobile node's IP flows MUST be tunneled back to the local mobility > anchor. > " > > Thanks Sri for the quick reply. > > Regards, > Ahmad > > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Monday, January 30, 2012 6:30 PM > To: Ahmad Muhanna; netext@ietf.org > Subject: Re: [netext] Review of ID: > draft-ietf-netext-pmipv6-sipto-option-01.txt > > Hi Ahmad, > > Thanks for the review. Please see inline. > > > > On 1/30/12 8:19 AM, "Ahmad Muhanna" wrote: > >> Hello, >> >> Please find my review comments for Rev 01 of the I-D >> (draft-ietf-netext-pmipv6-sipto-option) below: >> >> >> I have mainly editorial comments that need clarification and a couple >> of minor technical ones below. >> >> Regards, >> Ahmad >> >>>>>>> >> >> 1. Introduction >> >> Mobile Operators are expanding their network coverage by integrating >> various access technology domains into a common IP mobile core. >> >> For >> providing IP mobility support to a mobile node irrespective of the >> access network to which it is attached, the 3GPP S2/a Proxy Mobile >> IPv6 [TS23402] interface, specified by the 3GPP system architecture, >> is providing the needed protocol glue. >> [Ahmad-01] >> why we are using S2/a rather than S2a? >> > > Yes, it should be s2a. > > >> [Ahmad-02] >> Please replace 'is providing' with 'provides' >> > > Ok > >> When this protocol interface >> based on Proxy Mobile IPv6 [RFC5213] is used, the mobile node is >> topologically anchored on the local mobility anchor [RFC5213] in the >> home network. >> >> [Ahmad-03] >> when Proxy Mobile IPv6 protocol [RFC5213] is used on this interface, >> the mobile node ... >> >> [Ahmad-04] >> Is it "anchored on" or "anchored at"? >> > > I can rephrase. > > >> The mobile node's IP traffic is always tunneled back >> from the mobile access gateway [RFC5213] in the access network to the >> local mobility anchor in the home network. >> >> However, with the exponential growth in the mobile data traffic, >> mobile operators are exploring new ways to offload some of the IP >> traffic flows at the nearest access edge where ever there is an >> internet peering point, as supposed to carrying it all the way to the >> mobility anchor in the home network. Not all IP traffic needs to be >> routed back to the home network, some of the non-essential traffic >> which does not require IP mobility support can be offloaded at the >> mobile access gateway in the access network. This approach provides >> greater leverage and efficient usage of the mobile packet core with >> increased overall network capacity and by lowering transport costs. >> >> [Ahmad-06] >> I have problem with the last sentence above... what are we trying to say? >> > Without offload, all the user plane traffic is going through the PGW. With the > approach specified in this document, some of the non-essential traffic can be > offloaded at the access edge, as supposed to carrying it through EPC. > In essence this results in: > > - Efficient usage of the packet core; by virtue or carrying select traffic > - Lowers the transport cost; if the packet core is considered as a premium > resource and using it only for select traffic and offloading all the other > traffic through the cheaper access, say WLAN. > > > >> May be something like follows: >> "With increased overall network capacity, this approach provides >> greater leverage and efficient usage of the mobile packet core which >> help lowering transport cost" Hope it makes it read better! :-) >> > > Ok. I can rephrase the text. > > >> >> The local mobility anchor in the home network can potentially deliver >> the IP flow selectors to the mobile access gateway in the access >> network, for identifying the IP flows that needs to be offloaded. >> >> This document defines a new mobility option, IP Traffic Offload >> Selector option for Proxy Mobile IPv6 (PMIPv6). This option can be >> used by the local mobility anchor for notifying the flow selectors >> for that can be used by the local mobility anchor for notifying the >> mobile access gateway flows that can be offloaded at the access edge. >> >> [Ahmad-07] >> This is a little confusing; sounds as if the notification goes to the >> flow selectors. What about? >> "This option can be used by the local mobility anchor to notify the >> mobile access gateway with the flow selectors that can be offloaded at >> the access edge." >> > > Ok. I can rephrase it. > > >> >> Since, the mobile node's IP address topologically belongs to the home >> network, the offloaded IP traffic flows need to be NAT [RFC2663] >> translated. Given this NAT translation requirement for the offloaded >> traffic, this approach will be limited to mobile node's IPv4 flows. >> >> There are better ways to solve this problem for IPv6 and with the >> goal not to create NAT66 requirement, [Ahmad-08] Can we remove the >> above sentence? and start the sentence with the following portion. >> > > Well, the scope of the document is only for IPv4. If we say it applies for > IPv6 user flows, we need a NAT66 gateway. I'm not sure, chairs will agree :), > Raj made sure we put this line. > > > >> This specification does not >> support traffic offload support for IPv6 flows. This document also >> does not define any new semantics for flow selectors. The flow >> identification and the related semantics are all leveraged from >> [RFC6088]. >> >> >> 2. Conventions and Terminology >> >> 2.1. Conventions >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in RFC 2119 [RFC2119]. >> >> 2.2. Terminology >> >> All the mobility related terms used in this document are to be >> interpreted as defined in the base Proxy Mobile IPv6 specifications >> [RFC5213] and [RFC5844]. Additionally, this document uses the >> following abbreviations: >> >> IP Flow >> >> IP Flow represents a set of IP packets that match a traffic >> selector. The selector is typically based on the source IP >> address, destination IP address, source port, destination port and >> other fields in upper layer headers. >> >> Selective IP Traffic Offload (SIPTO) >> >> The approach of selecting specific IP flows and routing them to >> the local network, as supposed to tunneling them to the home >> network. >> >> NAT (Network Address Translation) >> >> Network Address Translation [RFC2663] is a method by which IP >> addresses are mapped from one address realm to another, providing >> transparent routing to end hosts. >> [Ahmad-09] >> Do we need to include this terminology? >> > > True. May be its too obvious. Can get rid of that. Fine, either way. > > > >> >> 3. Solution Overview >> >> The following illustrates the scenario where the mobile access >> gateway in an access network having the ability to offload some of >> the IPv4 traffic flows, based on the traffic selectors it received >> from the local mobility anchor in the home network. For example, all >> the HTTP flows may be be offloaded at the mobile access gateway and >> all the other flows for that mobility session are tunneled back to >> the local mobility anchor. >> >> >> >> >> _----_ >> _( )_ >> ( Internet ) >> (_ _) >> '----' >> | >> (IPv4 Traffic Offload Point >> at access edge gateway for >> non-essential traffic >> Ex: HTTP Traffic Offloaded) >> | >> ...................................................... >> | . +----------------+ >> +---+ . | Operator Value | >> |NAT| . | Added Services | >> +---+ . +----------------+ >> | _----_ | >> +-----+ _( )_ +-----+ >> [MN]----| MAG |======( IP )======| LMA |-- Internet >> +-----+ (_ _) +-----+ >> '----' ( >> . >> . >> . >> [Access Network] . [Home Network] >> ...................................................... >> >> Figure 1: Access Networks attached to MAG >> >> >> >> 3.1. LMA Considerations >> >> The following considerations apply to the local mobility anchor and >> the mobile access gateway. >> [Ahmad-10] >> Is this a common section then? >> > > Oops. Copy paste error. The explanation needs to go to the main section. > Thanks for pointing this. > > > >> Figure 1 explains the operational sequence of the IP Traffic Offload >> selectors between the mobile access gateway and the local mobility >> anchor. >> >> >> MN MAG(NAT) LMA >> |------>| | 1. Mobile Node Attach >> | |------->| 2. Proxy Binding Update >> | |<-------| 3. Proxy Binding Acknowledgement (IPTS Option) >> | |========| 4. Tunnel/Route Setup >> | + | 5. Installing the traffic offload rules >> |------>| | 6. IPv4 packet from mobile node >> | | | 7. Forwarding rule - Tunnel home/offload >> | | | >> >> >> >> Figure 2: Exchange of IP Traffic Offload Selectors >> >> o If the received Proxy Binding Update includes the IP Traffic >> Offload Selector Option Section 4, but if the configuration >> variable, EnableIPTrafficOffloadSupport on the local mobility >> anchor is set to a value of (0), then the local mobility anchor >> MUST ignore the IP Traffic Offload Selector Option and process the >> rest of the packet. This would not have no effect on the >> operation of the rest of the protocol. >> >> o If the received Proxy Binding Update includes the IP Traffic >> Offload Selector Option Section 4, and if the configuration >> variable, EnableIPTrafficOffloadSupport on the local mobility >> anchor is set to a value of (1), then the local mobility anchor >> can construct the traffic selectors based on the offload policy >> and deliver those selectors in the Proxy Binding Acknowledgement >> message using the IP Traffic Offload Selector Option. >> [Ahmad-11] >> Why NOT use the following: "the local mobility anchor (identify/or >> acquire) the traffic selectors based on.... This will encompass the >> possibility for the LMA to receive the offload policy via a different >> infrastructure node, e.g., PCRF. Just a suggestion. >> > > That's a good point. The policy can come from PCRF. Sure. > > > >> However, if >> the received Proxy Binding Update included a proposed Offload >> traffic selectors, the local mobility anchor MAY choose to honor >> that request and include the proposed selectors in the reply. >> >> 3.2. MAG Considerations >> >> o If the configuration variable, EnableIPTrafficOffloadSupport on >> the mobile access gateway is set to a value of (0), then the >> mobile access gateway MUST NOT include the IP Traffic Offload >> Selector Option Section 4 in the Proxy Binding Update message that >> it sends to the local mobility anchor. Otherwise, the option MUST >> be included in the Proxy Binding Update message. >> >> When this option >> is included, it is an indication to the local mobility anchor that >> the mobile access gateway is capable of supporting IP Traffic >> Offload support. The TS format field of the IP Traffic Offload >> >> [Ahmad-12] >> Have we defined what TS before now? >> > > Will add a reference to the later section, where its defined. > > > > > >> Selector Option MUST be set to a value of (0), indicating that the >> mobile access gateway is not proposing any specific offload policy >> for that mobility session, but a request to the local mobility >> anchor to provide the IP traffic offload flow selectors for that >> mobility session. >> >> o The mobility access gateway MAY choose to include its proposed IP >> traffic offload flow selectors in the IP Traffic Offload Selector >> Option Section 4. Including this offload traffic spec serves as >> a [Ahmad-13] "Including this offload traffic selectors serves ..." >> > > Ok. > > >> proposal to the local mobility anchor, which the local mobility >> anchor can override with its own offload policy, or agree to the >> proposed policy. When including the offload traffic selectors, >> the TS format field of the IP Traffic Offload Selector Option MUST >> be set to the respective flow specification type. >> >> o If there is no IP Traffic Offload Selector Option in the >> corresponding Proxy Binding Acknowledgement message, that the >> mobile access gateway receives in response to a Proxy Binding >> Update, it serves as an indication that the local mobility anchor >> does not support IP Traffic Offload support for that mobility >> session, and it implies the local mobility anchor cannot deliver >> IP flow selectors for that mobility session. >> >> The mobility access >> [Ahmad-14] >> What the mobility access means here? is that a term that is defined >> somewhere? >> > > > You meant "mobility session" ? Its defined in the base spec. Let me add a > reference. > > > >> upon accepting the Proxy Binding Acknowledgement message MUST NOT >> enable any offload policy for that mobility session. All the >> mobile node's IP flows MUST be tunneled back to the local mobility >> anchor. >> >> o If there is IP Traffic Offload Selector Option in the >> corresponding Proxy Binding Acknowledgement message, it is an >> indication that the local mobility anchor has provided the IP >> traffic Offload selectors for that mobility session and the >> identified IP flows have to be offloaded. Considerations related >> to (M) flag MUST be applied. >> [Ahmad-15] >> what about MAG handling of the TS option in BA when the MAG has not sent it >> in >> the BU? I believe this is a valid scenario that needs to be addressed. >> >> > > So, we used TS as a means to notify the capability and also as a means to > exchange the offload flow selectors. If the capable of supporting SIPTO, it > can include this option and the LMA can deliver the offload flow selectors. > Now, if the MAG is not capable (Ex: a residential gateway withno scope for > offload, or have internet peering points), then it will not include the TS > and the LMA will not deliver those selectors. But, there is also the other > question which you are pointing too. Should the LMA notify the offload flow > selectors dynamically, this is an open question. > > >> >> 4. IP Traffic Offload Selector Option >> >> A new mobility option, IP Traffic Offload Selector option, is defined >> for using it in Proxy Binding Update (PBU) and Proxy Binding >> Acknowledgement (PBA) messages exchanged between a local mobility >> anchor and a mobile access gateway. >> >> [Ahmad-16] >> "A new mobility option, IP Traffic Offload Selector option, is defined >> for using it in Proxy Binding Update (PBU) and Proxy Binding >> Acknowledgement (PBA) messages exchanged between a mobile access gateway >> and a local mobility anchor." seems that the draft always mentions LMA first! >> :-) >> > > I can switch :) > >> >> This option is used for carrying >> the flow selectors for supporting IP traffic offload function at the >> mobile access gateway. >> [Ahmad-17] >> I think we should use the word enforcing/or enabling rather than supporting >> for the sentence to read as follows: >> "This option is used for carrying the flow selectors for enforcing/enabling >> IP >> traffic offload function at the mobile access gateway." >> > > OK. > >> >> The alignment requirement for this option is 4n. >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |M| Reserved | TS Format | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Traffic Selector ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Figure 3: IP Traffic Offload Selector Option >> >> >> Type >> >> >> Length >> 8-bit unsigned integer indicating the length in octets of the >> option, excluding the type and length fields. >> >> Reserved >> [Ahmad-18] Insert line. >> This field is unused for now. The value MUST be >> initialized to 0 by the sender and MUST be ignored by the >> receiver. >> > > Ok. > > >> IP Traffic Offload Mode Flag >> [Ahmad-19] Insert line. >> > > Ok. > >> This field indicates the offload mode. >> If the (M) flag value is set to a value of (1), it is an >> indication that all the flows except the identified IP flow(s) in >> this mobility option needs to be offloaded at the mobile access >> gateway. If the (M) flag value is set to a value of (0), it is an >> indication that the identified IP flow(s) needs to be offloaded at >> the mobile access gateway and all other IP flows associated with >> that mobility session needs to be tunneled to the local mobility >> anchor. >> [Ahmad-20] >> We need to add >>some text<< under the MAG consideration to mention that >> despite the M flag value in the TS Option in the BU, the setting by the LMA >> in >> the BA overrides. something like that. >> > > Sure. This is a good point. We missed few considerations on the override > part. > > > >> TS Format >> [Ahmad-21] Insert line. >> > > Ok. > > >> An 8-bit unsigned integer indicating the Traffic Selector >> Format. The value of "0" is reserved and is used when there are >> no selectors to carry, relevant when the option is used as a >> capability indicator. The value of (1) is assigned for IPv4 >> Binary Traffic Selector [RFC6088]. >> [Ahmad-22] >> should not we mention that all other values are reserved? >> > > Sure > > >> TS Selector >> [Ahmad-23] Insert line. >> > > Sure > >> A variable-length opaque field for including the traffic >> specification identified by the TS format field. >> [Ahmad-24] >> Should not we say: " ... identified by the TS format field and the IP Traffic >> Offload Mode Flag" Just wondering. the key word here "identified" >> > > The selectors still apply for both the state values of the (M) flag. Its > more an inverse rule, if the identified traffic is offloaded, or if the > identified traffic is allowed to come in. > > > >> >> When the value >> of TS Format field is set to (1), the format that follows is the >> IPv4 Binary Traffic Selector specified in section 3.1 of >> [RFC6088]. >> > > Thanks a lot Ahmad for the review. We will work on a revision. Let me know > if these comments address all the review comments. > > > Regards > Sri > > > >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > From internet-drafts@ietf.org Tue Jan 31 07:09:48 2012 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 6298121F863E; Tue, 31 Jan 2012 07:09:48 -0800 (PST) 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 krtTgPJqVPJX; Tue, 31 Jan 2012 07:09:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C3621F84F7; Tue, 31 Jan 2012 07:09:47 -0800 (PST) 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: 3.64p1 Message-ID: <20120131150947.3484.47246.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2012 07:09:47 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-sipto-option-02.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 15:09:48 -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 Wor= king Group of the IETF. Title : IPv4 Traffic Offload Selector Option for Proxy Mobile IP= v6 Author(s) : Sri Gundavelli Xingyue Zhou Jouni Korhonen Rajeev Koodli Filename : draft-ietf-netext-pmipv6-sipto-option-02.txt Pages : 12 Date : 2012-01-31 This specification defines a mechanism and a related mobility option for carrying IPv4 Offload traffic selectors between a mobile access gateway and a local mobility anchor in a Proxy Mobile IPv6 domain. Based on the received offload flow selectors from the local mobility anchor, a mobile access gateway can enable offload traffic rule on the selected IPv4 flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-sipto-option-0= 2.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-sipto-option-02= .txt