From mccap@petoni.org Thu Jun 9 14:30:26 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D6A11E811D for ; Thu, 9 Jun 2011 14:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZ8WyG58vUMz for ; Thu, 9 Jun 2011 14:30:25 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id E0F5011E813A for ; Thu, 9 Jun 2011 14:30:24 -0700 (PDT) Received: by fxm15 with SMTP id 15so1437007fxm.31 for ; Thu, 09 Jun 2011 14:30:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.48.139 with SMTP id r11mr1299704faf.63.1307655023481; Thu, 09 Jun 2011 14:30:23 -0700 (PDT) Received: by 10.223.54.88 with HTTP; Thu, 9 Jun 2011 14:30:23 -0700 (PDT) X-Originating-IP: [173.142.31.86] In-Reply-To: <4DCB9463.1000008@gmail.com> References: <20110504204006.6944.34365.idtracker@ietfa.amsl.com> <4DCB9463.1000008@gmail.com> Date: Thu, 9 Jun 2011 17:30:23 -0400 Message-ID: From: Pete McCann To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Mip4] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-mip4-nemov4-dynamic-05 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 21:30:26 -0000 Any other thoughts on this? If I don't hear anything in the next couple of days, I will complete the PROTO writeup with a note that said we discussed it, but no one objected to the publication or asked for work-arounds. -Pete From mccap@petoni.org Thu Jun 9 15:04:39 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C331F0C37 for ; Thu, 9 Jun 2011 15:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKskjkjvAeDu for ; Thu, 9 Jun 2011 15:04:38 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82B4A1F0C34 for ; Thu, 9 Jun 2011 15:04:38 -0700 (PDT) Received: by fxm15 with SMTP id 15so1451013fxm.31 for ; Thu, 09 Jun 2011 15:04:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.98.4 with SMTP id o4mr424578fan.120.1307657077495; Thu, 09 Jun 2011 15:04:37 -0700 (PDT) Received: by 10.223.54.88 with HTTP; Thu, 9 Jun 2011 15:04:37 -0700 (PDT) X-Originating-IP: [173.142.31.86] Date: Thu, 9 Jun 2011 18:04:37 -0400 Message-ID: From: Pete McCann To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Mip4] Working Group Last Call on draft-ietf-mip4-nemo-haaro-04 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 22:04:39 -0000 This message announces a WG last call on: "Home Agent assisted Route Optimization between Mobile IPv4 Networks" draft-ietf-mip4-nemo-haaro-04 This document describes a Home Agent assisted Route Optimization functionality to IPv4 Network Mobility Protocol. The function is designed to facilitate optimal routing in cases where all nodes are connected to a single Home Agent, thus the use case is Route Optimization within single organization or similar entity. The functionality adds the possibility to discover: eligible peer nodes based on information received from Home Agent; Network Prefixes they represent; and, how to establish a direct tunnel between such nodes. This draft is intended for publication as a Proposed Standard. The last call will conclude at 24:00 UTC on Thursday, June 23, 2011. A URL for this Internet-Draft is: Please respond to this WG last call: * If you have no comments on the draft, and support its advancement, simply respond with a line containing something like "I support the advancement of this document to the IESG with a request for publication as proposed standard." If you have comments, please use a line similar to the one above, and supplement this with your comments. * If you *don't* support its advancement, respond with a line containing something like the following, supplemented by your comments - "I don't support the advancement of this document to the IESG with a request for publication as proposed standard, for the following reasons:" ... -Pete From tslura@gmail.com Sat Jun 11 06:43:15 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBFA11E80AB for ; Sat, 11 Jun 2011 06:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ucGU1u7pdp9 for ; Sat, 11 Jun 2011 06:43:14 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id BBBDC11E80AA for ; Sat, 11 Jun 2011 06:43:14 -0700 (PDT) Received: by ywp31 with SMTP id 31so1884569ywp.31 for ; Sat, 11 Jun 2011 06:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=h9huClFgbtPDCfPrCEJnm9Bz3cRHZF4F6TkcdSBqGZk=; b=vqFVN/S79vURP5GLb1zZYT+5EhaBVmdZZSsOasKu2x1Kz5CmGDRqUVCc0BKqyNr92m G/zLv27XTvyc8KWZt9OGr6j1Te7UZtgyYsF2GyxxzZnk25gaMcd6/Ga+CMIOIAWlFDFF GL6Lz2m3mj9sXiMiph20Eb0Z7Q5PGeBI78FCk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JlUUcGLwDKf9qUVkBPgT1SeodkZD7Ad8mcWddQS9MsXyEZy7Ie9spcESLg2jnYa5Vz 9M/yh8YyfAxCSE3pRtCogo4alYq1bgcSPUfr6ctWUfdQen06YptCoTIMes7YMePpK5ui 8m9wFnzxkRSlfnN9o5ab2nGLRa7goSklvpWaM= MIME-Version: 1.0 Received: by 10.236.155.164 with SMTP id j24mr12527yhk.300.1307799794199; Sat, 11 Jun 2011 06:43:14 -0700 (PDT) Received: by 10.236.207.193 with HTTP; Sat, 11 Jun 2011 06:43:14 -0700 (PDT) Date: Sat, 11 Jun 2011 14:43:14 +0100 Message-ID: From: TS Lura To: mip4@ietf.org Content-Type: multipart/alternative; boundary=20cf302d4c302bab8104a56fde90 Subject: [Mip4] Reporting of the time of point of changing the point of attachment. X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 13:43:15 -0000 --20cf302d4c302bab8104a56fde90 Content-Type: text/plain; charset=ISO-8859-1 Dear mip4 mailing list, I am conduction some light research into mipv4. Problem: Users reporting high latency time while roaming between layer 3 subnets. What I am trying to answer is: First: What would be the best way to monitor and report the time, when a client re-registers while roaming between subnets, with access only to the home agent? Second: Would this be a complicated process? So far my initial research has not revealed if there are any oid in the rfc 2006 mipHA which will report the time used in the process of re-registering. And it looks for me at this moment that the IP traffic it self needs to be monitored to extract the time in ms for the re-registering of a client. Kind regards, TSLura. --20cf302d4c302bab8104a56fde90 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear mip4 mailing list,

I am conduction some light resea= rch into mipv4.=A0

Problem: Users reporting high l= atency time while roaming between layer 3 subnets.

What I am trying to answer is:=A0
First: What would be the best w= ay to monitor and report the time, when a client re-registers while roaming= between subnets, with=A0access=A0only to the home agent?=A0

=
Second: Would this be a complicated process?

= So= far my initial research has not revealed if there are any oid in the rfc 2= 006 mipHA which will report the time used in the process of re-registering. A= nd it looks for me at this moment that the IP traffic it self needs to be m= onitored to extract the time in ms for the re-registering of a client.



Kind regards,
<= br>
TSLura.
--20cf302d4c302bab8104a56fde90-- From sgundave@cisco.com Mon Jun 13 08:11:41 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDD811E80D2 for ; Mon, 13 Jun 2011 08:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvXjsLCXCt2z for ; Mon, 13 Jun 2011 08:11:39 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9A011E808C for ; Mon, 13 Jun 2011 08:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2006; q=dns/txt; s=iport; t=1307977896; x=1309187496; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=O9pFZS0OC6WMxfgXGORvpy7iFfgUE+n+sWHKaX2nilg=; b=ZiS8jOElk3q6j9A9nuI3SuymZGrCcG2Ldmnlgf/PzBdhUlAejAkYAtcT NvH6S6Ut92nJhKcbRUSTOAYZ9EHaDMqJ1EIBkms8Nsy9VTNdNAiFcCazm OiMdbGOpQvdpoIDFIuuqM3UIvC7kVg85ohvU8q8oKuLRQSBOakKri5VjP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBACIo9k2rRDoJ/2dsb2JhbABSl1SOZXeIcqFpnUaGJASHDYonhFiLJQ X-IronPort-AV: E=Sophos;i="4.65,359,1304294400"; d="scan'208";a="712594979" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 13 Jun 2011 15:11:36 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5DFBaeC022757; Mon, 13 Jun 2011 15:11:36 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, 13 Jun 2011 08:11:35 -0700 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, 13 Jun 2011 15:11:35 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Mon, 13 Jun 2011 08:11:34 -0700 From: Sri Gundavelli To: Pete McCann , Message-ID: Thread-Topic: [Mip4] Working Group Last Call on draft-ietf-mip4-nemo-haaro-04 Thread-Index: Acwp3C601d/pC6lyGESPRvy5U2VbGg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Jun 2011 15:11:35.0728 (UTC) FILETIME=[2FBBC300:01CC29DC] Subject: Re: [Mip4] Working Group Last Call on draft-ietf-mip4-nemo-haaro-04 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 15:11:41 -0000 Hi Pete, I support the advancement of this document to be published as a proposed "experimental" standard. I've reviewed the earlier versions of the draft. Regards Sri On 6/9/11 3:04 PM, "Pete McCann" wrote: > This message announces a WG last call on: > > "Home Agent assisted Route Optimization between Mobile IPv4 Networks" > draft-ietf-mip4-nemo-haaro-04 > > This document describes a Home Agent assisted Route Optimization > functionality to IPv4 Network Mobility Protocol. The function is > designed to facilitate optimal routing in cases where all nodes are > connected to a single Home Agent, thus the use case is Route > Optimization within single organization or similar entity. The > functionality adds the possibility to discover: eligible peer nodes > based on information received from Home Agent; Network Prefixes they > represent; and, how to establish a direct tunnel between such nodes. > > This draft is intended for publication as a Proposed Standard. > The last call will conclude at 24:00 UTC on Thursday, June 23, 2011. > > A URL for this Internet-Draft is: > > > > > > > Please respond to this WG last call: > > > > * If you have no comments on the draft, and support its advancement, > simply respond with a line containing something like > > "I support the advancement of this document to the IESG with a request > for publication as proposed standard." > > If you have comments, please use a line similar to the one above, and > supplement this with your comments. > > > * If you *don't* support its advancement, respond with a line containing > something like the following, supplemented by your comments - > > "I don't support the advancement of this document to the IESG with a > request for publication as proposed standard, for the following reasons:" ... > > > -Pete From jukka.manner@tkk.fi Mon Jun 13 12:13:12 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0E31F0C7C for ; Mon, 13 Jun 2011 12:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqz4oo8PCWcx for ; Mon, 13 Jun 2011 12:13:11 -0700 (PDT) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by ietfa.amsl.com (Postfix) with ESMTP id C1CD91F0C75 for ; Mon, 13 Jun 2011 12:13:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 481F71E0BE; Mon, 13 Jun 2011 22:12:58 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EjCj6RdpiTb6; Mon, 13 Jun 2011 22:12:54 +0300 (EEST) Received: from [192.168.100.14] (a91-152-186-160.elisa-laajakaista.fi [91.152.186.160]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id E8FB71E01B; Mon, 13 Jun 2011 22:12:53 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Jukka Manner In-Reply-To: <29555_1307657089_4DF14381_29555_51_1_BANLkTimcspV3DZrty+9UVm1-PpoCf860cA@mail.gmail.com> Date: Mon, 13 Jun 2011 22:12:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <29555_1307657089_4DF14381_29555_51_1_BANLkTimcspV3DZrty+9UVm1-PpoCf860cA@mail.gmail.com> To: mip4@ietf.org, Pete McCann X-Mailer: Apple Mail (2.1084) Subject: Re: [Mip4] Working Group Last Call on draft-ietf-mip4-nemo-haaro-04 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 19:13:12 -0000 Hi, I have supported the work earlier and I still support the advancement to = the IESG for publication. You seem to talk about a Proposed standard, = although the document implies Experimental. Regards, Jukka On Jun 10, 2011, at 1:04 AM, Pete McCann wrote: > This message announces a WG last call on: >=20 > "Home Agent assisted Route Optimization between Mobile IPv4 Networks" > draft-ietf-mip4-nemo-haaro-04 >=20 > This document describes a Home Agent assisted Route Optimization > functionality to IPv4 Network Mobility Protocol. The function is > designed to facilitate optimal routing in cases where all nodes are > connected to a single Home Agent, thus the use case is Route > Optimization within single organization or similar entity. The > functionality adds the possibility to discover: eligible peer nodes > based on information received from Home Agent; Network Prefixes they > represent; and, how to establish a direct tunnel between such nodes. >=20 > This draft is intended for publication as a Proposed Standard. > The last call will conclude at 24:00 UTC on Thursday, June 23, 2011. >=20 > A URL for this Internet-Draft is: >=20 > = >=20 >=20 >=20 >=20 > Please respond to this WG last call: >=20 >=20 >=20 > * If you have no comments on the draft, and support its advancement, > simply respond with a line containing something like >=20 > "I support the advancement of this document to the IESG with a request > for publication as proposed standard." >=20 > If you have comments, please use a line similar to the one above, and > supplement this with your comments. >=20 >=20 > * If you *don't* support its advancement, respond with a line = containing > something like the following, supplemented by your comments - >=20 > "I don't support the advancement of this document to the IESG with a > request for publication as proposed standard, for the following = reasons:" ... >=20 >=20 > -Pete > --=20 > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ From mccap@petoni.org Mon Jun 13 17:26:10 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC83C21F85BD for ; Mon, 13 Jun 2011 17:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-GEZ-2SC+g1 for ; Mon, 13 Jun 2011 17:26:10 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id EACBE21F85BA for ; Mon, 13 Jun 2011 17:26:09 -0700 (PDT) Received: by fxm11 with SMTP id 11so6327337fxm.27 for ; Mon, 13 Jun 2011 17:26:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.48.139 with SMTP id r11mr5833278faf.63.1308011168852; Mon, 13 Jun 2011 17:26:08 -0700 (PDT) Received: by 10.223.54.88 with HTTP; Mon, 13 Jun 2011 17:26:08 -0700 (PDT) X-Originating-IP: [64.53.131.166] In-Reply-To: References: Date: Mon, 13 Jun 2011 20:26:08 -0400 Message-ID: From: Pete McCann To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Mip4] Working Group Last Call on draft-ietf-mip4-nemo-haaro-04 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 00:26:11 -0000 My mistake - this should be an Experimental RFC. -Pete On Thu, Jun 9, 2011 at 6:04 PM, Pete McCann wrote: > This message announces a WG last call on: > > "Home Agent assisted Route Optimization between Mobile IPv4 Networks" > draft-ietf-mip4-nemo-haaro-04 > > =A0 This document describes a Home Agent assisted Route Optimization > =A0 functionality to IPv4 Network Mobility Protocol. =A0The function is > =A0 designed to facilitate optimal routing in cases where all nodes are > =A0 connected to a single Home Agent, thus the use case is Route > =A0 Optimization within single organization or similar entity. =A0The > =A0 functionality adds the possibility to discover: eligible peer nodes > =A0 based on information received from Home Agent; Network Prefixes they > =A0 represent; and, how to establish a direct tunnel between such nodes. > > This draft is intended for publication as a Proposed Standard. > The last call will conclude at 24:00 UTC on Thursday, June 23, 2011. > > A URL for this Internet-Draft is: > > > > > > > Please respond to this WG last call: > > > > * If you have no comments on the draft, and support its advancement, > =A0simply respond with a line containing something like > > "I support the advancement of this document to the IESG with a request > =A0for publication as proposed standard." > > If you have comments, please use a line similar to the one above, and > supplement this with your comments. > > > * If you *don't* support its advancement, respond with a line containing > =A0something like the following, supplemented by your comments - > > "I don't support the advancement of this document to the IESG with a > request for publication as proposed standard, for the following reasons:"= ... > > > -Pete > From Xiangsong.Cui@huawei.com Mon Jun 13 19:34:21 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DB511E80B9 for ; Mon, 13 Jun 2011 19:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDaHZopKvPtG for ; Mon, 13 Jun 2011 19:34:20 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4532F11E8075 for ; Mon, 13 Jun 2011 19:34:20 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMR004TKDR2UQ@szxga05-in.huawei.com> for mip4@ietf.org; Tue, 14 Jun 2011 10:33:02 +0800 (CST) Received: from c00111037 ([10.111.16.79]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LMR00ELWDR0XK@szxga05-in.huawei.com> for mip4@ietf.org; Tue, 14 Jun 2011 10:33:02 +0800 (CST) Date: Tue, 14 Jun 2011 10:33:00 +0800 From: Xiangsong Cui In-reply-to: To: 'Pete McCann' , mip4@ietf.org Message-id: <001101cc2a3b$617eaab0$247c0010$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acwm8T7U/t8sKrHoR1mhhZplfJNAlwDSc78Q References: Subject: Re: [Mip4] Working Group Last Call on draft-ietf-mip4-nemo-haaro-04 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 02:34:21 -0000 Hi, I have reviewed this draft and I support it. By the way, RFC 3344 has been obsoleted by RFC 5944, this should be updated in the draft. Regards, Xiangsong > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of > Pete McCann > Sent: Friday, June 10, 2011 6:05 AM > To: mip4@ietf.org > Subject: [Mip4] Working Group Last Call on draft-ietf-mip4-nemo-haaro-04 > > This message announces a WG last call on: > > "Home Agent assisted Route Optimization between Mobile IPv4 Networks" > draft-ietf-mip4-nemo-haaro-04 > > This document describes a Home Agent assisted Route Optimization > functionality to IPv4 Network Mobility Protocol. The function is > designed to facilitate optimal routing in cases where all nodes are > connected to a single Home Agent, thus the use case is Route > Optimization within single organization or similar entity. The > functionality adds the possibility to discover: eligible peer nodes > based on information received from Home Agent; Network Prefixes they > represent; and, how to establish a direct tunnel between such nodes. > > This draft is intended for publication as a Proposed Standard. > The last call will conclude at 24:00 UTC on Thursday, June 23, 2011. > > A URL for this Internet-Draft is: > > > > > > > Please respond to this WG last call: > > > > * If you have no comments on the draft, and support its advancement, > simply respond with a line containing something like > > "I support the advancement of this document to the IESG with a request > for publication as proposed standard." > > If you have comments, please use a line similar to the one above, and > supplement this with your comments. > > > * If you *don't* support its advancement, respond with a line containing > something like the following, supplemented by your comments - > > "I don't support the advancement of this document to the IESG with a > request for publication as proposed standard, for the following reasons:" ... > > > -Pete > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ From giovanni.giambene@gmail.com Fri Jun 17 00:28:27 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C9321F84C3 for ; Fri, 17 Jun 2011 00:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVK9PFGI-YHD for ; Fri, 17 Jun 2011 00:28:26 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 54B8921F84BA for ; Fri, 17 Jun 2011 00:28:26 -0700 (PDT) Received: by vws12 with SMTP id 12so2225145vws.31 for ; Fri, 17 Jun 2011 00:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=V3kgzVfxhjL3kEPvhSl31rPeqrNQihM8xNugbPBZVk4=; b=m3c0Q94hONMhs2quSuwCEe6fJw+DVL8Sot2GNtTVc5IdUx4V1S0hCQ8WWcqTSW9rgk JEK20AageyrNdJbNVRDIDVG75kr5BNzjGM4ClPyNX1i6j4MviC0KbXUOnDnNqBHU7O1X osoKTc7IuqGtnMmRNOZwOqKObkxdGX35aD4Uc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=bcc:mime-version:date:message-id:subject:from:to:content-type; b=Zn4PcK7ZFPjEMwk6fORlMSdjsro0TjPqI+tD/9yDU3vNBKDE/YmgvqjCE6H7tA06Xh sCKOYAn1JBvHT2aNm8HKgQYuoNkUJsZmjpkXrICj6x1eBqtTbZPkAtjwSJ8CNZZpjYBV XTDYcK0WWojYHOtw+n4dMUbTIZWAnlwAsvEqE= MIME-Version: 1.0 Received: by 10.52.112.131 with SMTP id iq3mr2439516vdb.118.1308295705693; Fri, 17 Jun 2011 00:28:25 -0700 (PDT) Received: by 10.52.188.232 with HTTP; Fri, 17 Jun 2011 00:28:25 -0700 (PDT) Date: Fri, 17 Jun 2011 09:28:25 +0200 Message-ID: From: Giovanni Giambene To: Giovanni Giambene Content-Type: multipart/alternative; boundary=bcaec548a361cc8d8c04a5e35437 X-Mailman-Approved-At: Fri, 17 Jun 2011 03:44:00 -0700 Subject: [Mip4] Summer School on Satellite Communications and Networking (Siena, Italy, 5-9 September 2011) - Early registration ends on June 20, 2011 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 07:28:27 -0000 --bcaec548a361cc8d8c04a5e35437 Content-Type: text/plain; charset=ISO-8859-1 Dear Colleague, I am very pleased to bring to your attention the opportunity of the SatNEx III Summer School 2011 initiative on Satellite Communications and Networking, organized in Siena, Italy, Faculty of Engineering, September 5-9, 2011 (http://satnexiiisummerschool2011.dii.unisi.it/index.html). Please distribute this message among your PhD students and young researchers. The FULL PROGRAM is available at the following link: http://satnexiiisummerschool2011.dii.unisi.it/Summer_School_2011_detailed_program.pdf Young researchers, participating to the school, can submit INNOVATIVE RESEARCH IDEAS that will be reviewed and presented the last day that is devoted to innovation, including R&D presentations by major stakeholders (e.g., INMARSAT, TriaGnoSys, National Instruments, EUTELSAT, ESA, Telespazio, ASI, etc.). The best idea will be awarded. Submission instructions (and template) of innovative ideas are provided at the link (SUBMISSION DEADLINE: June 20, 2011): http://satnexiiisummerschool2011.dii.unisi.it/innovative.html There is an online hotel booking form with CHEAP ACCOMMODATIONS in Siena: http://satnexiiisummerschool2011.dii.unisi.it/tourist.html The participation to the school requires REGISTRATION (deadline for early registration: June 20, 2011), please follow the instructions at the following link: http://satnexiiisummerschool2011.dii.unisi.it/registration.html. The students will have to do an EXAMINATION at the end of each lesson and will receive a certificate for 1 ECTS at the end of the school. I hope you like this initiative and the school program. Thanks a lot. Looking forward to hearing from you, Sincerely, Giovanni Giambene Siena Summer School 2011 organizer --------------------------------------------------------------------- Dr. Giovanni Giambene Assistant Professor Dipartimento di Ingegneria dell'Informazione Universita' degli Studi di Siena Via Roma, 56 53100 Siena, Italy Phone: +39 0577 234850 then dial 1016 Mobile phone: +39 320 43 55 871 Fax: +39 0577 233602 E-mail: giambene at unisi.it Skype: giambene Home page: http://www.dii.unisi.it/~giambene/ --------------------------------------------------------------------- --bcaec548a361cc8d8c04a5e35437 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Colleague,

I am very pleased to bring to your attention the opp= ortunity of the SatNEx III Summer School 2011 initiative on Satellite Commu= nications and Networking, organized in Siena, Italy, Faculty of Engineering= , September 5-9, 2011 (http://satnexiiisummerschool2011.dii.unisi.it/index.html). Please distribute this message among your PhD students and young resea= rchers.

The FULL PROGRAM is available at the following link:
http://satnexiiisummerschool2011.dii.unisi.it/Summer_School_2011_de= tailed_program.pdf

Young researchers, participating to the school, can submit INNOVATIVE R= ESEARCH IDEAS that will be reviewed and presented the last day that is devo= ted to innovation, including R&D presentations by major stakeholders (e= .g., INMARSAT, TriaGnoSys, National=A0 Instruments, EUTELSAT, ESA, Telespaz= io, ASI, etc.). The best idea will be awarded.

Submission instructions (and template) of innovative ideas are provided= at the link (SUBMISSION DEADLINE: June 20, 2011):
http://satnexiiisummer= school2011.dii.unisi.it/innovative.html

There is an online hotel booking form with CHEAP ACCOMMODATIONS in Sien= a:=A0 http://satnexiiisummerschool2011.dii.unisi.it/tourist.html

The= participation to the school requires REGISTRATION (deadline for early regi= stration: June 20, 2011), please follow the instructions at the following l= ink:
http://satnexiiisummerschool2011.dii.unisi.it/registration.html.
The students will have to do an EXAMINATION at the end of each lesson and= will receive a certificate for 1 ECTS at the end of the school.

I hope you like this initiative and the school program. Thanks a lot.
Looking forward to hearing from you,

Sincerely,

Giovann= i Giambene
Siena Summer School 2011 organizer

=A0
---------------------------------------------------------------------Dr. Giovanni Giambene
Assistant Professor
Dipartimento di Ingegneri= a dell'Informazione
Universita' degli Studi di Siena
Via Roma= , 56
53100 Siena, Italy
Phone: +39 0577 234850 =A0 then dial 1016
Mobile p= hone: +39 320 43 55 871
Fax: +39 0577 233602
E-mail: giambene at unisi.it
Skype: giambene Home page: http://www.dii.unisi.it/~giambene/
------------------------------= ---------------------------------------

--bcaec548a361cc8d8c04a5e35437-- From mccap@petoni.org Fri Jun 17 08:33:11 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DD311E81B8 for ; Fri, 17 Jun 2011 08:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNObzumLLrlw for ; Fri, 17 Jun 2011 08:33:10 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 40DB211E81B4 for ; Fri, 17 Jun 2011 08:33:09 -0700 (PDT) Received: by fxm15 with SMTP id 15so2102292fxm.31 for ; Fri, 17 Jun 2011 08:33:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.28.220 with SMTP id n28mr2667133fac.101.1308324788277; Fri, 17 Jun 2011 08:33:08 -0700 (PDT) Received: by 10.223.54.88 with HTTP; Fri, 17 Jun 2011 08:33:08 -0700 (PDT) X-Originating-IP: [64.53.131.166] Date: Fri, 17 Jun 2011 10:33:08 -0500 Message-ID: From: Pete McCann To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-mip4-nemov4-dynamic.all@tools.ietf.org Subject: [Mip4] Request to Publish draft-ietf-mip4-nemov4-dynamic-05 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 15:33:11 -0000 Dear iesg-secretary (BCC'd): This is a request for the IESG to consider publication of draft-ietf-mip4-nemov4-dynamic-05 as a Proposed Standard. Answers to the questionnaire are below. > =A0(1.a) Who is the Document Shepherd for this document? Has the > =A0 =A0 =A0 =A0Document Shepherd personally reviewed this version of the > =A0 =A0 =A0 =A0document and, in particular, does he or she believe this > =A0 =A0 =A0 =A0version is ready for forwarding to the IESG for publicatio= n? The document shepherd is Pete McCann. =A0Yes, I have reviewed this version of the document and I believe it is ready for publication. > =A0(1.b) Has the document had adequate review both from key WG members > =A0 =A0 =A0 =A0and from key non-WG members? Does the Document Shepherd ha= ve > =A0 =A0 =A0 =A0any concerns about the depth or breadth of the reviews tha= t > =A0 =A0 =A0 =A0have been performed? Yes, and no. > =A0(1.c) Does the Document Shepherd have concerns that the document > =A0 =A0 =A0 =A0needs more review from a particular or broader perspective= , > =A0 =A0 =A0 =A0e.g., security, operational complexity, someone familiar w= ith > =A0 =A0 =A0 =A0AAA, internationalization or XML? No. > =A0(1.d) Does the Document Shepherd have any specific concerns or > =A0 =A0 =A0 =A0issues with this document that the Responsible Area Direct= or > =A0 =A0 =A0 =A0and/or the IESG should be aware of? For example, perhaps h= e > =A0 =A0 =A0 =A0or she is uncomfortable with certain parts of the document= , or > =A0 =A0 =A0 =A0has concerns whether there really is a need for it. In any > =A0 =A0 =A0 =A0event, if the WG has discussed those issues and has indica= ted > =A0 =A0 =A0 =A0that it still wishes to advance the document, detail those > =A0 =A0 =A0 =A0concerns here. Has an IPR disclosure related to this docum= ent > =A0 =A0 =A0 =A0been filed? If so, please include a reference to the > =A0 =A0 =A0 =A0disclosure and summarize the WG discussion and conclusion = on > =A0 =A0 =A0 =A0this issue. No concerns. Two IPR disclosures have been filed with respect to this document. Discussion regarding the IPR was held on the list and there were no objections to publishing the document as-is. > =A0(1.e) How solid is the WG consensus behind this document? Does it > =A0 =A0 =A0 =A0represent the strong concurrence of a few individuals, wit= h > =A0 =A0 =A0 =A0others being silent, or does the WG as a whole understand = and > =A0 =A0 =A0 =A0agree with it? Consensus is solid. > =A0(1.f) Has anyone threatened an appeal or otherwise indicated extreme > =A0 =A0 =A0 =A0discontent? If so, please summarise the areas of conflict = in > =A0 =A0 =A0 =A0separate email messages to the Responsible Area Director. = (It > =A0 =A0 =A0 =A0should be in a separate email because this questionnaire i= s > =A0 =A0 =A0 =A0entered into the ID Tracker.) No. > =A0(1.g) Has the Document Shepherd personally verified that the > =A0 =A0 =A0 =A0document satisfies all ID nits? (See the Internet-Drafts C= hecklist > =A0 =A0 =A0 =A0and http://tools.ietf.org/tools/idnits/). Boilerplate chec= ks are > =A0 =A0 =A0 =A0not enough; this check needs to be thorough. Has the docum= ent > =A0 =A0 =A0 =A0met all formal review criteria it needs to, such as the MI= B > =A0 =A0 =A0 =A0Doctor, media type and URI type reviews? No nits found. > =A0(1.h) Has the document split its references into normative and > =A0 =A0 =A0 =A0informative? Are there normative references to documents t= hat > =A0 =A0 =A0 =A0are not ready for advancement or are otherwise in an uncle= ar > =A0 =A0 =A0 =A0state? If such normative references exist, what is the > =A0 =A0 =A0 =A0strategy for their completion? Are there normative referen= ces > =A0 =A0 =A0 =A0that are downward references, as described in [RFC3967]? I= f > =A0 =A0 =A0 =A0so, list these downward references to support the Area > =A0 =A0 =A0 =A0Director in the Last Call procedure for them [RFC3967]. The document contains only normative references, contained in a properly labeled "Normative References" section. =A0No downward refs are present. > =A0(1.i) Has the Document Shepherd verified that the document IANA > =A0 =A0 =A0 =A0consideration section exists and is consistent with the bo= dy > =A0 =A0 =A0 =A0of the document? If the document specifies protocol > =A0 =A0 =A0 =A0extensions, are reservations requested in appropriate IANA > =A0 =A0 =A0 =A0registries? Are the IANA registries clearly identified? If > =A0 =A0 =A0 =A0the document creates a new registry, does it define the > =A0 =A0 =A0 =A0proposed initial contents of the registry and an allocatio= n > =A0 =A0 =A0 =A0procedure for future registrations? Does it suggest a > =A0 =A0 =A0 =A0reasonable name for the new registry? See [RFC5226]. If th= e > =A0 =A0 =A0 =A0document describes an Expert Review process has Shepherd > =A0 =A0 =A0 =A0conferred with the Responsible Area Director so that the I= ESG > =A0 =A0 =A0 =A0can appoint the needed Expert during the IESG Evaluation? The document has a properly labeled IANA considerations section which requests no actions from IANA. > =A0(1.j) Has the Document Shepherd verified that sections of the > =A0 =A0 =A0 =A0document that are written in a formal language, such as XM= L > =A0 =A0 =A0 =A0code, BNF rules, MIB definitions, etc., validate correctly= in > =A0 =A0 =A0 =A0an automated checker? No such formal languages are used in the document. > =A0(1.k) The IESG approval announcement includes a Document > =A0 =A0 =A0 =A0Announcement Write-Up. Please provide such a Document > =A0 =A0 =A0 =A0Announcement Write-Up? Recent examples can be found in the > =A0 =A0 =A0 =A0"Action" announcements for approved documents. The approva= l > =A0 =A0 =A0 =A0announcement contains the following sections: > > =A0 =A0 Technical Summary The NEMOv4 specification allows a Mobile Router to register a whole network prefix. In the base specification, the Mobile Router must be pre-configured with a home prefix which is sent in the NEMO Registration Request. In this document, the possibility of allocating a prefix from the home network dynamically is allowed. The use of an all-zeroes value in the home prefix extension is proposed to indicate a request for dynamic assignment. > =A0 =A0 Working Group Summary This short and simple draft encountered very little controversy in the working group. > =A0 =A0 Document Quality The document is simple and the protocol well-specified. From jari.arkko@piuha.net Sat Jun 18 22:25:38 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACF121F853E for ; Sat, 18 Jun 2011 22:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPHOq9wzLtbe for ; Sat, 18 Jun 2011 22:25:37 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 8E66621F853D for ; Sat, 18 Jun 2011 22:25:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B6CFE2CC3B; Sun, 19 Jun 2011 08:25:36 +0300 (EEST) 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 xE4zWRX8SSs9; Sun, 19 Jun 2011 08:25:35 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 7A4002CC2F; Sun, 19 Jun 2011 08:25:35 +0300 (EEST) Message-ID: <4DFD884D.8060704@piuha.net> Date: Sun, 19 Jun 2011 08:25:33 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: draft-ietf-mip4-nemov4-dynamic@tools.ietf.org, Mobile IPv4 Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 05:25:38 -0000 I have reviewed this draft. I think it is short, well written and ready to move forward with the exception of one issue: > According to this specification, a Mobile Router MAY include one or > more mobile network request extensions with the prefix field set to > zero. ... > In this case, the Mobile Router MAY set the > prefix length field of such extensions to zero or to a length of its > choice as a hint to the home agent. ... > If in response to a registration request with a mobile network > request extension with the prefix field set to zero, a Mobile Router > receives a registration reply with a network acknowledgement > extension including Code field set to 1 "invalid prefix", it may use > it as a hint that the home agent does not support dynamic prefix > allocation. > But RFC 5177 says: > When the prefix > length is zero or greater than decimal 32, the status Code MUST be > set to MOBNET_INVALID_PREFIX_LEN. > I think the model for backwards compatibility needs work. Specifically, if the mobile router uses a non-zero prefix length as a hint, it may happen that a plain RFC 5177 implementation thinks its a real prefix request, mistakenly inserts the prefix (with zero bits) to some routing table somewhere but does not check that this causes an error or undefined behavior. There is no text in RFC 5177 that asks to check for zero bits. I see a few possibilities to fix this problem. 1) Convince ourselves that existing NEMOv4 implementations do in fact check for zero, despite RFC 5177 text. 2) Drop the prefix size hint functionality from this draft. 3) Move the prefix size hint to a new optional attribute that is carried separately in the requests. Do you agree that this is a problem, or am I missing something obvious? If this is a problem, what does the working group want to do? Jari From kleung@cisco.com Mon Jun 20 12:32:57 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE69A11E8202 for ; Mon, 20 Jun 2011 12:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JC1FtFoawCN for ; Mon, 20 Jun 2011 12:32:56 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id B887611E81FC for ; Mon, 20 Jun 2011 12:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=3572; q=dns/txt; s=iport; t=1308598376; x=1309807976; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=tQvRS1NibbwHQBRUrAywmOI5/rpvBkr/zvY1/8fjEro=; b=fH208VCRMIFsp2t9sEOc9UY65rZQtSeJSJUi1rSJg5JQKjIlPKLiEw7O RJ0dosbnc/sWHSAeRORC66CBt4yHFzO8ybZYcX2+TK8QmH/O3rXDpHKwB +7zipfIrGppmpUmhSfxoUXhpNVLQ5XT4+hfmCWzGkT8zRh9r9Aey2Opga o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAN+f/02rRDoG/2dsb2JhbABTl1mPC3eqXJ4OhioEhyCPJ4s4 X-IronPort-AV: E=Sophos;i="4.65,396,1304294400"; d="scan'208";a="717666028" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 20 Jun 2011 19:32:23 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5KJWNhW012048; Mon, 20 Jun 2011 19:32:23 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jun 2011 12:32:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2011 12:32:31 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520F2D4027@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4DFD884D.8060704@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic Thread-Index: AcwuQVYQzQcSEO1BTjS9BWrQtUwv4wBNPvig References: <4DFD884D.8060704@piuha.net> From: "Kent Leung (kleung)" To: "Jari Arkko" , , "Mobile IPv4 Mailing List" X-OriginalArrivalTime: 20 Jun 2011 19:32:23.0197 (UTC) FILETIME=[C73E4CD0:01CC2F80] Subject: Re: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 19:32:57 -0000 Hi Jari. Thanks for the thorough review. Good catch. :) I would like to confirm my understanding of the issue. 1) RFC 5177 checks the validity of Prefix Length field in the Mobile Network Request Ext. This value cannot be "zero or greater than decimal 32". So there is no backwards compatibility issue. In fact, the draft uses this check to confirm HA does not support the dynamic feature based on the return code 1 "invalid prefix length". 2) The backwards compatibility issue arises when the prefix is zero and non-zero prefix length is used as a hint by MR. In this case, HA cannot tell the difference between RFC 5177 explicit mode and this draft's dynamic hint mode. The HA may inadvertently process network prefix zero for routing setup. This is likely not a problem because existing NEMOv4-based implementation performs sanity check on prefix zero. Though I agree that the case is not explicitly specified in the RFC. Based on your suggested fixes, I would prefer #1 since the problem with backward compatibility won't likely happen. #2 would be my next choice if folks feel strongly against #1. Kent -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Jari Arkko Sent: Saturday, June 18, 2011 10:26 PM To: draft-ietf-mip4-nemov4-dynamic@tools.ietf.org; Mobile IPv4 Mailing List Subject: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic I have reviewed this draft. I think it is short, well written and ready=20 to move forward with the exception of one issue: > According to this specification, a Mobile Router MAY include one or > more mobile network request extensions with the prefix field set to > zero.=20 ... > In this case, the Mobile Router MAY set the > prefix length field of such extensions to zero or to a length of its > choice as a hint to the home agent. ... > If in response to a registration request with a mobile network > request extension with the prefix field set to zero, a Mobile Router > receives a registration reply with a network acknowledgement > extension including Code field set to 1 "invalid prefix", it may use > it as a hint that the home agent does not support dynamic prefix > allocation. > =20 But RFC 5177 says: > When the prefix > length is zero or greater than decimal 32, the status Code MUST be > set to MOBNET_INVALID_PREFIX_LEN. > =20 I think the model for backwards compatibility needs work. Specifically,=20 if the mobile router uses a non-zero prefix length as a hint, it may=20 happen that a plain RFC 5177 implementation thinks its a real prefix=20 request, mistakenly inserts the prefix (with zero bits) to some routing=20 table somewhere but does not check that this causes an error or=20 undefined behavior. There is no text in RFC 5177 that asks to check for=20 zero bits. I see a few possibilities to fix this problem. 1) Convince ourselves that existing NEMOv4 implementations do in fact=20 check for zero, despite RFC 5177 text. 2) Drop the prefix size hint functionality from this draft. 3) Move the prefix size hint to a new optional attribute that is carried separately in the requests. Do you agree that this is a problem, or am I missing something obvious?=20 If this is a problem, what does the working group want to do? Jari --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From jari.arkko@piuha.net Mon Jun 20 12:46:27 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F2F1F0C39 for ; Mon, 20 Jun 2011 12:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5zsBL5Ue3J2 for ; Mon, 20 Jun 2011 12:46:27 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA291F0C36 for ; Mon, 20 Jun 2011 12:46:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id DDBD92CC39; Mon, 20 Jun 2011 22:46:17 +0300 (EEST) 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 N1v+IbbEPUa7; Mon, 20 Jun 2011 22:46:13 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id BBD9E2CC2F; Mon, 20 Jun 2011 22:46:13 +0300 (EEST) Message-ID: <4DFFA385.10506@piuha.net> Date: Mon, 20 Jun 2011 22:46:13 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "Kent Leung (kleung)" References: <4DFD884D.8060704@piuha.net> <2979E38DD6FC6544B789C8DAD7BAFC520F2D4027@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC520F2D4027@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mip4-nemov4-dynamic@tools.ietf.org, Mobile IPv4 Mailing List Subject: Re: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 19:46:27 -0000 Yes, your understanding is correct as far as I can tell. Do you know _all_ nemov4 implementations? If you think you are aware of all of their behaviour, and they all check for zero bits, then we should go with solution #1. Jair Kent Leung (kleung) kirjoitti: > Hi Jari. Thanks for the thorough review. Good catch. :) I would like > to confirm my understanding of the issue. > > 1) RFC 5177 checks the validity of Prefix Length field in the Mobile > Network Request Ext. This value cannot be "zero or greater than decimal > 32". So there is no backwards compatibility issue. In fact, the draft > uses this check to confirm HA does not support the dynamic feature based > on the return code 1 "invalid prefix length". > > 2) The backwards compatibility issue arises when the prefix is zero and > non-zero prefix length is used as a hint by MR. In this case, HA cannot > tell the difference between RFC 5177 explicit mode and this draft's > dynamic hint mode. The HA may inadvertently process network prefix zero > for routing setup. This is likely not a problem because existing > NEMOv4-based implementation performs sanity check on prefix zero. > Though I agree that the case is not explicitly specified in the RFC. > > Based on your suggested fixes, I would prefer #1 since the problem with > backward compatibility won't likely happen. #2 would be my next choice > if folks feel strongly against #1. > > Kent > > > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of > Jari Arkko > Sent: Saturday, June 18, 2011 10:26 PM > To: draft-ietf-mip4-nemov4-dynamic@tools.ietf.org; Mobile IPv4 Mailing > List > Subject: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic > > I have reviewed this draft. I think it is short, well written and ready > to move forward with the exception of one issue: > > >> According to this specification, a Mobile Router MAY include one or >> more mobile network request extensions with the prefix field set to >> zero. >> > ... > >> In this case, the Mobile Router MAY set the >> prefix length field of such extensions to zero or to a length of its >> choice as a hint to the home agent. >> > ... > >> If in response to a registration request with a mobile network >> request extension with the prefix field set to zero, a Mobile Router >> receives a registration reply with a network acknowledgement >> extension including Code field set to 1 "invalid prefix", it may use >> it as a hint that the home agent does not support dynamic prefix >> allocation. >> >> > > But RFC 5177 says: > >> When the prefix >> length is zero or greater than decimal 32, the status Code MUST be >> set to MOBNET_INVALID_PREFIX_LEN. >> >> > > I think the model for backwards compatibility needs work. Specifically, > if the mobile router uses a non-zero prefix length as a hint, it may > happen that a plain RFC 5177 implementation thinks its a real prefix > request, mistakenly inserts the prefix (with zero bits) to some routing > table somewhere but does not check that this causes an error or > undefined behavior. There is no text in RFC 5177 that asks to check for > zero bits. > > I see a few possibilities to fix this problem. > > 1) Convince ourselves that existing NEMOv4 implementations do in fact > check for zero, despite RFC 5177 text. > > 2) Drop the prefix size hint functionality from this draft. > > 3) Move the prefix size hint to a new optional attribute that is carried > > separately in the requests. > > Do you agree that this is a problem, or am I missing something obvious? > If this is a problem, what does the working group want to do? > > Jari > > From kleung@cisco.com Mon Jun 20 13:11:47 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E5A11E80A5 for ; Mon, 20 Jun 2011 13:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUNGz7VLq5pq for ; Mon, 20 Jun 2011 13:11:46 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id B9B6511E808E for ; Mon, 20 Jun 2011 13:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=4762; q=dns/txt; s=iport; t=1308600706; x=1309810306; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=nplcmhjXJzu+RBEaoXn+pgtEo235LAuK8XTgMXuIOh4=; b=Oi4n3RayVGKKMUVyYSydA9ni2LyPATjD23a5WPHl1zE3pjd4OFbVXnyQ FDM2tVE+vhr7i4xwCOFyzPoSpSaNA8dOMiDvr4GufBBcsH296f8zYIQDS UbAmiUc1tqDsLo+Oj2kV4K3rJ/l3dM/uUoOsUf+ZoQW4zkdSyyEWwf8WW g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAHSo/02rRDoG/2dsb2JhbABTl1qPC3eqZp4YhioEhyCPJ4s4 X-IronPort-AV: E=Sophos;i="4.65,396,1304294400"; d="scan'208";a="341978942" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 20 Jun 2011 20:11:46 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5KKBkai028833; Mon, 20 Jun 2011 20:11:46 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jun 2011 13:11:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2011 13:10:52 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520F2D4061@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4DFFA385.10506@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic Thread-Index: AcwvgsFOzps9m6QiTGuWaefO2yHgCgAAcRyA References: <4DFD884D.8060704@piuha.net> <2979E38DD6FC6544B789C8DAD7BAFC520F2D4027@xmb-sjc-235.amer.cisco.com> <4DFFA385.10506@piuha.net> From: "Kent Leung (kleung)" To: "Jari Arkko" X-OriginalArrivalTime: 20 Jun 2011 20:11:46.0174 (UTC) FILETIME=[47AFF9E0:01CC2F86] Cc: draft-ietf-mip4-nemov4-dynamic@tools.ietf.org, Mobile IPv4 Mailing List Subject: Re: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 20:11:47 -0000 Obviously, I cannot speak for all implementations. I only know about the commercial deployment of Mobile IP standards based mobile network technology on Cisco routers and MIP agents. As for the logic of allowing prefix zero, this would be quite problematic due to the non-deterministic nature of multiple MRs registering such a prefix to the HA. In general, there are a bunch of issues with prefix zero that is redistributed via routing protocols by HA. Maybe we can go with #1 due to the possible calamity with any HA allowing prefix zero? Such implementation needs to be fixed anyways... ;) Kent -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Monday, June 20, 2011 12:46 PM To: Kent Leung (kleung) Cc: draft-ietf-mip4-nemov4-dynamic@tools.ietf.org; Mobile IPv4 Mailing List Subject: Re: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic Yes, your understanding is correct as far as I can tell. Do you know=20 _all_ nemov4 implementations? If you think you are aware of all of their behaviour, and they all check for zero bits, then we should go with=20 solution #1. Jair Kent Leung (kleung) kirjoitti: > Hi Jari. Thanks for the thorough review. Good catch. :) I would like > to confirm my understanding of the issue. > > 1) RFC 5177 checks the validity of Prefix Length field in the Mobile > Network Request Ext. This value cannot be "zero or greater than decimal > 32". So there is no backwards compatibility issue. In fact, the draft > uses this check to confirm HA does not support the dynamic feature based > on the return code 1 "invalid prefix length". > > 2) The backwards compatibility issue arises when the prefix is zero and > non-zero prefix length is used as a hint by MR. In this case, HA cannot > tell the difference between RFC 5177 explicit mode and this draft's > dynamic hint mode. The HA may inadvertently process network prefix zero > for routing setup. This is likely not a problem because existing > NEMOv4-based implementation performs sanity check on prefix zero. > Though I agree that the case is not explicitly specified in the RFC. > > Based on your suggested fixes, I would prefer #1 since the problem with > backward compatibility won't likely happen. #2 would be my next choice > if folks feel strongly against #1. > > Kent > > > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of > Jari Arkko > Sent: Saturday, June 18, 2011 10:26 PM > To: draft-ietf-mip4-nemov4-dynamic@tools.ietf.org; Mobile IPv4 Mailing > List > Subject: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic > > I have reviewed this draft. I think it is short, well written and ready=20 > to move forward with the exception of one issue: > > =20 >> According to this specification, a Mobile Router MAY include one or >> more mobile network request extensions with the prefix field set to >> zero.=20 >> =20 > ... > =20 >> In this case, the Mobile Router MAY set the >> prefix length field of such extensions to zero or to a length of its >> choice as a hint to the home agent. >> =20 > ... > =20 >> If in response to a registration request with a mobile network >> request extension with the prefix field set to zero, a Mobile Router >> receives a registration reply with a network acknowledgement >> extension including Code field set to 1 "invalid prefix", it may use >> it as a hint that the home agent does not support dynamic prefix >> allocation. >> =20 >> =20 > > But RFC 5177 says: > =20 >> When the prefix >> length is zero or greater than decimal 32, the status Code MUST be >> set to MOBNET_INVALID_PREFIX_LEN. >> =20 >> =20 > > I think the model for backwards compatibility needs work. Specifically,=20 > if the mobile router uses a non-zero prefix length as a hint, it may=20 > happen that a plain RFC 5177 implementation thinks its a real prefix=20 > request, mistakenly inserts the prefix (with zero bits) to some routing=20 > table somewhere but does not check that this causes an error or=20 > undefined behavior. There is no text in RFC 5177 that asks to check for=20 > zero bits. > > I see a few possibilities to fix this problem. > > 1) Convince ourselves that existing NEMOv4 implementations do in fact=20 > check for zero, despite RFC 5177 text. > > 2) Drop the prefix size hint functionality from this draft. > > 3) Move the prefix size hint to a new optional attribute that is carried > > separately in the requests. > > Do you agree that this is a problem, or am I missing something obvious?=20 > If this is a problem, what does the working group want to do? > > Jari > > =20 From jari.arkko@piuha.net Mon Jun 20 13:15:47 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9F31F0C70 for ; Mon, 20 Jun 2011 13:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoqJbVZXVazJ for ; Mon, 20 Jun 2011 13:15:47 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0E81F0C71 for ; Mon, 20 Jun 2011 13:15:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BF0A42D366; Mon, 20 Jun 2011 23:15:31 +0300 (EEST) 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 k3ZdVcQU1eR5; Mon, 20 Jun 2011 23:15:31 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 98F302CC2F; Mon, 20 Jun 2011 23:15:30 +0300 (EEST) Message-ID: <4DFFAA61.4080304@piuha.net> Date: Mon, 20 Jun 2011 23:15:29 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "Kent Leung (kleung)" References: <4DFD884D.8060704@piuha.net> <2979E38DD6FC6544B789C8DAD7BAFC520F2D4027@xmb-sjc-235.amer.cisco.com> <4DFFA385.10506@piuha.net> <2979E38DD6FC6544B789C8DAD7BAFC520F2D4061@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC520F2D4061@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mip4-nemov4-dynamic@tools.ietf.org, Mobile IPv4 Mailing List Subject: Re: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 20:15:47 -0000 Kent Leung (kleung) kirjoitti: > Obviously, I cannot speak for all implementations. I only know about > the commercial deployment of Mobile IP standards based mobile network > technology on Cisco routers and MIP agents. OK. Do you know of other implementations, even if you do not know their behavior? Others, what other implementations are there? What do they do? > As for the logic of > allowing prefix zero, this would be quite problematic due to the > non-deterministic nature of multiple MRs registering such a prefix to > the HA. In general, there are a bunch of issues with prefix zero that > is redistributed via routing protocols by HA. Maybe we can go with #1 > due to the possible calamity with any HA allowing prefix zero? Such > implementation needs to be fixed anyways... ;) > That's a possible argument, yes. Jari From kleung@cisco.com Mon Jun 20 13:20:31 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC9F1F0C77 for ; Mon, 20 Jun 2011 13:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjIr+Apq9pZO for ; Mon, 20 Jun 2011 13:20:30 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6044C1F0C38 for ; Mon, 20 Jun 2011 13:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=1348; q=dns/txt; s=iport; t=1308601230; x=1309810830; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=4xvbwj4c3agjBbphAunlTrTjJkOnvPgy92p8HIx6TVU=; b=lhvxDma+8Vop/oINz09TlchHFw0RTVh+H5XM1hJYStaaNWWGDZ+mPb10 Mp5cyeUZep9yKGUI2Co2kW7tf6vW9D4Jx153RscY2NF4EGaZkXwjC1X7m bMyK8YcQhsx4OkdiI0OqRdS8FrDYHGf57eIrbX4dW+hw7TJknW3MKHgG2 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAE2r/01Io8UR/2dsb2JhbABTl1qPC3eIc6FunhSGKgSHII8nizg X-IronPort-AV: E=Sophos;i="4.65,396,1304294400"; d="scan'208";a="36177674" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 20 Jun 2011 20:20:28 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5KKKDwJ001632; Mon, 20 Jun 2011 20:20:26 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jun 2011 13:20:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2011 13:19:12 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520F2D406F@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4DFFAA61.4080304@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic Thread-Index: AcwvhtOfYrGHYpCdT/q4YHD8i0DM9wAACE3w References: <4DFD884D.8060704@piuha.net> <2979E38DD6FC6544B789C8DAD7BAFC520F2D4027@xmb-sjc-235.amer.cisco.com> <4DFFA385.10506@piuha.net> <2979E38DD6FC6544B789C8DAD7BAFC520F2D4061@xmb-sjc-235.amer.cisco.com> <4DFFAA61.4080304@piuha.net> From: "Kent Leung (kleung)" To: "Jari Arkko" X-OriginalArrivalTime: 20 Jun 2011 20:20:14.0455 (UTC) FILETIME=[76A58070:01CC2F87] Cc: draft-ietf-mip4-nemov4-dynamic@tools.ietf.org, Mobile IPv4 Mailing List Subject: Re: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 20:20:31 -0000 -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Monday, June 20, 2011 1:15 PM To: Kent Leung (kleung) Cc: draft-ietf-mip4-nemov4-dynamic@tools.ietf.org; Mobile IPv4 Mailing List Subject: Re: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic Kent Leung (kleung) kirjoitti: > Obviously, I cannot speak for all implementations. I only know about > the commercial deployment of Mobile IP standards based mobile network > technology on Cisco routers and MIP agents. OK. Do you know of other implementations, even if you do not know their=20 behavior? Others, what other implementations are there? What do they do? KL> I'm not aware of other NEMOv4-based implementations used in deployment. There are commercial deployments that do not used NEMOv4. So can't help there. > As for the logic of > allowing prefix zero, this would be quite problematic due to the > non-deterministic nature of multiple MRs registering such a prefix to > the HA. In general, there are a bunch of issues with prefix zero that > is redistributed via routing protocols by HA. Maybe we can go with #1 > due to the possible calamity with any HA allowing prefix zero? Such > implementation needs to be fixed anyways... ;) > =20 That's a possible argument, yes. KL> Bug fix. :) Kent Jari From bridgetb@gmail.com Fri Jun 24 07:25:19 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C9611E80E0 for ; Fri, 24 Jun 2011 07:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVHhY-5Dc2BX for ; Fri, 24 Jun 2011 07:25:18 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA87D11E80DE for ; Fri, 24 Jun 2011 07:25:17 -0700 (PDT) Received: by gya6 with SMTP id 6so1673932gya.31 for ; Fri, 24 Jun 2011 07:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=7FEJ7lwitIkXAHt4V8Gh6Zg0MnHK7M31YYsE6N7jfdk=; b=e2F2i0asc5Wy9W+8sWt8BEcpF0kbO3TpLM+kdCLOJfdUPLv2h/sDkp4vTxu0WwrhCJ ji1Xh0SG2rBgWO7NZHM5XKfx2sIbYiDvYya6+drzBfNA3iSOIqA/r6y1JGcpeO6VV3sr 8C2rz6DOG9Fl72vunvFYoqRfI2zguYTCFZc8k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=bcc:mime-version:from:date:message-id:subject:to:content-type; b=ubFI3q3jwfCBrZ2me9C5c2p/PV+4ZWHqNiBXnUj3fGiCEQOHEFHpMCSD0/YC+C3Hb2 AFhcBhjY4yIyoeFIApl8EuryRvJZy1iqqyg/npzJvViCU44x2M63ZcUArJu6lveOyWKG 3YdHsnbraNFucq7yLkFGGZFvWWF8r37Vvx5TM= Received: by 10.236.185.134 with SMTP id u6mr5211438yhm.76.1308925517069; Fri, 24 Jun 2011 07:25:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.208.194 with HTTP; Fri, 24 Jun 2011 07:24:56 -0700 (PDT) From: Bridget Benson Date: Fri, 24 Jun 2011 10:24:56 -0400 Message-ID: To: Bridget Benson Content-Type: multipart/alternative; boundary=20cf30549c3f7b7e7504a675f818 X-Mailman-Approved-At: Fri, 24 Jun 2011 10:43:14 -0700 Subject: [Mip4] WUWNet'11 Call for Papers X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 14:26:50 -0000 --20cf30549c3f7b7e7504a675f818 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable WUWNet'11: The Sixth ACM International Workshop on UnderWater Networks http://wuwnet.acm.org/2011/ December 1-2, 2011 Seattle, WA, USA CALL FOR PAPERS The oceans cover 71% of the Earth's surface and represent one of the least explored frontiers; yet, the oceans are integral to climate regulation, nutrient production, oil retrieval, and transportation. Also, water systems in general are of vital importance to life on Earth and commerce. For these reasons, there is significant interest in monitoring aquatic environments for scientific, environmental, commercial, safety, and military purposes. WUWNet is the premier venue for early work bringing real-time, in-situ sensing and actuation to this aquatic world. The goal of this workshop is t= o bring together researchers and practitioners in areas relevant to underwate= r networks. Thus, many layers of the communication stack - from the physical layer to the application layer - will be represented. The objective is to serve as a forum for presenting state-of-the-art research, for exchanging ideas and experiences, and for facilitating interaction and collaboration. The workshop will span two days, including presentations of technical papers, a keynote talk, a panel, and a poster/demo session. The scope of th= e WUWNet workshop covers a broad range of research directions related to underwater systems including communications, networking, system integration= , and vehicle coordination. Specific topics of interest include, but are not limited to: - Underwater network architectures - Efficient underwater communications, with techniques from the physical layer to the application layer - Cooperative underwater communications, including, PHY, MAC, routing, and data transfer - Services for underwater systems, such as localization, time synchronization, reliable data transfer, security - Subsea communication for underwater vehicles (gliders, submersibles, etc.) - Coordination algorithms for underwater vehicles and sensor nodes, or human operator interaction - Modeling, simulation, and testbeds for underwater systems - Applications that broadly address subsea networks, including coordinated vehicle systems - Experimental results from underwater networking trials - Application requirements for underwater networks presented by end users SUBMISSION GUIDELINES Submissions for technical papers must describe original research, not published or currently under review for other workshops, conferences, journals, or magazines. All papers will be reviewed by the program committee for novelty and contribution. The workshop accepts two types of papers: full and short. Short papers may represent less mature work than full papers, or may contai= n new ideas for future research. Full papers should be more complete in their treatment of the topic. All accepted papers, full and short, will be published in the workshop proceedings. Paper submission will be handled electronically. Authors should prepare a PDF version of their papers. The page limit for full papers is 8 pages, and that for short papers is 5 pages in standard ACM conference format. Please see the workshop website for definitive formatting guidelines and sample templates. Furthermore, this year WUWNet will also have a =93Demo/Doctoral Symposium,= =94 which will provide a forum for both graduate and undergraduate students working on research topics relevant to WUWNet to discuss their goals, methods, and results at an early stage in their research. A 2-page extended abstract (in standard ACM conference format, with the student as first author) must be submitted by the deadline provided below. Last, but not least, a call for work-in-progress posters and demos will be announced separately. IMPORTANT DATES Paper registration: August 12, 2011 Paper submission: August 19, 2011 Acceptance notification: October 14, 2011 Camera-ready date: November 4, 2011 Workshop date: December 1-2, 2011 Demo/Doctoral Symposium extended abstract submission: September 30, 2011 Demo/Doctoral Symposium acceptance notification: October 14, 2011 Student travel grant submission: October 21, 2011 Student travel grant notification: October 28, 2011 ORGANIZERS General Chairs: Payman Arabshahi (Univ. of Washington) Jun-Hong Cui (Univ. of Connecticut) Program Committee Chairs: Qilian Liang (UT Arlington) Dario Pompili (Rutgers Univ.) Sumit Roy (Univ. of Washington) ----- Bridget Benson, PhD Postdoctoral Researcher Coastal Environmental Sensing Networks University of Massachusetts Boston www.cesn.org --20cf30549c3f7b7e7504a675f818 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
WUWNet'11: The Sixth ACM International Workshop on UnderWater Netw= orks


Decem= ber 1-2, 2011

Seattle, WA, USA

CALL FOR PAPERS

The oceans cover 71% of the Earth's surface and represent one o= f the least explored frontiers; yet, the oceans are integral to climate reg= ulation, nutrient production, oil retrieval, and transportation. Also, wate= r systems in general are of vital importance to life on Earth and commerce.= For these reasons, there is significant interest in monitoring aquatic env= ironments for scientific, environmental, commercial, safety, and military p= urposes.

WUWNet is the premier venue for early work bringing rea= l-time, in-situ sensing and actuation to this aquatic world. The goal of th= is workshop is to bring together researchers and practitioners in areas rel= evant to underwater networks. Thus, many layers of the communication stack = - from the physical layer to the application layer - will be represented. T= he objective is to serve as a forum for presenting state-of-the-art researc= h, for exchanging ideas and experiences, and for facilitating interaction a= nd collaboration.

The workshop will span two days, including presentation= s of technical papers, a keynote talk, a panel, and a poster/demo session. = The scope of the WUWNet workshop covers a broad range of research direction= s related to underwater systems including communications, networking, syste= m integration, and vehicle coordination. Specific topics of interest includ= e, but are not limited to:

- =A0Underwater network architectures
- =A0Ef= ficient underwater communications, with techniques from the physical layer = to the application layer
- =A0Cooperative underwater communicatio= ns, including, PHY, MAC, routing, and data transfer
- =A0Services for underwater systems, such as localization, time synch= ronization, reliable data transfer, security
- =A0Subsea communic= ation for underwater vehicles (gliders, submersibles, etc.)
- =A0= Coordination algorithms for underwater vehicles and sensor nodes, or human = operator interaction
- =A0Modeling, simulation, and testbeds for underwater systems
- =A0Applications that broadly address subsea networks, including coordi= nated vehicle systems
- =A0Experimental results from underwater n= etworking trials
- =A0Application requirements for underwater networks presented by end= users

SUBMISSION GUIDELINES

<= div>Submissions for technical papers must describe original research, not p= ublished or currently under review for other workshops, conferences, journa= ls, or magazines.

All papers will be reviewed by the program committee fo= r novelty and contribution. The workshop accepts two types of papers: full = and short. Short papers may represent less mature work than full papers, or= may contain new ideas for future research. Full papers should be more comp= lete in their treatment of the topic. All accepted papers, full and short, = will be published in the workshop proceedings.

Paper submission will be handled electronically. Author= s should prepare a PDF version of their papers. The page limit for full pap= ers is 8 pages, and that for short papers is 5 pages in standard ACM confer= ence format. Please see the workshop website for definitive formatting guid= elines and sample templates.

Furthermore, this year WUWNet will also have a =93Demo/= Doctoral Symposium,=94 which will provide a forum for both graduate and und= ergraduate students working on research topics relevant to WUWNet to discus= s their goals, methods, and results at an early stage in their research. A = 2-page extended abstract (in standard ACM conference format, with the stude= nt as first author) must be submitted by the deadline provided below.

Last, but not least, a call for work-in-progress poster= s and demos will be announced separately.

IMPORTAN= T DATES

Paper registration: =A0 =A0 =A0 =A0August = 12, 2011
Paper submission: =A0 =A0 =A0 =A0 =A0 =A0August 19, 2011
Acc= eptance notification: =A0 =A0October 14, 2011
Camera-ready date: = =A0 =A0 =A0 =A0November 4, 2011
Workshop date: =A0 =A0 =A0 =A0 = =A0 =A0December 1-2, 2011

Demo/Doctoral Symposium extended abstract submission: =A0 = =A0September 30, 2011
Demo/Doctoral Symposium acceptance notifica= tion: =A0 =A0 =A0 =A0October 14, 2011
Student travel grant submis= sion: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October 21, 2011
Student travel grant notification: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0October 28, 2011

ORGANIZERS

General Chairs:
Payman Arabshahi (Univ. of Washington)
Jun-Hong Cui (Univ. of Connecticut)

Program Committee Chairs:
Qilian Liang (UT Ar= lington)
Dario Pompili (Rutgers Univ.)
Sumit Roy (Univ.= of Washington)


-----
Bridget Benson, PhD
Postdoctoral Researcher
Coastal Environmental Sen= sing Networks
University of Massachusetts Boston
--20cf30549c3f7b7e7504a675f818-- From alexandru.petrescu@gmail.com Wed Jun 29 03:03:48 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CF421F86F6 for ; Wed, 29 Jun 2011 03:03:48 -0700 (PDT) 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_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAK2+n6dca+T for ; Wed, 29 Jun 2011 03:03:30 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 597EB21F86F4 for ; Wed, 29 Jun 2011 03:03:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p5TA3SYC008681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 29 Jun 2011 12:03:28 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p5TA3SmF004031 for ; Wed, 29 Jun 2011 12:03:28 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p5TA3SNw003525 for ; Wed, 29 Jun 2011 12:03:28 +0200 Message-ID: <4E0AF870.2000205@gmail.com> Date: Wed, 29 Jun 2011 12:03:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mip4@ietf.org References: <4DFD884D.8060704@piuha.net> <2979E38DD6FC6544B789C8DAD7BAFC520F2D4027@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC520F2D4027@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 10:03:49 -0000 Le 20/06/2011 21:32, Kent Leung (kleung) a écrit : > Hi Jari. Thanks for the thorough review. Good catch. :) I would > like to confirm my understanding of the issue. > > 1) RFC 5177 checks the validity of Prefix Length field in the Mobile > Network Request Ext. This value cannot be "zero or greater than > decimal 32". So there is no backwards compatibility issue. In > fact, the draft uses this check to confirm HA does not support the > dynamic feature based on the return code 1 "invalid prefix length". > > 2) The backwards compatibility issue arises when the prefix is zero > and non-zero prefix length is used as a hint by MR. In this case, > HA cannot tell the difference between RFC 5177 explicit mode and > this draft's dynamic hint mode. The HA may inadvertently process > network prefix zero for routing setup. This is likely not a problem > because existing NEMOv4-based implementation performs sanity check on > prefix zero. Though I agree that the case is not explicitly specified > in the RFC. > > Based on your suggested fixes, I would prefer #1 since the problem > with backward compatibility won't likely happen. #2 would be my > next choice if folks feel strongly against #1. As I understand it, I prefer to use #2 "Drop the prefix size hint functionality from this draft.". The reason I prefer so is manyfold: It is sufficient to put 0 in the prefix (not the length) to make it look like a request, and ignore the prefix length altogether. It's not necessary to reinforce the 0 in prefix with another 0 in len to make it sound like a "request" as opposed to prefix non-zero being "imposed". It is good to make prefix allocation with DHCP subnet allocation recently resurrected draft-ietf-dhc-subnet-alloc rather than with MIP4/NEMOv4. I am saying so after experimenting with DHCPv6 prefix delegation for MIPv6/NEMOv6 (rather than MIPv6-based prefix allocation for NEMOv6). Prefix 0/length0 has a special meaning in IPv6 (not sure in IPv4) - it means "default route" by RFC. This is a different meaning than requesting prefix allocation. Alex > > Kent > > > -----Original Message----- From: mip4-bounces@ietf.org > [mailto:mip4-bounces@ietf.org] On Behalf Of Jari Arkko Sent: > Saturday, June 18, 2011 10:26 PM To: > draft-ietf-mip4-nemov4-dynamic@tools.ietf.org; Mobile IPv4 Mailing > List Subject: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic > > I have reviewed this draft. I think it is short, well written and > ready to move forward with the exception of one issue: > >> According to this specification, a Mobile Router MAY include one or >> more mobile network request extensions with the prefix field set to >> zero. > ... >> In this case, the Mobile Router MAY set the prefix length field of >> such extensions to zero or to a length of its choice as a hint to >> the home agent. > ... >> If in response to a registration request with a mobile network >> request extension with the prefix field set to zero, a Mobile >> Router receives a registration reply with a network acknowledgement >> extension including Code field set to 1 "invalid prefix", it may >> use it as a hint that the home agent does not support dynamic >> prefix allocation. >> > > But RFC 5177 says: >> When the prefix length is zero or greater than decimal 32, the >> status Code MUST be set to MOBNET_INVALID_PREFIX_LEN. >> > > I think the model for backwards compatibility needs work. > Specifically, if the mobile router uses a non-zero prefix length as > a hint, it may happen that a plain RFC 5177 implementation thinks its > a real prefix request, mistakenly inserts the prefix (with zero > bits) to some routing table somewhere but does not check that this > causes an error or undefined behavior. There is no text in RFC 5177 > that asks to check for zero bits. > > I see a few possibilities to fix this problem. > > 1) Convince ourselves that existing NEMOv4 implementations do in fact > check for zero, despite RFC 5177 text. > > 2) Drop the prefix size hint functionality from this draft. > > 3) Move the prefix size hint to a new optional attribute that is > carried > > separately in the requests. > > Do you agree that this is a problem, or am I missing something > obvious? If this is a problem, what does the working group want to > do? > > Jari > From alexandru.petrescu@gmail.com Wed Jun 29 03:07:54 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F34211E8070 for ; Wed, 29 Jun 2011 03:07:54 -0700 (PDT) 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_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXfgwB4JUoIM for ; Wed, 29 Jun 2011 03:07:53 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAE79E8032 for ; Wed, 29 Jun 2011 03:07:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p5TA7pF3019306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Jun 2011 12:07:51 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p5TA7pHx008399; Wed, 29 Jun 2011 12:07:51 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p5TA7oOC010441; Wed, 29 Jun 2011 12:07:50 +0200 Message-ID: <4E0AF976.4010700@gmail.com> Date: Wed, 29 Jun 2011 12:07:50 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mip4@ietf.org References: <4DFD884D.8060704@piuha.net> <2979E38DD6FC6544B789C8DAD7BAFC520F2D4027@xmb-sjc-235.amer.cisco.com> <4DFFA385.10506@piuha.net> In-Reply-To: <4DFFA385.10506@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 10:07:54 -0000 Le 20/06/2011 21:46, Jari Arkko a écrit : > Yes, your understanding is correct as far as I can tell. Do you know > _all_ nemov4 implementations? If you think you are aware of all of their > behaviour, and they all check for zero bits, then we should go with > solution #1. Our NEMOv4 implementation does not use explicit mode, but only the implicit mode (i.e. no prefix in the RegReq). As such there is no means for our HA to check for a request of prefix allocation. Currently I am divided between trying DHCP subnet allocation or NEMOv4 prefix allocation. Alex > > Jair > > Kent Leung (kleung) kirjoitti: >> Hi Jari. Thanks for the thorough review. Good catch. :) I would like >> to confirm my understanding of the issue. >> >> 1) RFC 5177 checks the validity of Prefix Length field in the Mobile >> Network Request Ext. This value cannot be "zero or greater than decimal >> 32". So there is no backwards compatibility issue. In fact, the draft >> uses this check to confirm HA does not support the dynamic feature based >> on the return code 1 "invalid prefix length". >> >> 2) The backwards compatibility issue arises when the prefix is zero and >> non-zero prefix length is used as a hint by MR. In this case, HA cannot >> tell the difference between RFC 5177 explicit mode and this draft's >> dynamic hint mode. The HA may inadvertently process network prefix zero >> for routing setup. This is likely not a problem because existing >> NEMOv4-based implementation performs sanity check on prefix zero. >> Though I agree that the case is not explicitly specified in the RFC. >> >> Based on your suggested fixes, I would prefer #1 since the problem with >> backward compatibility won't likely happen. #2 would be my next choice >> if folks feel strongly against #1. >> >> Kent >> >> >> -----Original Message----- >> From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of >> Jari Arkko >> Sent: Saturday, June 18, 2011 10:26 PM >> To: draft-ietf-mip4-nemov4-dynamic@tools.ietf.org; Mobile IPv4 Mailing >> List >> Subject: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic >> >> I have reviewed this draft. I think it is short, well written and >> ready to move forward with the exception of one issue: >> >>> According to this specification, a Mobile Router MAY include one or >>> more mobile network request extensions with the prefix field set to >>> zero. >> ... >>> In this case, the Mobile Router MAY set the >>> prefix length field of such extensions to zero or to a length of its >>> choice as a hint to the home agent. >> ... >>> If in response to a registration request with a mobile network >>> request extension with the prefix field set to zero, a Mobile Router >>> receives a registration reply with a network acknowledgement >>> extension including Code field set to 1 "invalid prefix", it may use >>> it as a hint that the home agent does not support dynamic prefix >>> allocation. >> >> But RFC 5177 says: >>> When the prefix >>> length is zero or greater than decimal 32, the status Code MUST be >>> set to MOBNET_INVALID_PREFIX_LEN. >> >> I think the model for backwards compatibility needs work. >> Specifically, if the mobile router uses a non-zero prefix length as a >> hint, it may happen that a plain RFC 5177 implementation thinks its a >> real prefix request, mistakenly inserts the prefix (with zero bits) to >> some routing table somewhere but does not check that this causes an >> error or undefined behavior. There is no text in RFC 5177 that asks to >> check for zero bits. >> >> I see a few possibilities to fix this problem. >> >> 1) Convince ourselves that existing NEMOv4 implementations do in fact >> check for zero, despite RFC 5177 text. >> >> 2) Drop the prefix size hint functionality from this draft. >> >> 3) Move the prefix size hint to a new optional attribute that is carried >> >> separately in the requests. >> >> Do you agree that this is a problem, or am I missing something >> obvious? If this is a problem, what does the working group want to do? >> >> Jari >> > From alexandru.petrescu@gmail.com Wed Jun 29 03:11:39 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFED111E808D for ; Wed, 29 Jun 2011 03:11:39 -0700 (PDT) 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_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wAEuMSpGrCw for ; Wed, 29 Jun 2011 03:11:39 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 05E6D11E80BA for ; Wed, 29 Jun 2011 03:11:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p5TABXsS012903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Jun 2011 12:11:33 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p5TABX89011399; Wed, 29 Jun 2011 12:11:33 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p5TABX2I014518; Wed, 29 Jun 2011 12:11:33 +0200 Message-ID: <4E0AFA54.9090008@gmail.com> Date: Wed, 29 Jun 2011 12:11:32 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mip4@ietf.org References: <4DFD884D.8060704@piuha.net> <2979E38DD6FC6544B789C8DAD7BAFC520F2D4027@xmb-sjc-235.amer.cisco.com> <4DFFA385.10506@piuha.net> <2979E38DD6FC6544B789C8DAD7BAFC520F2D4061@xmb-sjc-235.amer.cisco.com> <4DFFAA61.4080304@piuha.net> <2979E38DD6FC6544B789C8DAD7BAFC520F2D406F@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC520F2D406F@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 10:11:39 -0000 Le 20/06/2011 22:19, Kent Leung (kleung) a écrit : > > > -----Original Message----- From: Jari Arkko > [mailto:jari.arkko@piuha.net] Sent: Monday, June 20, 2011 1:15 PM To: > Kent Leung (kleung) Cc: > draft-ietf-mip4-nemov4-dynamic@tools.ietf.org; Mobile IPv4 Mailing > List Subject: Re: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic > > Kent Leung (kleung) kirjoitti: >> Obviously, I cannot speak for all implementations. I only know >> about the commercial deployment of Mobile IP standards based mobile >> network technology on Cisco routers and MIP agents. > > OK. Do you know of other implementations, even if you do not know > their behavior? > > Others, what other implementations are there? What do they do? > > KL> I'm not aware of other NEMOv4-based implementations used in > deployment. There are commercial deployments that do not used > NEMOv4. So can't help there. Hm. This year there have been demoed trials for public transportation, with press and commercial interests which do use NEMOv4. The implementation was from us not from Cisco. But. This is an ongoing reality check that we should bear in mind. During several recent years there exist an increasing number of commercial real deployments with sold product which look very much like what we call "moving networks" and thus very pertinent to Mobile IP, but not using Mobile IP nor NEMOv4. Alex >> As for the logic of allowing prefix zero, this would be quite >> problematic due to the non-deterministic nature of multiple MRs >> registering such a prefix to the HA. In general, there are a bunch >> of issues with prefix zero that is redistributed via routing >> protocols by HA. Maybe we can go with #1 due to the possible >> calamity with any HA allowing prefix zero? Such implementation >> needs to be fixed anyways... ;) >> > > That's a possible argument, yes. > > KL> Bug fix. :) > > Kent > > > Jari >