From abdussalambaryun@gmail.com Sat Dec 1 05:38:24 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFD421F87AF for ; Sat, 1 Dec 2012 05:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 gGGsGkLlk2y8 for ; Sat, 1 Dec 2012 05:38:24 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF64221F8CDB for ; Sat, 1 Dec 2012 05:38:23 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so409296vbb.31 for ; Sat, 01 Dec 2012 05:38:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vU92tupg0MTwKsKNPUjxb8J1XLpSzNOoNxny12HrwDU=; b=zxsQ0ntkHI45K1bh4JolcHzGvcErBMwgtAoHFPg2CeDgzPu5cc/XacR8ogSw1FFOzi HEa9Vgrm5UvUcvh7U5qPm5DjnXIVoVcceRvi2CKPV57kVrOjqIHGG6zstgt3rM8CTt8V 5ph5mSYkQUaLXs7S3bFPn44ALBVeXrVm1f0sN+v62JDyOhIgSP7IWTN5r6O5wiy2mDB6 vTactQuxqOqCQoDbxzIlpnigAj9K7LNxDqWuLvJOO3Avf5zwVWE2FmCV5ipbmW06hj/G NVPadeR4ASVym150EG7AneMfpt9i1dkEndhEl0H1YHNJG5pyUSQ6AN7v0Xjdk7+U4Xju Cv2A== MIME-Version: 1.0 Received: by 10.58.143.12 with SMTP id sa12mr3937514veb.43.1354369103328; Sat, 01 Dec 2012 05:38:23 -0800 (PST) Received: by 10.220.145.5 with HTTP; Sat, 1 Dec 2012 05:38:23 -0800 (PST) In-Reply-To: <50B97B4D.60209@computer.org> References: <20121201032732.9644.98468.idtracker@ietfa.amsl.com> <50B97B4D.60209@computer.org> Date: Sat, 1 Dec 2012 14:38:23 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Fwd: New Version Notification for draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 13:38:24 -0000 On 12/1/12, Charles E. Perkins wrote: > > Hello folks, > > The new AODVv2 draft has been posted. I put in the necessary specification > to enable alternate metrics; more discussion is needed for this point. > > I noticed at the last minute that there were some mistakes in the example > message formats in the Appendices. I think that I fixed most or all of > them, > but today I have run out of time. Nevertheless, instead of waiting until > next week to post the draft, I have submitted it today in case anyone > would like to have it available during the week. Somehow I don't think > it will be the last version anyway. I don't worry about versions numbers, but group discussions progress :) > > Another thing I did not do is to re-verify that it is compatible with the > latest version of LOADng. If there are incompatibilities, I expect them to > be minor, but as always everything is open for discussion. If compatible then advantage but not necessary, it will just delay progress. > > If there is a desire to specify Cost() functions for other alternate > metrics, > that will require more discussion. I know this has been discussed before, > and in other working groups as well. Whether the discussion would result > in further changes to the AODVv2 document, I don't know. In the meantime, > we can just have HopCount to be the only fully specified metric for AODVv2. I recommend that thoes discussions to be for a new draft regarding AODVv2 cost functions, this draft specifies routing as done for OLSRv2 and metric specification for other drafts. > > There are some issues that may need to be posted to the Issue Tracker, > possibly including: > - whether SeqNum == 0 should be a reserved value > - whether a packet with alternate metric is recoverable when > a handling node does not understand the metric. > - whether msg-hop-count can be relied on to count hops of > a RteMsg > - whether msg-orig-addr can be relied on to indicate the IP address > of the originator of a message > - whether msg-hop-count *really* has to be initialized to zero. I agree thoes need mentioning, however, I need to review again, > > Have a great weekend! > > Regards, > Charlie P. > > PS. The draft for Intermediate RREP needs to be updated to > account for minor differences introduced by enabling > alternate metrics. > Is that draft a WG draft, if not please advise, Thanks AB From internet-drafts@ietf.org Sat Dec 1 08:59:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1D411E809C; Sat, 1 Dec 2012 08:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 nXmTlec5IsRy; Sat, 1 Dec 2012 08:59:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63BB11E80A4; Sat, 1 Dec 2012 08:58:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121201165859.9401.25788.idtracker@ietfa.amsl.com> Date: Sat, 01 Dec 2012 08:58:59 -0800 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-smf-mib-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 16:59:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Definition of Managed Objects for the Manet Simplified M= ulticast Framework Relay Set Process Author(s) : Robert G. Cole Joseph Macker Brian Adamson Filename : draft-ietf-manet-smf-mib-06.txt Pages : 61 Date : 2012-12-01 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc Networks (MANETs). The SMF-MIB also reports state information, performance metrics, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-smf-mib-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-smf-mib-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rgcole01@comcast.net Sat Dec 1 09:15:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC841F0C5C for ; Sat, 1 Dec 2012 09:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, 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 8B7kBRz7WUF3 for ; Sat, 1 Dec 2012 09:15:44 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id CEEE611E8099 for ; Sat, 1 Dec 2012 09:15:43 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta07.westchester.pa.mail.comcast.net with comcast id WH9Z1k0031ei1Bg57HFjHL; Sat, 01 Dec 2012 17:15:43 +0000 Received: from [10.0.1.195] ([68.55.94.27]) by omta24.westchester.pa.mail.comcast.net with comcast id WHFi1k00J0bRkG43kHFiNu; Sat, 01 Dec 2012 17:15:43 +0000 Message-ID: <50BA3B3E.7060506@comcast.net> Date: Sat, 01 Dec 2012 12:15:42 -0500 From: Cole User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: manet@ietf.org References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354382143; bh=BmA+suEJCbZoaoSdy5UKaYeTfXzSZEhnLOKM3WyXc/M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QsdVsTTeXfNAyyy+G88g58FE99WRXd0SNfuaIdR38BHYQXiGIQFJY1NN6WlmkqJNR DTLrlNZhkjgV4HfDXN5juGAoGK9/ipLzuYzed0kpdtvGu2iqJGcMxr6ASNre7ijT/2 CTzqO2OW9WhqJ2mGb4szNY0ek5C++EZgTHWOzfutGdnwjfhBJeVH3l+0wTG6eLMquu M2z3fJw//XKbe2gf6ckYUp2ZBIrn5XJo/gkLkHDVcaleuFy+19Fiv44csQDHiq6QFV bJMrrG7ooAdnJwWMZFqmdzK+dFpNdby+RIz1YnMjb5GlQqsIkHSnNJHSej9cwL++A4 1Qu+0mT0FckUg== Subject: [manet] Fwd: Fw: New Version Notification for draft-ietf-manet-smf-mib-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 17:15:44 -0000 Joe, Stan, We have done our final review of the SMF-MIB and have posted to the Working Group. There have been no substantive comments on the draft from the WG for quite a while. We would like to request that this draft be moved to Working Group Last Call. We hope you all concur? Respectfully, Bob ----- Original Message ----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Saturday, December 01, 2012 04:59 PM To: Cole, Robert G CIV USARMY CERDEC (US) Cc: adamson@itd.nrl.navy.mil ; macker@itd.nrl.navy.mil Subject: New Version Notification for draft-ietf-manet-smf-mib-06.txt A new version of I-D, draft-ietf-manet-smf-mib-06.txt has been successfully submitted by Robert G. Cole and posted to the IETF repository. Filename: draft-ietf-manet-smf-mib Revision: 06 Title: Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process Creation date: 2012-12-01 WG ID: manet Number of pages: 61 URL: http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-mib-06.txt Status: http://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib Htmlized: http://tools.ietf.org/html/draft-ietf-manet-smf-mib-06 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-smf-mib-06 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc Networks (MANETs). The SMF-MIB also reports state information, performance metrics, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems. The IETF Secretariat From charliep@computer.org Sat Dec 1 09:23:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F35E1F0C5C for ; Sat, 1 Dec 2012 09:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 nUL1s+t5qwIf for ; Sat, 1 Dec 2012 09:23:36 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 790AD1F0C67 for ; Sat, 1 Dec 2012 09:23:36 -0800 (PST) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Teqmt-00031z-KG; Sat, 01 Dec 2012 12:23:35 -0500 Message-ID: <50BA3D0F.4030808@computer.org> Date: Sat, 01 Dec 2012 09:23:27 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Abdussalam Baryun References: <20121201032732.9644.98468.idtracker@ietfa.amsl.com> <50B97B4D.60209@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86105fbbfef4e536e2ff9c8f4f764566a3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: manet Subject: Re: [manet] Fwd: New Version Notification for draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 17:23:37 -0000 Hello Abdussalam, On 12/1/2012 5:38 AM, Abdussalam Baryun wrote: > I recommend that thoes discussions to be for a new draft regarding > AODVv2 cost functions, this draft specifies routing as done for OLSRv2 > and metric specification for other drafts. I agree there is work to be done here. First, however, we need to get agreement on the protocol aspects and route table organization for dealing with multiple metrics. In fact, for various metrics like "latency", the definitions will be pretty much straightforward. We'd just have to decide whether the units are milliseconds, or whether to use the 16 bit formats that have already been discussed, etc. I have not yet studied whether or not the [manet] discussion is conformant with the specification in RFC 6551. Anyway, these details are not difficult technically. If we want to support non-additive metrics, some of the existing text will require revision. > PS. The draft for Intermediate RREP needs to be updated to > account for minor differences introduced by enabling > alternate metrics. > > Is that draft a WG draft, if not please advise, > > It is not a working group draft. It was pulled out of the base DYMO specification at the request of the LOADng team, because it is a feature unlikely to be supported by LOADng devices. If I remember correctly, this was suggested because if iRREP were in the main draft, they said there might be industry pressure for LOADng devices to support iRREP. I am fine to put iRREP back into the base specification, or to have it as a separate WG draft. -- Regards, Charlie P. From henning.rogge@fkie.fraunhofer.de Mon Dec 3 05:25:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F9F21F86F5 for ; Mon, 3 Dec 2012 05:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.721 X-Spam-Level: * X-Spam-Status: No, score=1.721 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_LOLITA1=1.865, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_PBL=0.905] 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 t3wCtBilD8r5 for ; Mon, 3 Dec 2012 05:25:56 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id EA03721F86CF for ; Mon, 3 Dec 2012 05:25:52 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TfW1u-0002sV-EM; Mon, 03 Dec 2012 14:25:50 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TfW1u-0005Tw-Bc; Mon, 03 Dec 2012 14:25:50 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 3 Dec 2012 14:25:50 +0100 Message-ID: <50BCA857.8070400@fkie.fraunhofer.de> Date: Mon, 3 Dec 2012 14:25:43 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> In-Reply-To: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080306060509070006060106" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/15671/Sun Dec 2 21:45:09 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 84e5304b03f4226ca8d53c11587376df Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 13:25:58 -0000 --------------ms080306060509070006060106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Charly, I tried to do a first DYMO review based on your new draft. I did not=20 looked into the protocol workings itself, but I still hope you will find = the input useful. > Mobile Ad hoc Networks Working Group C. Perkins > Internet-Draft Futurewei > Intended status: Standards Track I. Chakeres > Expires: June 4, 2013 CenGen Page 5: > AODVv2 Sequence Number (SeqNum) > An AODVv2 Sequence Number is an unsigned integer maintained by > each AODVv2 router. This sequence number guarantees the temporal > order of routing information to maintain loop-free routes. The > value zero (0) is reserved to indicate that the SeqNum for a > destination address is unknown. I still do not like this special value. > Handling Router (HandlingRtr) > HandlingRtr denotes the AODVv2 router handling an AODVv2 message. Do you really need the "HandlingRtr" abbreviation? It complicates the=20 text and does not shorten it that much. Page 6: > Originating Node (OrigNode) > Originating Router (OrigRtr) See comment to "HandlingRtr". > Router Client > An AODVv2 router may be configured with a list of other IP > addresses and networks which correspond to other non-router nodes > which require the services of the AODVv2 router for route > discovery and maintenance. An AODVv2 is always its own client, so > that the list of client IP addresses is never empty. > > Sequence Number (SeqNum) > Same as AODVv2 Sequence Number. If this is the same, why do you need "AODVv2 Sequence Number" ? Just use = "Sequence Number" > Target Node (TargNode) > The Target Node denotes the node for which a route is needed. > > Target Router (TargRtr) > The TargetRtr denotes the AODVv2 router which serves TargNode. TargRtr? TargetRtr? TargetRouter? Page 8: > +--------------------+-------------------------------------------+ > | Notation | Information Location and/or Meaning | > +--------------------+-------------------------------------------+ > | Route[DestAddr] | A route table entry towards DestAddr | > | Route[Addr]{field} | A field in a route table entry | > | -- | -- | > | RREQ.{field} | Field in RREQ | > | RREP.{field} | Field in RREP | > | RERR.{field} | Field in RERR | Maybe RREQ{field} to be costistent with the Route notation? > | -- | -- | > | MsgHdr | the RFC5444 Message Header | > | MsgTLV | an RFC5444 Message TLV | > | MetricTypeTLV | MetricType MsgTLV for Metric AddrTLV | > | MAL | MsgHdr. | Do you really need this abbreviation? > | -- | -- | > | AddrBlk | an RFC5444 address block | > | AddrBlk[1] | The first address slot in AddrBlk | > | AddrBlk[N] | The Nth address slot in AddrBlk | > | AddrBlk[OrigNode] | AddrBlk[1] | > | AddrBlk[TargNode] | AddrBlk[2] | Using the order of addresses in an address block as protocol semantics=20 is a bad idea. Use TLVs attached to the addresses to identify their purpo= se. > | AddrTLV | an RFC5444 address block TLV | Is this an address TLV block (a list of TLVs) or an address block TLV (a = single TLV) ? The following notation suggests its a TLV block. > | AddrTLV[1] | the first item in AddrTLV | > | AddrTLV[N] | the Nth item in AddrTLV | > | AddrTLV[OrigNode] | AddrTLV[1] | > | AddrTLV[TargNode] | AddrTLV[2] | Again, using the order of addresses as protocol semantics is a bad idea. = Use TLVs attached to the addresses to identify their purpose. > | HopCountTLV | Metric8 AddrTLV when MetricTypeTLV=3D3 | Defining an abbreviation for a TLV that depends on the value of a=20 different TLV is confusing. > | Metric8TLV | Metric8 AddrTLV | > | SeqNumTLV | Sequence Number TLV for AddrBlk addresses | > | RteAddrBlk | the main address block in a RteMsg | RteMsg ? Less abbreviations! > | RteSeqNumTLV | Sequence Numbers for RteAddrBlk addresses | > | UnreachAddrBlk | Unreachable Node AddrBlk in RERR | > | -- | -- | > | OrigRtr | RREQ Originating Router | > | OrigNode | Originating Node | > | RREQ_Gen | AODVv2 router originating an RREQ | > | RREP_Gen | AODVv2 router responding to an RREQ | > | RteMsg | either RREQ or RREP | > | RteMsg_Orig | Originator of a RteMsg | > | HandlingRtr | Handling Router | > | TargRtr | Target Router | > | TargNode | Target Node | > | UnreachableNode | Unreachable Node | > +--------------------+-------------------------------------------+ Page 10: > 5. Data Structures > > 5.1. Route Table Entry > > The route table entry is a conceptual data structure. > Implementations may use any internal representation so long as it > provides access to the same information as specified below. > > Conceptually, a route table entry has the following fields: > > Route.Address > The (host or network) destination address of the node(s) > associated with the routing table entry > > Route.PfxLen Another confusing abbreviation. > The value is the length of the netmask/prefix. If the value of > the Route.PfxLen is nonzero and different than the length of only if non-zero? How does AODVv2 represents a "full internet" route=20 like 0.0.0.0/0 ? > addresses in the address family used by the AODVv2 routers, the > associated address is a routing prefix, rather than a host > address. Page 12: > Timed > The expiration of a Timed route is controlled by the > Route.ExpirationTime time of the route table entry, not > MAX_IDLETIME. Until that time, a Timed route can be used for > forwarding packets. Afterwards, the route must be Expired (or > expunged). > > The route's state determines the operations that can be performed on > the route table entry. During use, an Active route is maintained > continuously by AODVv2 and is considered to remain active as long as > it is used at least once during every ACTIVE_INTERVAL. When a route > is no longer Active, it becomes an Idle route. After a route remains > Idle for MAX_IDLETIME, it becomes an Expired route; after that, the > route is not used for forwarding, but the sequence number information > can be maintained until the destination sequence number has had no > updates for MAX_SEQNUM_LIFETIME. After MAX_SEQNUM_LIFETIME, old > sequence number information is considered no longer valuable and the > route is expunged. > > MAX_SEQNUM_LIFETIME is the time after a reboot during which an AODVv2 Is MAX_SEQNUM_LIFETIME different to a "Validity Time" ? > router MUST NOT transmit any routing messages. Thus, if all other > AODVv2 routers expunge routes to the rebooted router after that time > interval, the rebooted AODVv2 router's sequence number will not be > considered stale by any other AODVv2 router in the MANET. > > When the link to a route's next hop is broken, the route is marked as > being Broken, and the route may no longer be used. > > 5.2. Bidirectional Connectivity During Route Discovery and Blacklists= > > To avoid repeated failure of Route Discovery, an AODVv2 router > (HandlingRtr) handling a RREP message MAY attempt to verify Another unnecessary abbreviation Page 13: > BlacklistNode > The IP address of the node that did not verify bidirectional > connectivity. Blacklist.Node ? > BlacklistRmTime > The time at which BlacklistNode will be removed from the > blacklist. Blacklist.RemoveTime ? > 5.4. AODVv2 Packet Header Fields and Information Elements > > In its default mode of operation, AODVv2 uses the UDP port 269 > [RFC5498] to carry protocol packets. In addition, IP Protocol Number > 138 has been reserved for MANET protocols [RFC5498]. Most AODVv2 > messages are sent with the IP destination address set to the link- You mean packets, not messages? Page 14: > manually configured router adjacencies, or in order to improve > robustness. > > The IPv4 TTL (IPv6 Hop Limit) field for all packets containing AODVv2 > messages is set to 255. If a packet is received with a value other I think (if we keep this at all) this should move to "security=20 considerations". > than 255, any AODVv2 message contained in the packet MUST be > disregarded by AODVv2. This mechanism, known as "The Generalized TTL > Security Mechanism" (GTSM) [RFC5082] helps to assure that packets > have not traversed any intermediate routers. I do not agree with this MUST. > IP packets containing AODVv2 protocol messages SHOULD be given > priority queuing and channel access. > > AODVv2 messages are transmitted in packets that conform to the packet > and message format described in [RFC5444]. Here is a brief > description of the format. > > A packet formatted according to RFC5444 contains zero or more > messages. > > A message contains a message header, message TLV block, and zero > or more address blocks. > > Each address block may also have associated TLV blocks. "have one associated TLV block" (one per address block). > If a packet contains only a single AODVv2 message and no packet TLVs, > it need not include a packet-header [RFC5444]. This is wrong and breaks ALL RFC5444 compatibility. You MUST put the=20 minimal Packet-Header in front of the first message (which is a single 0 = octet). > The length of an > address (32 bits for IPv4 and 128 bits for IPv6) inside an AODVv2 > message is indicated by the msg-addr-length (MAL) in the msg-header, > as specified in [RFC5444]. > > When multiple messages are aggregated into a single packet according > to RFC 5444 formatting, and the aggregation of messages is also > authenticated (e.g., with IPsec), it becomes unfeasible to delete > individual messages. Packet signatures are "link scope" because packets should not be=20 forwarded with RFC5444. If you want to forward some/all messages, you=20 can generate a new packet signature. Page 15: > An AODVv2 router SHOULD maintain OwnSeqNum in persistent storage. If > an AODVv2 router's OwnSeqNum is lost, it MUST take the following > actions to avoid the danger of routing loops. First, the AODVv2 > router MUST invalidate all route table entries, by setting > Route.Broken for each entry. Furthermore the AODVv2 router MUST wait > for at least MAX_SEQNUM_LIFETIME before transmitting or MAX_SEQNUM_LIFETIME looks more and more like a typical validity time. Page 16: > Generally, HopCount may still be considered the default metric for > use in MANETs, notwithstanding the above objections. Each metric has > to have a Metric Type, and the Metric Type is allocated by IANA as > specified in [RFC6551]. Each Route has to include the Metric Type as > part of the route table entry for that route. Hop Count has Metric > Type assignment 3. The Cost of a route using Metric Type 3 is > naturally the Hop Count between the router and the destination. For > routes R1 and R2 using Metric Type 3, LoopFree (R1, R2) is TRUE when > Cost(R2) <=3D (Cost(R1) + 1). The specification of Cost(R) and Cost(R2) < Cost(R1) ? > LoopFree(R1,R2) for metric types other than 3 is beyond the scope of > this document. Could the Cost() function be used locally to calculate the original link = cost, so that it doesn't need to be considered anymore when receiving=20 and processing messages ? Page 19: > o If RteMsg.VALIDITY_TIME is not included, then > Route.ExpirationTime :=3D MAXTIME, otherwise Route.ExpirationTime :=3D= > Current_Time + RteMsg.VALIDITY_TIME How does the VALIDITY_TIME relate to the MAX_SEQNUM_LIFETIME ? Page 21/22: > 7.2. RteMsg Structure > > RteMsgs have the following general format: > > +---------------------------------------------------------------+ > | RFC 5444 Packet Header | > +---------------------------------------------------------------+ This is not part of the Message. > | RFC 5444 Message Header | > +---------------------------------------------------------------+ > | RFC 5444 MsgHdr, opt. DestOnly TLV, opt. MetricTypeTLV | I would suggest using an optional Extension Type for the Metric TLV=20 instead of the MetricTypeTLV. > +---------------------------------------------------------------+ > | RteAddrBlk {[1]:=3DRREQ.OrigNode,[2]:=3DRREQ.TargNode)} | > +---------------------------------------------------------------+ > | RteSeqNumTLV (OrigRtr.Seqnum, TargNode.Seqnum) | > +---------------------------------------------------------------+ Not clear to which addresses these TLVs belong. > | Added Node Address Block (Optional) | > +---------------------------------------------------------------+ A second address block? Couldn't these be inside the first address block = too? > | Added Node Address TLV (SeqNum) | > +---------------------------------------------------------------+ > | Added Node Address TLV (Metric[MetricType]) | > +---------------------------------------------------------------+ I am not sure if the diagram above is really helpful understanding what=20 a message looks like. Page 23: > 7.3. RREQ Generation > > RREQ_Gen generates the RREQ according to the following steps, with > order of protocol elements illustrated schematically in Figure 1. > > 1. RREQ_Gen MUST increment its OwnSeqNum by one (1) according to the > rules specified in Section 5.5. This assures that all nodes with > existing routing information will use RREQ_Gen's new information > to update existing routing table information. > > 2. OrigNode MUST be a unicast address. If RREQ_Gen is not OrigNode, > then OwnSeqNum will be used as the value of OrigNode.SeqNum. will > be used by AODVv2 routers to create a route toward the OrigNode, > enabling a RREP from TargRtr, and eventually used for proper > forwarding of data packets. > > 3. If RREQ_Gen requires that only TargRtr is allowed to generate a > RREP, then RREQ_Gen includes the "Destination RREP Only" TLV as > part of the RFC 5444 message header. This also assures that > TargRtr increments its sequence number. Otherwise, intermediate > AODVv2 routers MAY respond to the RREQ_Gen's RREQ if they have an > valid route to TargNode (see Section 13.2). > > 4. msg-hopcount MUST be set to 0. > > * This RFC 5444 constraint causes the typical RteMsg payload > incur additional enlargement. There is no constraint in RFC5444 to add this field to a message. Unless = you plan to use it. Page 24: > 7. RREQ_Gen adds OrigNode.Addr, its prefix, and the RREQ_Gen.SeqNum > (OwnSeqNum) to the RREQ. > > 8. If OrigNode.Metric is included it is set to the cost of the route > between OrigNode and RREQ_Gen. > > An example RREQ message format is illustrated in Appendix A.1. > > 7.4. RREP Generation > > An AODVv2 router (TargRtr, called in this section RREP_Gen) generates > a RREP in order to provide a route to the Target Node (TargNode) of a > RREQ, thus satisfying the routing requirement for packets to flow > between OrigNode and TargNode. This section specifies the generation > of an RREP by the RREP_Gen. The basic format of an RREP conforms to > the structure for RteMsgs as illustrated in Figure 1. Optionally, > RREP messages may be generated by AODVv2 routers other than TargRtr; > this optional message generation is known as "Intermediate RREP" > generation, and is specified in Internet Draft [I-D.perkins-irrep]. > If TargNode is not a unicast IP address the RREP MUST NOT be > generated, and processing for the RREQ is complete. > > Otherwise RREP_Gen generates the RREP as follows: > > 1. RREP_Gen first uses the routing information to update its route > table entry for OrigNode if necessary as specified in > Section 6.2. > > 2. RREP_Gen MUST increment its OwnSeqNum by one (1) according to > the rules specified in Section 5.5. > > 3. RREP.AddrBlk[OrigNode] :=3D RREQ.AddrBlk[OrigNode] > > 4. RREP.AddrBlk[TargNode] :=3D RREQ.AddrBlk[TargNode] > > 5. RREP.SeqNumTLV[OrigNode] :=3D RREQ.SeqNumTLV[OrigNode] > > 6. RREP.SeqNumTLV[TargNode] :=3D OwnSeqNum > > 7. If Route[TargNode].PfxLen/8 is equal to the number of bytes in > the addresses of the RREQ (4 for IPv4, 16 for IPv6), then no > is included with the iRREP. Otherwise, > RREP.PfxLen[TargNode] :=3D RREQ.PfxLen[TargNode] according to the > rules of RFC 5444 AddrBlk encoding. Isn't this "full prefix length can be skipped" an explicit part of the=20 RFC 5444 description? I do not think you need to worry about this here,=20 its the choice of the implementation if it want to use=20 ahassingle/ahasmulti both 0 or not. Page 28: > 8.3. RERR Generation > > An RERR message is generated by a AODVv2 router (in this section, > called RERR_Gen) in order to to notify upstream routers that packets > cannot be delivered to certain destinations. An RERR message has the > following general structure: > > +---------------------------------------------------------------+ > | RFC 5444 Packet Header | > +---------------------------------------------------------------+ Not part of the message. Page 29: > Message Header > RFC 5444 MsgHdr may contain the following options: > > * > > * > > * PktSource MsgTLV Message-TLVs are not part of the RFC5444 message header. Page 32: > 10. Simple Internet Attachment > > Simple Internet attachment means attachment of a stub (i.e., non- > transit) network of AODVv2 routers to the Internet via a single > Internet AODVv2 router (called IAR). maybe just call it (Internet) Gateway instead of IAR? > As in any Internet-attached network, AODVv2 routers, and their > clients, wishing to be reachable from hosts on the Internet MUST have > IP addresses within the IAR's routable and topologically correct > prefix (e.g. 191.0.2.0/24). > > The IAR is responsible for generating RREQ messages to find nodes > within the MANET on behalf of nodes on the Internet, as well as > responding to route requests from the AODVv2 MANET on behalf of the > nodes on the Internet. Its not allowed to have two gateways to the Internet for an AODVv2 MANET?= Page 40: > +------------------------+-----------+------------------------------+ > | Name | Value | Description | > +------------------------+-----------+------------------------------+ > | MAX_HOPCOUNT | 20 hops | This value MUST be larger | > | | | than the AODVv2 network | > | | | diameter. Otherwise, | > | | | routing messages may not | > | | | reach their intended | > | | | destinations. | What is the reason to make this less than 255 in the default case? > | MTU | TBD -- | Determines the maximum | > | | depends | number of RFC 5444 AddrBlk | > | | on | entries | > | | address | | > | | family | | > +------------------------+-----------+------------------------------+ This description is either unnecessary (if you mean MTU as in "interface = maximum transfer unit") or confusing. > Table 4: Default Parameter Values > > In addition to the above parameters and timing values, several > administrative options exist. These options have no influence on > correct routing behavior, although they may potentially reduce AODVv2 > protocol messaging in certain situations. The default behavior is to > NOT enable any of these options; and although many of these options > can be administratively controlled, they may be better served by > intelligent control. The following table enumerates several of the > options. > > +-------------------------+-----------------------------------------+ > | Name | Description | > +-------------------------+-----------------------------------------+ > | APPEND_INFORMATION | Whether or not appending routing | > | | information for AddedNodes to a RteMsg | > | | is enabled. | This is a "strange" default value. Page 41: > | CONTROL_TRAFFIC_LIMIT | TBD [50 msgs/sec?] | > +-------------------------+-----------------------------------------+ Packets per second? Page 42: > | Packet source IP | 12 - | 4 or | Provides the IP address for | > | address | TBD | 16 | RERR messages generated due | > | (PktSource) | | octets | to inability to deliver a | > | | | | packet. | I remember that there were some concerns putting addresses into TLVs=20 when we talked about DLEP in April. > | Metric Type | 13 - | 1 | Type of metric in the Metric8 | > | | TBD | octet | or Metric16 AddrTLV. | > +-------------------+------+--------+-------------------------------+ As I said before, I would remove this TLV completely. > Table 7: Message TLV Types > > 15.3. Address Block TLV Specification The types collide with your allocation in chapter 15.2, which was called = "Message and Address Block TLV Type Specification". > +---------------+------------+----------+---------------------------+ > | Name | Type | Length | Value | > +---------------+------------+----------+---------------------------+ > | VALIDITY_TIME | 1[RFC5497] | 1 octet | The maximum amount of | > | | | | time that information can | > | | | | be maintained before | > | | | | being deleted. The | > | | | | VALIDITY_TIME TLV is | > | | | | defined in [RFC5497]. | > | | | | -- | > | Sequence | 10 - TBD | 2 octets | The latest AODVv2 | > | Number | | | sequence number | > | (SeqNum) | | | associated with the | > | | | | address. | > | Metric8 | 11 - TBD | 1 octet | 8-bit Cost of the route | > | | | | to reach the destination | > | | | | address. | > | Metric16 | 12 - TBD | 2 octets | 16-bit Cost of the route | > | | | | to reach the destination | > | | | | address. | > +---------------+------------+----------+---------------------------+ Why not just one Metric TLV which can have a length of 1-2 ? You have an = explicit length field in the message anyways. > Table 8: Address Block TLV (AddrTLV) Types > > The same number space should be used for both Metric8 and Metric16 > metric types. > > 15.4. Metric Type Number Allocation "Metric TLV Extension Types Allocation" ? > Metric types are identified according to the assignments as specified > in [RFC6551]. The metric type of the Hop Count metric is assigned to > be 3, in order to maintain compatibility with that existing table of > values from RFC 6551. If non-additive metrics are to be used, the > specification for assessing the usability of route updates (see > Section 6.1 ) may require changes. "non-addititve metrics are not supported in this draft" ? Page 43: > +-----------------------+----------+-----------+ > | Name | Type | Size | > +-----------------------+----------+-----------+ > | Reserved | 0 | Undefined | Why is 0 reserved? 0 would be the Extension type that can skip the=20 additional byte in the TLV. > | Unallocated | 1 -- 2 | TBD | > | Hop Count | 3 - TBD | 1 octet | > | Unallocated | 4 -- 254 | TBD | > | Reserved | 255 | Undefined | > +-----------------------+----------+-----------+ > > Table 9: Metric Types Page 47: > Appendix A. Example RFC 5444-compliant packet formats > > The following three subsections show example RFC 5444-compliant > packets for AODVv2 message types RREQ, RREP, and RERR. These > proposed message formats are designed based on expected savings from > IPv6 addressable MANET nodes, and a layout for the Address TLVs that > may be viewed as natural, even if perhaps not the absolute most > compact possible encoding. > > For RteMsgs, the msg-hdr fields are followed by at least one and > optionally two Address Blocks. The first AddrBlk contains OrigNode > and TargNode. For each AddrBlk, there must be AddrTLVs of type > Seqnum and of type Metric. You should be able to parse any number of address blocks. Page 48: > A.1. RREQ Message Format > > The figure below illustrates a packet format for an example RREQ > message. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PV=3D0 | PF=3D0 | msg-type=3DRREQ | MF=3D4 | MAL=3D3 | msg-size=3D= 24 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ msg-size =3D 28 ? > | msg-size=3D24 | msg-hop-limit | msg.tlvs-length=3D0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | num-addr=3D2 |1|0|0|0|0| Rsv | head-length=3D3 |Head(Orig&Targ)| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Head (bytes for Orig & Target)| Orig.Tail | Target.Tail | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | addr.tlvs-length=3D11 | type=3DSeqNum |0|1|0|1|0|0|Rsv| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Index-start=3D0 | tlv-length=3D2 | Orig.Node Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | type=3DSeqNum |0|1|0|1|0|0|Rsv| Index-start=3D0 | tlv-length=3D1 = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ type =3D Metric-TLV ? > | OrigNodeHopCt | > +-+-+-+-+-+-+-+-+ > RREQ with SeqNum and Metric AddrTLVs added, and: - two addresses in > Address Block - address length =3D 4 [IPv4], shared initial bytes =3D = 3 - > Sequence Number available only for Orig.Node in addr.tlv - Hop Count > available only for Orig.Node in Metric8 AddrTLV - Addresses stored in > the order OrigNode, TargNode Page 49: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PV=3D0 | PF=3D0 | msg-type=3DRERR | MF=3D4 | MAL=3D3 | msg-size=3D= 25 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | msg-size=3D25 | msg-hop-limit | msg.tlvs-length=3D0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | num-addr=3D2 |1|0|0|0|0| Rsv | head-length=3D3 |Head(Two Dests)| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Head (for both destinations) | Tail(Dest_1) | Tail(Dest_2) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | addr.tlvs-length=3D8 | type=3DSeqNum |0|1|0|1|0|0|Rsv| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If these sequence numbers are one for each destination, the TLV is wrong.= It doesn't need the Index-start (because it will explicitly refer to all = addresses in the block), but it needs the tismultivalue flag. In=20 addition to this the length of the TLV must be 4. > | Index-start=3D0 | tlv-length=3D2 | Dest_1 Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Dest_2 Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > RERR with - Two Unreachable Node address in Address Block - address > length =3D 4 [IPv4], shared initial bytes =3D 3 - Two Sequence Numbers= > available in addr.tlv - Addresses stored from Originator to Target Page 50: > A.4. RREP_ACK Message Format > > The figure below illustrates a packet format for an example RREP_ACK > message. > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PV=3D0 | PF=3D0 |msg-type=3DRREPAk| MF=3D0 | MAL=3D3 | msg-size=3D= 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | msg-size=3D3 | > +-+-+-+-+-+-+-+-+ msg-size =3D 4 ? Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms080306060509070006060106 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEyMDMxMzI1NDdaMCMGCSqGSIb3DQEJBDEWBBTtjw/abvZxs4Zb7EGU7fjSECyQHTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAgXoCJMWFHyyYxGkGWyrm14QofAS7SCBlwPE+3dYfnlDj m396Od5/gc2OCMeQ8KBGJNxkEdvjVgiN/5hpqclFCUyKdgucETPMI3PM8127PFT94IvPnSFG skY6A5hMzBL6VlvnYYMpnxjvkc2OJGhciFviNuFTdDLyDop2+2SmaFFYMT0q3h3jjY58r0YA VPeSoR+OOH1NWyQCZH9Du36130Bkv2hDXG1WlYBW2CT3pdZvVBuOKy31EuIOH6Fb1PBlFUsW fNu8FoB7Z7qx3NlBi3bmGectFTQcynt+NdnJuBuk0Rz2K9Wh6fbRzE/kXj1lPJgDmt3OIwGn Pj8DhN5tZAAAAAAAAA== --------------ms080306060509070006060106-- From Chris.Dearlove@baesystems.com Mon Dec 3 05:31:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2852221F846B for ; Mon, 3 Dec 2012 05:31:18 -0800 (PST) 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 GGLvHrEQlnFc for ; Mon, 3 Dec 2012 05:31:17 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 5F88821F849A for ; Mon, 3 Dec 2012 05:31:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,206,1355097600"; d="scan'208";a="291019909" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 03 Dec 2012 13:31:16 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qB3DVGrL024863 for ; Mon, 3 Dec 2012 13:31:16 GMT X-IronPort-AV: E=Sophos;i="4.84,206,1355097600"; d="scan'208";a="243184" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds017.greenlnk.net with ESMTP; 03 Dec 2012 13:31:16 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Mon, 3 Dec 2012 13:31:16 +0000 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-24.txt Thread-Index: AQHNz3PdizJJy8YTn0ujf7TOKm3zcZgHFHyAgAAAlyA= Date: Mon, 3 Dec 2012 13:31:15 +0000 Message-ID: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> In-Reply-To: <50BCA857.8070400@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 13:31:18 -0000 >> | MAL | MsgHdr. | > Do you really need this abbreviation? That's directly from 5444, where it is used in a picture as it's a 4 bit fi= eld that needed a 7 absolute maximum. 5 preferred maximum, character abbrev= iation. (I haven't yet looked at the draft myself, and am not sure when exactly I'l= l get the time.) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Mon Dec 3 05:38:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805D921F8596 for ; Mon, 3 Dec 2012 05:38:20 -0800 (PST) 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 vZ4Mc5IcZwJM for ; Mon, 3 Dec 2012 05:38:20 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id B21EC21F8500 for ; Mon, 3 Dec 2012 05:38:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,206,1355097600"; d="scan'208";a="246949415" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 03 Dec 2012 13:38:09 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qB3Dc8fY006388 for ; Mon, 3 Dec 2012 13:38:08 GMT X-IronPort-AV: E=Sophos;i="4.84,206,1355097600"; d="scan'208";a="30623" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 03 Dec 2012 13:38:07 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0309.002; Mon, 3 Dec 2012 13:38:08 +0000 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-24.txt Thread-Index: AQHNz3PdizJJy8YTn0ujf7TOKm3zcZgHFHyAgAABzKA= Date: Mon, 3 Dec 2012 13:38:08 +0000 Message-ID: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> In-Reply-To: <50BCA857.8070400@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 13:38:20 -0000 > > If a packet contains only a single AODVv2 message and no packet TLVs, > > it need not include a packet-header [RFC5444]. > This is wrong and breaks ALL RFC5444 compatibility. You MUST put the > minimal Packet-Header in front of the first message (which is a single 0 > octet). Henning is right that you can't drop the packet header. But I don't exactly agree with the way to present this fact. If using 5444, in particular on the manet UDP port/IP protocol, the packet header is outside the remit of AODVv2. You can say that AODVv2 provides instructions that it should include something, and you can say that if something is present then AODVv2 can use it. But that's about it. It's actually misleading to include any further packet information in the draft. I think NHDP and OLSRv2 provide models of this, though I haven't checked their wording before sending this. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From charliep@computer.org Mon Dec 3 06:51:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3CB21F86C3 for ; Mon, 3 Dec 2012 06:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6] 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 zJMODP+5axvv for ; Mon, 3 Dec 2012 06:51:50 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id A3D8D21F8443 for ; Mon, 3 Dec 2012 06:51:50 -0800 (PST) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TfXN7-0000Ei-DI; Mon, 03 Dec 2012 09:51:49 -0500 Message-ID: <50BCBC7A.1080904@computer.org> Date: Mon, 03 Dec 2012 06:51:38 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Henning Rogge References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> In-Reply-To: <50BCA857.8070400@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8629ba96355d51d277cb546095327781a5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 14:51:52 -0000 Hello Henning, Your review is much appreciated. Just a few follow-up comments for now, more later: On 12/3/2012 5:25 AM, Henning Rogge wrote: > > > > AODVv2 Sequence Number (SeqNum) > > An AODVv2 Sequence Number is an unsigned integer maintained by > > each AODVv2 router. This sequence number guarantees the temporal > > order of routing information to maintain loop-free routes. The > > value zero (0) is reserved to indicate that the SeqNum for a > > destination address is unknown. > > I still do not like this special value. Whether the special value is needed depends on how the SeqNum TLV is defined. Since Address TLVs are constrained to have the same "cardinality" as the Address Block they refer to, but the SeqNum is often unknown for one of the addresses in the Block, there seems to be a need for a SeqNum value that isn't a legal SeqNum value. > > > Handling Router (HandlingRtr) > > HandlingRtr denotes the AODVv2 router handling an AODVv2 message. > > Do you really need the "HandlingRtr" abbreviation? It complicates the > text and does not shorten it that much. The debate on the proper mix of abbreviations versus fully expanded terminology is difficult to resolve to everyone's satisfaction. The new AODVv2 specification uses "more descriptive" abbreviations and is, I hope, a lot easier to understand. Expanding *all* abbreviations can have the effect of making the descriptions seem overly verbose. I'll be happy to do whatever makes the most people happy. I am O.K. with expanding this abbreviation and others in the document, as long as people agree it makes the document easier to understand. As a sort of "counter-example", usually in physics we see formulas such as "F = ma^2" instead of "Force equals the product of the mass and the square of the acceleration". This seems obvious to you and me, but for some people it's not at all obvious (e.g., what is F and what does it have to do with ma {my mother!}?). Abbreviations have the following advantages: - The abbreviated term is suddenly outside the domain of verbose natural language and is instead distinguished as an important term (e.g., protocol element) - Abbreviations, used properly, enable more compact representations of formulaic information (e.g., as in the assignment statements). A new abbreviation is a universal source of discomfort. Perhaps after a little more time, you might feel comfortable with some of the abbreviations that are used with AODVv2. I've been reading the document with them for several weeks now and they feel quite natural to me. I'm pretty sure you wouldn't want to expand all uses of, say, MPR in OLSRv2. Anyway, there are at least two sides of this issue and I'd hope some people might find the abbreviations to be an improvement. > > > Sequence Number (SeqNum) > > Same as AODVv2 Sequence Number. > > If this is the same, why do you need "AODVv2 Sequence Number" ? Just > use "Sequence Number" Check. However, I thought that the way Sequence Numbers were used here could be properly understood by relating their use model to that of AODV. > > > > | -- | -- | > > | AddrBlk | an RFC5444 address block | > > | AddrBlk[1] | The first address slot in AddrBlk | > > | AddrBlk[N] | The Nth address slot in AddrBlk | > > | AddrBlk[OrigNode] | AddrBlk[1] | > > | AddrBlk[TargNode] | AddrBlk[2] | > > Using the order of addresses in an address block as protocol semantics > is a bad idea. Use TLVs attached to the addresses to identify their > purpose. But this is the same way that Prefix Lengths are used to associate additional information to the addresses in and Address Block.. > > > | AddrTLV | an RFC5444 address block TLV | > > Is this an address TLV block (a list of TLVs) or an address block TLV > (a single TLV) ? It was meant to denote a single address block TLV. In all cases that are specified in AODVv2, there is one TLV value per address in the Address Block. > > The following notation suggests its a TLV block. > > > | AddrTLV[1] | the first item in AddrTLV | > > | AddrTLV[N] | the Nth item in AddrTLV | > > | AddrTLV[OrigNode] | AddrTLV[1] | > > | AddrTLV[TargNode] | AddrTLV[2] | > > Again, using the order of addresses as protocol semantics is a bad > idea. Use TLVs attached to the addresses to identify their purpose. This would necessitate a N single address blocks for N addresses, along with N Address Block TLVs. That sounds like a bad idea to me. And, really, I have no idea why it is bad. > > > Route.PfxLen > > Another confusing abbreviation. See above... Would you prefer Route.PrefixLength? > > The value is the length of the netmask/prefix. If the value of > > the Route.PfxLen is nonzero and different than the length of > > only if non-zero? How does AODVv2 represents a "full internet" route > like 0.0.0.0/0 ? AODVv2 does not represent that route, and it's explicitly defined to be an inadmissible value for AODVv2. However, this can be changed so that, say, 255 is the admissible value. > > > MAX_SEQNUM_LIFETIME is the time after a reboot during which an AODVv2 > > Is MAX_SEQNUM_LIFETIME different to a "Validity Time" ? After Validity Time, a route is invalid, but the sequence number information is still valid. After MAX_SEQNUM_LIFETIME, the sequence number information is no longer valid and must be expunged. > > > 5.4. AODVv2 Packet Header Fields and Information Elements > > > > In its default mode of operation, AODVv2 uses the UDP port 269 > > [RFC5498] to carry protocol packets. In addition, IP Protocol Number > > 138 has been reserved for MANET protocols [RFC5498]. Most AODVv2 > > messages are sent with the IP destination address set to the link- > > You mean packets, not messages? Check. > > Page 14: > > > manually configured router adjacencies, or in order to improve > > robustness. > > > > The IPv4 TTL (IPv6 Hop Limit) field for all packets containing AODVv2 > > messages is set to 255. If a packet is received with a value other > > I think (if we keep this at all) this should move to "security > considerations". I am O.K. with that. > > > than 255, any AODVv2 message contained in the packet MUST be > > disregarded by AODVv2. This mechanism, known as "The Generalized TTL > > Security Mechanism" (GTSM) [RFC5082] helps to assure that packets > > have not traversed any intermediate routers. > > I do not agree with this MUST. Can you say more about why you disagree? > > > IP packets containing AODVv2 protocol messages SHOULD be given > > priority queuing and channel access. > > > > AODVv2 messages are transmitted in packets that conform to the packet > > and message format described in [RFC5444]. Here is a brief > > description of the format. > > > > A packet formatted according to RFC5444 contains zero or more > > messages. > > > > A message contains a message header, message TLV block, and zero > > or more address blocks. > > > > Each address block may also have associated TLV blocks. > > "have one associated TLV block" (one per address block). It is permissible to have more than one TLV block per address block, right? > > > If a packet contains only a single AODVv2 message and no packet TLVs, > > it need not include a packet-header [RFC5444]. > > This is wrong and breaks ALL RFC5444 compatibility. You MUST put the > minimal Packet-Header in front of the first message (which is a single > 0 octet). Oops, that's what I meant to say :-) > > > The length of an > > address (32 bits for IPv4 and 128 bits for IPv6) inside an AODVv2 > > message is indicated by the msg-addr-length (MAL) in the msg-header, > > as specified in [RFC5444]. > > > > When multiple messages are aggregated into a single packet according > > to RFC 5444 formatting, and the aggregation of messages is also > > authenticated (e.g., with IPsec), it becomes unfeasible to delete > > individual messages. > > Packet signatures are "link scope" because packets should not be > forwarded with RFC5444. If you want to forward some/all messages, you > can generate a new packet signature. That's also approximately what I intended to say. > > > Page 16: > > > Generally, HopCount may still be considered the default metric for > > use in MANETs, notwithstanding the above objections. Each metric has > > to have a Metric Type, and the Metric Type is allocated by IANA as > > specified in [RFC6551]. Each Route has to include the Metric Type as > > part of the route table entry for that route. Hop Count has Metric > > Type assignment 3. The Cost of a route using Metric Type 3 is > > naturally the Hop Count between the router and the destination. For > > routes R1 and R2 using Metric Type 3, LoopFree (R1, R2) is TRUE when > > Cost(R2) <= (Cost(R1) + 1). The specification of Cost(R) and > > Cost(R2) < Cost(R1) ? For Hop Count, it turns out that you can add one and still have loop freedom. > > > LoopFree(R1,R2) for metric types other than 3 is beyond the scope of > > this document. > > Could the Cost() function be used locally to calculate the original > link cost, so that it doesn't need to be considered anymore when > receiving and processing messages ? Well, that's about what would happen in reality. > > > Page 21/22: > > > 7.2. RteMsg Structure > > > > RteMsgs have the following general format: > > > > +---------------------------------------------------------------+ > > | RFC 5444 Packet Header | > > +---------------------------------------------------------------+ > > This is not part of the Message. O.K. I am happy to leave that out, or else I can say "Packets containing a RteMsg", whichever people think is more clear. > > +---------------------------------------------------------------+ > > | RteAddrBlk {[1]:=RREQ.OrigNode,[2]:=RREQ.TargNode)} | > > +---------------------------------------------------------------+ > > | RteSeqNumTLV (OrigRtr.Seqnum, TargNode.Seqnum) | > > +---------------------------------------------------------------+ > > Not clear to which addresses these TLVs belong. They belong to the preceding address block, as it's described in RFC 5444 (to my understanding). > > > | Added Node Address Block (Optional) | > > +---------------------------------------------------------------+ > > A second address block? Couldn't these be inside the first address > block too? Yes, I could define an address block with special meaning for the first two addresses that are different than the rest of the addresses. I thought that would be considerably more complicated to understand, especially as including the rest of the addresses is an optional feature from a long time ago. > > > | Added Node Address TLV (SeqNum) | > > +---------------------------------------------------------------+ > > | Added Node Address TLV (Metric[MetricType]) | > > +---------------------------------------------------------------+ > > I am not sure if the diagram above is really helpful understanding > what a message looks like. I hope it seems more helpful after a few more days consideration. Or if you have suggestion on how to make it better I will be happy to try something new. > > > 4. msg-hopcount MUST be set to 0. > > > > * This RFC 5444 constraint causes the typical RteMsg payload > > incur additional enlargement. > > There is no constraint in RFC5444 to add this field to a message. > Unless you plan to use it. The constraint is that it has to be set to zero, if it's included. I understand why the constraint was made, but I don't agree that the constraint is needed. However, I am not right now trying to propose changes to RFC 5444. > > Simple Internet attachment means attachment of a stub (i.e., non- > > transit) network of AODVv2 routers to the Internet via a single > > Internet AODVv2 router (called IAR). > > maybe just call it (Internet) Gateway instead of IAR? O.K. Ian had abbreviated it, but I am O.K. with your suggestion. > > > As in any Internet-attached network, AODVv2 routers, and their > > clients, wishing to be reachable from hosts on the Internet MUST have > > IP addresses within the IAR's routable and topologically correct > > prefix (e.g. 191.0.2.0/24). > > > > The IAR is responsible for generating RREQ messages to find nodes > > within the MANET on behalf of nodes on the Internet, as well as > > responding to route requests from the AODVv2 MANET on behalf of the > > nodes on the Internet. > > Its not allowed to have two gateways to the Internet for an AODVv2 MANET? I will think about that. > > Page 40: > > > +------------------------+-----------+------------------------------+ > > | Name | Value | Description | > > +------------------------+-----------+------------------------------+ > > | MAX_HOPCOUNT | 20 hops | This value MUST be larger | > > | | | than the AODVv2 network | > > | | | diameter. Otherwise, | > > | | | routing messages may not | > > | | | reach their intended | > > | | | destinations. | > > What is the reason to make this less than 255 in the default case? Because the AODVv2 messages aren't going to be traversing hundreds of hops in any imaginable future AODVv2 network. > > > | MTU | TBD -- | Determines the maximum | > > | | depends | number of RFC 5444 AddrBlk | > > | | on | entries | > > | | address | | > > | | family | | > > +------------------------+-----------+------------------------------+ > > This description is either unnecessary (if you mean MTU as in > "interface maximum transfer unit") or confusing. I am O.K. to leave this out. Maybe it can go in the Terminology section and cite a relevant RFC. > > > > > > +-------------------------+-----------------------------------------+ > > | Name | Description | > > +-------------------------+-----------------------------------------+ > > | APPEND_INFORMATION | Whether or not appending routing | > > | | information for AddedNodes to a RteMsg | > > | | is enabled. | > > This is a "strange" default value. You're right :-) > > Page 41: > > > | CONTROL_TRAFFIC_LIMIT | TBD [50 msgs/sec?] | > > +-------------------------+-----------------------------------------+ > > Packets per second? O.K. > > Page 42: > > > | Packet source IP | 12 - | 4 or | Provides the IP address for | > > | address | TBD | 16 | RERR messages generated due | > > | (PktSource) | | octets | to inability to deliver a | > > | | | | packet. | > > I remember that there were some concerns putting addresses into TLVs > when we talked about DLEP in April. Well, the information has to go somewhere. I could define a new "type" of Address Block, or Address Block with one Address and new TLV type. These are all more and more verbose (bloated?) ways of going about imparting the same information. I admit that I get tired of seeing message size grow and grow for reasons that don't really make very much sense to me. Should I look up the DLEP discussion from April, or do you happen to remember what the objection was? > > > Metric types are identified according to the assignments as specified > > in [RFC6551]. The metric type of the Hop Count metric is assigned to > > be 3, in order to maintain compatibility with that existing table of > > values from RFC 6551. If non-additive metrics are to be used, the > > specification for assessing the usability of route updates (see > > Section 6.1 ) may require changes. > > "non-addititve metrics are not supported in this draft" ? O.K... > > > For RteMsgs, the msg-hdr fields are followed by at least one and > > optionally two Address Blocks. The first AddrBlk contains OrigNode > > and TargNode. For each AddrBlk, there must be AddrTLVs of type > > Seqnum and of type Metric. > > You should be able to parse any number of address blocks. Do you mean to suggest that a protocol cannot define messages that have specific meanings for the address blocks it uses? -- Regards, Charlie P. From Chris.Dearlove@baesystems.com Mon Dec 3 07:19:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59C621F846B for ; Mon, 3 Dec 2012 07:19:08 -0800 (PST) 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 0MVupqdgRc7Z for ; Mon, 3 Dec 2012 07:19:08 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id ECF1021F85E2 for ; Mon, 3 Dec 2012 07:19:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,208,1355097600"; d="scan'208";a="246985485" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 03 Dec 2012 15:19:07 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qB3FJ624008417 for ; Mon, 3 Dec 2012 15:19:07 GMT X-IronPort-AV: E=Sophos;i="4.84,208,1355097600"; d="scan'208";a="48339" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 03 Dec 2012 15:19:06 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Mon, 3 Dec 2012 15:19:06 +0000 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , Henning Rogge Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-24.txt Thread-Index: AQHNz3PdizJJy8YTn0ujf7TOKm3zcZgHFHyAgAAYAQCAAABW4A== Date: Mon, 3 Dec 2012 15:19:06 +0000 Message-ID: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BCBC7A.1080904@computer.org> In-Reply-To: <50BCBC7A.1080904@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 15:19:09 -0000 >> Again, using the order of addresses as protocol semantics is a bad >> idea. Use TLVs attached to the addresses to identify their purpose. > This would necessitate a N single address blocks for N addresses, > along with N Address Block TLVs. Without at this point taking a view as to whether conveying information by order is a good idea or not, I'm just going to address the latter point. There's absolutely no reason why conveying the function of addresses using TLVs requires separate address blocks. An illustration of a case where one address block contains multiple addresses with different functions is in the example HELLO message in one of the appendices to NHDP (RFC 6130). > It is permissible to have more than one TLV block per address > block, right? No. See grammar in 5444. Each address block is followed by exactly one TLV block. That can have multiple TLVs in it of course, which does everything you want. > Do you mean to suggest that a protocol cannot define messages > that have specific meanings for the address blocks it uses? There is, as a matter of fact, no specification in 5444 on the subject. 5444 is consistent with allowing this. Now there are people, Henning is clearly one and I know others, who strongly feel that although not prohibited by the wording of 5444, this is contrary to the spirit of 5444. This viewpoint as I have seen it expressed (not by Henning, who may or may not agree with this bit) is that the intent is to be able to associate attributes with addresses, attributes being expressed using TLVs. People may have created generic 5444 parsers which assume this model. What is the case is that NHDP and OLSRv2 take this approach. NHDP in particular carries both local and neighbour addresses. It could have been part of the design to put one before the other, in separate or the same address blocks. But that approach was not followed. There's also, while discussing this, a separate but related issue that neither NHDP nor OLSRv2 attach any meaning to the absence of a TLV. It could have been the design of NHDP that any address without some sort of neighbour TLV was a local address. This was explicitly not done, in order to allow possible additions of other addresses in extensions, with their own TLVs. Unfortunately, the authors of 5444 lacked the time to write a rationale (perhaps an informational draft) for design decisions made in 5444, which might have considered some of these topics (with or without conclusions). (The authors have some unpublished material, but not a coherent draft. I does remain on a maybe list, especially when they start issuing more than 24 hours in a day.) So in short, it's not banned, but some people have an unpublished view as to how things should or should not be used that go further that the strict limits of 5444. I'm still not stating a personal view, just that I think neither of the views "it's not prohibited" and "it works better as an address /association mapping" should be dismissed out of hand. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From charliep@computer.org Mon Dec 3 10:32:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DEF21F891B for ; Mon, 3 Dec 2012 10:32:57 -0800 (PST) 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 MgrpB8RsxJ8I for ; Mon, 3 Dec 2012 10:32:56 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id EB88D21F8905 for ; Mon, 3 Dec 2012 10:32:55 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Tfap3-0004g3-PS; Mon, 03 Dec 2012 13:32:53 -0500 Message-ID: <50BCF04B.9040302@computer.org> Date: Mon, 03 Dec 2012 10:32:43 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BCBC7A.1080904@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86ac9ac81121d5765a6e40a51f8ff537f8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:32:57 -0000 Hello Chris, On 12/3/2012 7:19 AM, Dearlove, Christopher (UK) wrote: >>> Again, using the order of addresses as protocol semantics is a bad >>> idea. Use TLVs attached to the addresses to identify their purpose. >> This would necessitate a N single address blocks for N addresses, >> along with N Address Block TLVs. > Without at this point taking a view as to whether conveying information > by order is a good idea or not, I'm just going to address the latter point. > There's absolutely no reason why conveying the function of addresses > using TLVs requires separate address blocks. An illustration of a case > where one address block contains multiple addresses with different > functions is in the example HELLO message in one of the appendices > to NHDP (RFC 6130). Err, right -- but isn't it correct to say "one Address Block TLV", where the one Address TLV block has N TLV values, and even multiple TLVs of different TLV types? And isn't it O.K. that some of the TLVs have N values, one per address in the address block? Then doesn't that automatically imply that each of the values in the TLV is supposed to be associated with the corresponding positionally located address in the Address Block? If a protocol message needs two Address Blocks for two different purposes, why isn't is O.K. to say that the first block is for purpose_A and the second address block is for purpose_B...? What RFC 5444 calls a TLV is a lot more like what I would have expected to be called a TLV "array" or "list" (or "block", but that term is already consumed by RFC 5444). My understand of TLV had (before RFC 5444) been that "Value" is singular -- the interpretation most intuitive from the "name" TLV and many previous RFCs and the Wikipedia definition http://en.wikipedia.org/wiki/Type-length-value But never mind, I'm not proposing to change RFC 5444. I'm only trying to explain why using generally intuitive terminology is not so simple, and I appreciate the help in trying to get it right for AODVv2. > >> It is permissible to have more than one TLV block per address >> block, right? > No. See grammar in 5444. Each address block is followed by exactly > one TLV block. That can have multiple TLVs in it of course, which does > everything you want. See above... so if my understanding above is correct, I agree with you and please excuse the use of wrong "TLV block" terminology. > >> Do you mean to suggest that a protocol cannot define messages >> that have specific meanings for the address blocks it uses? > There is, as a matter of fact, no specification in 5444 on the subject. > 5444 is consistent with allowing this. Whew! -- Regards, Charlie P. From abdussalambaryun@gmail.com Mon Dec 3 15:56:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1441221F88B1 for ; Mon, 3 Dec 2012 15:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 chsscl+nQyJ6 for ; Mon, 3 Dec 2012 15:56:42 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0B59021F8715 for ; Mon, 3 Dec 2012 15:56:41 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so2695831vcb.31 for ; Mon, 03 Dec 2012 15:56:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TB424sWbfYGMZL6NHV6wXaZboZ0jWx4qWKS75N5+NwQ=; b=sB2Ee/baewM2ET7E/5MnDVajozpA8PyvjgxfmhFHp66dcxB94MdAnGS95Quo5By+d1 ljzvIZRIp6qNagzVUrsmc4Y/3riUtUNHtb/z7TO6+z4xZecVdB5xJGGikXb9K3ZQiF8T 8NlUXgIJMHti5QZJjKabcstXM3R3264t5zwGmKM4OFUIa5eLxp/zWVEe7DfqBCsFCvqw 9LmtQthQe8nTeD54xRHhfK3QUJuDBefrvV3mMirJepMK/A6OTVRB37WB5kFaB47zSPqz S3UDVnSkFBxVKbQ6FQFqlMkKWlRDkyL5FoW/uLkp9k5lewCNX2tzUobLXUmUcCCZHgx2 p7bA== MIME-Version: 1.0 Received: by 10.220.16.12 with SMTP id m12mr10077878vca.14.1354578998654; Mon, 03 Dec 2012 15:56:38 -0800 (PST) Received: by 10.220.145.5 with HTTP; Mon, 3 Dec 2012 15:56:38 -0800 (PST) In-Reply-To: <50BCF04B.9040302@computer.org> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BCBC7A.1080904@computer.org> <50BCF04B.9040302@computer.org> Date: Tue, 4 Dec 2012 00:56:38 +0100 Message-ID: From: Abdussalam Baryun To: "manet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 23:56:43 -0000 Any routing protocol using rfc5444 defines its protocol addresses, messages, TLVs blocks, or values for its purposes, I think the way explained in the draft fits AODVv2 purposes, and does not violate rfc5444. AB On 12/3/12, Charles E. Perkins wrote: > > Hello Chris, > > On 12/3/2012 7:19 AM, Dearlove, Christopher (UK) wrote: >>>> Again, using the order of addresses as protocol semantics is a bad >>>> idea. Use TLVs attached to the addresses to identify their purpose. >>> This would necessitate a N single address blocks for N addresses, >>> along with N Address Block TLVs. >> Without at this point taking a view as to whether conveying information >> by order is a good idea or not, I'm just going to address the latter >> point. >> There's absolutely no reason why conveying the function of addresses >> using TLVs requires separate address blocks. An illustration of a case >> where one address block contains multiple addresses with different >> functions is in the example HELLO message in one of the appendices >> to NHDP (RFC 6130). > > Err, right -- but isn't it correct to say "one Address Block TLV", where > the one > Address TLV block has N TLV values, and even multiple TLVs of different TLV > types? > > And isn't it O.K. that some of the TLVs have N values, one per address > in the > address block? Then doesn't that automatically imply that each of the > values > in the TLV is supposed to be associated with the corresponding positionally > located address in the Address Block? > > If a protocol message needs two Address Blocks for two different purposes, > why isn't is O.K. to say that the first block is for purpose_A and the > second > address block is for purpose_B...? > > What RFC 5444 calls a TLV is a lot more like what I would have expected > to be called a TLV "array" or "list" (or "block", but that term is already > consumed by RFC 5444). My understand of TLV had (before RFC 5444) > been that "Value" is singular -- the interpretation most intuitive from the > "name" TLV and many previous RFCs and the Wikipedia definition > http://en.wikipedia.org/wiki/Type-length-value > > But never mind, I'm not proposing to change RFC 5444. I'm only trying > to explain why using generally intuitive terminology is not so simple, > and I appreciate the help in trying to get it right for AODVv2. > > > > > >> >>> It is permissible to have more than one TLV block per address >>> block, right? >> No. See grammar in 5444. Each address block is followed by exactly >> one TLV block. That can have multiple TLVs in it of course, which does >> everything you want. > > See above... so if my understanding above is correct, I agree with you and > please excuse the use of wrong "TLV block" terminology. > >> >>> Do you mean to suggest that a protocol cannot define messages >>> that have specific meanings for the address blocks it uses? >> There is, as a matter of fact, no specification in 5444 on the subject. >> 5444 is consistent with allowing this. > > Whew! > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Mon Dec 3 16:19:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1898E21F8960 for ; Mon, 3 Dec 2012 16:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 gON1LDE4f98S for ; Mon, 3 Dec 2012 16:19:27 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7947721F8942 for ; Mon, 3 Dec 2012 16:19:27 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so2461739vbb.31 for ; Mon, 03 Dec 2012 16:19:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Acg5E9VCS4R47U6xR0aXVIkvA5+NWxoSWrBmT7O85AU=; b=RtU7x6W8Y6ceFzhWdBFuQEJpaxoogO2TvucGK7kmqkG1PMc26rYsfOTuGQKSKDlk+m KHYTbpIpQHP7cT1trNQrF7JRARPKLNPoV0LuPao5wBVCYVsKfm40vDsM4XqIYNG60RNZ +XTY4KQw8Niq4QaTxKnHx7rl1EtGW45rNrR0jGbHpmZmtRwbkYKFXDbhz7KEvDRaq0QL wCGViUXvPXgQ5dV6C73TKhoKOjo66ivlKXkn9PzyDwBrV/s2rsdetziF848AiFTOcndL swzmNww4cYe9QQo27RvR8JRsCaGoIZa3LZM1wbLGog7kd7ImxaHEuIpr5KOTnUsePptP y4Cw== MIME-Version: 1.0 Received: by 10.220.16.12 with SMTP id m12mr10131096vca.14.1354580367001; Mon, 03 Dec 2012 16:19:27 -0800 (PST) Received: by 10.220.145.5 with HTTP; Mon, 3 Dec 2012 16:19:26 -0800 (PST) In-Reply-To: <50BCF04B.9040302@computer.org> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BCBC7A.1080904@computer.org> <50BCF04B.9040302@computer.org> Date: Tue, 4 Dec 2012 01:19:26 +0100 Message-ID: From: Abdussalam Baryun To: "manet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 00:19:28 -0000 > But never mind, I'm not proposing to change RFC 5444. I'm only trying > to explain why using generally intuitive terminology is not so simple, > and I appreciate the help in trying to get it right for AODVv2. > RFC5444 is a general format. We may need to update RFC5444 or introduce new message formatting in MANET, however, it still not necessary to limit routing functions' advantages for fitting a general format. AB From abdussalambaryun@gmail.com Mon Dec 3 16:26:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844B621F88E2 for ; Mon, 3 Dec 2012 16:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 hMp15Gx1L1uA for ; Mon, 3 Dec 2012 16:26:08 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 02B4321F891B for ; Mon, 3 Dec 2012 16:26:07 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so2711774vcb.31 for ; Mon, 03 Dec 2012 16:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fyWnuwmV7vqvtjZSwR54jLXbCsVtUd/ggrwqSKHutnc=; b=pRO7XfGtRj1W2CexARrmUkEn7F+Jw7ozgRXfefwVlYhU8mzdBOyA+ot6wCzPbroVGO dc3cmxxWk8hfPh8M/n/5vJUaYQXUec8qL1ta561l/Z2+Mi0B06E/3Bm551A4co/Ag11R /Y9ExkX6lq+Vd9MMzRVudmzBFRGehBspU/hF9RR4kNMp3PXV/ohoEIv/1q0WfvkzvmHi WzSITJjU1IvFjdMOsMwLVekMqMrGNBKDrpf8jGvUhvtC8hEr1fgkWsZyMHEu4Emq2zHQ /myCzA8EZ4grY+XDNpyBH+Tq1Op+whFgfMgXLpxv7WtqCFuTTGpHtlhSeDbda97EmNG0 lcGA== MIME-Version: 1.0 Received: by 10.58.252.72 with SMTP id zq8mr10503597vec.20.1354580767503; Mon, 03 Dec 2012 16:26:07 -0800 (PST) Received: by 10.220.145.5 with HTTP; Mon, 3 Dec 2012 16:26:07 -0800 (PST) In-Reply-To: <50BA3D0F.4030808@computer.org> References: <20121201032732.9644.98468.idtracker@ietfa.amsl.com> <50B97B4D.60209@computer.org> <50BA3D0F.4030808@computer.org> Date: Tue, 4 Dec 2012 01:26:07 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Fwd: New Version Notification for draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 00:26:08 -0000 Hi Charlie, On 12/1/12, Charles E. Perkins wrote: > > > It is not a working group draft. It was pulled out of the base DYMO > specification at the request of the LOADng team, because it is a feature > unlikely to be supported by LOADng devices. If I remember correctly, > this was suggested because if iRREP were in the main draft, they said > there might be industry pressure for LOADng devices to support iRREP. > I am fine to put iRREP back into the base specification, or to have it as > a separate WG draft. > I agree to let it separate draft as done, because it will have better advantages as I understand from your reply. AB From abdussalambaryun@gmail.com Mon Dec 3 16:31:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA8B21F88A4 for ; Mon, 3 Dec 2012 16:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 l3EAGs5AfwBj for ; Mon, 3 Dec 2012 16:31:45 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0788921F8879 for ; Mon, 3 Dec 2012 16:31:44 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so2468072vbb.31 for ; Mon, 03 Dec 2012 16:31:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L6y4BldAw9ZKUmQJArmFt5dH/9EbHrj3TziSKKuGgms=; b=DS8E8jGe4gY2JxoGWoTVXNvw+nM4CMZzcd7RbRPWK3WHrgQw/xKvDl/UIGJAKbqmwB lB3lcwOG+dFBhrqrBF9tGBGuz+6p7TeykePpWrbiYrzS38IPL9jimKWhrC8pn5iCyvvh eBUJHXYEzkuimgEb2V5O+Xm4jVYcBfny36PSA+nddhKKNiaOefuDjaxxsowQT2BdRWRa CgXrCDtlkHVstN7hflN7mn8vlkv0y7m6DMIQ2W39w0Dd1VfPUEVrdHZ5AH1RtlT5zeGi 1/2ZwI+huZOCc0tjETeIEaN6NZR/Gdp7jTFuH8xi3hBj4d0Rw96sEYeiAY7oo/h6tcNs jQEw== MIME-Version: 1.0 Received: by 10.52.99.131 with SMTP id eq3mr8946031vdb.55.1354581104517; Mon, 03 Dec 2012 16:31:44 -0800 (PST) Received: by 10.220.145.5 with HTTP; Mon, 3 Dec 2012 16:31:44 -0800 (PST) In-Reply-To: <50BA3B3E.7060506@comcast.net> References: <50BA3B3E.7060506@comcast.net> Date: Tue, 4 Dec 2012 01:31:44 +0100 Message-ID: From: Abdussalam Baryun To: Cole Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Fwd: Fw: New Version Notification for draft-ietf-manet-smf-mib-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 00:31:45 -0000 +1 AB On 12/1/12, Cole wrote: > Joe, Stan, > > We have done our final review of the SMF-MIB and have posted > to the Working Group. There have been > no substantive comments on the draft from the WG for quite a while. We > would like to request that this draft be moved to Working Group Last > Call. We hope you all concur? > > Respectfully, Bob > > ----- Original Message ----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Saturday, December 01, 2012 04:59 PM > To: Cole, Robert G CIV USARMY CERDEC (US) > Cc: adamson@itd.nrl.navy.mil ; > macker@itd.nrl.navy.mil > Subject: New Version Notification for draft-ietf-manet-smf-mib-06.txt > > > A new version of I-D, draft-ietf-manet-smf-mib-06.txt > has been successfully submitted by Robert G. Cole and posted to the > IETF repository. > > Filename: draft-ietf-manet-smf-mib > Revision: 06 > Title: Definition of Managed Objects for the Manet Simplified Multicast > Framework Relay Set Process > Creation date: 2012-12-01 > WG ID: manet > Number of pages: 61 > URL: > http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-mib-06.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib > Htmlized: http://tools.ietf.org/html/draft-ietf-manet-smf-mib-06 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-smf-mib-06 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes objects for configuring aspects of the > Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc > Networks (MANETs). The SMF-MIB also reports state information, > performance metrics, and notifications. In addition to > configuration, the additional state and performance information is > useful to operators troubleshooting multicast forwarding problems. > > > > > The IETF Secretariat > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From sratliff@cisco.com Mon Dec 3 19:44:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B61E21F8647; Mon, 3 Dec 2012 19:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQqWoR39PREj; Mon, 3 Dec 2012 19:44:50 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 38FCF21F8616; Mon, 3 Dec 2012 19:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24488; q=dns/txt; s=iport; t=1354592690; x=1355802290; h=from:to:cc:subject:date:message-id:mime-version; bh=rQdyO4p+ycXzI4OcAuEHsMuudQjgHCUTf3sDsCRIrtQ=; b=Zy06mTJIL6RTNvnHlqRLxxXBxySoP2341oVdXip+Lchct4lWM7RyCE98 cLHqd/7kMpsbx/vIkXF+4agQoNGWhFFIXL6JY8b9yUh0IGri7ZFPcyENg HpKilg/dhf5tL+FvRHzWDmeUz21qnsJAqysgMmUrXftwqGFucTXX/MkRU w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEMAKtwvVCtJXHA/2dsb2JhbAA6Cr45FmwHgh4BAQEDAWsHBwUNASpWJwQODQGIAQYMrliQP4xLBoNPYQOST5N5gmUNgWUHFwYY X-IronPort-AV: E=McAfee;i="5400,1158,6915"; a="148764753" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 04 Dec 2012 03:44:49 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qB43inKH025090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Dec 2012 03:44:49 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.161]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 21:44:48 -0600 From: "Stan Ratliff (sratliff)" To: "ietf-secretary@ietf.org" Thread-Topic: Please publish draft-ietf-manet-olsrv2-metrics-rationale-01 Thread-Index: AQHN0dG1rxh24LsGZECxQc0m/Ag6MA== Date: Tue, 4 Dec 2012 03:44:48 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF0729D@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.218] Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FF0729Dxmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "manet-chairs@tools.ietf.org" , manet List Subject: [manet] Please publish draft-ietf-manet-olsrv2-metrics-rationale-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 03:44:52 -0000 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FF0729Dxmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please publish draft-ietf-manet-olsrv2-metrics-rationale-01 as an Informati= onal RFC. The Shepherds Writeup is below. Regards, Stan > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Why > is this the proper type of RFC? Is this type of RFC indicated in the > title page header? This document is requested to be published as an Informational RFC. OLSRv2 reflects ~8 years of experiences with OLSR, published as RFC3626 (Experimental), and multiple independent implementations and deployments exist, and this protocol is in final review by the IESG for publication as a Proposed Standard. (The single DISCUSS outstanding is not related to the subject matter of this document.) This document presents the design rationale behind the way in which OLSRv2 incorporated metrics. It does not mandate any protocol behaviors. > (2) The IESG approval announcement includes a Document Announcement > Write-Up. Please provide such a Document Announcement Write-Up. Recent > examples can be found in the "Action" announcements for approved > documents. The approval announcement contains the following sections: > Technical Summary > > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. The abstract of this document is included below. This document describes the rationale for and design considerations behind how link metrics are included in OLSRv2, in order to allow routing by other than minimum hop count routes. > Working Group Summary > > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? o OLSRv2 was first submitted as an individual draft in July 2005 (draft-clausen-manet-olsrv2-00), and accepted as a Working Group document in August 2005. o OLSRv2 is close to approval as a Propose Standard by the IESG (one DISCUSS to resolve). o A key difference between RFC3626 and OLSRv2 is the introduction of support for link metrics. An individual draft (draft-dearlove-olsrv2-metrics-00) was submitted in 2007, discussing the design options, culminating in 2010 with draft-dearlove-olsrv2-metrics-05 documenting Working Group consensus on this matter. Metrics support was, then, folded into OLSRv2. o This document retains and documents the design rationale, and important decisions for how metrics were integrated into OLSRv2. > Document Quality > > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? There is a number of independent implementations of OLSRv2, as was indicated in the write-up for that OLSRv2. This document does not propose a protocol, or mandate protocol behavior, but rather presents part of the design rationale for OLSRv2. > Personnel > > Who is the Document Shepherd? Who is the Responsible Area > Director? Adrian Farrel is the Responsible Area Director; Stan Ratliff is the Docume= nt Shepherd. > (3) Briefly describe the review of this document that was performed by > the Document Shepherd. If this version of the document is not ready > for publication, please explain why the document is being forwarded to > the IESG. The shepherd has read and reviewed the document. no issues exist; the docum= ent is ready for publication. > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? No concerns exist. > (5) Do portions of the document need review from a particular or from > broader perspective, e.g., security, operational complexity, AAA, DNS, > DHCP, XML, or internationalization? If so, describe the review that > took place. The authors do not believe that - outside the usual directorate reviews during IETF Last Call - additional reviews are required. > (6) Describe any specific concerns or issues that the Document Shepherd > has with this document that the Responsible Area Director and/or the > IESG should be aware of? For example, perhaps he or she is uncomfortable > with certain parts of the document, or has concerns whether there really > is a need for it. In any event, if the WG has discussed those issues and > has indicated that it still wishes to advance the document, detail those > concerns here. There are no issues that the ADs and/or the IESG should be aware of. > (7) Has each author confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP 78 > and BCP 79 have already been filed. If not, explain why. All authors have confirmed that they are unaware of any IPR needing disclos= ure, indeed that there are no known IPR claims related to this document. > (8) Has an IPR disclosure been filed that references this document? > If so, summarize any WG discussion and conclusion regarding the IPR > disclosures. No IPR disclosures have been filed. > (9) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with it? > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in separate > email messages to the Responsible Area Director. (It should be in a > separate email because this questionnaire is publicly available.) > (11) Identify any ID nits the Document Shepherd has found in this > document. (See http://www.ietf.org/tools/idnits/ [^] and the Internet-Dra= fts > Checklist). Boilerplate checks are not enough; this check needs to be > thorough. IDnits returns no errors or warnings > (12) Describe how the document meets any required formal review > criteria, such as the MIB Doctor, media type, and URI type reviews. This document does not specify a protocol, a format, a media type or reserv= e any code-points. Thus, such reviews are not needed. > (13) Have all references within this document been identified as > either normative or informative? Yes. > (14) Are there normative references to documents that are not ready for > advancement or are otherwise in an unclear state? If such normative > references exist, what is the plan for their completion? No. There are no normative references in this document. > (15) Are there downward normative references references (see RFC 3967)? > If so, list these downward references to support the Area Director in the > Last Call procedure. No. There are no normative references. All informative references are, furthermore, to already published RFCs or soon-to-be-RFCs (OLSRv2 currently in IESG review) > (16) Will publication of this document change the status of any > existing RFCs? Are those RFCs listed on the title page header, listed > in the abstract, and discussed in the introduction? If the RFCs are not > listed in the Abstract and Introduction, explain why, and point to the > part of the document where the relationship of this document to the > other RFCs is discussed. If this information is not in the document, > explain why the WG considers it unnecessary. Publication of this document will not change the status of any existing RFC= s. > (17) Describe the Document Shepherd's review of the IANA considerations > section, especially with regard to its consistency with the body of the > document. Confirm that all protocol extensions that the document makes > are associated with the appropriate reservations in IANA registries. > Confirm that any referenced IANA registries have been clearly > identified. Confirm that newly created IANA registries include a > detailed specification of the initial contents for the registry, that > allocations procedures for future registrations are defined, and a > reasonable name for the new registry has been suggested (see RFC 5226). This document has no actions for IANA. > (18) List any new IANA registries that require Expert Review for future > allocations. Provide any public guidance that the IESG would find > useful in selecting the IANA Experts for these new registries. This document has no actions for IANA. > (19) Describe reviews and automated checks performed by the Document > Shepherd to validate sections of the document written in a formal > language, such as XML code, BNF rules, MIB definitions, etc. No automated checks, other than IDnits, performed; the document does not specify a protocol, but documents a design rationale. --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FF0729Dxmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <22BDA7FACA465345B996C3EB2B1B2FD5@cisco.com> Content-Transfer-Encoding: quoted-printable
Please publish draft-ietf-manet-olsrv2-metrics-rationale-01 as an Info= rmational RFC. The Shepherds Writeup is below. 

Regards,
Stan


> (1) What type of RFC is being requested (BCP, Proposed Standard,<= /div>
> Internet Standard, Informational, Experimental, or Historic)? Why=
> is this the proper type of RFC? Is this type of RFC indicated in = the
> title page header?

This document is requested to be published as an Informational RFC.

OLSRv2 reflects ~8 years of experiences with OLSR, published as RFC362= 6
(Experimental), and multiple independent implementations and deploymen= ts
exist, and this protocol is in final review by the IESG for publicatio= n
as a Proposed Standard. (The single DISCUSS outstanding is not related=
to the subject matter of this document.)

This document presents the design rationale behind the way in which
OLSRv2 incorporated metrics. It does not mandate any protocol behavior= s.

> (2) The IESG approval announcement includes a Document Announceme= nt
> Write-Up. Please provide such a Document Announcement Write-Up. R= ecent
> examples can be found in the "Action" announcements for= approved
> documents. The approval announcement contains the following secti= ons:

> Technical Summary
>
>  Relevant content can frequently be found in the abstract&nb= sp;
>  and/or introduction of the document. If not, this may be&nb= sp;
>  an indication that there are deficiencies in the abstract&n= bsp;
>  or introduction.

The abstract of this document is included below.

   This document describes the rationale for and design cons= iderations
   behind how link metrics are included in OLSRv2, in order = to allow
   routing by other than minimum hop count routes.
   
> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For&= nbsp;
>  example, was there controversy about particular points or&n= bsp;
>  were there decisions where the consensus was particularly&n= bsp;
>  rough?
o OLSRv2 was first submitted as an individual draft in July 2005
(dr= aft-clausen-manet-olsrv2-00), and accepted as a Working Group
doc= ument in August 2005.

o OLSRv2 is close to approval as a Propose Standard by the IESG
               (one DISCUSS to= resolve).
o A key difference between RFC3626 and OLSRv2 is the introduction of
sup= port for link metrics. An individual draft
(dr= aft-dearlove-olsrv2-metrics-00) was submitted in 2007, discussing
the= design options, culminating in 2010 with
dra= ft-dearlove-olsrv2-metrics-05 documenting Working Group consensus
on = this matter. Metrics support was, then, folded into OLSRv2.

o This document retains and documents the design rationale, and import= ant
dec= isions for how metrics were integrated into OLSRv2.

> Document Quality
>
>  Are there existing implementations of the protocol? Have a&= nbsp;
>  significant number of vendors indicated their plan to =
>  implement the specification? Are there any reviewers that&n= bsp;
>  merit special mention as having done a thorough review,&nbs= p;
>  e.g., one that resulted in important changes or a 
>  conclusion that the document had no substantive issues? If&= nbsp;
>  there was a MIB Doctor, Media Type or other expert review,&= nbsp;
>  what was its course (briefly)? In the case of a Media Type&= nbsp;
>  review, on what date was the request posted?

The= re is a number of independent implementations of OLSRv2, as was
ind= icated in the write-up for that OLSRv2.
Thi= s document does not propose a protocol, or mandate protocol behavior,
but= rather presents part of the design rationale for OLSRv2.
> Personnel
>
>  Who is the Document Shepherd? Who is the Responsible Area
>  Director?

Adrian Farrel is the Responsible Area Director;  Stan Ratliff is = the Document Shepherd.

> (3) Briefly describe the review of this document that was perform= ed by
> the Document Shepherd. If this version of the document is not rea= dy
> for publication, please explain why the document is being forward= ed to
> the IESG.

The shepherd has read and reviewed the document. no issues exist; the = document is ready for publication. 

> (4) Does the document Shepherd have any concerns about the depth = or
> breadth of the reviews that have been performed? 

No concerns exist. 

> (5) Do portions of the document need review from a particular or = from
> broader perspective, e.g., security, operational complexity, AAA,= DNS,
> DHCP, XML, or internationalization? If so, describe the review th= at
> took place.

The authors do not believe that - outside the usual directorate review= s
during  IETF Last Call - additional reviews are required.

> (6) Describe any specific concerns or issues that the Document Sh= epherd
> has with this document that the Responsible Area Director and/or = the
> IESG should be aware of? For example, perhaps he or she is uncomf= ortable
> with certain parts of the document, or has concerns whether there= really
> is a need for it. In any event, if the WG has discussed those iss= ues and
> has indicated that it still wishes to advance the document, detai= l those
> concerns here.

There are no issues that the ADs and/or the IESG should be aware of.&n= bsp;

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of = BCP 78
> and BCP 79 have already been filed. If not, explain why.

All authors have confirmed that they are unaware of any IPR needing di= sclosure,
indeed that there are no known IPR claims related to this document.

> (8) Has an IPR disclosure been filed that references this documen= t?
> If so, summarize any WG discussion and conclusion regarding the I= PR
> disclosures.

No IPR disclosures have been filed.

> (9) How solid is the WG consensus behind this document? Does it&n= bsp;
> represent the strong concurrence of a few individuals, with other= s
> being silent, or does the WG as a whole understand and agree with= it? 

> (10) Has anyone threatened an appeal or otherwise indicated extre= me 
> discontent? If so, please summarise the areas of conflict in sepa= rate
> email messages to the Responsible Area Director. (It should be in= a
> separate email because this questionnaire is publicly available.)=  

> (11) Identify any ID nits the Document Shepherd has found in this=
> document. (See http://www.ietf.org/tools/idnits/ [^] and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs t= o be
> thorough.

IDnits returns no errors or warnings

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type review= s.

This document does not specify a protocol, a format, a media type or r= eserve
any code-points. Thus, such reviews are not needed.

> (13) Have all references within this document been identified as<= /div>
> either normative or informative?

Yes.

> (14) Are there normative references to documents that are not rea= dy for
> advancement or are otherwise in an unclear state? If such normati= ve
> references exist, what is the plan for their completion?

No. There are no normative references in this document.

> (15) Are there downward normative references references (see RFC = 3967)?
> If so, list these downward references to support the Area Directo= r in the
> Last Call procedure. 

No. There are no normative references. 

All informative references are, furthermore, to already published RFCs= or
soon-to-be-RFCs (OLSRv2 currently in IESG review)

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, li= sted
> in the abstract, and discussed in the introduction? If the RFCs a= re not
> listed in the Abstract and Introduction, explain why, and point t= o the
> part of the document where the relationship of this document to t= he
> other RFCs is discussed. If this information is not in the docume= nt,
> explain why the WG considers it unnecessary.

Publication of this document will not change the status of any existin= g RFCs.

> (17) Describe the Document Shepherd's review of the IANA consider= ations
> section, especially with regard to its consistency with the body = of the
> document. Confirm that all protocol extensions that the document = makes
> are associated with the appropriate reservations in IANA registri= es.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a<= /div>
> detailed specification of the initial contents for the registry, = that
> allocations procedures for future registrations are defined, and = a
> reasonable name for the new registry has been suggested (see RFC = 5226).

This document has no actions for IANA.

> (18) List any new IANA registries that require Expert Review for = future
> allocations. Provide any public guidance that the IESG would find=
> useful in selecting the IANA Experts for these new registries.

This document has no actions for IANA.
   
> (19) Describe reviews and automated checks performed by the Docum= ent
> Shepherd to validate sections of the document written in a formal=
> language, such as XML code, BNF rules, MIB definitions, etc.

No automated checks, other than IDnits, performed; the document does n= ot
specify a protocol, but documents a design rationale.
--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FF0729Dxmbalnx03ciscoc_-- From marius@itee.uq.edu.au Mon Dec 3 21:21:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACCB21E803A for ; Mon, 3 Dec 2012 21:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.52 X-Spam-Level: X-Spam-Status: No, score=0.52 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] 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 ydIlC9P-arMK for ; Mon, 3 Dec 2012 21:21:07 -0800 (PST) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by ietfa.amsl.com (Postfix) with ESMTP id 90C3321E803D for ; Mon, 3 Dec 2012 21:21:06 -0800 (PST) Received: from smtp1.soe.uq.edu.au (smtp1.soe.uq.edu.au [10.138.113.40]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id qB45L2sV026766 for ; Tue, 4 Dec 2012 15:21:03 +1000 Received: from UQEXET2.soe.uq.edu.au (uqexet2.soe.uq.edu.au [130.102.129.39]) by smtp1.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id qB45L2c2006059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 4 Dec 2012 15:21:02 +1000 Received: from uqexht3.soe.uq.edu.au (130.102.129.72) by UQEXET2.soe.uq.edu.au (130.102.129.39) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 4 Dec 2012 15:21:02 +1000 Received: from UQEXMDA8.soe.uq.edu.au ([169.254.5.195]) by uqexht3.soe.uq.edu.au ([130.102.129.72]) with mapi id 14.01.0355.002; Tue, 4 Dec 2012 15:21:02 +1000 From: Marius Portmann To: "'manet@ietf.org'" Thread-Topic: DYMO/AODVv2 and LOADng -- Problems and Proposed Solutions Thread-Index: Ac3R3dtIO2t17KHuRA6f+i1YXgHJDw== Date: Tue, 4 Dec 2012 05:21:00 +0000 Message-ID: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.102.64.21] Content-Type: multipart/alternative; boundary="_000_55276FFE1B06A541A659C0B360E8066F17E689UQEXMDA8soeuqedua_" MIME-Version: 1.0 X-UQ-FilterTime: 1354598464 X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub Subject: [manet] DYMO/AODVv2 and LOADng -- Problems and Proposed Solutions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 05:21:10 -0000 --_000_55276FFE1B06A541A659C0B360E8066F17E689UQEXMDA8soeuqedua_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have been following the recent discussion on DYMO and LOADng with intere= st, and would like to share some of our findings and experience in this con= text, in the hope of being able to make a constructive contribution. Any fe= edback is appreciated. Based on a careful analysis of AODV, we have encountered problems that stil= l persist in both DYMO (ver 23) and LOADng (ver 6). (1) Non-Optimal Routes -------------------------------- On-demand/reactive routing protocols (such as AODV, DYMO and LOADng) often = fail to discover the best (shortest) routes [1,2]. The problem is that during route discovery the destination (target) node do= es not forward route requests; so, nodes that lie downstream of the destina= tion node frequently create non-optimal routes to the source. Knightly and = Miskovic [1] have shown that "poorly selected paths can have significantly = higher routing-metric costs, and their duration can extend to minute time s= cales". We have verified that this problem exists in DYMO and LOADng. As a possible solution, we propose that route requests are always forwarded= , even by nodes generating a route reply [2,3]. The forwarded request shoul= d include a flag stating that a reply has already been initiated. In [3] it= is shown that this increases the quality of routes. Of course this could i= ncrease the overhead of control messages, but in most of the cases the addi= tional overhead is minimal, since a request floods the entire network anywa= y. (2) Route Reply Loss ----------------------------- AODV can lose route replies (http://www.ietf.org/mail-archive/web/manet/cur= rent/msg05702.html). The reason is that route replies are only forwarded by an intermediate node= when the node updates its routing table. This problem has partly been solved in DYMO and LOADng by increasing sequen= ce numbers when initiating a route reply. However, a careful analysis shows that replies can still be lost; yielding = again non-optimal routes or route discovery failures. Namely, if one route = reply overtakes another, i.e., a newer reply reaches a node earlier than an= older one, then the older route reply is dropped [4]. A solution consists of intermediate nodes always forwarding route replies. = Surely, forwarding (unicasting) replies increases the number of messages in= the network. But, (a) route discovery is more likely and (b) re-sending a = route request to establish a route would yield another broadcast cycle, wh= ich is much more expensive w.r.t. network load. (3) Route Request Loss --------------------------------------------- Similar to (2), route requests might be lost in DYMO and LOADng. Namely, if one route request overtakes another, i.e., a newer request reach= es a node earlier than an older one, then the older route request is droppe= d. This problem does not occur in AODV, thanks to the use of a list of previou= sly seen RREQ IDs. --------------------------------------------- If requested we can provide more detailed explanations and examples. Rob van Glabbeek Peter H=F6fner Marius Portmann Wee Lum Tan (a team of networks and formal methods researchers at NICTA, working on for= mally modelling and analysing MANET routing protocols) cheers Marius References --------------- [1] S. Miskovic and E. W. Knightly, "Routing primitives for wireless mesh n= etworks: Design, analysis and experiments", in Conference on Information Co= mmunications (INFOCOM'10). IEEE, 2010, pp. 2793-2801. networks.rice.edu/papers/MeshRoutingPrimitives.pdf [2] P. H=F6fner, R. J. van Glabbeek, W. L. Tan, M. Portmann, A. McIver, and= A. Fehnker, "A rigorous analysis of AODV and its variants", in Modeling, A= nalysis and Simulation of Wireless and Mobile Systems (MSWIM'12). ACM Press= , 2012. doi:10.1145/2387238.2387274 http://www.cse.unsw.edu.au/~rvg/pub/mswim12.pdf [3] A. Fehnker, R. J. van Glabbeek, P. H=F6fner, A. McIver, M. Portmann, an= d W. L. Tan, "Automated analysis of AODV using UPPAAL", in Tools and Algori= thms for the Construction and Analysis of Systems (TACAS'12), LNCS, C. Flan= agan and B. K=F6nig, Eds., vol. 7214. Springer, 2012, pp. 173-187. doi:10.1= 007/978-3-642-28756-5_13 http://www.cse.unsw.edu.au/~rvg/pub/tacas12.pdf [4] P. H=F6fner, and S. Edenhofer, "Towards a Rigorous Analysis of AODVv2 (= DYMO)", in Workshop on Rigorous Protocol Engineering, IEEE http://www.nicta.com.au/pub?id=3D6169 ---------------------------------------------------------------------- Dr Marius Portmann School of ITEE The University of Queensland Brisbane 4072, Australia CRICOS Provider No: 00025B Tel: +61 7 3300 8561, Fax: +61 7 3365 4999 ---------------------------------------------------------------------- --_000_55276FFE1B06A541A659C0B360E8066F17E689UQEXMDA8soeuqedua_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We have been following the recent discussion on DYMO and LOA= Dng with interest, and would like to share some of our findings and experie= nce in this context, in the hope of being able to make a constructive contribution. Any feedback is appreciated.

 

Based on a careful analysis of AODV, we have encountered pro= blems that still persist in both DYMO (ver 23) and LOADng (ver 6).

 

(1) Non-Optimal Routes

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

On-demand/reactive routing protocols (such as AODV, DYM= O and LOADng) often fail to discover the best (shortest) routes [1,2].=

 

The problem is that during route discovery the destinat= ion (target) node does not forward route requests; so, nodes that lie = downstream of the destination node frequently create non-optimal routes to the source. Knightly and Miskovic [1] have = ;shown that "poorly selected paths can have significantly higher routi= ng-metric costs, and their duration can extend to minute time scales".=  

We have verified that this problem exists in DYMO and LOADng= .

 

As a possible solution, we propose that route requests are a= lways forwarded, even by nodes generating a route reply [2,3]. The for= warded request should include a flag stating that a reply has already been initiated. In [3] it is shown that this incr= eases the quality of routes. Of course this could increase the overhea= d of control messages, but in most of the cases the additional overhea= d is minimal, since a request floods the entire network anyway.

  

(2) Route Reply Loss

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

AODV can lose route replies (http://www.ietf.org/mail-arch= ive/web/manet/current/msg05702.html). 

The reason is that route replies are only forwarded by = an intermediate node when the node updates its routing table. 

This problem has partly been solved in DYMO and LOADng by in= creasing sequence numbers when initiating a route reply.<= /font>

However, a careful analysis shows that replies can still be = lost; yielding again non-optimal routes or route discovery failures. N= amely, if one route reply overtakes another, i.e., a newer reply reaches a node earlier than an older one, then the old= er route reply is dropped [4].

 

A solution consists of intermediate nodes always forwarding = route replies. Surely, forwarding (unicasting) replies increases the n= umber of messages in the network. But, (a) route discovery is more likely and (b) re-sending a route request to establish a= route would yield another broadcast  cycle, which is much more expens= ive w.r.t. network load.

 

(3) Route Request Loss

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

Similar to (2), route requests might be lost in DYMO an= d LOADng.

Namely, if one route request overtakes another, i.e., a newe= r request reaches a node earlier than an older one, then the older route re= quest is dropped.

This problem does not occur in AODV, thanks to the use of a = list of previously seen RREQ IDs.

 

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


If requested we can provide  more detailed explanations and examples.<= o:p>

 

 

Rob van Glabbeek

Peter H=F6fner

Marius Portmann

Wee Lum Tan

(a team of networks and formal methods researchers at NICTA,= working on formally modelling and analysing MANET routing protocols)<= /o:p>

 

 

cheers

Marius

 

 

 

References

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

[1] S. Miskovic and E. W. Knightly, "Routing primitives= for wireless mesh networks: Design, analysis and experiments", in Con= ference on Information Communications (INFOCOM’10). IEEE, 2010, pp. 2793-2801.

networks.rice.edu/papers/MeshRoutingPrimitives.pdf=

[2] P. H=F6fner, R. J. van Glabbeek, W. L. Tan, M. Portmann,= A. McIver, and A. Fehnker, "A rigorous analysis of AODV and its varia= nts", in Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWIM’12). ACM Press, 2012. doi:10.114= 5/2387238.2387274

= http://www.cse.unsw.edu.au/~rvg/pub/mswim12.pdf

[3] A. Fehnker, R. J. van Glabbeek, P. H=F6fner, A. McI= ver, M. Portmann, and W. L. Tan, "Automated analysis of AODV using UPP= AAL", in Tools and Algorithms for the Construction and Analysis of Systems (TACAS’12), LNCS, C. Flanagan and B. K=F6nig, Ed= s., vol. 7214. Springer, 2012, pp. 173–187. doi:10.1007/978-3-642-287= 56-5_13

= http://www.cse.unsw.edu.au/~rvg/pub/tacas12.pdf

[4] P. H=F6fner, and S. Edenh= ofer, "Towards a Rigorous Analysis of AODVv2 (DYMO)", in Workshop= on Rigorous Protocol Engineering, IEEE
http://www.nicta.com.au/pub?id=3D6169

 

 

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

Dr Marius Portmann<= /span>

School of ITEE

The University of Queensland

Brisbane 4072, Australia<= /o:p>

CRICOS Provider No: 00025B

Tel: +61 7 3300 8561, Fax:= +61 7 3365 4999

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

&= nbsp;

 

--_000_55276FFE1B06A541A659C0B360E8066F17E689UQEXMDA8soeuqedua_-- From henning.rogge@fkie.fraunhofer.de Tue Dec 4 00:29:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B809621F851C for ; Tue, 4 Dec 2012 00:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.188 X-Spam-Level: X-Spam-Status: No, score=0.188 tagged_above=-999 required=5 tests=[AWL=1.532, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 22OPcSwykURm for ; Tue, 4 Dec 2012 00:29:45 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 67F1521F8C02 for ; Tue, 4 Dec 2012 00:29:45 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tfnsr-0000Yw-7l; Tue, 04 Dec 2012 09:29:41 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tfnsr-0002M8-51; Tue, 04 Dec 2012 09:29:41 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 4 Dec 2012 09:29:40 +0100 Message-ID: <50BDB46D.3040700@fkie.fraunhofer.de> Date: Tue, 4 Dec 2012 09:29:33 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Charles E. Perkins" References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BCBC7A.1080904@computer.org> <50BCF04B.9040302@computer.org> In-Reply-To: <50BCF04B.9040302@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000605020703030204030902" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/15677/Tue Dec 4 01:34:35 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 676a75961403c53da43f811dd9e91d0e Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 08:29:46 -0000 --------------ms000605020703030204030902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 12/03/2012 07:32 PM, Charles E. Perkins wrote: > Err, right -- but isn't it correct to say "one Address Block TLV", > where the one Address TLV block has N TLV values, and even multiple > TLVs of different TLV types? When I read "Address Block TLV" I think you are talking about a TLV...=20 while if you say "Address TLV Block" I think you are talking about a=20 block of TLVs. Most likely its just wording, but I was confused about it. > And isn't it O.K. that some of the TLVs have N values, one per > address in the address block? Then doesn't that automatically imply > that each of the values in the TLV is supposed to be associated with > the corresponding positionally located address in the Address Block? Each TLV in the TLV-Block associated with an Address block can apply to=20 one address (any of the addresses in the block), a sequence of=20 continuous addresses or all of the addresses. > If a protocol message needs two Address Blocks for two different > purposes, why isn't is O.K. to say that the first block is for > purpose_A and the second address block is for purpose_B...? The problem I have with this approach is that we are making it harder to = extend the message later. If you can discover the meaning of an address=20 by looking at one of the attached TLVs, it is much easier to add more=20 data to the message without breaking old parsers. The advantage I see in a format like RFC5444 is that we don't need a=20 "hidden semantic", everything can be contained in the TLVs and addresses = with attached TLVs. > What RFC 5444 calls a TLV is a lot more like what I would have > expected to be called a TLV "array" or "list" (or "block", but that > term is already consumed by RFC 5444). My understand of TLV had > (before RFC 5444) been that "Value" is singular -- the interpretation > most intuitive from the "name" TLV and many previous RFCs and the > Wikipedia definition http://en.wikipedia.org/wiki/Type-length-value An address-TLV in RFC5444 can have a single value for a single address,=20 multiple values for a sequence of addresses or a single value for a=20 sequence of addresses. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000605020703030204030902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEyMDQwODI5MzhaMCMGCSqGSIb3DQEJBDEWBBSDZxuy6atekDD6k4I+56m2mtT2lzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAbLa6BiDRFD2m0zSssLFL1gT7mWY7nDDGo+B20G65eZHw Juxsxpx4kZYadq5zsAWiMYVCCwanwO8dw0+JdUJXJRDEhkeXpb9LU7NCCLH3hxKrPGhkW8bc vVT3DddUVe6qeJzGgsvURMuQQEDj6T96IJ7n+HjUNv4zp8SpshGcfTrXuqlzv/zGxSQUxGxP ginjS+To/YbcigKPuUnJM9m+vbubMdA+f3SLkUD7H0qIDg2qDyXtGmwREciUcCHhEzfLktop 4FOp6DGtCwnOy0rW/DZInjiVmRF4UiybR5nN9NQXGxuY5Yjf1BwyUtMxRz2wNoNHedHum7ab poFf1gGvpAAAAAAAAA== --------------ms000605020703030204030902-- From abdussalambaryun@gmail.com Tue Dec 4 07:04:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B597A21F8BD6 for ; Tue, 4 Dec 2012 07:04:34 -0800 (PST) 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=[AWL=-0.000, 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 7oh2VVzScXCh for ; Tue, 4 Dec 2012 07:04:33 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB5721F8BD5 for ; Tue, 4 Dec 2012 07:04:33 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so5184047vba.27 for ; Tue, 04 Dec 2012 07:04:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/VNriG1YebUxBAS1EM1FeB4tM78gYw3BkMfajgvRDvs=; b=f5FU25BANsVp5jutoDDobL/JPo5DWJ64rpHREhA8MdjDVbsHcIvv6ta0Y9qz7noNv/ tJpEqX+dRr4Fp5cmGXN+/60sooe16Ks8tZ3jbwPXkH+V97G64eTCgu8IXLVLDiggX+NH NmUBpq2uuG7IyJ6Luqd0uVX94T7ENC8FRv065/KpXziZt8PxZEkZFa1m41sFcLMcb7Xi d3pUwUXLjHHZJP26ugwRL/w7ZZ56D0ecTSPaYayREdQ5N8FsvOrwGlo4udzV4l9SC9eT 57EJSrzuXptUq7R0iItSCy4dw8wakLrjFFkKmep5LNXRM4StiGBB1g54Rx9ZE21h050y 8Mig== MIME-Version: 1.0 Received: by 10.220.107.5 with SMTP id z5mr11861263vco.22.1354633471826; Tue, 04 Dec 2012 07:04:31 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 4 Dec 2012 07:04:31 -0800 (PST) In-Reply-To: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> References: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> Date: Tue, 4 Dec 2012 15:04:31 +0000 Message-ID: From: Abdussalam Baryun To: Marius Portmann Content-Type: multipart/alternative; boundary=f46d043c7bd4e39cf304d0082e71 Cc: "manet@ietf.org" Subject: Re: [manet] DYMO/AODVv2 and LOADng -- Problems and Proposed Solutions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 15:04:34 -0000 --f46d043c7bd4e39cf304d0082e71 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Marius Thanks for your feedback and references, but your analysis will be more interesting if I know when/how such disadvantages happen in your work done so far. Could you inform on the list of the evaluation you done as including number of nodes, mobility model, etc. However, when I get time to read your references I can reply better. No protocol is perfect in general :) AB On Tue, Dec 4, 2012 at 5:21 AM, Marius Portmann wrot= e: > We have been following the recent discussion on DYMO and LOADng with > interest, and would like to share some of our findings and experience in > this context, in the hope of being able to make a constructive > contribution. Any feedback is appreciated.**** > > ** ** > > Based on a careful analysis of AODV, we have encountered problems that > still persist in both DYMO (ver 23) and LOADng (ver 6).**** > > ** ** > > (1) Non-Optimal Routes**** > > --------------------------------**** > > On-demand/reactive routing protocols (such as AODV, DYMO and LOADng) ofte= n > fail to discover the best (shortest) routes [1,2].**** > > ** ** > > The problem is that during route discovery the destination (target) node > does not forward route requests; so, nodes that lie downstream of the > destination node frequently create non-optimal routes to the > source. Knightly and Miskovic [1] have shown that "poorly selected paths > can have significantly higher routing-metric costs, and their duration ca= n > extend to minute time scales". **** > > We have verified that this problem exists in DYMO and LOADng.**** > > ** ** > > As a possible solution, we propose that route requests are always > forwarded, even by nodes generating a route reply [2,3]. The forwarded > request should include a flag stating that a reply has already been > initiated. In [3] it is shown that this increases the quality of routes. = Of > course this could increase the overhead of control messages, but in most = of > the cases the additional overhead is minimal, since a request floods the > entire network anyway.**** > > **** > > (2) Route Reply Loss**** > > -----------------------------**** > > AODV can lose route replies ( > http://www.ietf.org/mail-archive/web/manet/current/msg05702.html). **** > > The reason is that route replies are only forwarded by an intermediate > node when the node updates its routing table. **** > > This problem has partly been solved in DYMO and LOADng by increasing > sequence numbers when initiating a route reply.**** > > However, a careful analysis shows that replies can still be lost; yieldin= g > again non-optimal routes or route discovery failures. Namely, if one rout= e > reply overtakes another, i.e., a newer reply reaches a node earlier than = an > older one, then the older route reply is dropped [4].**** > > ** ** > > A solution consists of intermediate nodes always forwarding route > replies. Surely, forwarding (unicasting) replies increases the number of > messages in the network. But, (a) route discovery is more likely and (b) > re-sending a route request to establish a route would yield another > broadcast cycle, which is much more expensive w.r.t. network load.**** > > ** ** > > (3) Route Request Loss**** > > ---------------------------------------------**** > > Similar to (2), route requests might be lost in DYMO and LOADng.**** > > Namely, if one route request overtakes another, i.e., a newer request > reaches a node earlier than an older one, then the older route request is > dropped.**** > > This problem does not occur in AODV, thanks to the use of a list of > previously seen RREQ IDs.**** > > ** ** > > ---------------------------------------------**** > > > If requested we can provide more detailed explanations and examples.**** > > ** ** > > ** ** > > Rob van Glabbeek**** > > Peter H=F6fner**** > > Marius Portmann**** > > Wee Lum Tan**** > > (a team of networks and formal methods researchers at NICTA, working on > formally modelling and analysing MANET routing protocols)**** > > ** ** > > ** ** > > cheers**** > > Marius**** > > ** ** > > ** ** > > ** ** > > References**** > > ---------------**** > > [1] S. Miskovic and E. W. Knightly, "Routing primitives for wireless mesh > networks: Design, analysis and experiments", in Conference on Information > Communications (INFOCOM=9210). IEEE, 2010, pp. 2793-2801.**** > > networks.rice.edu/papers/MeshRoutingPrimitives.pdf**** > > [2] P. H=F6fner, R. J. van Glabbeek, W. L. Tan, M. Portmann, A. McIver, a= nd > A. Fehnker, "A rigorous analysis of AODV and its variants", in Modeling, > Analysis and Simulation of Wireless and Mobile Systems (MSWIM=9212). > ACM Press, 2012. doi:10.1145/2387238.2387274**** > > http://www.cse.unsw.edu.au/~rvg/pub/mswim12.pdf**** > > [3] A. Fehnker, R. J. van Glabbeek, P. H=F6fner, A. McIver, M. Portmann, = and > W. L. Tan, "Automated analysis of AODV using UPPAAL", in Tools and > Algorithms for the Construction and Analysis of Systems (TACAS=9212), LNC= S, > C. Flanagan and B. K=F6nig, Eds., vol. 7214. Springer, 2012, pp. 173=9618= 7. > doi:10.1007/978-3-642-28756-5_13**** > > http://www.cse.unsw.edu.au/~rvg/pub/tacas12.pdf**** > > [4] P. H=F6fner, and S. Edenhofer, "Towards a Rigorous Analysis of AODVv2 > (DYMO)", in Workshop on Rigorous Protocol Engineering, IEEE > http://www.nicta.com.au/pub?id=3D6169**** > > ** ** > > ** ** > > ----------------------------------------------------------------------***= * > > Dr Marius Portmann**** > > School of ITEE**** > > The University of Queensland**** > > Brisbane 4072, Australia**** > > CRICOS Provider No: 00025B**** > > Tel: +61 7 3300 8561, Fax: +61 7 3365 4999**** > > ----------------------------------------------------------------------***= * > > ** ** > > ** ** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --f46d043c7bd4e39cf304d0082e71 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Marius
=A0
Thanks for your feedback and referen= ces, but your analysis will be more interesting if I know when/how such dis= advantages happen in your work done so far. Could you inform on the list of= the evaluation you done as including number of nodes, mobility model, etc.= However, when I get time to read your references I can reply better.
=A0
No protocol is perfect in general :)
=A0
=
AB

On Tue, Dec 4, 2012 at 5:21= AM, Marius Portmann <marius@itee.uq.edu.au> wrote:

We have been following the recent discussion on DYMO and LOADng with inte= rest, and would like to share some of our findings and experience in this c= ontext, in the hope of being able to make a constructive contribution. Any feedback is appreciated.<= /u>

=A0

Based on a careful analysis of AODV, we have encountered problems that st= ill persist in both DYMO (ver 23) and LOADng (ver 6).<= /font>

=A0

(1) Non-Optimal Routes

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

On-demand/reactive routing protocols (such as=A0AODV, DYMO and LOADng)=A0= often fail to discover the best (shortest) routes [1,2].

=A0

The problem is that during route discovery the=A0destination (target) nod= e does not forward route requests; so,=A0nodes that lie downstream of the d= estination node frequently create non-optimal routes to the source.=A0Knightly and Miskovic [1] have=A0shown= that "poorly selected paths can have significantly higher routing-met= ric costs, and their duration can extend to minute time scales".=A0=

We have verified that this problem exists in DYMO and LOADng.

=A0

As a possible solution, we propose that route requests are always forward= ed, even by nodes generating a route reply [2,3].=A0The forwarded request s= hould include a flag stating that a reply has already been initiated. In [3] it is shown that this incr= eases the quality of routes.=A0Of course this could increase the overhead o= f control messages, but in most of the cases=A0the additional overhead is m= inimal, since=A0a request floods the entire network anyway.

=A0=A0

(2) Route Reply Loss

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

AODV can lose route replies (http://www.ietf.org/mail= -archive/web/manet/current/msg05702.html).=A0

The reason is that route replies=A0are only forwarded by an intermediate = node when the=A0node updates its routing table.=A0

This problem has partly been solved in DYMO and LOADng by increasing sequ= ence numbers when initiating a route reply.

However, a careful analysis shows that replies can still be lost; yieldin= g again non-optimal routes or route discovery failures.=A0Namely, if one ro= ute reply overtakes another, i.e., a newer reply reaches a node earlier than an older one, then the old= er route reply is dropped=A0[4].

=A0

A solution consists of intermediate nodes always forwarding route replies= .=A0Surely, forwarding (unicasting) replies increases the number of message= s in the network. But, (a) route discovery is more likely and (b) re-sending a route request to establish a= route would yield another broadcast =A0cycle, which is much more expensive= w.r.t. network load.

=A0

(3) Route Request Loss

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

Similar to (2),=A0route requests might be lost in DYMO and LOADng.=

Namely, if one route request overtakes another, i.e., a newer request rea= ches a node earlier than an older one, then the older route request is drop= ped.

This problem does not occur in AODV, thanks to the use of a list of previ= ously seen RREQ IDs.

=A0

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


If requested we can provide =A0more detailed explanations and examples.<= /u>

=A0

=A0

Rob van Glabbeek

Peter H=F6fner

Marius Portmann

Wee Lum Tan

(a team of networks and formal methods researchers at NICTA, working on f= ormally modelling and analysing MANET routing protocols)

=A0

=A0

cheers

Marius

=A0

=A0

=A0

References

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

[1] S. Miskovic and E. W. Knightly, "Routing primitives for wireless= mesh networks: Design, analysis and experiments", in Conference on In= formation Communications (INFOCOM=9210). IEEE, 2010, pp. 2793-2801.

networks.rice.edu/papers/MeshRoutingPrimitives.pdf

[2] P. H=F6fner, R. J. van Glabbeek, W. L. Tan, M. Portmann, A. McIver, a= nd A. Fehnker, "A rigorous analysis of AODV and its variants", in= Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWIM=9212). ACM=A0Press, 2012.=A0doi:10.1145/2387238.= 2387274

http://www.cse.unsw.edu.au/~rvg/pub/mswim12.pdf

[3]=A0A. Fehnker, R. J. van Glabbeek, P. H=F6fner, A. McIver, M. Portmann= , and W. L. Tan, "Automated analysis of AODV using UPPAAL", in To= ols and Algorithms for the Construction and Analysis of Systems (TACAS=9212), LNCS, C. Flanagan and B. K=F6nig, Eds., = vol. 7214. Springer, 2012, pp. 173=96187. doi:10.1007/978-3-642-28756-5_13<= u>

http://www.cse.unsw.edu.au/~rvg/pub/tacas12.pdf

= [4] P. H=F6fner, and S. Edenhofer, "Tow= ards a Rigorous Analysis of AODVv2 (DYMO)", in Workshop on Rigorous Pr= otocol Engineering, IEEE
h= ttp://www.nicta.com.au/pub?id=3D6169=

=A0

=A0

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

Dr Marius Portmann=

School of ITEE<= /u>

The University of = Queensland

Brisbane 4072, Aus= tralia

CRICOS Provider No= : 00025B

Tel: +61 7 3= 300 8561, Fax: +61 7 3365 4999

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

=A0

=A0


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--f46d043c7bd4e39cf304d0082e71-- From sratliff@cisco.com Tue Dec 4 07:09:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7199D21F8AF4 for ; Tue, 4 Dec 2012 07:09:28 -0800 (PST) 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 dFi+joTST+BR for ; Tue, 4 Dec 2012 07:09:27 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A982121F8AA2 for ; Tue, 4 Dec 2012 07:09:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=655; q=dns/txt; s=iport; t=1354633767; x=1355843367; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KEHc00RU18HLAEUhfLCOllryYKr6KRJXSMD9CfBynsM=; b=cALkV49Aosp6koAvj/9+nhrYqeNyDHyf3RQZqys7kBEWmPbFGKJXvLJr 8sc0DT8EGdUQc3kpc1HYsMtmsMMAZMlVeNemjxQ9VFBedRYyJMlOwytjW T8oFJ48SphZLfVQzNmxPg43fdosGCtVea33/S2cTYce///UE/aXPzGg8o k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYFAEIRvlCtJV2b/2dsb2JhbABEhWy2OYIIFnOCHgEBAQMBeQULAgEIGAokMiUCBA4FCIgCBrE6kFSMN4NgYQOIKp4ggnKCIQ X-IronPort-AV: E=McAfee;i="5400,1158,6915"; a="148993631" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 04 Dec 2012 15:09:23 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qB4F9NoZ023055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Dec 2012 15:09:23 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.161]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Tue, 4 Dec 2012 09:09:23 -0600 From: "Stan Ratliff (sratliff)" To: manet List Thread-Topic: WG LC for the OLSRv2-MIB? Thread-Index: AQHN0dvGgZf0yDiVmkar35EYUeLrmpgI8UgAgAAyRgA= Date: Tue, 4 Dec 2012 15:09:22 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF07610@xmb-aln-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.115] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <22E9072313852B44A5CB20F3D436F70A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Robert G. Cole" , Thomas Heide Clausen Subject: Re: [manet] WG LC for the OLSRv2-MIB? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 15:09:28 -0000 All,=20 We are starting a 2-week Working Group Last call on the OLSRv2 MIB.=20 Regards, Stan On Dec 4, 2012, at 7:09 AM, Thomas Clausen wrote: > Seconded (as-if that was needed) from me. >=20 > The pending issue in OLSRv2 relates to security, and its resolution shoul= d not have any impact on the MIB. >=20 > Thomas >=20 > On Dec 4, 2012, at 5:56 AM, Ulrich Herberg wrote: >=20 >> Stan, Joe, >>=20 >> As I said during the last [manet] meeting, I believe that the OLSRv2-MIB= draft is ready for a WG LC. I would like to ask you to consider requesting= a WG LC. >>=20 >> Best regards >> Ulrich >=20 From sratliff@cisco.com Tue Dec 4 07:14:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FB221F8BF3 for ; Tue, 4 Dec 2012 07:14:31 -0800 (PST) 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 quiPYTYedg9V for ; Tue, 4 Dec 2012 07:14:30 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA2121F8BF2 for ; Tue, 4 Dec 2012 07:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=143; q=dns/txt; s=iport; t=1354634070; x=1355843670; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Zm3Ut76iRgHx0jltIM1gM3dXi9h96Y95NRMboPHTYV4=; b=X66Z9MXYx0eBmiEU8BJVWj5prOMlFtj5d2ijbBGJ/8MtU1WGORluc4Og hKfT/VXIQn/GqxMaeLflsdaU9nPa6owt31Q9E+oQQHFMyEL62TiGXm8fm 0mhPXvCStWfzvvmvWf2o0nfUF4DSoE4WfzikbnaChhWHHpWAJekfOPLeU 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABgSvlCtJXG8/2dsb2JhbABEvi0Wc4IgAQQ6UQEqFEInBBuICKAukQ+QVIw3g2BhA6ZKgnKCIQ X-IronPort-AV: E=McAfee;i="5400,1158,6915"; a="149212245" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 04 Dec 2012 15:14:29 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qB4FETqP023224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Dec 2012 15:14:29 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.161]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Tue, 4 Dec 2012 09:14:29 -0600 From: "Stan Ratliff (sratliff)" To: manet List Thread-Topic: draft-ietf-manet-smf-mib-06 in WGLC status Thread-Index: AQHN0jIOT6D77y7E706zdie+/cDptg== Date: Tue, 4 Dec 2012 15:14:29 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF076DD@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.115] Content-Type: text/plain; charset="us-ascii" Content-ID: <5A3AD6D4F8207E4E82DACBC7C352C2AD@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [manet] draft-ietf-manet-smf-mib-06 in WGLC status X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 15:14:31 -0000 All,=20 Let's also start a 2-week WGLC on the above draft. Review and comment (if y= ou're going to) by 12/28/2012.=20 Regards, Stan= From charliep@computer.org Tue Dec 4 10:26:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B0F21F8CB0 for ; Tue, 4 Dec 2012 10:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 FvMJIWkjVz6n for ; Tue, 4 Dec 2012 10:26:13 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id C331C21F8CAE for ; Tue, 4 Dec 2012 10:26:12 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TfxC7-0006Ri-DH; Tue, 04 Dec 2012 13:26:11 -0500 Message-ID: <50BE4036.30507@computer.org> Date: Tue, 04 Dec 2012 10:25:58 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Marius Portmann References: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> In-Reply-To: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> Content-Type: multipart/alternative; boundary="------------010302090205060505060308" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad861efc673f53c3bb5e637f511fc4fc19ea350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "'manet@ietf.org'" Subject: Re: [manet] DYMO/AODVv2 and LOADng -- Problems and Proposed Solutions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 18:26:13 -0000 This is a multi-part message in MIME format. --------------010302090205060505060308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Marius, Interesting results. I have some follow-up questions. On 12/3/2012 9:21 PM, Marius Portmann wrote: > > (1) Non-Optimal Routes > > -------------------------------- > > On-demand/reactive routing protocols (such as AODV, DYMO and > LOADng) often fail to discover the best (shortest) routes [1,2]. > This is certainly true. There have been measurements about how far from optimal the routes can be, and if I remember correctly it's typically somewhere in the neighborhood of 10%, depending on congestion and node mobility. > The problem is that during route discovery the destination (target) > node does not forward route requests; so, nodes that lie downstream of > the destination node frequently create non-optimal routes to the > source. Knightly and Miskovic [1] have shown that "poorly selected > paths can have significantly higher routing-metric costs, and their > duration can extend to minute time scales". > > We have verified that this problem exists in DYMO and LOADng. > Moreover, the result makes intuitive sense. However, the nodes which establish non-optimalroutes to the source are also unlikely to use those routes. > As a possible solution, we propose that route requests are always > forwarded, even by nodes generating a route reply [2,3]. The forwarded > request should include a flag stating that a reply has already been > initiated. In [3] it is shown that this increases the quality of > routes. Of course this could increase the overhead of control > messages, but in most of the cases the additional overhead is minimal, > since a request floods the entire network anyway. > This can be made into an optional behavior, controllable either by a system-wide configuration parameter, or a new RREQ option. I would not expect that it should be the default behavior. > (2) Route Reply Loss > > ----------------------------- > > AODV can lose route replies > (http://www.ietf.org/mail-archive/web/manet/current/msg05702.html). > > The reason is that route replies are only forwarded by an intermediate > node when the node updates its routing table. > > This problem has partly been solved in DYMO and LOADng by increasing > sequence numbers when initiating a route reply. > > However, a careful analysis shows that replies can still be lost; > yielding again non-optimal routes or route discovery failures. Namely, > if one route reply overtakes another, i.e., a newer reply reaches a > node earlier than an older one, then the older route reply is dropped [4]. > I guess you mean that the two RREPs under discussion were going towards two distinct Originating Nodes. Otherwise, it would be good for the older RREP to be dropped. For the case of two distinct Originating Nodes, the behavior is a protocol error that needs to be fixed."Always forwarding" RREPs is one alternative, and certainly preferable to a new Route Discovery cyclein the network. I am confident that there is a better solution, and I will work on finding and specifying it. > (3) Route Request Loss > > --------------------------------------------- > > Similar to (2), route requests might be lost in DYMO and LOADng. > > Namely, if one route request overtakes another, i.e., a newer request > reaches a node earlier than an older one, then the older route request > is dropped. > > This problem does not occur in AODV, thanks to the use of a list of > previously seen RREQ IDs. > I think that a "better" solution for (2) will also resolve this problem. Here, the solution of "always forwarding" seems much less palatable. Thanks much for reporting these error cases, and for providing the references. -- Regards, Charlie P. --------------010302090205060505060308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello Marius,

Interesting results.  I have some follow-up questions.

On 12/3/2012 9:21 PM, Marius Portmann wrote:

(1) Non-Optimal Routes

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

On-demand/reactive routing protocols (such as AODV, DYMO and LOADng) often fail to discover the best (shortest) routes [1,2].


This is certainly true.  There have been measurements about how far from optimal
the routes can be, and if I remember correctly it's typically somewhere in the
neighborhood of 10%, depending on congestion and node mobility.

 

The problem is that during route discovery the destination (target) node does not forward route requests; so, nodes that lie downstream of the destination node frequently create non-optimal routes to the source. Knightly and Miskovic [1] have shown that "poorly selected paths can have significantly higher routing-metric costs, and their duration can extend to minute time scales". 

We have verified that this problem exists in DYMO and LOADng.


Moreover, the result makes intuitive sense.  However, the nodes which establish
non-optimal routes to the source are also unlikely to use those routes.

 

As a possible solution, we propose that route requests are always forwarded, even by nodes generating a route reply [2,3]. The forwarded request should include a flag stating that a reply has already been initiated. In [3] it is shown that this increases the quality of routes. Of course this could increase the overhead of control messages, but in most of the cases the additional overhead is minimal, since a request floods the entire network anyway.


This can be made into an optional behavior, controllable either by a
system-wide configuration parameter, or a new RREQ option.  I would
not expect that it should be the default behavior.

(2) Route Reply Loss

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

AODV can lose route replies (http://www.ietf.org/mail-archive/web/manet/current/msg05702.html). 

The reason is that route replies are only forwarded by an intermediate node when the node updates its routing table. 

This problem has partly been solved in DYMO and LOADng by increasing sequence numbers when initiating a route reply.

However, a careful analysis shows that replies can still be lost; yielding again non-optimal routes or route discovery failures. Namely, if one route reply overtakes another, i.e., a newer reply reaches a node earlier than an older one, then the older route reply is dropped [4].


I guess you mean that the two RREPs under discussion were going towards
two distinct Originating Nodes.  Otherwise, it would be good for the older RREP
to be dropped.

For the case of two distinct Originating Nodes, the behavior is a protocol
error that needs to be fixed.  "Always forwarding" RREPs is one alternative,
and certainly preferable to a new Route Discovery cycle in the network.
I am confident that there is a better solution, and I will work on finding
and specifying it.

 

(3) Route Request Loss

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

Similar to (2), route requests might be lost in DYMO and LOADng.

Namely, if one route request overtakes another, i.e., a newer request reaches a node earlier than an older one, then the older route request is dropped.

This problem does not occur in AODV, thanks to the use of a list of previously seen RREQ IDs.


I think that a "better" solution for (2) will also resolve this problem.
Here, the solution of "always forwarding" seems much less palatable.

Thanks much for reporting these error cases, and for providing the
references.

-- 
Regards,
Charlie P.
--------------010302090205060505060308-- From yi.jiazi@gmail.com Wed Dec 5 09:34:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D5B21F8C9F for ; Wed, 5 Dec 2012 09:34:15 -0800 (PST) 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 1gPK4RkgZck5 for ; Wed, 5 Dec 2012 09:34:10 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 0493021F8C04 for ; Wed, 5 Dec 2012 09:34:09 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so1617796wib.13 for ; Wed, 05 Dec 2012 09:34:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=s24gN3f036OidFIaXjLURyYzvPnIrLDrVvH2LUw2NXs=; b=Wgepgl/2uQHjI4y12MWJO6NfNsdme//M2ONyyHr49sEwt8eTQf8w7AP2hkeQ4xp8cc fyaoekRzeDyS9+OiWzB8f4DJFFjj9p4puydtUCyfid1vz+Mv/DK997/6/eHf6l/bmg4o I4aWWZHyzBAe3YQwgdX9h4NpKmjrK0O3Gg3K4p5Z01QbVqbpXpy1adn+1diJbRzql7I8 nRxDq5spPUskUrm/756SIN66Mcn50VKZRGY2p6rc0pCsA333Nox2nt9P5J0AyModyAju QCATMkj8XnclUr8R45WPU/eIQ1fKiC4C1G5ghzo5w6VKPXbJ2uA8mxuS9784Zam7yA9q 1JSw== Received: by 10.180.97.137 with SMTP id ea9mr4516021wib.13.1354728848921; Wed, 05 Dec 2012 09:34:08 -0800 (PST) Received: from new-host-2.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id bz12sm7311083wib.5.2012.12.05.09.34.05 (version=SSLv3 cipher=OTHER); Wed, 05 Dec 2012 09:34:07 -0800 (PST) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_6EBDA084-9B44-4383-8968-3106AE4A0341" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi YI In-Reply-To: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> Date: Wed, 5 Dec 2012 18:34:04 +0100 Message-Id: References: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> To: Marius Portmann X-Mailer: Apple Mail (2.1499) Cc: "'manet@ietf.org'" Subject: Re: [manet] DYMO/AODVv2 and LOADng -- Problems and Proposed Solutions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 17:34:15 -0000 --Apple-Mail=_6EBDA084-9B44-4383-8968-3106AE4A0341 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Marius,=20 Thanks for you valuable comments, please check inline: On Dec 4, 2012, at 6:21 AM, Marius Portmann = wrote: > We have been following the recent discussion on DYMO and LOADng with = interest, and would like to share some of our findings and experience in = this context, in the hope of being able to make a constructive = contribution. Any feedback is appreciated. > =20 > Based on a careful analysis of AODV, we have encountered problems that = still persist in both DYMO (ver 23) and LOADng (ver 6). > =20 > (1) Non-Optimal Routes > -------------------------------- > On-demand/reactive routing protocols (such as AODV, DYMO and LOADng) = often fail to discover the best (shortest) routes [1,2]. > =20 > The problem is that during route discovery the destination (target) = node does not forward route requests; so, nodes that lie downstream of = the destination node frequently create non-optimal routes to the source. = Knightly and Miskovic [1] have shown that "poorly selected paths can = have significantly higher routing-metric costs, and their duration can = extend to minute time scales".=20 > We have verified that this problem exists in DYMO and LOADng. > =20 > As a possible solution, we propose that route requests are always = forwarded, even by nodes generating a route reply [2,3]. The forwarded = request should include a flag stating that a reply has already been = initiated. In [3] it is shown that this increases the quality of routes. = Of course this could increase the overhead of control messages, but in = most of the cases the additional overhead is minimal, since a request = floods the entire network anyway. In LOADng, only bi-diretional routes are used by default, i.e. only the = routes that are verified by RREP are used. So I think the example you = mentioned in figure 2 of [3,4] shouldn't be a problem for LOADng. =20 Of course, another well-known non-optimal routes problem is because of = the broadcast nature of on-demand protocol. The LOADng authors are still = discussing how to improve it.=20 > =20 > (2) Route Reply Loss > ----------------------------- > AODV can lose route replies = (http://www.ietf.org/mail-archive/web/manet/current/msg05702.html).=20 > The reason is that route replies are only forwarded by an intermediate = node when the node updates its routing table.=20 > This problem has partly been solved in DYMO and LOADng by increasing = sequence numbers when initiating a route reply. > However, a careful analysis shows that replies can still be lost; = yielding again non-optimal routes or route discovery failures. Namely, = if one route reply overtakes another, i.e., a newer reply reaches a node = earlier than an older one, then the older route reply is dropped [4]. > =20 > A solution consists of intermediate nodes always forwarding route = replies. Surely, forwarding (unicasting) replies increases the number of = messages in the network. But, (a) route discovery is more likely and (b) = re-sending a route request to establish a route would yield another = broadcast cycle, which is much more expensive w.r.t. network load. I think it would be safe to forward every unicast RREPs.=20 In the meantime, I'm wondering how often the situation that you = mentioned in fig 1 of [4] would happen. Because it requires 1) two RREPs = are generated in very short time interval and 2) The route set up by = broadcasting two RREQs between the two nodes (B and T in your example) = are different.=20 I'll first check this with other LOADng authors also, to see which might = be the better choice to make.=20 > =20 > (3) Route Request Loss > --------------------------------------------- > Similar to (2), route requests might be lost in DYMO and LOADng. > Namely, if one route request overtakes another, i.e., a newer request = reaches a node earlier than an older one, then the older route request = is dropped. > This problem does not occur in AODV, thanks to the use of a list of = previously seen RREQ IDs. > =20 > --------------------------------------------- Could you please have an example of this? What you said, the case that a = newer RREQ reaches a node earlier than an older one, shouldn't happen. = Because in LOADng, the originator of RREQ has a rate limit, i.e. certain = interval. If an old RREQ came to an intermediate router that slow, = probably it shouldn't be forwarded anyway, because it has great = possibility to carry bad route information.=20 best Jiazi >=20 > If requested we can provide more detailed explanations and examples. > =20 > =20 > Rob van Glabbeek > Peter H=F6fner > Marius Portmann > Wee Lum Tan > (a team of networks and formal methods researchers at NICTA, working = on formally modelling and analysing MANET routing protocols) > =20 > =20 > cheers > Marius > =20 > =20 > =20 > References > --------------- > [1] S. Miskovic and E. W. Knightly, "Routing primitives for wireless = mesh networks: Design, analysis and experiments", in Conference on = Information Communications (INFOCOM=9210). IEEE, 2010, pp. 2793-2801. > networks.rice.edu/papers/MeshRoutingPrimitives.pdf > [2] P. H=F6fner, R. J. van Glabbeek, W. L. Tan, M. Portmann, A. = McIver, and A. Fehnker, "A rigorous analysis of AODV and its variants", = in Modeling, Analysis and Simulation of Wireless and Mobile Systems = (MSWIM=9212). ACM Press, 2012. doi:10.1145/2387238.2387274 > http://www.cse.unsw.edu.au/~rvg/pub/mswim12.pdf > [3] A. Fehnker, R. J. van Glabbeek, P. H=F6fner, A. McIver, M. = Portmann, and W. L. Tan, "Automated analysis of AODV using UPPAAL", in = Tools and Algorithms for the Construction and Analysis of Systems = (TACAS=9212), LNCS, C. Flanagan and B. K=F6nig, Eds., vol. 7214. = Springer, 2012, pp. 173=96187. doi:10.1007/978-3-642-28756-5_13 > http://www.cse.unsw.edu.au/~rvg/pub/tacas12.pdf > [4] P. H=F6fner, and S. Edenhofer, "Towards a Rigorous Analysis of = AODVv2 (DYMO)", in Workshop on Rigorous Protocol Engineering, IEEE > http://www.nicta.com.au/pub?id=3D6169 >=20 > =20 > =20 > ---------------------------------------------------------------------- > Dr Marius Portmann > School of ITEE > The University of Queensland > Brisbane 4072, Australia > CRICOS Provider No: 00025B > Tel: +61 7 3300 8561, Fax: +61 7 3365 4999 > ---------------------------------------------------------------------- > =20 > =20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_6EBDA084-9B44-4383-8968-3106AE4A0341 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Marius, 

Thanks for you valuable = comments, please check inline:

On Dec 4, 2012, at 6:21 AM, Marius Portmann <marius@itee.uq.edu.au> = wrote:

We have been following the recent discussion = on DYMO and LOADng with interest, and would like to share some of our = findings and experience in this context, in the hope of being able to = make a constructive contribution. Any feedback is = appreciated.
Based on a careful = analysis of AODV, we have encountered problems that still persist in = both DYMO (ver 23) and LOADng (ver = 6).
(1) Non-Optimal = Routes
On-demand/reactive routing protocols (such = as AODV, DYMO and LOADng) often fail to discover the best = (shortest) routes [1,2].
 
The problem is that during route discovery = the destination (target) node does not forward route requests; = so, nodes that lie downstream of the destination node frequently = create non-optimal routes to the source. Knightly and Miskovic [1] = have shown that "poorly selected paths can have significantly = higher routing-metric costs, and their duration can extend to minute = time scales". 
We = have verified that this problem exists in DYMO and = LOADng.
As a possible = solution, we propose that route requests are always forwarded, even by = nodes generating a route reply [2,3]. The forwarded request should = include a flag stating that a reply has already been initiated. In [3] = it is shown that this increases the quality of routes. Of course = this could increase the overhead of control messages, but in most of the = cases the additional overhead is minimal, since a request = floods the entire network = anyway.

In= LOADng, only bi-diretional routes are used by default, i.e. only the = routes that are verified by RREP are used. So I think the example you = mentioned in figure 2 of [3,4] shouldn't be a problem for LOADng. =  

Of course, another well-known = non-optimal routes problem is because of the broadcast nature of = on-demand protocol. The LOADng authors are still discussing how to = improve it. 

(2) Route = Reply Loss





 
(3) Route Request = Loss
Similar to = (2), route requests might be lost in DYMO and = LOADng.
Namely, if = one route request overtakes another, i.e., a newer request reaches a = node earlier than an older one, then the older route request is = dropped.
This = problem does not occur in AODV, thanks to the use of a list of = previously seen RREQ IDs.
 

If requested we can provide  more = detailed explanations and examples.
 
 
Rob van = Glabbeek
Peter = H=F6fner
Marius = Portmann
Wee Lum = Tan
(a team of = networks and formal methods researchers at NICTA, working on formally = modelling and analysing MANET routing = protocols)
________________________________= _______________
manet mailing list
 Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Marius Portmann References: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> <50BE4036.30507@computer.org> In-Reply-To: <50BE4036.30507@computer.org> Content-Type: multipart/alternative; boundary="------------080202080302080402080201" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86da871ff8e92b2647fd2e89e063f2ee3e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "'manet@ietf.org'" Subject: Re: [manet] DYMO/AODVv2 and LOADng -- Problems and Proposed Solutions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 19:33:51 -0000 This is a multi-part message in MIME format. --------------080202080302080402080201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello again Marius, I have been looking for the protocol error, and up until now have not found it. I probably should have looked closer before sending my reply to you yesterday. Here is a summary of the relevant protocol details that affect processing (and, retransmission) of RREQ and RREP messages. - Check that the RREQ or RREP is "valid" - Test all the routing information and use when permissible - Update certain fields of the incoming message - Decide whether to advertise availability for forwarding - If so, retransmit (or, consume the RREQ and transmit RREP) The relevant point is that an AODVv2 router retransmits the RREQ or RREP regardless of whether the AODVv2 router used the incoming routing information to update its route table. I thought there might be some wording to the contrary, but after reading the relevant parts of the specification several times I haven't found any such wording. Please let me know what I have missed. Otherwise, since the AODVv2 routers typically do retransmit route discovery messages even when not using the routing information contained by those route discovery messages, I think the problem you identified for earlier protocols does not arise. Regards, Charlie P. On 12/4/2012 10:25 AM, Charles E. Perkins wrote: > > Hello Marius, > > Interesting results. I have some follow-up questions. > > On 12/3/2012 9:21 PM, Marius Portmann wrote: >> >> (1) Non-Optimal Routes >> >> -------------------------------- >> >> On-demand/reactive routing protocols (such as AODV, DYMO and >> LOADng) often fail to discover the best (shortest) routes [1,2]. >> > > This is certainly true. There have been measurements about how far > from optimal > the routes can be, and if I remember correctly it's typically > somewhere in the > neighborhood of 10%, depending on congestion and node mobility. > >> The problem is that during route discovery the destination (target) >> node does not forward route requests; so, nodes that lie downstream >> of the destination node frequently create non-optimal routes to the >> source. Knightly and Miskovic [1] have shown that "poorly selected >> paths can have significantly higher routing-metric costs, and their >> duration can extend to minute time scales". >> >> We have verified that this problem exists in DYMO and LOADng. >> > > Moreover, the result makes intuitive sense. However, the nodes which > establish > non-optimalroutes to the source are also unlikely to use those routes. > >> As a possible solution, we propose that route requests are always >> forwarded, even by nodes generating a route reply [2,3]. The >> forwarded request should include a flag stating that a reply has >> already been initiated. In [3] it is shown that this increases the >> quality of routes. Of course this could increase the overhead of >> control messages, but in most of the cases the additional overhead is >> minimal, since a request floods the entire network anyway. >> > > This can be made into an optional behavior, controllable either by a > system-wide configuration parameter, or a new RREQ option. I would > not expect that it should be the default behavior. > > >> (2) Route Reply Loss >> >> ----------------------------- >> >> AODV can lose route replies >> (http://www.ietf.org/mail-archive/web/manet/current/msg05702.html). >> >> The reason is that route replies are only forwarded by an >> intermediate node when the node updates its routing table. >> >> This problem has partly been solved in DYMO and LOADng by increasing >> sequence numbers when initiating a route reply. >> >> However, a careful analysis shows that replies can still be lost; >> yielding again non-optimal routes or route discovery >> failures. Namely, if one route reply overtakes another, i.e., a newer >> reply reaches a node earlier than an older one, then the older route >> reply is dropped [4]. >> > > I guess you mean that the two RREPs under discussion were going towards > two distinct Originating Nodes. Otherwise, it would be good for the > older RREP > to be dropped. > > For the case of two distinct Originating Nodes, the behavior is a protocol > error that needs to be fixed."Always forwarding" RREPs is one alternative, > and certainly preferable to a new Route Discovery cyclein the network. > I am confident that there is a better solution, and I will work on finding > and specifying it. > >> (3) Route Request Loss >> >> --------------------------------------------- >> >> Similar to (2), route requests might be lost in DYMO and LOADng. >> >> Namely, if one route request overtakes another, i.e., a newer request >> reaches a node earlier than an older one, then the older route >> request is dropped. >> >> This problem does not occur in AODV, thanks to the use of a list of >> previously seen RREQ IDs. >> > > I think that a "better" solution for (2) will also resolve this problem. > Here, the solution of "always forwarding" seems much less palatable. > > Thanks much for reporting these error cases, and for providing the > references. > > -- > Regards, > Charlie P. -- Regards, Charlie P. --------------080202080302080402080201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello again Marius,

I have been looking for the protocol error, and up until now have not
found it.  I probably should have looked closer before sending my
reply to you yesterday.   Here is a summary of the relevant protocol
details that affect processing (and, retransmission) of RREQ and RREP
messages.

- Check that the RREQ or RREP is "valid"
- Test all the routing information and use when permissible
- Update certain fields of the incoming message
- Decide whether to advertise availability for forwarding
- If so, retransmit (or, consume the RREQ and transmit RREP)

The relevant point is that an AODVv2 router retransmits the
RREQ or RREP regardless of whether the AODVv2 router used
the incoming routing information to update its route table.

I thought there might be some wording to the contrary, but after
reading the relevant parts of the specification several times I haven't
found any such wording.  Please let me know what I have missed.

Otherwise, since the AODVv2 routers typically do retransmit
route discovery messages even when not using the routing
information contained by those route discovery messages, I think
the problem you identified for earlier protocols does not arise.

Regards,
Charlie P.


On 12/4/2012 10:25 AM, Charles E. Perkins wrote:

Hello Marius,

Interesting results.  I have some follow-up questions.

On 12/3/2012 9:21 PM, Marius Portmann wrote:

(1) Non-Optimal Routes

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

On-demand/reactive routing protocols (such as AODV, DYMO and LOADng) often fail to discover the best (shortest) routes [1,2].


This is certainly true.  There have been measurements about how far from optimal
the routes can be, and if I remember correctly it's typically somewhere in the
neighborhood of 10%, depending on congestion and node mobility.

 

The problem is that during route discovery the destination (target) node does not forward route requests; so, nodes that lie downstream of the destination node frequently create non-optimal routes to the source. Knightly and Miskovic [1] have shown that "poorly selected paths can have significantly higher routing-metric costs, and their duration can extend to minute time scales". 

We have verified that this problem exists in DYMO and LOADng.


Moreover, the result makes intuitive sense.  However, the nodes which establish
non-optimal routes to the source are also unlikely to use those routes.

 

As a possible solution, we propose that route requests are always forwarded, even by nodes generating a route reply [2,3]. The forwarded request should include a flag stating that a reply has already been initiated. In [3] it is shown that this increases the quality of routes. Of course this could increase the overhead of control messages, but in most of the cases the additional overhead is minimal, since a request floods the entire network anyway.


This can be made into an optional behavior, controllable either by a
system-wide configuration parameter, or a new RREQ option.  I would
not expect that it should be the default behavior.

(2) Route Reply Loss

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

AODV can lose route replies (http://www.ietf.org/mail-archive/web/manet/current/msg05702.html). 

The reason is that route replies are only forwarded by an intermediate node when the node updates its routing table. 

This problem has partly been solved in DYMO and LOADng by increasing sequence numbers when initiating a route reply.

However, a careful analysis shows that replies can still be lost; yielding again non-optimal routes or route discovery failures. Namely, if one route reply overtakes another, i.e., a newer reply reaches a node earlier than an older one, then the older route reply is dropped [4].


I guess you mean that the two RREPs under discussion were going towards
two distinct Originating Nodes.  Otherwise, it would be good for the older RREP
to be dropped.

For the case of two distinct Originating Nodes, the behavior is a protocol
error that needs to be fixed.  "Always forwarding" RREPs is one alternative,
and certainly preferable to a new Route Discovery cycle in the network.
I am confident that there is a better solution, and I will work on finding
and specifying it.

 

(3) Route Request Loss

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

Similar to (2), route requests might be lost in DYMO and LOADng.

Namely, if one route request overtakes another, i.e., a newer request reaches a node earlier than an older one, then the older route request is dropped.

This problem does not occur in AODV, thanks to the use of a list of previously seen RREQ IDs.


I think that a "better" solution for (2) will also resolve this problem.
Here, the solution of "always forwarding" seems much less palatable.

Thanks much for reporting these error cases, and for providing the
references.

-- 
Regards,
Charlie P.


-- 
Regards,
Charlie P.
--------------080202080302080402080201-- From charliep@computer.org Wed Dec 5 13:45:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C52421F8BA7 for ; Wed, 5 Dec 2012 13:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[AWL=-1.532, BAYES_00=-2.599, FRT_LOLITA1=1.865, J_CHICKENPOX_43=0.6, J_CHICKENPOX_56=0.6] 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 GPp58clgN7Oq for ; Wed, 5 Dec 2012 13:45:19 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9770521F8B99 for ; Wed, 5 Dec 2012 13:45:19 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TgMmM-0003Bs-7U; Wed, 05 Dec 2012 16:45:18 -0500 Message-ID: <50BFC05E.4030006@computer.org> Date: Wed, 05 Dec 2012 13:45:02 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Henning Rogge References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> In-Reply-To: <50BCA857.8070400@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8685a0726fe8e010f9ffcbd07a94446bef350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 21:45:21 -0000 Hello Henning, Here is some more follow-up on your observations and suggestions. On 12/3/2012 5:25 AM, Henning Rogge wrote: > > > Handling Router (HandlingRtr) > > HandlingRtr denotes the AODVv2 router handling an AODVv2 message. > > Do you really need the "HandlingRtr" abbreviation? It complicates the > text and does not shorten it that much. Would you like to see this terminology changed to instead be "Handler"? I guess there's no need to constantly remind the reader that the node doing the AODVv2 processing is a "router"... > > Page 6: > > > Originating Node (OrigNode) > > > Originating Router (OrigRtr) > > See comment to "HandlingRtr". Well, yes, but here the abbreviation really is a bit shorter. > > > Router Client > > An AODVv2 router may be configured with a list of other IP > > addresses and networks which correspond to other non-router nodes > > which require the services of the AODVv2 router for route > > discovery and maintenance. An AODVv2 is always its own client, so > > that the list of client IP addresses is never empty. > > > > Sequence Number (SeqNum) > > Same as AODVv2 Sequence Number. > > If this is the same, why do you need "AODVv2 Sequence Number" ? Just > use "Sequence Number" O.K. I will change the instances of AODVv2 Sequence Number as you suggest, and use "Sequence Number" instead. It does read better that way. > > > Target Node (TargNode) > > The Target Node denotes the node for which a route is needed. > > > > Target Router (TargRtr) > > The TargetRtr denotes the AODVv2 router which serves TargNode. > > TargRtr? TargetRtr? TargetRouter? I'll make them all consistent, using TargRtr. > > Page 8: > > > +--------------------+-------------------------------------------+ > > | Notation | Information Location and/or Meaning | > > +--------------------+-------------------------------------------+ > > | Route[DestAddr] | A route table entry towards DestAddr | > > | Route[Addr]{field} | A field in a route table entry | > > | -- | -- | > > | RREQ.{field} | Field in RREQ | > > | RREP.{field} | Field in RREP | > > | RERR.{field} | Field in RERR | > > Maybe RREQ{field} to be costistent with the Route notation? It turns out that the '.' notation was much more prevalent, so I changed Route[Addr]{field} to be Route[Addr].{field}. > > > | -- | -- | > > | MsgHdr | the RFC5444 Message Header | > > | MsgTLV | an RFC5444 Message TLV | > > | MetricTypeTLV | MetricType MsgTLV for Metric AddrTLV | > > | MAL | MsgHdr. | > > Do you really need this abbreviation? Do you mean MAL? Or MsgHdr? I have gone through the document and replaced MsgHdr with Message Header. In some cases, this required a bit of rewording for easier reading. > > > | -- | -- | > > | AddrBlk | an RFC5444 address block | > > | AddrBlk[1] | The first address slot in AddrBlk | > > | AddrBlk[N] | The Nth address slot in AddrBlk | > > | AddrBlk[OrigNode] | AddrBlk[1] | > > | AddrBlk[TargNode] | AddrBlk[2] | > > Using the order of addresses in an address block as protocol semantics > is a bad idea. Use TLVs attached to the addresses to identify their > purpose. Still pondering this, and awaiting more discussion on the mailing list... > > > | AddrTLV | an RFC5444 address block TLV | > > Is this an address TLV block (a list of TLVs) or an address block TLV > (a single TLV) ? > > The following notation suggests its a TLV block. It is intended to be a TLV block as defined by RFC 5444, and the description changed accordingly. > > > | HopCountTLV | Metric8 AddrTLV when MetricTypeTLV=3 | > > Defining an abbreviation for a TLV that depends on the value of a > different TLV is confusing. Please let me know if you still think so after a few more days. To me, this seems very natural. However, the term is never used in the document, so I have deleted it. > > > | Metric8TLV | Metric8 AddrTLV | > > | SeqNumTLV | Sequence Number TLV for AddrBlk addresses | > > | RteAddrBlk | the main address block in a RteMsg | > > RteMsg ? Less abbreviations! RteMsg turns out to be a very handy abbreviation. Maybe if there are fewer other abbreviations, RteMsg won't seem so unwelcome. I'm trying to reduce them. > > Page 10: > > > 5. Data Structures > > > > 5.1. Route Table Entry > > > > The route table entry is a conceptual data structure. > > Implementations may use any internal representation so long as it > > provides access to the same information as specified below. > > > > Conceptually, a route table entry has the following fields: > > > > Route.Address > > The (host or network) destination address of the node(s) > > associated with the routing table entry > > > > Route.PfxLen > > Another confusing abbreviation. > > The value is the length of the netmask/prefix. If the value of > > the Route.PfxLen is nonzero and different than the length of I have changed instances of PfxLen to be PrefixLength. > > only if non-zero? How does AODVv2 represents a "full internet" route > like 0.0.0.0/0 ? As mentioned before, I don't think that's a useful PrefixLength, but I have changed the invalid value to be INVALID_PREFIX_LENGTH (255) instead of zero. > > > router MUST NOT transmit any routing messages. Thus, if all other > > AODVv2 routers expunge routes to the rebooted router after that time > > interval, the rebooted AODVv2 router's sequence number will not be > > considered stale by any other AODVv2 router in the MANET. > > > > When the link to a route's next hop is broken, the route is marked as > > being Broken, and the route may no longer be used. > > > > 5.2. Bidirectional Connectivity During Route Discovery and Blacklists > > > > To avoid repeated failure of Route Discovery, an AODVv2 router > > (HandlingRtr) handling a RREP message MAY attempt to verify > > Another unnecessary abbreviation > > Page 13: > > > BlacklistNode > > The IP address of the node that did not verify bidirectional > > connectivity. > > Blacklist.Node ? > > > BlacklistRmTime > > The time at which BlacklistNode will be removed from the > > blacklist. > > Blacklist.RemoveTime ? Done and Done. > > > 5.4. AODVv2 Packet Header Fields and Information Elements > > > > In its default mode of operation, AODVv2 uses the UDP port 269 > > [RFC5498] to carry protocol packets. In addition, IP Protocol Number > > 138 has been reserved for MANET protocols [RFC5498]. Most AODVv2 > > messages are sent with the IP destination address set to the link- > > You mean packets, not messages? Fixed. > > Page 14: > > > manually configured router adjacencies, or in order to improve > > robustness. > > > > The IPv4 TTL (IPv6 Hop Limit) field for all packets containing AODVv2 > > messages is set to 255. If a packet is received with a value other > > I think (if we keep this at all) this should move to "security > considerations". > > > than 255, any AODVv2 message contained in the packet MUST be > > disregarded by AODVv2. This mechanism, known as "The Generalized TTL > > Security Mechanism" (GTSM) [RFC5082] helps to assure that packets > > have not traversed any intermediate routers. > > I do not agree with this MUST. I am O.K. to move this to the Security Considerations, but I am awaiting for more mailing list discussion. I don't see the problem, though... > > > Each address block may also have associated TLV blocks. > > "have one associated TLV block" (one per address block). > > > If a packet contains only a single AODVv2 message and no packet TLVs, > > it need not include a packet-header [RFC5444]. > > This is wrong and breaks ALL RFC5444 compatibility. You MUST put the > minimal Packet-Header in front of the first message (which is a single > 0 octet). Fixed. > > > > > When multiple messages are aggregated into a single packet according > > to RFC 5444 formatting, and the aggregation of messages is also > > authenticated (e.g., with IPsec), it becomes unfeasible to delete > > individual messages. > > Packet signatures are "link scope" because packets should not be > forwarded with RFC5444. If you want to forward some/all messages, you > can generate a new packet signature. I agree. But do you think that the wording quoted above is misleading? > > > Page 21/22: > > > 7.2. RteMsg Structure > > > > RteMsgs have the following general format: > > > > +---------------------------------------------------------------+ > > | RFC 5444 Packet Header | > > +---------------------------------------------------------------+ > > This is not part of the Message. O.K. I have taken these blocks out. > > > | RFC 5444 Message Header | > > +---------------------------------------------------------------+ > > | RFC 5444 MsgHdr, opt. DestOnly TLV, opt. MetricTypeTLV | > > I would suggest using an optional Extension Type for the Metric TLV > instead of the MetricTypeTLV. I don't really understand that. The Extension Type is for 16-bit types, right? I thought it would be better to have the MetricTypeTLV instead of different AddrTLV types for each metric...? > > > +---------------------------------------------------------------+ > > | RteAddrBlk {[1]:=RREQ.OrigNode,[2]:=RREQ.TargNode)} | > > +---------------------------------------------------------------+ > > | RteSeqNumTLV (OrigRtr.Seqnum, TargNode.Seqnum) | > > +---------------------------------------------------------------+ > > Not clear to which addresses these TLVs belong. I'm hoping it should be clear that they're for the preceding AddrBlk. RFC 5444 grammar says: := ..... ()* so that the should be associated with the preceding in all cases... (?) > > > | Added Node Address Block (Optional) | > > +---------------------------------------------------------------+ > > A second address block? Couldn't these be inside the first address > block too? No, because different AddrTLV blocks might apply. > > > | Added Node Address TLV (SeqNum) | > > +---------------------------------------------------------------+ > > | Added Node Address TLV (Metric[MetricType]) | > > +---------------------------------------------------------------+ > > I am not sure if the diagram above is really helpful understanding > what a message looks like. The parts of the message are laid out in the order they appear in the message... can you suggest how can it be made more clear? > > > 7. If Route[TargNode].PfxLen/8 is equal to the number of bytes in > > the addresses of the RREQ (4 for IPv4, 16 for IPv6), then no > > is included with the iRREP. Otherwise, > > RREP.PfxLen[TargNode] := RREQ.PfxLen[TargNode] according to the > > rules of RFC 5444 AddrBlk encoding. > > Isn't this "full prefix length can be skipped" an explicit part of the > RFC 5444 description? I do not think you need to worry about this > here, its the choice of the implementation if it want to use > ahassingle/ahasmulti both 0 or not. There may be instances of AddrBlks of addresses for which only some of the addresses have associated prefix lengths. I guess I "could" leave out this information, but I didn't think it would hurt to leave it in. > > Page 28: > > > 8.3. RERR Generation > > > > An RERR message is generated by a AODVv2 router (in this section, > > called RERR_Gen) in order to to notify upstream routers that packets > > cannot be delivered to certain destinations. An RERR message has the > > following general structure: > > > > +---------------------------------------------------------------+ > > | RFC 5444 Packet Header | > > +---------------------------------------------------------------+ > > Not part of the message. Deleted. > > Page 29: > > > Message Header > > RFC 5444 MsgHdr may contain the following options: > > > > * > > > > * > > > > * PktSource MsgTLV > > Message-TLVs are not part of the RFC5444 message header. Hmm... I tried to reword it to fix this problem. > > Page 32: > > > 10. Simple Internet Attachment > > > > Simple Internet attachment means attachment of a stub (i.e., non- > > transit) network of AODVv2 routers to the Internet via a single > > Internet AODVv2 router (called IAR). > > maybe just call it (Internet) Gateway instead of IAR? I am O.K. with this, but there might be some additional context associated with the name "Gateway". I'll delay following this suggestion until there is a little more discussion on the mailing list. > > > As in any Internet-attached network, AODVv2 routers, and their > > clients, wishing to be reachable from hosts on the Internet MUST have > > IP addresses within the IAR's routable and topologically correct > > prefix (e.g. 191.0.2.0/24). > > > > The IAR is responsible for generating RREQ messages to find nodes > > within the MANET on behalf of nodes on the Internet, as well as > > responding to route requests from the AODVv2 MANET on behalf of the > > nodes on the Internet. > > Its not allowed to have two gateways to the Internet for an AODVv2 MANET? This is related to multi-homing. There are some considerations about multi-homing in Section 4 that apply. I'd rather not enlarge the specification to do multi-homing any time soon, although there is one relatively straightforward way to do it. > > > | MTU | TBD -- | Determines the maximum | > > | | depends | number of RFC 5444 AddrBlk | > > | | on | entries | > > | | address | | > > | | family | | > > +------------------------+-----------+------------------------------+ > > This description is either unnecessary (if you mean MTU as in > "interface maximum transfer unit") or confusing. I have deleted this table entry. The abbreviation only appears once elsewhere in the document. I reckon everyone will know what it means. > > > > > Table 4: Default Parameter Values > > > > In addition to the above parameters and timing values, several > > administrative options exist. These options have no influence on > > correct routing behavior, although they may potentially reduce AODVv2 > > protocol messaging in certain situations. The default behavior is to > > NOT enable any of these options; and although many of these options > > can be administratively controlled, they may be better served by > > intelligent control. The following table enumerates several of the > > options. > > > > +-------------------------+-----------------------------------------+ > > | Name | Description | > > +-------------------------+-----------------------------------------+ > > | APPEND_INFORMATION | Whether or not appending routing | > > | | information for AddedNodes to a RteMsg | > > | | is enabled. | > > This is a "strange" default value. > > Page 41: > > > | CONTROL_TRAFFIC_LIMIT | TBD [50 msgs/sec?] | > > +-------------------------+-----------------------------------------+ > > Packets per second? Fixed. > > Page 42: > > > | Packet source IP | 12 - | 4 or | Provides the IP address for | > > | address | TBD | 16 | RERR messages generated due | > > | (PktSource) | | octets | to inability to deliver a | > > | | | | packet. | > > I remember that there were some concerns putting addresses into TLVs > when we talked about DLEP in April. > > > | Metric Type | 13 - | 1 | Type of metric in the Metric8 | > > | | TBD | octet | or Metric16 AddrTLV. | > > +-------------------+------+--------+-------------------------------+ > > As I said before, I would remove this TLV completely. > > > Table 7: Message TLV Types > > > > 15.3. Address Block TLV Specification > > The types collide with your allocation in chapter 15.2, which was > called "Message and Address Block TLV Type Specification". > > > +---------------+------------+----------+---------------------------+ > > | Name | Type | Length | Value | > > +---------------+------------+----------+---------------------------+ > > | VALIDITY_TIME | 1[RFC5497] | 1 octet | The maximum amount of | > > | | | | time that information can | > > | | | | be maintained before | > > | | | | being deleted. The | > > | | | | VALIDITY_TIME TLV is | > > | | | | defined in [RFC5497]. | > > | | | | -- | > > | Sequence | 10 - TBD | 2 octets | The latest AODVv2 | > > | Number | | | sequence number | > > | (SeqNum) | | | associated with the | > > | | | | address. | > > | Metric8 | 11 - TBD | 1 octet | 8-bit Cost of the route | > > | | | | to reach the destination | > > | | | | address. | > > | Metric16 | 12 - TBD | 2 octets | 16-bit Cost of the route | > > | | | | to reach the destination | > > | | | | address. | > > +---------------+------------+----------+---------------------------+ > > Why not just one Metric TLV which can have a length of 1-2 ? You have > an explicit length field in the message anyways. > > > Table 8: Address Block TLV (AddrTLV) Types > > > > The same number space should be used for both Metric8 and Metric16 > > metric types. > > > > 15.4. Metric Type Number Allocation > > "Metric TLV Extension Types Allocation" ? > > > Metric types are identified according to the assignments as specified > > in [RFC6551]. The metric type of the Hop Count metric is assigned to > > be 3, in order to maintain compatibility with that existing table of > > values from RFC 6551. If non-additive metrics are to be used, the > > specification for assessing the usability of route updates (see > > Section 6.1 ) may require changes. > > "non-addititve metrics are not supported in this draft" ? Fixed. > > Page 43: > > > +-----------------------+----------+-----------+ > > | Name | Type | Size | > > +-----------------------+----------+-----------+ > > | Reserved | 0 | Undefined | > > Why is 0 reserved? 0 would be the Extension type that can skip the > additional byte in the TLV. O.K. I have changed it to be Unallocated. > > Page 47: > > > For RteMsgs, the msg-hdr fields are followed by at least one and > > optionally two Address Blocks. The first AddrBlk contains OrigNode > > and TargNode. For each AddrBlk, there must be AddrTLVs of type > > Seqnum and of type Metric. > > You should be able to parse any number of address blocks. This is related to your earlier comment, and I'm hoping to get some more discussion about this on the mailing list. > > Page 48: > > > A.1. RREQ Message Format > > > > The figure below illustrates a packet format for an example RREQ > > message. > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | PV=0 | PF=0 | msg-type=RREQ | MF=4 | MAL=3 | msg-size=24 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > msg-size = 28 ? Fixed. > > > | msg-size=24 | msg-hop-limit | msg.tlvs-length=0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | num-addr=2 |1|0|0|0|0| Rsv | head-length=3 |Head(Orig&Targ)| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Head (bytes for Orig & Target)| Orig.Tail | Target.Tail | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | addr.tlvs-length=11 | type=SeqNum |0|1|0|1|0|0|Rsv| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Index-start=0 | tlv-length=2 | Orig.Node Sequence # | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | type=SeqNum |0|1|0|1|0|0|Rsv| Index-start=0 | tlv-length=1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > type = Metric-TLV ? type=Metric > > Page 49: > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | PV=0 | PF=0 | msg-type=RERR | MF=4 | MAL=3 | msg-size=25 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | msg-size=25 | msg-hop-limit | msg.tlvs-length=0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | num-addr=2 |1|0|0|0|0| Rsv | head-length=3 |Head(Two Dests)| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Head (for both destinations) | Tail(Dest_1) | Tail(Dest_2) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | addr.tlvs-length=8 | type=SeqNum |0|1|0|1|0|0|Rsv| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > If these sequence numbers are one for each destination, the TLV is wrong. > > It doesn't need the Index-start (because it will explicitly refer to > all addresses in the block), but it needs the tismultivalue flag. In > addition to this the length of the TLV must be 4. > > > | Index-start=0 | tlv-length=2 | Dest_1 Sequence # | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Dest_2 Sequence # | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > RERR with - Two Unreachable Node address in Address Block - address > > length = 4 [IPv4], shared initial bytes = 3 - Two Sequence Numbers > > available in addr.tlv - Addresses stored from Originator to Target > > Page 50: > > > A.4. RREP_ACK Message Format > > > > The figure below illustrates a packet format for an example RREP_ACK > > message. > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | PV=0 | PF=0 |msg-type=RREPAk| MF=0 | MAL=3 | msg-size=3 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | msg-size=3 | > > +-+-+-+-+-+-+-+-+ > > msg-size = 4 ? Fixed. And, again, thanks very much for your comments. I probably need to update the Examples again, and to take time to proofread the RFC 5444 flags fields carefully. -- Regards, Charlie P. From henning.rogge@fkie.fraunhofer.de Thu Dec 6 00:38:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF9B21F850A for ; Thu, 6 Dec 2012 00:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[AWL=0.766, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 6IanXvuy0ZHn for ; Thu, 6 Dec 2012 00:38:12 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 9C04F21F8507 for ; Thu, 6 Dec 2012 00:38:10 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TgWy7-0004WD-Ty; Thu, 06 Dec 2012 09:38:07 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TgWy7-00016r-RD; Thu, 06 Dec 2012 09:38:07 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 6 Dec 2012 09:38:07 +0100 Message-ID: <50C05967.405@fkie.fraunhofer.de> Date: Thu, 6 Dec 2012 09:37:59 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Charles E. Perkins" References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> In-Reply-To: <50BFC05E.4030006@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060004040803040709020701" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/15689/Thu Dec 6 04:52:13 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 54721e72237ea80a36fbd5caa469df82 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 08:38:13 -0000 --------------ms060004040803040709020701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 12/05/2012 10:45 PM, Charles E. Perkins wrote: > > Hello Henning, > > Here is some more follow-up on your observations and suggestions. > > On 12/3/2012 5:25 AM, Henning Rogge wrote: >> >> > Handling Router (HandlingRtr) >> > HandlingRtr denotes the AODVv2 router handling an AODVv2 message. >> >> Do you really need the "HandlingRtr" abbreviation? It complicates the >> text and does not shorten it that much. > > Would you like to see this terminology changed to instead be "Handler"?= > I guess there's no need to constantly remind the reader that the node > doing the AODVv2 processing is a "router"... I think we should have a discussion on the list if that many=20 abbreviations are really useful/necessary for a draft/rfc. In my opinion = they have no advantage (beyond saving a few characters) and make the=20 draft harder to read. >> Using the order of addresses in an address block as protocol semantics= >> is a bad idea. Use TLVs attached to the addresses to identify their >> purpose. > > Still pondering this, and awaiting more discussion on the mailing list.= =2E. I agree, that would be a good idea. >> only if non-zero? How does AODVv2 represents a "full internet" route >> like 0.0.0.0/0 ? > > As mentioned before, I don't think that's a useful PrefixLength, > but I have changed the invalid value to be INVALID_PREFIX_LENGTH > (255) instead of zero. If you don't consider this a useful prefix length, what does the "AODVv2 = mesh uplink" (the connection the the backbone internet) announce as a=20 prefix? >> > than 255, any AODVv2 message contained in the packet MUST be >> > disregarded by AODVv2. This mechanism, known as "The Generalized TT= L >> > Security Mechanism" (GTSM) [RFC5082] helps to assure that packets >> > have not traversed any intermediate routers. >> >> I do not agree with this MUST. > > I am O.K. to move this to the Security Considerations, but I am > awaiting for more mailing list discussion. I don't see the problem, > though... I am okay with having more discussion about this point. I see a problem when combining AODVv2 with other RFC5444 using protocols = (like NHDP). Protocols defining a RFC5444 message should be careful to=20 have mandatory changes on the RFC5444 packet level. >> > When multiple messages are aggregated into a single packet according= >> > to RFC 5444 formatting, and the aggregation of messages is also >> > authenticated (e.g., with IPsec), it becomes unfeasible to delete >> > individual messages. >> >> Packet signatures are "link scope" because packets should not be >> forwarded with RFC5444. If you want to forward some/all messages, you >> can generate a new packet signature. > > I agree. But do you think that the wording quoted above is misleading?= I am not sure we need this paragraph at all. RFC5444 packets are never forwarded at all, they are assembled only for=20 a single hop by combining messages. "deleting individual messages" doesn't make sense in this context. >> > | RFC 5444 MsgHdr, opt. DestOnly TLV, opt. MetricTypeTLV | >> >> I would suggest using an optional Extension Type for the Metric TLV >> instead of the MetricTypeTLV. > > I don't really understand that. The Extension Type is for 16-bit types= , > right? > I thought it would be better to have the MetricTypeTLV instead of diffe= rent > AddrTLV types for each metric...? RFC5444 TLVs normally have a 8-Bit type field (which in the case of the=20 MetricTLV is fixed), but can have an additional 8-Bit extension-type. I suggest using this 8-Bit extension-type for storing the metric-type,=20 similar to the way OLSRv2 use its metric TLV. This will make the MetricTypeTLV unnecessary (and even save a few bytes=20 in the message). >> > +---------------------------------------------------------------+ >> > | RteAddrBlk {[1]:=3DRREQ.OrigNode,[2]:=3DRREQ.TargNode)} = | >> > +---------------------------------------------------------------+ >> > | RteSeqNumTLV (OrigRtr.Seqnum, TargNode.Seqnum) | >> > +---------------------------------------------------------------+ >> >> Not clear to which addresses these TLVs belong. > > I'm hoping it should be clear that they're for the > preceding AddrBlk. RFC 5444 grammar says: > > :=3D > ..... > > ()* > > so that the should be associated with > the preceding in all cases... (?) > >> >> > | Added Node Address Block (Optional) | >> > +---------------------------------------------------------------+ >> >> A second address block? Couldn't these be inside the first address >> block too? > > No, because different AddrTLV blocks might apply. As I stated before, I think giving the order and association with=20 different address-blocks a semantic meaning >> > | Added Node Address TLV (SeqNum) | >> > +---------------------------------------------------------------+ >> > | Added Node Address TLV (Metric[MetricType]) | >> > +---------------------------------------------------------------+ >> >> I am not sure if the diagram above is really helpful understanding >> what a message looks like. > > The parts of the message are laid out in the order they appear > in the message... can you suggest how can it be made more clear? I think we should first discuss the "position/address-block association=20 as semantics" thing on the list. >> > 7. If Route[TargNode].PfxLen/8 is equal to the number of bytes in >> > the addresses of the RREQ (4 for IPv4, 16 for IPv6), then no >> > is included with the iRREP. Otherwise, >> > RREP.PfxLen[TargNode] :=3D RREQ.PfxLen[TargNode] according to the >> > rules of RFC 5444 AddrBlk encoding. >> >> Isn't this "full prefix length can be skipped" an explicit part of the= >> RFC 5444 description? I do not think you need to worry about this >> here, its the choice of the implementation if it want to use >> ahassingle/ahasmulti both 0 or not. > > There may be instances of AddrBlks of addresses for which only some > of the addresses have associated prefix lengths. I guess I "could" lea= ve > out this information, but I didn't think it would hurt to leave it in. This is not possible in RFC5444. You have to state if addresses have or have not a prefix length in the=20 address block header. Its not really a problem, because you can set a 32/128 prefix length. > I am O.K. with this, but there might be some additional context associa= ted > with the name "Gateway". I'll delay following this suggestion until th= ere > is a little more discussion on the mailing list. Okay. >> > As in any Internet-attached network, AODVv2 routers, and their >> > clients, wishing to be reachable from hosts on the Internet MUST hav= e >> > IP addresses within the IAR's routable and topologically correct >> > prefix (e.g. 191.0.2.0/24). >> > >> > The IAR is responsible for generating RREQ messages to find nodes >> > within the MANET on behalf of nodes on the Internet, as well as >> > responding to route requests from the AODVv2 MANET on behalf of the >> > nodes on the Internet. >> >> Its not allowed to have two gateways to the Internet for an AODVv2 MAN= ET? > > This is related to multi-homing. There are some considerations about > multi-homing in Section 4 that apply. I'd rather not enlarge the > specification > to do multi-homing any time soon, although there is one relatively > straightforward way to do it. Okay, I wasn't sure if multiple gateways are supported or not. > And, again, thanks very much for your comments. > > I probably need to update the Examples again, and to take time to > proofread the RFC 5444 flags fields carefully. Packet/Message examples are always a pain to get right, I think everyone = on this list will agree to this. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms060004040803040709020701 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEyMDYwODM4MDVaMCMGCSqGSIb3DQEJBDEWBBT97CAw3Sx3/PgsVVnszpOAi0Y9KTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAfGtx/9oEnpiiIcD5d7j1ImKasKwNBTCjnNG6TrsthpYv tE5naK8dqtMVGrvvDtmYEDZKDwe7FF3+T7pgjdOflQaiJ7g5I4XS99wP4yRSySTKUz8ZY0g/ VZ8253+h2pimXoA8Ve8IYpBxF981eefc4oS7BwxHWAjSdmQDuK3lIaD7OVEef0XZHwkAU9D+ cNEJSHLYsr/tCWFnwW/srqUHDS6xXFMu4nOkzE6KbLZyLTjQiNTrPgJT2fdDWydN2yOBZZaE lthB+4pz0pC8MkGB/Y90Ie1XKRIBSm+1hvKcMqdscHS4pDvboT5Di/s4/rdw0e8O7S+afyWl ErB+4C+WQwAAAAAAAA== --------------ms060004040803040709020701-- From sratliff@cisco.com Thu Dec 6 11:24:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D43121F88BE for ; Thu, 6 Dec 2012 11:24:56 -0800 (PST) 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 O0lYyglpg7JK for ; Thu, 6 Dec 2012 11:24:55 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C22D821F88B9 for ; Thu, 6 Dec 2012 11:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9155; q=dns/txt; s=iport; t=1354821894; x=1356031494; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lBCXEtW9d44KY+OxNJN6uxA1HlcEQ2Ei0++Z54V5oq8=; b=ZMPTKsLqP+EPcnGVZywIMEa+fdL0QeS+G7ECpW1WiXKs/uMEzNV04IUH OZ2JCx5aNGs6/lLYUXeKowoffDFIz+c2WvVSu13xlBMSU80Bnizbara2i w8ML7he8CVFo7/JKQOkhYb05SSRjwU66Tyw0YvPPBrfDbPpzohfqSXZBt g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAzwwFCtJV2Z/2dsb2JhbAA6Cr4oFnOCHgEBAQMBAQEBawsFCwIBCBgKHQcnCxQRAgQOBQiIAgYMwmaMORGDUWEDklCTeoJzgiI X-IronPort-AV: E=McAfee;i="5400,1158,6918"; a="150217642" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 06 Dec 2012 19:24:54 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qB6JOsCk008104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Dec 2012 19:24:54 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.161]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Thu, 6 Dec 2012 13:24:53 -0600 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-24.txt Thread-Index: AQHNz3PfX48qsstVK0mFSMr40eak8pgHeRGAgAOwKwCAALZvgIAAtL0A Date: Thu, 6 Dec 2012 19:24:53 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> In-Reply-To: <50C05967.405@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.115] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 19:24:56 -0000 One item inline=85=20 On Dec 6, 2012, at 3:37 AM, Henning Rogge wrote: > On 12/05/2012 10:45 PM, Charles E. Perkins wrote: >>=20 >> Hello Henning, >>=20 >> Here is some more follow-up on your observations and suggestions. >>=20 >> On 12/3/2012 5:25 AM, Henning Rogge wrote: >>>=20 >>> > Handling Router (HandlingRtr) >>> > HandlingRtr denotes the AODVv2 router handling an AODVv2 message. >>>=20 >>> Do you really need the "HandlingRtr" abbreviation? It complicates the >>> text and does not shorten it that much. >>=20 >> Would you like to see this terminology changed to instead be "Handler"? >> I guess there's no need to constantly remind the reader that the node >> doing the AODVv2 processing is a "router"... >=20 > I think we should have a discussion on the list if that many abbreviation= s are really useful/necessary for a draft/rfc. In my opinion they have no a= dvantage (beyond saving a few characters) and make the draft harder to read= . >=20 >>> Using the order of addresses in an address block as protocol semantics >>> is a bad idea. Use TLVs attached to the addresses to identify their >>> purpose. >>=20 >> Still pondering this, and awaiting more discussion on the mailing list..= . >=20 > I agree, that would be a good idea. >=20 >>> only if non-zero? How does AODVv2 represents a "full internet" route >>> like 0.0.0.0/0 ? >>=20 >> As mentioned before, I don't think that's a useful PrefixLength, >> but I have changed the invalid value to be INVALID_PREFIX_LENGTH >> (255) instead of zero. >=20 > If you don't consider this a useful prefix length, what does the "AODVv2 = mesh uplink" (the connection the the backbone internet) announce as a prefi= x? Not useful? It's a default route=85 I've used it myself *many* times. Stan >=20 >>> > than 255, any AODVv2 message contained in the packet MUST be >>> > disregarded by AODVv2. This mechanism, known as "The Generalized TTL >>> > Security Mechanism" (GTSM) [RFC5082] helps to assure that packets >>> > have not traversed any intermediate routers. >>>=20 >>> I do not agree with this MUST. >>=20 >> I am O.K. to move this to the Security Considerations, but I am >> awaiting for more mailing list discussion. I don't see the problem, >> though... >=20 > I am okay with having more discussion about this point. >=20 > I see a problem when combining AODVv2 with other RFC5444 using protocols = (like NHDP). Protocols defining a RFC5444 message should be careful to have= mandatory changes on the RFC5444 packet level. >=20 >>> > When multiple messages are aggregated into a single packet according >>> > to RFC 5444 formatting, and the aggregation of messages is also >>> > authenticated (e.g., with IPsec), it becomes unfeasible to delete >>> > individual messages. >>>=20 >>> Packet signatures are "link scope" because packets should not be >>> forwarded with RFC5444. If you want to forward some/all messages, you >>> can generate a new packet signature. >>=20 >> I agree. But do you think that the wording quoted above is misleading? >=20 > I am not sure we need this paragraph at all. >=20 > RFC5444 packets are never forwarded at all, they are assembled only for a= single hop by combining messages. >=20 > "deleting individual messages" doesn't make sense in this context. >=20 >>> > | RFC 5444 MsgHdr, opt. DestOnly TLV, opt. MetricTypeTLV | >>>=20 >>> I would suggest using an optional Extension Type for the Metric TLV >>> instead of the MetricTypeTLV. >>=20 >> I don't really understand that. The Extension Type is for 16-bit types, >> right? >> I thought it would be better to have the MetricTypeTLV instead of differ= ent >> AddrTLV types for each metric...? >=20 > RFC5444 TLVs normally have a 8-Bit type field (which in the case of the M= etricTLV is fixed), but can have an additional 8-Bit extension-type. >=20 > I suggest using this 8-Bit extension-type for storing the metric-type, si= milar to the way OLSRv2 use its metric TLV. >=20 > This will make the MetricTypeTLV unnecessary (and even save a few bytes i= n the message). >=20 >>> > +---------------------------------------------------------------+ >>> > | RteAddrBlk {[1]:=3DRREQ.OrigNode,[2]:=3DRREQ.TargNode)} | >>> > +---------------------------------------------------------------+ >>> > | RteSeqNumTLV (OrigRtr.Seqnum, TargNode.Seqnum) | >>> > +---------------------------------------------------------------+ >>>=20 >>> Not clear to which addresses these TLVs belong. >>=20 >> I'm hoping it should be clear that they're for the >> preceding AddrBlk. RFC 5444 grammar says: >>=20 >> :=3D >> ..... >> >> ()* >>=20 >> so that the should be associated with >> the preceding in all cases... (?) >>=20 >>>=20 >>> > | Added Node Address Block (Optional) | >>> > +---------------------------------------------------------------+ >>>=20 >>> A second address block? Couldn't these be inside the first address >>> block too? >>=20 >> No, because different AddrTLV blocks might apply. >=20 > As I stated before, I think giving the order and association with differe= nt address-blocks a semantic meaning >=20 >>> > | Added Node Address TLV (SeqNum) | >>> > +---------------------------------------------------------------+ >>> > | Added Node Address TLV (Metric[MetricType]) | >>> > +---------------------------------------------------------------+ >>>=20 >>> I am not sure if the diagram above is really helpful understanding >>> what a message looks like. >>=20 >> The parts of the message are laid out in the order they appear >> in the message... can you suggest how can it be made more clear? >=20 >=20 > I think we should first discuss the "position/address-block association a= s semantics" thing on the list. >=20 >>> > 7. If Route[TargNode].PfxLen/8 is equal to the number of bytes in >>> > the addresses of the RREQ (4 for IPv4, 16 for IPv6), then no >>> > is included with the iRREP. Otherwise, >>> > RREP.PfxLen[TargNode] :=3D RREQ.PfxLen[TargNode] according to the >>> > rules of RFC 5444 AddrBlk encoding. >>>=20 >>> Isn't this "full prefix length can be skipped" an explicit part of the >>> RFC 5444 description? I do not think you need to worry about this >>> here, its the choice of the implementation if it want to use >>> ahassingle/ahasmulti both 0 or not. >>=20 >> There may be instances of AddrBlks of addresses for which only some >> of the addresses have associated prefix lengths. I guess I "could" leav= e >> out this information, but I didn't think it would hurt to leave it in. >=20 > This is not possible in RFC5444. >=20 > You have to state if addresses have or have not a prefix length in the ad= dress block header. >=20 > Its not really a problem, because you can set a 32/128 prefix length. >=20 >> I am O.K. with this, but there might be some additional context associat= ed >> with the name "Gateway". I'll delay following this suggestion until the= re >> is a little more discussion on the mailing list. >=20 > Okay. >=20 >>> > As in any Internet-attached network, AODVv2 routers, and their >>> > clients, wishing to be reachable from hosts on the Internet MUST have >>> > IP addresses within the IAR's routable and topologically correct >>> > prefix (e.g. 191.0.2.0/24). >>> > >>> > The IAR is responsible for generating RREQ messages to find nodes >>> > within the MANET on behalf of nodes on the Internet, as well as >>> > responding to route requests from the AODVv2 MANET on behalf of the >>> > nodes on the Internet. >>>=20 >>> Its not allowed to have two gateways to the Internet for an AODVv2 MANE= T? >>=20 >> This is related to multi-homing. There are some considerations about >> multi-homing in Section 4 that apply. I'd rather not enlarge the >> specification >> to do multi-homing any time soon, although there is one relatively >> straightforward way to do it. >=20 > Okay, I wasn't sure if multiple gateways are supported or not. >=20 >> And, again, thanks very much for your comments. >>=20 >> I probably need to update the Examples again, and to take time to >> proofread the RFC 5444 flags fields carefully. >=20 > Packet/Message examples are always a pain to get right, I think everyone = on this list will agree to this. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Thu Dec 6 11:41:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB1B21F88C1 for ; Thu, 6 Dec 2012 11:41:09 -0800 (PST) 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 cLJFKbZzb2ht for ; Thu, 6 Dec 2012 11:41:08 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0C6F21F883B for ; Thu, 6 Dec 2012 11:41:08 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so4506623pad.31 for ; Thu, 06 Dec 2012 11:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=+dZCJTfTKs0KcypkSav3o3T8/wOJt0yZT/WUQArTlPM=; b=ZRhdWN7ev7/sqgc7WDca/upzaSFK7PkTKsauIX/feHlPOTc6EQfnEUosMXjp9WagZe 7MfvlQBdnOdaTqYiJ2iNINyyz0yDR9zNh6NGtSyvyB1GqYXdqLm3tt56JDM0inRnFEs4 mb47q7HsOvl9qJTfl7VBtmKZTNymwKj3W69q32oNmWCZv0rlwrGULuJLWm1epy7YZnUu Rvz42xSMRPfDVVDtP8r3WC94OXVAwJz4D2au5iCc9zxW//SFi1hHEq6qKtus7IVIj4kW 939YxT+T/zfQmaPGqP+FUjax2AXzQ2JwgW2fruvJC1ANS3rb6ixKC4dkmAzaklbyh7Dt ep3w== Received: by 10.68.253.66 with SMTP id zy2mr8347205pbc.131.1354822868510; Thu, 06 Dec 2012 11:41:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.88.132 with HTTP; Thu, 6 Dec 2012 11:40:48 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Thu, 6 Dec 2012 20:40:48 +0100 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 19:41:09 -0000 On Thu, Dec 6, 2012 at 8:24 PM, Stan Ratliff (sratliff) wrote: > One item inline=85 > > On Dec 6, 2012, at 3:37 AM, Henning Rogge wrote: > >> On 12/05/2012 10:45 PM, Charles E. Perkins wrote: >>>> only if non-zero? How does AODVv2 represents a "full internet" route >>>> like 0.0.0.0/0 ? >>> >>> As mentioned before, I don't think that's a useful PrefixLength, >>> but I have changed the invalid value to be INVALID_PREFIX_LENGTH >>> (255) instead of zero. >> >> If you don't consider this a useful prefix length, what does the "AODVv2= mesh uplink" (the connection the the backbone internet) announce as a pref= ix? > > Not useful? It's a default route=85 I've used it myself *many* times. Exactly my thought. The "0.0.0.0/0" route (the default route) is the MOST common/useful route you will see in a mesh network beyond the host routes. Its the "the rest of the world is beyond this node" thing... Even Sensor networks will have at least one node with this route. Henning --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From charliep@computer.org Thu Dec 6 14:30:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA7421F85DB for ; Thu, 6 Dec 2012 14:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, 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 8qqcBa3m6itI for ; Thu, 6 Dec 2012 14:30:41 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id C2FEC21F85D3 for ; Thu, 6 Dec 2012 14:30:41 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Tgjxn-000773-9m; Thu, 06 Dec 2012 17:30:39 -0500 Message-ID: <50C11C77.8020400@computer.org> Date: Thu, 06 Dec 2012 14:30:15 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86b823a7baf0797dc8d05e7c4ca43f9563350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 22:30:42 -0000 Hello Stan and Henning, On 12/6/2012 11:24 AM, Stan Ratliff (sratliff) wrote: > >>>> only if non-zero? How does AODVv2 represents a "full internet" route >>>> like 0.0.0.0/0 ? >>> As mentioned before, I don't think that's a useful PrefixLength, >>> but I have changed the invalid value to be INVALID_PREFIX_LENGTH >>> (255) instead of zero. >> If you don't consider this a useful prefix length, what does the "AODVv2 mesh uplink" (the connection the the backbone internet) announce as a prefix? > Not useful? It's a default route… I've used it myself *many* times. > > Stan > I reckon everyone on this list has used default routes for most of our network connectivity. But the routers in the AODVv2 specification don't advertise default routes. And even more to the point, they don't advertise routes like 191.2.3/0 ... If we were going to specify more details about an Internet Gateway, then there would be a good reason to discuss advertising default routes, and actually I did do this for an earlier Gateway specification. Sorry to raise your alarms... -- Regards, Charlie P. From charliep@computer.org Thu Dec 6 16:40:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E1221F86D8 for ; Thu, 6 Dec 2012 16:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, 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 3dXhPNfAgjTr for ; Thu, 6 Dec 2012 16:40:09 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id A9BB121F854D for ; Thu, 6 Dec 2012 16:40:09 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Tglz6-000409-NF; Thu, 06 Dec 2012 19:40:08 -0500 Message-ID: <50C13AD1.30200@computer.org> Date: Thu, 06 Dec 2012 16:39:45 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Henning Rogge References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> In-Reply-To: <50BCA857.8070400@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86b55bbbc5c42ab45b27970935f70cbbce350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: manet@ietf.org Subject: [manet] Administratively controlled options in AODVv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 00:40:10 -0000 Hello again Henning, Following up on your observation about things in Section 13... The whole section needs to be reorganized. I think the tables ought to be as follows: a) Timers = e.g., MAX_IDLETIME b) Protocol constants = e.g., INVALID_PREFIX_LENGTH c) Administrative (functional) controls = e.g., USE_MULTICAST_RREP d) Other administrative parameters and lists = e.g., CONTROL_TRAFFIC_LIMIT The numbers in a) and d) would be more likely to require consideration and adjustment when the nodes are "configured" for service in the ad hoc network. Numbers in b) and c) would more likely just maintain their default values. For each value in the four tables, the section defining its meaning should be cross referenced. For many values, a default value would be provided. Does this seem like a reasonable proposal? I would also minimize the parameter description in the table, preferring to keep such description in the relevant sections in the main body of the document. Regards, Charlie P. On 12/3/2012 5:25 AM, Henning Rogge wrote: ... skipping lines ... > > > Table 4: Default Parameter Values > > > > In addition to the above parameters and timing values, several > > administrative options exist. These options have no influence on > > correct routing behavior, although they may potentially reduce AODVv2 > > protocol messaging in certain situations. The default behavior is to > > NOT enable any of these options; and although many of these options > > can be administratively controlled, they may be better served by > > intelligent control. The following table enumerates several of the > > options. > > > > +-------------------------+-----------------------------------------+ > > | Name | Description | > > +-------------------------+-----------------------------------------+ > > | APPEND_INFORMATION | Whether or not appending routing | > > | | information for AddedNodes to a RteMsg | > > | | is enabled. | > > This is a "strange" default value. > > Page 41: > > > | CONTROL_TRAFFIC_LIMIT | TBD [50 msgs/sec?] | > > +-------------------------+-----------------------------------------+ > > Packets per second? > > ... skipping lines ... > > Henning Rogge > -- Regards, Charlie P. From henning.rogge@fkie.fraunhofer.de Fri Dec 7 04:35:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E649C21F8936 for ; Fri, 7 Dec 2012 04:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 pl3av3+EJwbo for ; Fri, 7 Dec 2012 04:35:34 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id D4AAC21F892A for ; Fri, 7 Dec 2012 04:35:33 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tgx9O-00033Q-M5; Fri, 07 Dec 2012 13:35:30 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tgx9O-0005L0-JM; Fri, 07 Dec 2012 13:35:30 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 7 Dec 2012 13:35:30 +0100 Message-ID: <50C1E291.20004@fkie.fraunhofer.de> Date: Fri, 7 Dec 2012 13:35:29 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Charles E. Perkins" References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50C13AD1.30200@computer.org> In-Reply-To: <50C13AD1.30200@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000602000708040101090701" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/15698/Fri Dec 7 04:27:23 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 71f20a6753145be45d3fd9933e2b2e69 Cc: manet@ietf.org Subject: Re: [manet] Administratively controlled options in AODVv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 12:35:35 -0000 --------------ms000602000708040101090701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 12/07/2012 01:39 AM, Charles E. Perkins wrote: > > Hello again Henning, > > Following up on your observation about things in Section 13... > > The whole section needs to be reorganized. I think the tables > ought to be as follows: > a) Timers > =3D e.g., MAX_IDLETIME > b) Protocol constants > =3D e.g., INVALID_PREFIX_LENGTH > c) Administrative (functional) controls > =3D e.g., USE_MULTICAST_RREP > d) Other administrative parameters and lists > =3D e.g., CONTROL_TRAFFIC_LIMIT > > The numbers in a) and d) would be more likely to require > consideration and adjustment when the nodes are "configured" > for service in the ad hoc network. Numbers in b) and c) would > more likely just maintain their default values. > > For each value in the four tables, the section defining its > meaning should be cross referenced. For many values, a default > value would be provided. > > Does this seem like a reasonable proposal? > > I would also minimize the parameter description in the > table, preferring to keep such description in the relevant > sections in the main body of the document. Maybe you could split the section into 4 subsections (13.1 to 13.4),=20 each with a small introduction sentence to explain whats the purpose of=20 these group of parameters. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000602000708040101090701 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEyMDcxMjM1MjlaMCMGCSqGSIb3DQEJBDEWBBTFD52gUugyZQjako/oe/sFZb3gTzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAqLXf5jfkI1AVw/xMu1WdPk0O1s+oRoh/sr5gbrfhpsnb udg8ckn4AgZXnJG3HHjZT2Y7YauBwXBx1jTT3DRPjVrZcgrxDJ4YlfQKoWGD9Z5cGmypOjda 60s0NeGGPDin4ddHyXNzX4PjmbcCB891uK78001EUY+GJWyrLpSPwJhSIvJfGYaJ6Vw4TP3p J4O4FHxlBAlBMobZRmL4bic4Y0d2IxNEf0JfSWayCWIEBBDWhpOVWIUbY7gTdcFfcX7b6/Zg 99CTnb5lY+YBUpTelXoy4PKcz7LSFCokgx0aSGAc/hwYgX1MbHIlLaoj59uNjsTJAR06lW0p mFJ3ln+ZzQAAAAAAAA== --------------ms000602000708040101090701-- From sratliff@cisco.com Fri Dec 7 07:27:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83C521F8799 for ; Fri, 7 Dec 2012 07:27:23 -0800 (PST) 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 h-LBHj+ZLpFZ for ; Fri, 7 Dec 2012 07:27:23 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC5721F8762 for ; Fri, 7 Dec 2012 07:27:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1764; q=dns/txt; s=iport; t=1354894043; x=1356103643; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/YU6roV0ClZD//MzOEN8CwnUs5hP9Iaf0ZqjmiAE8Ng=; b=fof2+eUotHPCXg9GZVsbsnwSL0uTuVZE5MU2DNhRMRr3BhnA1jm/0TsL OVb5GccRAtsOhD3D+tcR7y+6m8MEYnvfchr9ikUzyNjNJmSY5xmBE7Cq5 10NFSoXKia/gl9bpirD9mvWwOkgmfr9U5xB000eA0YjZKz42dG5KVpmIV E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEoKwlCtJV2b/2dsb2JhbABEunSDQhZzgh4BAQEDAXkQAgEIGAokMiUCBA4NiAMGwjSMP4NiYQOmTYJzgiI X-IronPort-AV: E=McAfee;i="5400,1158,6918"; a="150508304" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 07 Dec 2012 15:27:23 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qB7FRMTo017649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Dec 2012 15:27:22 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.125]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Fri, 7 Dec 2012 09:27:22 -0600 From: "Stan Ratliff (sratliff)" To: "Charles E. Perkins" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-24.txt Thread-Index: AQHNz3PfX48qsstVK0mFSMr40eak8pgHeRGAgAOwKwCAALZvgIAAtL0AgAAzy4CAARwvgA== Date: Fri, 7 Dec 2012 15:27:22 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> In-Reply-To: <50C11C77.8020400@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.115] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9EB5BF4A9AD3AA4E8EAD05FBF2925953@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 15:27:24 -0000 Charlie,=20 On Dec 6, 2012, at 5:30 PM, Charles E. Perkins wrote: >=20 > Hello Stan and Henning, >=20 > On 12/6/2012 11:24 AM, Stan Ratliff (sratliff) wrote: >>=20 >>>>> only if non-zero? How does AODVv2 represents a "full internet" route >>>>> like 0.0.0.0/0 ? >>>> As mentioned before, I don't think that's a useful PrefixLength, >>>> but I have changed the invalid value to be INVALID_PREFIX_LENGTH >>>> (255) instead of zero. >>> If you don't consider this a useful prefix length, what does the "AODVv= 2 mesh uplink" (the connection the the backbone internet) announce as a pre= fix? >> Not useful? It's a default route=85 I've used it myself *many* times. >>=20 >> Stan >>=20 >=20 > I reckon everyone on this list has used default routes for most of our > network connectivity. But the routers in the AODVv2 specification don't > advertise default routes. >=20 > And even more to the point, they don't advertise routes like > 191.2.3/0 ... >=20 > If we were going to specify more details about an Internet Gateway, > then there would be a good reason to discuss advertising default > routes, and actually I did do this for an earlier Gateway specification. >=20 > Sorry to raise your alarms=85 No worries. Well, maybe some worries=85 ;-)=20 I contend that, without any methodology ("gateway" or otherwise) to get "of= f of" (and conversely, "into") the MANET, the usefulness of the protocol is= questionable. Otherwise, it's an exercise in creating an incredible protoc= ol for which the prime use case is "5 guys down at the coffee house getting= together to play black-ops on their computers". Forgive me, but that isn't= worth it.=20 Regards, Stan >=20 > --=20 > Regards, > Charlie P. >=20 From hrogge@googlemail.com Fri Dec 7 07:34:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DDA21F8A88 for ; Fri, 7 Dec 2012 07:34:59 -0800 (PST) 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 Y3RKBTGy9mTh for ; Fri, 7 Dec 2012 07:34:58 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82F6721F8A7C for ; Fri, 7 Dec 2012 07:34:58 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so540416pad.31 for ; Fri, 07 Dec 2012 07:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=1E13QsM2kyKrkFX2D22qwN+dg6YKbyfgQ/cCR0LShtg=; b=nM18g75lvlFNTvd7EIAlJhfDKzuFoEq9Bks+908my1EqZ9RCHnq/2DjjfujjMqGKmw boo5czorxoCWvIMVKcIqYF4skulGAMzTjLTFzNRf+q6rCXkfjCyGpDUPKu6/0HNTjvsQ rO8qwm/suCwGt3VpJO0EExeXTbniV5NWdVWCRXx+dpixRThO/9h170vR7P483hgPHi1s MgvaABcZ+WzpEcOQ5Fc3QZN8EQZvDXFMRns+IvyhyIlfVYGRCeu+Tz5c4TNJi4W01u9z v9HL1tNqe3XZZTj96/Kfgf3WeMOorb6am8i5otoxSGd8RLJ4RgnwOULtjfU7BUyA1JrA FmgQ== Received: by 10.68.227.97 with SMTP id rz1mr16344315pbc.54.1354894498326; Fri, 07 Dec 2012 07:34:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.88.132 with HTTP; Fri, 7 Dec 2012 07:34:38 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Fri, 7 Dec 2012 16:34:38 +0100 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 15:34:59 -0000 On Fri, Dec 7, 2012 at 4:27 PM, Stan Ratliff (sratliff) wrote: > Charlie, > > On Dec 6, 2012, at 5:30 PM, Charles E. Perkins wrote: >> I reckon everyone on this list has used default routes for most of our >> network connectivity. But the routers in the AODVv2 specification don't >> advertise default routes. >> >> And even more to the point, they don't advertise routes like >> 191.2.3/0 ... Just as a comment, setting bits of the "host part" of a network route is not really useful. the only useful "/0" route is 0.0.0.0/0 (and ::/0 if you count IPv6). >> If we were going to specify more details about an Internet Gateway, >> then there would be a good reason to discuss advertising default >> routes, and actually I did do this for an earlier Gateway specification. >> >> Sorry to raise your alarms=85 > > No worries. Well, maybe some worries=85 ;-) > > I contend that, without any methodology ("gateway" or otherwise) to get "= off of" (and conversely, "into") the MANET, the usefulness of the protocol = is questionable. Otherwise, it's an exercise in creating an incredible prot= ocol for which the prime use case is "5 guys down at the coffee house getti= ng together to play black-ops on their computers". Forgive me, but that isn= 't worth it. Yes, thats my opinion too. @Charly: I know, announcing prefixes (including the 0/0 prefix) is difficult for reactive protocols, because it makes detecting a "missing route to network node" more difficult (but not impossible). But I think this MUST to be there in the protocol. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From sratliff@cisco.com Fri Dec 7 09:59:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A2521F8703 for ; Fri, 7 Dec 2012 09:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.818 X-Spam-Level: X-Spam-Status: No, score=-9.818 tagged_above=-999 required=5 tests=[AWL=-0.781, BAYES_00=-2.599, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, 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 lHj3p2cbO0bR for ; Fri, 7 Dec 2012 09:59:53 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3C921F86B9 for ; Fri, 7 Dec 2012 09:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5424; q=dns/txt; s=iport; t=1354903193; x=1356112793; h=from:to:subject:date:message-id:references:mime-version; bh=9AM3DQFHmUhaH0QActkJj0qwbOaWxKayqOJpqOrjPXI=; b=CeeFAmdSjsmc9lke8BXKCQ1ThgltSFc+DjFGM8dZ4waJLoA0hZJwQxqE I5gZS3eFUIeqYj1GAvysncqenZs2BbHDySBb8+m4bR9ETzbn1SXcgHgIR 9pQWnz8WvfJxON4IILuZ0OGq3yOBHCAzkvz7tz/ByIefC0Ws5P6YmNfml k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgGAJMtwlCtJXHA/2dsb2JhbABEglKDY7cVbxZzgh4BAQEEI2YCAQYGDQMBAgsdAwICAjAUBwIIAgQTCAyHfQyUU5pxklmMPxuDFTJhA5chjyyCc4FtNQ X-IronPort-AV: E=McAfee;i="5400,1158,6919"; a="150575324" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 07 Dec 2012 17:59:51 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qB7HxpDm014854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 7 Dec 2012 17:59:51 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.125]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Fri, 7 Dec 2012 11:59:51 -0600 From: "Stan Ratliff (sratliff)" To: " List" Thread-Topic: I have some questions about AODV in MANET! Thread-Index: AQHN1KQXdVRI3uD77EWs3sSGS+Wyrw== Date: Fri, 7 Dec 2012 17:59:50 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF157DA@xmb-aln-x03.cisco.com> References: <1239834511.545.1354902839367.JavaMail.root@CCMAIL_AP3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.115] Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FF157DAxmbalnx03ciscoc_" MIME-Version: 1.0 Subject: [manet] Fwd: I have some questions about AODV in MANET! X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 17:59:54 -0000 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FF157DAxmbalnx03ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yd2FyZGluZyBzb21ldGhpbmcgSSBqdXN0IGdvdCBvZmZsaW5lIHRvIHRoZSBsYXJnZXIgY29t bXVuaXR5Lg0KDQpSZWdhcmRzLA0KU3Rhbg0KDQoNCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0K DQpGcm9tOiDsnbTsnKTqsr0gPGx5azQ3MDdAc29va215dW5nLmFjLmtyPG1haWx0bzpseWs0NzA3 QHNvb2tteXVuZy5hYy5rcj4+DQpTdWJqZWN0OiBJIGhhdmUgc29tZSBxdWVzdGlvbnMgYWJvdXQg QU9EViBpbiBNQU5FVCENCkRhdGU6IERlY2VtYmVyIDcsIDIwMTIgMTI6NTM6NTkgUE0gRVNUDQpU bzogPHNyYXRsaWZmQGNpc2NvLmNvbTxtYWlsdG86c3JhdGxpZmZAY2lzY28uY29tPj4NCg0KDQpb aHR0cDovL2NjbWFpbC5zb29rbXl1bmcuYWMua3IvbWFpbC93ZWJtYWlscmVjb25mLnB1YmxpYy5k bz83MTk1NzMwXQ0KDQpIZWxsbywgSSdtIFl1bmkgaW4gU2VvdWwsIEtvcmVhIGFuZCBiZWluZyBp biBkb2N0b3JpYWwgY291cnNlLg0KDQoNCkkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUg ZGVmYXVsdCB2YWx1ZSBvZiBoZWxsbyBtZXNzYWdlIGludGVydmFsIGluIEFPRFYuDQoNCkZpcnN0 LCB3aHkgZGlkIHlvdSBzZXQgdGhpcyB2YWx1ZSBhdCAxMDAwIG1zPyBJcyB0aGlzIHZhbHVlIHNl bGVjdGVkIGZyb20gdmFyaW91cyBwZXJmb3JtYW5jZSB0ZXN0Pw0KDQooQmVjYXVzZSBteSBjdXJy ZW50IHJlc2VhcmNoIHRlbGxzIHNvbWUgb3RoZXIgb3B0aW1hbCB2YWx1ZSBvZiBoZWxsbyBwZXJp b2QuKQ0KDQoNCk5leHQsIHdoYXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgd2hlbiBJIHVzZSBvdGhl ciB2YWx1ZShjb21wYXJlZCB0byB5b3Vycykgb2YgaGVsbG8gbWVzc2FnZSBpbnRlcnZhbC4NCg0K DQpZb3VyIHJlc3BvbnNlcyB3aWxsIGJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQNCg0KVGhhbmsgeW91 Lg0KDQoNCmZyb20gWXVuaS4NCg0K --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FF157DAxmbalnx03ciscoc_ Content-Type: text/html; charset="utf-8" Content-ID: <8C7D880224947B4993F9C5589AC98399@cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCkZvcndhcmRpbmcgc29tZXRoaW5nIEkganVzdCBn b3Qgb2ZmbGluZSB0byB0aGUgbGFyZ2VyIGNvbW11bml0eS4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2PlN0YW48L2Rpdj4NCjxkaXY+PGJyPg0KPGRpdj48YnI+ DQo8ZGl2PkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1p bnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBzdHls ZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4 OyBtYXJnaW4tbGVmdDogMHB4OyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6J0hlbHZldGlj YSc7IGZvbnQtc2l6ZTptZWRpdW07IGNvbG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiPjxiPkZyb206 DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTonSGVsdmV0aWNhJzsgZm9udC1z aXplOm1lZGl1bTsiPuydtOycpOqyvSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx5azQ3MDdAc29va215 dW5nLmFjLmtyIj5seWs0NzA3QHNvb2tteXVuZy5hYy5rcjwvYT4mZ3Q7PGJyPg0KPC9zcGFuPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFy Z2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6J0hlbHZldGljYSc7IGZvbnQtc2l6ZTptZWRpdW07IGNvbG9yOnJnYmEoMCwgMCwgMCwg MS4wKTsiPjxiPlN1YmplY3Q6DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTon SGVsdmV0aWNhJzsgZm9udC1zaXplOm1lZGl1bTsiPjxiPkkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBh Ym91dCBBT0RWIGluIE1BTkVUITwvYj48YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1h cmdpbi1sZWZ0OiAwcHg7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTonSGVsdmV0aWNhJzsg Zm9udC1zaXplOm1lZGl1bTsgY29sb3I6cmdiYSgwLCAwLCAwLCAxLjApOyI+PGI+RGF0ZToNCjwv Yj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OidIZWx2ZXRpY2EnOyBmb250LXNpemU6 bWVkaXVtOyI+RGVjZW1iZXIgNywgMjAxMiAxMjo1Mzo1OSBQTSBFU1Q8YnI+DQo8L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJn aW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTonSGVsdmV0aWNhJzsgZm9udC1zaXplOm1lZGl1bTsgY29sb3I6cmdiYSgwLCAwLCAwLCAx LjApOyI+PGI+VG86DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTonSGVsdmV0 aWNhJzsgZm9udC1zaXplOm1lZGl1bTsiPiZsdDs8YSBocmVmPSJtYWlsdG86c3JhdGxpZmZAY2lz Y28uY29tIj5zcmF0bGlmZkBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjwvc3Bhbj48L2Rpdj4NCjxi cj4NCjxwPjxpbWcgc3JjPSJodHRwOi8vY2NtYWlsLnNvb2tteXVuZy5hYy5rci9tYWlsL3dlYm1h aWxyZWNvbmYucHVibGljLmRvPzcxOTU3MzAiPjwvcD4NCjxkaXYgc3R5bGU9IkJBQ0tHUk9VTkQt Q09MT1I6I2ZmZiI+DQo8cD5IZWxsbywgSSdtIFl1bmkgaW4gU2VvdWwsIEtvcmVhIGFuZCBiZWlu ZyBpbiBkb2N0b3JpYWwgY291cnNlLjwvcD4NCjxkaXY+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2st cGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8cD5JIGhhdmUgc29tZSBxdWVzdGlvbnMgYWJvdXQgdGhl IGRlZmF1bHQgdmFsdWUgb2YgaGVsbG8gbWVzc2FnZSBpbnRlcnZhbCBpbiBBT0RWLg0KPC9wPg0K PHA+Rmlyc3QsIHdoeSBkaWQgeW91IHNldCB0aGlzIHZhbHVlIGF0IDEwMDAgbXM/IElzIHRoaXMg dmFsdWUgc2VsZWN0ZWQgZnJvbSB2YXJpb3VzIHBlcmZvcm1hbmNlIHRlc3Q/PC9wPg0KPHA+KEJl Y2F1c2UgbXkgY3VycmVudCByZXNlYXJjaCB0ZWxscyBzb21lIG90aGVyIG9wdGltYWwgdmFsdWUg b2YgaGVsbG8gcGVyaW9kLik8L3A+DQo8ZGl2PjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNl aG9sZGVyIj4NCjwvZGl2Pg0KPHA+TmV4dCwgd2hhdCBzaG91bGQgYmUgY29uc2lkZXJlZCB3aGVu IEkgdXNlIG90aGVyIHZhbHVlKGNvbXBhcmVkIHRvIHlvdXJzKSBvZiBoZWxsbyBtZXNzYWdlIGlu dGVydmFsLjwvcD4NCjxkaXY+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0K PC9kaXY+DQo8cD5Zb3VyIHJlc3BvbnNlcyB3aWxsIGJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQgPC9w Pg0KPHA+VGhhbmsgeW91LiA8L3A+DQo8ZGl2PjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNl aG9sZGVyIj4NCjwvZGl2Pg0KPHA+ZnJvbSBZdW5pLiA8L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FF157DAxmbalnx03ciscoc_-- From teco@inf-net.nl Fri Dec 7 10:23:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95E621F8AA3 for ; Fri, 7 Dec 2012 10:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 XIi3wopyplPm for ; Fri, 7 Dec 2012 10:23:22 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9113D21F8984 for ; Fri, 7 Dec 2012 10:23:21 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so506710eek.31 for ; Fri, 07 Dec 2012 10:23:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=IephYlLYJV+PTfPybciCcu4OJwdZBfmSDP//EEahhKM=; b=p0elvQ/ZW64ofWxav1PYTbeK37OqKoxmkV1gWYOEntTpeCnfzXUYw9E3w+aEC9yl2r LAl0dnLIoNrf1jCUyjR+nHdKi8OgwTJKA2sJyyDJkYSJxTnRDUrsrFdGNIdRA4rl+FNI yrLG6GCRJGfl1wMv4xPGiJSJX9skxvO501uARVseIFOZLTQoHs1zLe4Ga9DjxlAr4Bdz MktN5Y6PaMOx1N13plVC7RVuT1Fb3CzOHuebwdFYfPwiDwUHX+zHfQuhTtV/ttxXr700 8o8SDmo+5M655drW9EU+ZrPwxaZpKYBJmHkuEOdywTcecNy/6pC9280eN7sAU+IOpjz+ 1QBQ== Received: by 10.14.221.5 with SMTP id q5mr19273467eep.33.1354904601244; Fri, 07 Dec 2012 10:23:21 -0800 (PST) Received: from [10.175.173.22] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id b49sm24148755eem.16.2012.12.07.10.23.17 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Dec 2012 10:23:20 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: Date: Fri, 7 Dec 2012 19:23:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <90BDEF4B-4233-452B-948A-733FCA50B6E9@inf-net.nl> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlACxTomBIaO3xasrt3KRusUOmGcstJARRPu9qdkJqvqtSeDMaxjo0MPiVpI36ogdfap5lb Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 18:23:23 -0000 I'm not a fan of a routing protocol that does not support multiple borders. Still, I am interested in reactive protocols. Simple Internet attachment works as described in the draft. Border replies for all destinations outside the network. Network has only single prefix. There are other solutions. BRDP is just one of them. Then, all packets are sent to the border that owns the source address prefix, if destination is outside. BRDP is proactive. I can think=20 of reactive border discovery, but as paths to a border would be=20 used quite frequently, I think proactive makes sense. There are a few implementation details, such as source address selection when there is no default gateway. Teco Op 7 dec. 2012, om 16:34 heeft Henning Rogge het volgende geschreven: > On Fri, Dec 7, 2012 at 4:27 PM, Stan Ratliff (sratliff) > wrote: >> Charlie, >>=20 >> On Dec 6, 2012, at 5:30 PM, Charles E. Perkins wrote: >>> I reckon everyone on this list has used default routes for most of = our >>> network connectivity. But the routers in the AODVv2 specification = don't >>> advertise default routes. >>>=20 >>> And even more to the point, they don't advertise routes like >>> 191.2.3/0 ... >=20 > Just as a comment, setting bits of the "host part" of a network route > is not really useful. the only useful "/0" route is 0.0.0.0/0 (and > ::/0 if you count IPv6). >=20 >>> If we were going to specify more details about an Internet Gateway, >>> then there would be a good reason to discuss advertising default >>> routes, and actually I did do this for an earlier Gateway = specification. >>>=20 >>> Sorry to raise your alarms=85 >>=20 >> No worries. Well, maybe some worries=85 ;-) >>=20 >> I contend that, without any methodology ("gateway" or otherwise) to = get "off of" (and conversely, "into") the MANET, the usefulness of the = protocol is questionable. Otherwise, it's an exercise in creating an = incredible protocol for which the prime use case is "5 guys down at the = coffee house getting together to play black-ops on their computers". = Forgive me, but that isn't worth it. >=20 > Yes, thats my opinion too. >=20 > @Charly: >=20 > I know, announcing prefixes (including the 0/0 prefix) is difficult > for reactive protocols, because it makes detecting a "missing route to > network node" more difficult (but not impossible). >=20 > But I think this MUST to be there in the protocol. >=20 > Henning Rogge > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Fri Dec 7 10:52:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A11721F85DD for ; Fri, 7 Dec 2012 10:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5s+joYUgMD-j for ; Fri, 7 Dec 2012 10:52:45 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4A321F85CB for ; Fri, 7 Dec 2012 10:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=644; q=dns/txt; s=iport; t=1354906365; x=1356115965; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MyA0crVMoVGM78lMTKaJ3GumFZbAB5fWwqX4VbN6sYQ=; b=IA7eJHBb9W+US1csXlIeoCXpFe0W0QYk55riw+d6/qcngsRsoe5eC09I +9ra6iM0hXdNl/Xy2YophtC1WyH4GbVciEjJb3uy7K8Q2vjfSwAjYJQmh qr5ln3keK28oPXK0nH+Lhl/nqOlYdbUNAXo00QIQZgAvcBMNTKfY32HHe U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFA5wlCtJV2a/2dsb2JhbABEvjoWc4IeAQEBAwF5BQsCASokMiUCBA4NiAMGwiuMP4NiYQOmTYJzgiI X-IronPort-AV: E=McAfee;i="5400,1158,6919"; a="150385165" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 07 Dec 2012 18:52:39 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qB7IqdXl027308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Dec 2012 18:52:39 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.125]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Fri, 7 Dec 2012 12:52:38 -0600 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: AODV/DYMO Gateway (was: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN1KwHXvn49iMpvk2ewQrq26lO0A== Date: Fri, 7 Dec 2012 18:52:38 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF168B3@xmb-aln-x03.cisco.com> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <90BDEF4B-4233-452B-948A-733FCA50B6E9@inf-net.nl> In-Reply-To: <90BDEF4B-4233-452B-948A-733FCA50B6E9@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.219] Content-Type: text/plain; charset="Windows-1252" Content-ID: <569BF5FCA72607428E9D425A305B7A37@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: [manet] AODV/DYMO Gateway (was: Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 18:52:46 -0000 Teco,=20 On Dec 7, 2012, at 1:23 PM, Teco Boot wrote: > I'm not a fan of a routing protocol that does not support multiple > borders. Still, I am interested in reactive protocols. >=20 > Simple Internet attachment works as described in the draft. Border > replies for all destinations outside the network. Network has only > single prefix. >=20 So, are you saying that a reactive protocol that has no defined method of i= ngress or egress to/from the MANET is a worthwhile pursuit? If so, I disagr= ee. I think that ingress/egress MUST be well-understood; it SHOULD be a par= t of the document. Regards, Stan [snip] From abdussalambaryun@gmail.com Fri Dec 7 11:06:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB96C21F8A88 for ; Fri, 7 Dec 2012 11:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 cbsjSKPDa6Jd for ; Fri, 7 Dec 2012 11:06:28 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDC721F8925 for ; Fri, 7 Dec 2012 11:06:28 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so796186vbb.31 for ; Fri, 07 Dec 2012 11:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qtrBTIdLlyUs3fdcGwJSRIobKiBxhsyhcd2h+PDmt0c=; b=wmBfgXrFFFiMhZeGN8QDCqggpSjHK3gzDToocfTspoQppA4MZJjucOWVlHQM9iIN7M zR5AWW2nK1Sih3ugm8qZOLMCmahGRPc7/hLWdIa9Ym1ClWiqJX+JWlWmilXCX5OGxo6W suaBcJvVDJiZ30OfdUJk7pscayqx/Eb1cjbgOifTpWZOH0DBlUkIjSbZgAdVv5td10EZ UkR0WtgJfvPABfpauNkCSPvDbd6NDJeaJ6RlHRr0Nko6GLYEzs5wGzJ64EXm4lfMpu30 z0kY1bdJRwpMt/1reVaaftHA1JnGbPSKGzitqiYl1BcpdH6R1BP5EIs8qjrYGHUpuPv4 9caA== MIME-Version: 1.0 Received: by 10.52.27.50 with SMTP id q18mr3926359vdg.20.1354907187592; Fri, 07 Dec 2012 11:06:27 -0800 (PST) Received: by 10.220.145.5 with HTTP; Fri, 7 Dec 2012 11:06:27 -0800 (PST) In-Reply-To: <90BDEF4B-4233-452B-948A-733FCA50B6E9@inf-net.nl> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <90BDEF4B-4233-452B-948A-733FCA50B6E9@inf-net.nl> Date: Fri, 7 Dec 2012 20:06:27 +0100 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 19:06:28 -0000 I agree that this draft should not worry about gateways just reactive routing. We got a proactive document submitted, and now we need complete the reactive one in similar ways, let gateways go into other newer drafts. If we add gateway discussions the draft will become older :-) AB On 12/7/12, Teco Boot wrote: > I'm not a fan of a routing protocol that does not support multiple > borders. Still, I am interested in reactive protocols. > > Simple Internet attachment works as described in the draft. Border > replies for all destinations outside the network. Network has only > single prefix. > > There are other solutions. BRDP is just one of them. Then, all > packets are sent to the border that owns the source address > prefix, if destination is outside. BRDP is proactive. I can think > of reactive border discovery, but as paths to a border would be > used quite frequently, I think proactive makes sense. > > There are a few implementation details, such as source address > selection when there is no default gateway. > > Teco > From abdussalambaryun@gmail.com Fri Dec 7 11:11:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333C921F89B3 for ; Fri, 7 Dec 2012 11:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 A+31pmuEYRce for ; Fri, 7 Dec 2012 11:11:00 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F83621F8925 for ; Fri, 7 Dec 2012 11:11:00 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so798092vcb.31 for ; Fri, 07 Dec 2012 11:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZXQokTS0mBClhQK+tuC4J/N2GJHWddQDolMkvxf9EI8=; b=SSO8BO94hvOOlrgyWk4+ULdpgWn+XJXwqTk4XityLg/Nnggalx84fiE48dbGl1AmTi StFnB+e4q/yA1JOn9BmL7DJ6gRJ74Ko9ixvsdNSTq8PbC8MgE5q6/Lv6qKjNU5/W//nK vQxcKb2VFBgC0sdpq9ePSEPQx5bbrlmJWcNEJmHuJFL/jxd7Y7mtrqjXqTIws+4exlJz DRXBShRSjn+vMs5Ewd345kTg3BuinSKK89Lvyd+OUNae5bCs8IbBKsjvyEJkyeNB2ODh wG6zVMd/zukCa6IGquKVxObWt9kLjxNwRG52U1VrLgoxgn6k0sluQjSh2go6GFoeBaL5 4YCw== MIME-Version: 1.0 Received: by 10.52.27.50 with SMTP id q18mr3933599vdg.20.1354907459019; Fri, 07 Dec 2012 11:10:59 -0800 (PST) Received: by 10.220.145.5 with HTTP; Fri, 7 Dec 2012 11:10:58 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF157DA@xmb-aln-x03.cisco.com> References: <1239834511.545.1354902839367.JavaMail.root@CCMAIL_AP3> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF157DA@xmb-aln-x03.cisco.com> Date: Fri, 7 Dec 2012 20:10:58 +0100 Message-ID: From: Abdussalam Baryun To: lyk4707@sookmyung.ac.kr Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: " List" Subject: Re: [manet] Fwd: I have some questions about AODV in MANET! X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 19:11:01 -0000 yes I recommend it was selected by test of general use cases, if other cases then you will need to test best performance by changing parameters. AB On 12/7/12, Stan Ratliff (sratliff) wrote: > Forwarding something I just got offline to the larger community. > > Regards, > Stan > > > Begin forwarded message: > > From: =EC=9D=B4=EC=9C=A4=EA=B2=BD > > Subject: I have some questions about AODV in MANET! > Date: December 7, 2012 12:53:59 PM EST > To: > > > > [http://ccmail.sookmyung.ac.kr/mail/webmailreconf.public.do?7195730] > > Hello, I'm Yuni in Seoul, Korea and being in doctorial course. > > > I have some questions about the default value of hello message interval i= n > AODV. > > First, why did you set this value at 1000 ms? Is this value selected from > various performance test? > > (Because my current research tells some other optimal value of hello > period.) > > > Next, what should be considered when I use other value(compared to yours)= of > hello message interval. > > > Your responses will be greatly appreciated > > Thank you. > > > from Yuni. > > From charliep@computer.org Fri Dec 7 11:15:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2D521F8AE3 for ; Fri, 7 Dec 2012 11:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 YarYtkeIxq+Y for ; Fri, 7 Dec 2012 11:15:48 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1375B21F8ADF for ; Fri, 7 Dec 2012 11:15:47 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Th3Ok-0001UP-N1; Fri, 07 Dec 2012 14:15:46 -0500 Message-ID: <50C2404E.5080803@computer.org> Date: Fri, 07 Dec 2012 11:15:26 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86aae1d92528b6611c677558a04662ee3e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 19:15:48 -0000 Hello Stan, Your suggestion is one that has been debated and resolved many times. Here's some of what I remember about the discussion. On 12/7/2012 7:27 AM, Stan Ratliff (sratliff) wrote: > I contend that, without any methodology ("gateway" or otherwise) to get "off of" (and conversely, "into") the MANET, the usefulness of the protocol is questionable. No doubt, it is useful to have ingress and egress to MANETs from the Internet. However, they are useful even as standalone networks: - Disaster scenarios - Military scenarios - Sensor networks / Internet of Things - Networks with intermittent Internet connectivity - Wireless Village > Otherwise, it's an exercise in creating an incredible protocol for which the prime use case is "5 guys down at the coffee house getting together to play black-ops on their computers". Forgive me, but that isn't worth it. Several points here: - This issue is not specific to reactive protocols. If it's worth it for proactive, it's worth it for reactive. - I'm delighted to provide a solution, as requested. It would be nearly the same for proactive and reactive, but I can frame it as restricted to reactive. - It doesn't have to be the same document as AODVv2; however, I can enlarge the current IAR section to describe the solution. If history is any guide, doing so might prolong the amount of time needed to finalize AODVv2. - If the five guys were important enough, it would be worth it :-) [... o.k., just kidding here ...] -- Regards, Charlie P. From abdussalambaryun@gmail.com Fri Dec 7 11:20:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A2A21F8B9D for ; Fri, 7 Dec 2012 11:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 7Y2b4-nD9Zjs for ; Fri, 7 Dec 2012 11:20:48 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D29E321F8AEC for ; Fri, 7 Dec 2012 11:20:46 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so806933vcb.31 for ; Fri, 07 Dec 2012 11:20:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vQ1w+WOn8slwDzizMe84pGRBHc4smp5Ez3rS9G9+h7A=; b=I9SghUNdc5EEe+Zoj/ZI5I344QJmhc7COYOP14akJyWOIF3W/DSLIPh2kEFTA+HP8z y2nBj3eDqH/aV+UcXmsoOzisbc2SGWdxTGTJAe4JnsglPP0o/A2Tuqi+NjZzw0xNgIGA 1w3UjzvosSXHC/W70FGVa4FA7jA89/CkmhxP/TjNHqjhgivV4Tr/rGF3cjwx7YNsAmM8 DjGtM8QeF3eC0hPbuZ042Xs8bau3fRsx9SQTQRiekMIUwkjbRPtyZdw2fLNpXSAwyOzF R5nV6pT4OJCvqKaVXA/UoRekFIy59HXbvw639a13M/u39JHlL3c9sbxUxOKKygjJtnKU 0OEQ== MIME-Version: 1.0 Received: by 10.52.175.106 with SMTP id bz10mr946453vdc.125.1354908046369; Fri, 07 Dec 2012 11:20:46 -0800 (PST) Received: by 10.220.145.5 with HTTP; Fri, 7 Dec 2012 11:20:46 -0800 (PST) In-Reply-To: <50C2404E.5080803@computer.org> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> Date: Fri, 7 Dec 2012 20:20:46 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 19:20:49 -0000 I agree with input and that we do for gateways issue of both proactive and reactive in one new draft to cover Stan's concerns, AB On 12/7/12, Charles E. Perkins wrote: > > Hello Stan, > > Your suggestion is one that has been debated and resolved > many times. Here's some of what I remember about the > discussion. > > On 12/7/2012 7:27 AM, Stan Ratliff (sratliff) wrote: >> I contend that, without any methodology ("gateway" or otherwise) to get >> "off of" (and conversely, "into") the MANET, the usefulness of the >> protocol is questionable. > > No doubt, it is useful to have ingress and egress to MANETs from the > Internet. > > However, they are useful even as standalone networks: > - Disaster scenarios > - Military scenarios > - Sensor networks / Internet of Things > - Networks with intermittent Internet connectivity > - Wireless Village > > >> Otherwise, it's an exercise in creating an incredible protocol for which >> the prime use case is "5 guys down at the coffee house getting together to >> play black-ops on their computers". Forgive me, but that isn't worth it. > > Several points here: > - This issue is not specific to reactive protocols. If it's worth it > for proactive, > it's worth it for reactive. > - I'm delighted to provide a solution, as requested. It would be nearly > the same > for proactive and reactive, but I can frame it as restricted to > reactive. > - It doesn't have to be the same document as AODVv2; however, I can enlarge > the current IAR section to describe the solution. If history is any > guide, > doing so might prolong the amount of time needed to finalize AODVv2. > - If the five guys were important enough, it would be worth it :-) [... > o.k., > just kidding here ...] > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From charliep@computer.org Fri Dec 7 11:23:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FCF21F8615 for ; Fri, 7 Dec 2012 11:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 z2rto4WO1Gxb for ; Fri, 7 Dec 2012 11:23:32 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id E135F21F853F for ; Fri, 7 Dec 2012 11:23:31 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Th3WF-000237-94; Fri, 07 Dec 2012 14:23:31 -0500 Message-ID: <50C24224.6010704@computer.org> Date: Fri, 07 Dec 2012 11:23:16 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Henning Rogge References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad867a55c743f69dfe199cdef42d10dfab81350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 19:23:32 -0000 Hello Henning, In an earlier email, you objected to my suggestion that zero was an invalid as claimed in the AODVv2 specification. AODVv2 routers never advertise 0.0.0.0 in any RteMsg (RREQ or RREP). On 12/7/2012 7:34 AM, Henning Rogge wrote: > >>> I reckon everyone on this list has used default routes for most of our >>> network connectivity. But the routers in the AODVv2 specification don't >>> advertise default routes. >>> >>> And even more to the point, they don't advertise routes like >>> 191.2.3/0 ... > Just as a comment, setting bits of the "host part" of a network route > is not really useful. the only useful "/0" route is 0.0.0.0/0 (and > ::/0 if you count IPv6). This was exactly my point. > I know, announcing prefixes (including the 0/0 prefix) is difficult > for reactive protocols, because it makes detecting a "missing route to > network node" more difficult (but not impossible). But I think this > MUST to be there in the protocol. Henning Rogge As I mentioned to Stan, I'm happy to go down that road. But I am also happy to make it into a separate document. Either way, I think it would be a bad idea for AODVv2 routers to advertise 0.0.0.0/0 as a general rule. The Gateway *might* do so, or else it might simply advertise that it's a "gateway". I'd prefer the latter, based on various complications that the former approach introduces. Not all functions that are *required* for MANETs to be useful have to be part of the reactive protocol specification. -- Regards, Charlie P. From charliep@computer.org Fri Dec 7 11:42:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE6521F86EB for ; Fri, 7 Dec 2012 11:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 XB40+qxRNme8 for ; Fri, 7 Dec 2012 11:42:27 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBEB21F86C8 for ; Fri, 7 Dec 2012 11:42:27 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Th3oY-0000EJ-5U; Fri, 07 Dec 2012 14:42:26 -0500 Message-ID: <50C24693.9070404@computer.org> Date: Fri, 07 Dec 2012 11:42:11 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Yuni References: <1239834511.545.1354902839367.JavaMail.root@CCMAIL_AP3> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF157DA@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF157DA@xmb-aln-x03.cisco.com> Content-Type: multipart/alternative; boundary="------------050009050002090202090100" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86d2db156f881db10770174de52514a1d0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: MANET List Subject: Re: [manet] Fwd: I have some questions about AODV in MANET! X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 19:42:29 -0000 This is a multi-part message in MIME format. --------------050009050002090202090100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Yuni, Hello messaging in AODV has been the source of numerous controversies. For one thing, it's not "reactive". For another, there are many "better" neighbor discovery protocols available. As an aside, now (nearly twenty years after first including the Hello messages as part of AODV) I believe that most such neighbor discovery protocols "should" also work as part of a multicast-backbone creation protocol, simply in order to reduce the amount of periodic signaling in the network. The 1000 ms value was selected as a tradeoff between a) the amount of time needed to detect a broken link b) the number of "typically useless" protocol messages interfering with actual data packet transmission. This value seriously needs adjustment depending on the nodal degree of the network. If the degree is small, the value can be less than 1000ms. If the degree is large, the value should be more than 1000ms. It also needs adjustment based on the bandwidth of the underlying physical medium. If you've got 55 Mb/sec WiFi, you don't have too much to worry over, no matter how dense the network is. In the mid 1990's, we were lucky to have even 100 Kb/sec. Anyway, bottom line: - AODV is Experimental and many decisions made in the late 1990's are often irrelevant nowadays - It was always expected that people would adjust these parameters based on particular network requirements. - Please look at alternate neighbor discovery methods. Regards, Charlie P. On 12/7/2012 9:59 AM, Stan Ratliff (sratliff) wrote: > Forwarding something I just got offline to the larger community. > > Regards, > Stan > > > Begin forwarded message: > >> *From: *??? > >> *Subject: **I have some questions about AODV in MANET!* >> *Date: *December 7, 2012 12:53:59 PM EST >> *To: *> >> >> Hello, I'm Yuni in Seoul, Korea and being in doctorial course. >> >> >> I have some questions about the default value of hello message >> interval in AODV. >> >> First, why did you set this value at 1000 ms? Is this value selected >> from various performance test? >> >> (Because my current research tells some other optimal value of hello >> period.) >> >> >> Next, what should be considered when I use other value(compared to >> yours) of hello message interval. >> >> >> Your responses will be greatly appreciated >> >> Thank you. >> >> >> from Yuni. >> > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Regards, Charlie P. --------------050009050002090202090100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello Yuni,

Hello messaging in AODV has been the source of numerous
controversies.  For one thing, it's not "reactive".  For another,
there are many "better" neighbor discovery protocols available.
As an aside, now (nearly twenty years after first including the
Hello messages as part of AODV) I believe that most such
neighbor discovery protocols "should" also work as part of
a multicast-backbone creation protocol, simply in order to
reduce the amount of periodic signaling in the network.

The 1000 ms value was selected as a tradeoff between
a) the amount of time needed to detect a broken link
b) the number of "typically useless" protocol messages
     interfering with actual data packet transmission.
This value seriously needs adjustment depending on the
nodal degree of the network.  If the degree is small, the
value can be less than 1000ms.  If the degree is large, the
value should be more than 1000ms.

It also needs adjustment based on the bandwidth of the
underlying physical medium.  If you've got 55 Mb/sec
WiFi, you don't have too much to worry over, no matter
how dense the network is.  In the mid 1990's, we were
lucky to have even 100 Kb/sec.

Anyway, bottom line:
- AODV is Experimental and many decisions made in the
   late 1990's are often irrelevant nowadays
- It was always expected that people would adjust these
   parameters based on particular network requirements.
- Please look at alternate neighbor discovery methods.

Regards,
Charlie P.


On 12/7/2012 9:59 AM, Stan Ratliff (sratliff) wrote:
Forwarding something I just got offline to the larger community.

Regards,
Stan


Begin forwarded message:

From: 이윤경 <lyk4707@sookmyung.ac.kr>
Subject: I have some questions about AODV in MANET!
Date: December 7, 2012 12:53:59 PM EST

Hello, I'm Yuni in Seoul, Korea and being in doctorial course.


I have some questions about the default value of hello message interval in AODV.

First, why did you set this value at 1000 ms? Is this value selected from various performance test?

(Because my current research tells some other optimal value of hello period.)


Next, what should be considered when I use other value(compared to yours) of hello message interval.


Your responses will be greatly appreciated

Thank you.


from Yuni. 




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



-- 
Regards,
Charlie P.
--------------050009050002090202090100-- From charliep@computer.org Fri Dec 7 12:07:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8207121F8758 for ; Fri, 7 Dec 2012 12:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 azgKja8P+JZs for ; Fri, 7 Dec 2012 12:07:28 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id C2A8521F85DA for ; Fri, 7 Dec 2012 12:07:27 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Th4Cl-0006nL-Bk; Fri, 07 Dec 2012 15:07:27 -0500 Message-ID: <50C24C6E.30101@computer.org> Date: Fri, 07 Dec 2012 12:07:10 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Henning Rogge References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86cad5573c387faa9f77a3cb003553faa3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "" Subject: [manet] Announcing prefixes... {was, Re: I-D Action: draft-ietf-manet-dymo-24.txt} X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 20:07:28 -0000 Hello Henning, I forgot to mention something... On 12/7/2012 7:34 AM, Henning Rogge wrote: > I know, announcing prefixes (including the 0/0 prefix) is difficult > for reactive protocols, because it makes detecting a "missing route to > network node" more difficult (but not impossible). But I think this > MUST to be there in the protocol. In fact, AODVv2 does enable AODVv2 routers to announce prefixes for their "client networks". When an AODVv2 router does that, it offers connectivity to any host on that "client network". The current document does not restrict the way that the AODVv2 router manages to offer this connectivity. If router X advertises connectivity to 191.78.79/24 (for example), then any other AODVv2 router in the MANET that wants to send a packet to any host on 191.78.79/24 can do so without initiating Route Discovery, by using its network route towards router X. This works just fine for "small" networks like 191.78.79/24. For 0/0, it makes the Gateway into a serious bottleneck. This feature also suggests that two different AODVv2 routers in an RFC 5444 address block may need to advertise network routes with different values. -- Regards, Charlie P. From sratliff@cisco.com Fri Dec 7 12:29:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6ED21F87D9 for ; Fri, 7 Dec 2012 12:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nokLHxaCfo6B for ; Fri, 7 Dec 2012 12:29:19 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DD49921F8745 for ; Fri, 7 Dec 2012 12:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2868; q=dns/txt; s=iport; t=1354912159; x=1356121759; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=U6Xq1sCkkeLQ95a8DmN25IE+WcTCBcf5Zjmko1afXzE=; b=dDCQ1xk9MYdng7PVzK/hHXa9A+qIlDLyYXbztfg1bQo+GUG10YJd9Cy4 1wqnX5IRhHAIZWJTIMmCnLK7fCGMDtoR8f1a/ct6NBmjuPaabzCRCq1k5 oFiyrTzyYAmGyWE2CBDJ167UCmtjcrVwpST9dIIjtjr67q65uIM9gO2PV c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAINQwlCtJV2Y/2dsb2JhbABEunuDQxZzgh4BAQEDAXkQAgEIGAokMiUCBA4NE4dwBsFbjD+DYmEDpk2Cc4Ii X-IronPort-AV: E=McAfee;i="5400,1158,6919"; a="150616927" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 07 Dec 2012 20:29:17 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qB7KTHWa001003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Dec 2012 20:29:17 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.125]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Fri, 7 Dec 2012 14:29:17 -0600 From: "Stan Ratliff (sratliff)" To: "Charles E. Perkins" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-24.txt Thread-Index: AQHNz3PfX48qsstVK0mFSMr40eak8pgHeRGAgAOwKwCAALZvgIAAtL0AgAAzy4CAARwvgIAAP7gAgAAUoQA= Date: Fri, 7 Dec 2012 20:29:17 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> In-Reply-To: <50C2404E.5080803@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.219] Content-Type: text/plain; charset="Windows-1252" Content-ID: <638D85E75C3E43438DEEA6102A809EF3@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 20:29:20 -0000 On Dec 7, 2012, at 2:15 PM, Charles E. Perkins wrote: >=20 > Hello Stan, >=20 > Your suggestion is one that has been debated and resolved > many times. Here's some of what I remember about the > discussion. >=20 > On 12/7/2012 7:27 AM, Stan Ratliff (sratliff) wrote: >> I contend that, without any methodology ("gateway" or otherwise) to get = "off of" (and conversely, "into") the MANET, the usefulness of the protocol= is questionable. >=20 > No doubt, it is useful to have ingress and egress to MANETs from the Inte= rnet. >=20 > However, they are useful even as standalone networks: > - Disaster scenarios > - Military scenarios > - Sensor networks / Internet of Things > - Networks with intermittent Internet connectivity > - Wireless Village >=20 I've dealt with the first two use cases you describe, and ingress/egress ha= s been an issue in every deployment. Admittedly, I'm extrapolating from my = experience, but when every single customer says "I need a way to communicat= e with the MANET from places outside the MANET", it seems pretty compelling= =85 And as for the "intermittent connectivity" case, yeah, I get it - it's = where MANET crosses that imaginary, ill-defined line into DTN. But the fact= that you *have* Internet connectivity, even intermittently, leads me to th= e conclusion that there needs to be a way to exploit it when it exists. >=20 >> Otherwise, it's an exercise in creating an incredible protocol for whic= h the prime use case is "5 guys down at the coffee house getting together t= o play black-ops on their computers". Forgive me, but that isn't worth it. >=20 > Several points here: > - This issue is not specific to reactive protocols. If it's worth it for= proactive, > it's worth it for reactive. > - I'm delighted to provide a solution, as requested. It would be nearly = the same > for proactive and reactive, but I can frame it as restricted to reactiv= e. > - It doesn't have to be the same document as AODVv2; however, I can enlar= ge > the current IAR section to describe the solution. If history is any gu= ide, > doing so might prolong the amount of time needed to finalize AODVv2. > - If the five guys were important enough, it would be worth it :-) [... = o.k., > just kidding here =85] My feeling, FWIW, is that ingress/egress SHOULD be a part of the base docum= ent. However, I understand the concerns of people that say it might be a pr= oblem (or extend ratification time, etc etc). So, I'm interested in hearing= other, interested opinions - both for DYMO/AODVv2/Whatever-we're-calling-i= t-this-week, as well as with regard to the LOADng spec.=20 And lastly=85.. if the 5 guys were *that* important, they most likely would= n't be *playing* black-ops=85 ;-) Stan >=20 > --=20 > Regards, > Charlie P. >=20 From charliep@computer.org Fri Dec 7 13:01:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFEC21F87C8 for ; Fri, 7 Dec 2012 13:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 pxPIxMFKMZRb for ; Fri, 7 Dec 2012 13:01:03 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD9821F8713 for ; Fri, 7 Dec 2012 13:01:02 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Th52c-0005D0-8v; Fri, 07 Dec 2012 16:01:02 -0500 Message-ID: <50C25900.7010509@computer.org> Date: Fri, 07 Dec 2012 13:00:48 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86eb376e471497b6d9976dc5d52ee3d58e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 21:01:04 -0000 Hello Stan, Small follow-up... On 12/7/2012 12:29 PM, Stan Ratliff (sratliff) wrote: > On Dec 7, 2012, at 2:15 PM, Charles E. Perkins wrote: > >> >> No doubt, it is useful to have ingress and egress to MANETs from the Internet. >> >> However, they are useful even as standalone networks: >> - Disaster scenarios >> - Military scenarios >> - Sensor networks / Internet of Things >> - Networks with intermittent Internet connectivity >> - Wireless Village >> > I've dealt with the first two use cases you describe, and ingress/egress has been an issue in every deployment. Admittedly, I'm extrapolating from my experience, but when every single customer says "I need a way to communicate with the MANET from places outside the MANET", it seems pretty compelling… See my first sentence! And, I observe that your customers didn't restrict to reactive. Indeed, Internet access is quite compelling, useful, and something worthy of attention in the working group. > And as for the "intermittent connectivity" case, yeah, I get it - it's where MANET crosses that imaginary, ill-defined line into DTN. DTN would be a *possible* functionality of the Gateway. Triggering expensive but temporary link establishment might be another. Address autoconfiguration might be another Offering *egress* is, as it turns out, a different functionality than offering *ingress*. Not that I'm claiming they should be in separate documents, but just pointing out something interesting. > But the fact that you *have* Internet connectivity, even intermittently, leads me to the conclusion that there needs to be a way to exploit it when it exists. Check. >> Several points here: >> - This issue is not specific to reactive protocols. If it's worth it for proactive, >> it's worth it for reactive. >> - I'm delighted to provide a solution, as requested. It would be nearly the same >> for proactive and reactive, but I can frame it as restricted to reactive. >> - It doesn't have to be the same document as AODVv2; however, I can enlarge >> the current IAR section to describe the solution. If history is any guide, >> doing so might prolong the amount of time needed to finalize AODVv2. >> - If the five guys were important enough, it would be worth it :-) [... o.k., >> just kidding here …] > My feeling, FWIW, is that ingress/egress SHOULD be a part of the base document. However, I understand the concerns of people that say it might be a problem (or extend ratification time, etc etc). I stand ready to go there, but just want to be clear that in the past it's been a long row to hoe. And, to re-emphasize, not all features useful for MANETs have to be in the reactive protocol document. > So, I'm interested in hearing other, interested opinions - both for DYMO/AODVv2/Whatever-we're-calling-it-this-week, I think that a single name change over the life of the Proposed Standard specification isn't very much like flavor-of-the-week...?? > as well as with regard to the LOADng spec. I think the considerations would be practically identical. > > > And lastly….. if the 5 guys were *that* important, they most likely wouldn't be *playing* black-ops… ;-) Well, I wouldn't mess with them. -- Regards, Charlie P. From teco@inf-net.nl Sat Dec 8 08:19:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4223921F86FF for ; Sat, 8 Dec 2012 08:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 vjPVDdiRaGFQ for ; Sat, 8 Dec 2012 08:19:46 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF6521F86D5 for ; Sat, 8 Dec 2012 08:19:45 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so892926eek.31 for ; Sat, 08 Dec 2012 08:19:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=04hUA+KqoMqryjunLLBQxif0/wUDnky7JOG+DDsY8do=; b=OkXkmoUTVJnjpnZ1t9VFWp0yLtCHE6qrIGB58KGAfhNP0vfGfwp1CPnrIlJpBRi2ja drJv9Pnmy9fLwONbwCiWOKDX/ZplqrhXEOAerD8tNTN/Wgio+CM5ckLZau/djEbQGrLS LltzPTwYYvGnbKAuu4FDiIetWQCkXA+ehvEuUpxNoc2U/fNGIPlVg9wL62Qo76bmzt6V 1BVlRx9IHCrHq6l39XhQuHl8KT2Hm/BvFawmmOdBaog9WMYBBCufb8ASJij2O8xccAiB Yj97aGC0b4MEnFJgjJdTL1nLsV57BmZOlHtzdBVtna5TTSWQgP/83YZ+EKIb61sBjYcZ Cuuw== Received: by 10.14.215.194 with SMTP id e42mr29778534eep.32.1354983585123; Sat, 08 Dec 2012 08:19:45 -0800 (PST) Received: from ?IPv6:2001:470:7a9b:1:4057:aa7d:3c88:81cb? ([2001:470:7a9b:1:4057:aa7d:3c88:81cb]) by mx.google.com with ESMTPS id e2sm30551509eeo.8.2012.12.08.08.19.43 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 08 Dec 2012 08:19:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF168B3@xmb-aln-x03.cisco.com> Date: Sat, 8 Dec 2012 17:19:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <90BDEF4B-4233-452B-948A-733FCA50B6E9@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF168B3@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkYIr6UfBRAT1bkyqYc4K2CJG3NB72RUtAcVhJqg2DGgSss8PtfNHBHvr0OtyNqmIiAC3NT Cc: "" Subject: Re: [manet] AODV/DYMO Gateway (was: Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 16:19:47 -0000 Op 7 dec. 2012, om 19:52 heeft Stan Ratliff (sratliff) het volgende = geschreven: > Teco,=20 >=20 > On Dec 7, 2012, at 1:23 PM, Teco Boot wrote: >=20 >> I'm not a fan of a routing protocol that does not support multiple >> borders. Still, I am interested in reactive protocols. >>=20 >> Simple Internet attachment works as described in the draft. Border >> replies for all destinations outside the network. Network has only >> single prefix. >>=20 >=20 > So, are you saying that a reactive protocol that has no defined method = of ingress or egress to/from the MANET is a worthwhile pursuit? I didn't say that. > If so, I disagree. I think that ingress/egress MUST be = well-understood; it SHOULD be a part of the document. Well, it has to be specified somewhere. BGP isn't part of OSPF. dymo-24 has the "Simple Internet Attachment", it permits only a single = gateway. For many use cases, this would be fine.=20 I said I'm interested in the multi-homed use cases. dymo-24 doesn't = support it right now. Teco >=20 > Regards, > Stan >=20 >=20 > [snip] >=20 From jpmacker@gmail.com Sat Dec 8 12:48:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA05A21F8548 for ; Sat, 8 Dec 2012 12:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 1nPeZ7sPEBns for ; Sat, 8 Dec 2012 12:48:58 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A84E21F8531 for ; Sat, 8 Dec 2012 12:48:58 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so907211qca.31 for ; Sat, 08 Dec 2012 12:48:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=+jAeCqJVm8mXNdebWURkYxM+Tgk59Nr31zq7TjM21iw=; b=mbEygwedxxU7QPi5SASPNmOhMTR6CpPf55LVS1hsTRpmyQYrJvA7XcLiQc28DRaCXf ubktowHbqZMtBCQ43k+VD8hxqaRERAoSbANol4wd3ZI3Ojw0VIjS4gkXBAFhrU6I9JqI G591PTiHIbIziqnJ4f7Zc07RDZjRSbmHxAYGfzOnA75Sif2aO6edyHd2s0lVJo/oAEhA J4YZ9QPkhM2KTT90kMUzwZAg3BDekzrKhVc73AJdjX4s4viPr21xGENxenr6niI7erkH Jc1uo3DR78oFaiu1IPmcVMahcZP2JP0HUvnra43mNiA3SRBO/DmASPjbAlHa0IactrrK lLbg== Received: by 10.224.179.212 with SMTP id br20mr17273492qab.51.1354999737584; Sat, 08 Dec 2012 12:48:57 -0800 (PST) Received: from [192.168.0.3] (c-69-140-35-132.hsd1.md.comcast.net. [69.140.35.132]) by mx.google.com with ESMTPS id ga9sm10891012qab.22.2012.12.08.12.48.56 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 08 Dec 2012 12:48:57 -0800 (PST) References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> X-Mailer: iPad Mail (10A523) From: jpmacker Date: Sat, 8 Dec 2012 15:48:57 -0500 To: "Stan Ratliff (sratliff)" Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 20:48:58 -0000 I would agree these networks may be somewhat private or unique but they are o= ften internetworked and are also often heterogeneous. while gatewaying reac= tive is perhaps more difficult and there may be multiple strategies i also f= eel something should be in the base specification On Dec 7, 2012, at 3:29 PM, "Stan Ratliff (sratliff)" w= rote: >=20 > On Dec 7, 2012, at 2:15 PM, Charles E. Perkins wrote: >=20 >>=20 >> Hello Stan, >>=20 >> Your suggestion is one that has been debated and resolved >> many times. Here's some of what I remember about the >> discussion. >>=20 >> On 12/7/2012 7:27 AM, Stan Ratliff (sratliff) wrote: >>> I contend that, without any methodology ("gateway" or otherwise) to get "= off of" (and conversely, "into") the MANET, the usefulness of the protocol i= s questionable. >>=20 >> No doubt, it is useful to have ingress and egress to MANETs from the Inte= rnet. >>=20 >> However, they are useful even as standalone networks: >> - Disaster scenarios >> - Military scenarios >> - Sensor networks / Internet of Things >> - Networks with intermittent Internet connectivity >> - Wireless Village >=20 > I've dealt with the first two use cases you describe, and ingress/egress h= as been an issue in every deployment. Admittedly, I'm extrapolating from my e= xperience, but when every single customer says "I need a way to communicate w= ith the MANET from places outside the MANET", it seems pretty compelling=E2=80= =A6 And as for the "intermittent connectivity" case, yeah, I get it - it's w= here MANET crosses that imaginary, ill-defined line into DTN. But the fact t= hat you *have* Internet connectivity, even intermittently, leads me to the c= onclusion that there needs to be a way to exploit it when it exists. >=20 >>=20 >>> Otherwise, it's an exercise in creating an incredible protocol for which= the prime use case is "5 guys down at the coffee house getting together to p= lay black-ops on their computers". Forgive me, but that isn't worth it. >>=20 >> Several points here: >> - This issue is not specific to reactive protocols. If it's worth it for= proactive, >> it's worth it for reactive. >> - I'm delighted to provide a solution, as requested. It would be nearly t= he same >> for proactive and reactive, but I can frame it as restricted to reactive= . >> - It doesn't have to be the same document as AODVv2; however, I can enlar= ge >> the current IAR section to describe the solution. If history is any gui= de, >> doing so might prolong the amount of time needed to finalize AODVv2. >> - If the five guys were important enough, it would be worth it :-) [... o= .k., >> just kidding here =E2=80=A6] >=20 > My feeling, FWIW, is that ingress/egress SHOULD be a part of the base docu= ment. However, I understand the concerns of people that say it might be a pr= oblem (or extend ratification time, etc etc). So, I'm interested in hearing o= ther, interested opinions - both for DYMO/AODVv2/Whatever-we're-calling-it-t= his-week, as well as with regard to the LOADng spec.=20 >=20 > And lastly=E2=80=A6.. if the 5 guys were *that* important, they most likel= y wouldn't be *playing* black-ops=E2=80=A6 ;-) >=20 > Stan >=20 >=20 >>=20 >> --=20 >> Regards, >> Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From thierry.lys@erdfdistribution.fr Sat Dec 8 13:03:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238A821F8600 for ; Sat, 8 Dec 2012 13:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.648 X-Spam-Level: X-Spam-Status: No, score=-7.648 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 KWq-JohkReFt for ; Sat, 8 Dec 2012 13:03:33 -0800 (PST) Received: from mtagate3.edf.fr (mtagate3.edf.fr [192.196.142.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7684B21F85DA for ; Sat, 8 Dec 2012 13:03:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,243,1355094000"; d="scan'208,217";a="139575362" Received: from unknown (HELO XHUB003BU.notes.edfgdf.fr) ([192.196.9.98]) by PCYF1MTA3.edf.fr with ESMTP; 08 Dec 2012 21:48:13 +0100 Auto-Submitted: auto-generated From: Thierry LYS To: manet@ietf.org Message-ID: Date: Sat, 8 Dec 2012 22:03:28 +0100 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=4EBBF05DDFE02A508f9e8a93df938690918c4EBBF05DDFE02A50" Content-Disposition: inline Subject: [manet] Thierry LYS est absent(e). X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 21:03:34 -0000 --0__=4EBBF05DDFE02A508f9e8a93df938690918c4EBBF05DDFE02A50 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Je serai absent(e) du 08/12/2012 au 24/12/2012. Je r=E9pondrai =E0 votre message d=E8s mon retour.= --0__=4EBBF05DDFE02A508f9e8a93df938690918c4EBBF05DDFE02A50 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable

Je serai absent(e) du 08/12/20= 12 au 24/12/2012.

Je r=E9pondrai =E0 votre me= ssage d=E8s mon retour.= --0__=4EBBF05DDFE02A508f9e8a93df938690918c4EBBF05DDFE02A50-- From charliep@computer.org Sat Dec 8 13:17:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EB821F89F6 for ; Sat, 8 Dec 2012 13:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 IuNGP+dcku9B for ; Sat, 8 Dec 2012 13:17:36 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id DB56921F89CE for ; Sat, 8 Dec 2012 13:17:35 -0800 (PST) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1ThRm9-0002Q8-G1; Sat, 08 Dec 2012 16:17:33 -0500 Message-ID: <50C3AE5E.1000900@computer.org> Date: Sat, 08 Dec 2012 13:17:18 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: jpmacker References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> In-Reply-To: <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> Content-Type: multipart/alternative; boundary="------------080106030004040109020104" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8664170bda5f9664ed93320ccb5d2eec9a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 21:17:36 -0000 This is a multi-part message in MIME format. --------------080106030004040109020104 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello Joe, Having a gateway from the MANET to the Internet is about the same whether the routing protocol is proactive or reactive. So, if this is a necessary feature for AODVv2, then presumably it's also a necessary feature for OLSRv2. Since the specification would be similar in either case, should we have one document to serve both cases? While of course I agree that we should support Internet Gateways, I am pretty sure it doesn't have to be part of the base specification, for the abovementioned reason as well as several other reasons. As I mentioned before to Henning: > > Not all functions that are *required* for MANETs to be useful > have to be part of the reactive protocol specification. Regards, Charlie P. On 12/8/2012 12:48 PM, jpmacker wrote: > I would agree these networks may be somewhat private or unique but they are often internetworked and are also often heterogeneous. while gatewaying reactive is perhaps more difficult and there may be multiple strategies i also feel something should be in the base specification > > -- Regards, Charlie P. --------------080106030004040109020104 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


Hello Joe,

Having a gateway from the MANET to the Internet is about the same
whether the routing protocol is proactive or reactive.  So, if this is a
necessary feature for AODVv2, then presumably it's also a necessary
feature for OLSRv2.

Since the specification would be similar in either case, should we
have one document to serve both cases?

While of course I agree that we should support Internet Gateways,
I am pretty sure it doesn't have to be part of the base specification,
for the abovementioned reason as well as several other reasons.
As I mentioned before to Henning:


Not all functions that are *required* for MANETs to be useful
have to be part of the reactive protocol specification.


Regards,
Charlie P.



On 12/8/2012 12:48 PM, jpmacker wrote:
I would agree these networks may be somewhat private or unique but they are often internetworked and are also often heterogeneous.  while gatewaying reactive is perhaps more difficult and there may be multiple strategies i also feel something should be in the base specification




-- 
Regards,
Charlie P.
--------------080106030004040109020104-- From jpmacker@gmail.com Sat Dec 8 21:09:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518D421F8BAE for ; Sat, 8 Dec 2012 21:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 aOZdgkgAdvVk for ; Sat, 8 Dec 2012 21:09:46 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8C61821F8BA8 for ; Sat, 8 Dec 2012 21:09:46 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id i20so690900qad.10 for ; Sat, 08 Dec 2012 21:09:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=hPg8YhUesWNU8tNvPsRPtk2yfSHQ5EUGu5KBUpeW7OE=; b=HnlLAKen6ScP86lZ2r0cEKZt8fz8vMP9/8S90E91WuAD71V7nQYkolfdCEJiWZWaJT dezf04w75V2eBufNBDYArlTL7ZFJ73KghOmfZ+nYzw4vmxvPTxUI/nONj3Ui6qTnR9xj ZgaAt55Vyhl6xdqjmyJQb4FGxcClftDL5KV0d5aRH1nlsdPEBykoLHsPiw8meSHKoGer ung72Yu4+v5ZvgvvHXnuALmQRkDwC3of1y9JeR5MQk13qXytSsDBBVnOZR2lk817tra9 TyQJH+bd6HfsnPlROCqHjz1Uvbhw4TMFptEpti3KLuI3ziIXujv6nablBzkNdlkEyZ9+ dOjQ== Received: by 10.224.109.199 with SMTP id k7mr19008342qap.66.1355029786054; Sat, 08 Dec 2012 21:09:46 -0800 (PST) Received: from [192.168.0.3] (c-69-140-35-132.hsd1.md.comcast.net. [69.140.35.132]) by mx.google.com with ESMTPS id q14sm11884221qaa.15.2012.12.08.21.09.44 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 08 Dec 2012 21:09:45 -0800 (PST) References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> Mime-Version: 1.0 (1.0) In-Reply-To: <50C3AE5E.1000900@computer.org> Content-Type: multipart/alternative; boundary=Apple-Mail-8BEC59BE-CE72-48CC-B256-1A2FBDB5F31C Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10A523) From: jpmacker Date: Sun, 9 Dec 2012 00:09:45 -0500 To: "Charles E. Perkins" Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 05:09:47 -0000 --Apple-Mail-8BEC59BE-CE72-48CC-B256-1A2FBDB5F31C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Well the 1st part of my comment was just supporting the fact that i believe m= any of the networks you mentioned need border gateway solutions. It sounded= like there was disagreement on that. 2nd i said i believe "something" should be in the base specification i did n= ot say what or whether it goes as far as a design recommendation. Perhaps a= t a minimum discuss known gatewaying issues/challenges. What I dont want is t= he impression left that solutions are not needed because I strongly believe t= hey are needed. Lets discuss one document at a time. Sent from my iPad On Dec 8, 2012, at 4:17 PM, "Charles E. Perkins" wro= te: >=20 > Hello Joe, >=20 > Having a gateway from the MANET to the Internet is about the same > whether the routing protocol is proactive or reactive. So, if this is a > necessary feature for AODVv2, then presumably it's also a necessary > feature for OLSRv2. >=20 > Since the specification would be similar in either case, should we > have one document to serve both cases? >=20 > While of course I agree that we should support Internet Gateways, > I am pretty sure it doesn't have to be part of the base specification, > for the abovementioned reason as well as several other reasons. > As I mentioned before to Henning: >=20 >>=20 >> Not all functions that are *required* for MANETs to be useful=20 >> have to be part of the reactive protocol specification.=20 >=20 >=20 > Regards, > Charlie P. >=20 >=20 >=20 > On 12/8/2012 12:48 PM, jpmacker wrote: >> I would agree these networks may be somewhat private or unique but they a= re often internetworked and are also often heterogeneous. while gatewaying r= eactive is perhaps more difficult and there may be multiple strategies i als= o feel something should be in the base specification >>=20 >>=20 >=20 > --=20 > Regards, > Charlie P. --Apple-Mail-8BEC59BE-CE72-48CC-B256-1A2FBDB5F31C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Well the 1st part of my comment was just supporting the fact that i believe many of the networks you mentioned need border gateway solutions.  It sounded like there was disagreement on that.

2nd i said i believe "something" should be in the base specification i did not say what or whether it goes as far as a design recommendation.  Perhaps at a minimum discuss known gatewaying issues/challenges. What I dont want is the impression left that solutions are not needed because I strongly believe they are needed.

Lets discuss one document at a time.

Sent from my iPad

On Dec 8, 2012, at 4:17 PM, "Charles E. Perkins" <charliep@computer.org> wrote:


Hello Joe,

Having a gateway from the MANET to the Internet is about the same
whether the routing protocol is proactive or reactive.  So, if this is a
necessary feature for AODVv2, then presumably it's also a necessary
feature for OLSRv2.

Since the specification would be similar in either case, should we
have one document to serve both cases?

While of course I agree that we should support Internet Gateways,
I am pretty sure it doesn't have to be part of the base specification,
for the abovementioned reason as well as several other reasons.
As I mentioned before to Henning:


Not all functions that are *required* for MANETs to be useful
have to be part of the reactive protocol specification.


Regards,
Charlie P.



On 12/8/2012 12:48 PM, jpmacker wrote:
I would agree these networks may be somewhat private or unique but they are often internetworked and are also often heterogeneous.  while gatewaying reactive is perhaps more difficult and there may be multiple strategies i also feel something should be in the base specification




-- 
Regards,
Charlie P.
--Apple-Mail-8BEC59BE-CE72-48CC-B256-1A2FBDB5F31C-- From abdussalambaryun@gmail.com Sun Dec 9 07:33:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693CF21F8A89 for ; Sun, 9 Dec 2012 07:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 n+krsGWmPscb for ; Sun, 9 Dec 2012 07:33:22 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF8DF21F8488 for ; Sun, 9 Dec 2012 07:33:22 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so1928992vcb.31 for ; Sun, 09 Dec 2012 07:33:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3hU2GZrkFiuqkRToL06aBD+R/ayUcHbY6cSkem9Olr8=; b=DINVfNeqgDqy14tg04ctmzPrleYPQ4cW51tGA7o2y4lYjIPExWwBd1q6wI5BVwVzjX B0JUyNpLdPqhF4tfBb2PZPyRX3XbDLbULKrN1tdHhfjiB+MQNm+AWct0peXkjPIUVH6n wGvTh4i7OAzyMvWpPvcGn7ptudQwiu1meI5otKkBUankQOyTZKVAD4SOomWHZCP2XzMI NriHXG8lgS+tsQ4FsWnI7xJq6Jvagw2lTjA7czV7upBBCkw+NZyLmA7jxg4cvnIeB2PE Z2nIxRpIIcN9fNKXNNYGJ3yUpp9zhyRYrqGTHLW2RyOLkHnQzSrSbacces3M3vPNWHIS 1DMg== MIME-Version: 1.0 Received: by 10.58.252.72 with SMTP id zq8mr7624422vec.20.1355067202039; Sun, 09 Dec 2012 07:33:22 -0800 (PST) Received: by 10.220.145.5 with HTTP; Sun, 9 Dec 2012 07:33:21 -0800 (PST) In-Reply-To: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> Date: Sun, 9 Dec 2012 16:33:21 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Cc: "Stan Ratliff \(sratliff\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 15:33:23 -0000 I was interested in minimum change in the draft of that issue if agreed-on/possible (and to refer to RFCs), but not to delay the draft submission (however, I am interested but no time to work this text like others). I recommend that any participant that interested in such including text/discuss regarding gateway issues in this WG draft, that participant to write down the text (i.e what he/she want written in the document) directly on the list (as please ADD the description ..), this way we can discuss better and save time of opening new issues. I don't think the editor should do all the work, or to leave issue open while brought to the table. Do you have some thing/input to include please reply quickly to complete this work/discussion? AB On 12/9/12, jpmacker wrote: > Well the 1st part of my comment was just supporting the fact that i believe > many of the networks you mentioned need border gateway solutions. It > sounded like there was disagreement on that. > > 2nd i said i believe "something" should be in the base specification i did > not say what or whether it goes as far as a design recommendation. Perhaps > at a minimum discuss known gatewaying issues/challenges. What I dont want is > the impression left that solutions are not needed because I strongly believe > they are needed. > > Lets discuss one document at a time. > > Sent from my iPad > > On Dec 8, 2012, at 4:17 PM, "Charles E. Perkins" > wrote: > >> >> Hello Joe, >> >> Having a gateway from the MANET to the Internet is about the same >> whether the routing protocol is proactive or reactive. So, if this is a >> necessary feature for AODVv2, then presumably it's also a necessary >> feature for OLSRv2. >> >> Since the specification would be similar in either case, should we >> have one document to serve both cases? >> >> While of course I agree that we should support Internet Gateways, >> I am pretty sure it doesn't have to be part of the base specification, >> for the abovementioned reason as well as several other reasons. >> As I mentioned before to Henning: >> >>> >>> Not all functions that are *required* for MANETs to be useful >>> have to be part of the reactive protocol specification. >> >> >> Regards, >> Charlie P. >> >> >> >> On 12/8/2012 12:48 PM, jpmacker wrote: >>> I would agree these networks may be somewhat private or unique but they >>> are often internetworked and are also often heterogeneous. while >>> gatewaying reactive is perhaps more difficult and there may be multiple >>> strategies i also feel something should be in the base specification >>> >>> >> >> -- >> Regards, >> Charlie P. > From abdussalambaryun@gmail.com Sun Dec 9 07:37:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F46D21F85C6 for ; Sun, 9 Dec 2012 07:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 6hkHoEWkNSDV for ; Sun, 9 Dec 2012 07:37:53 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C75BC21F84E2 for ; Sun, 9 Dec 2012 07:37:52 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so1930961vcb.31 for ; Sun, 09 Dec 2012 07:37:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gFHy0GoKkrCaVpEQE7kvHMYKrmAZjN0NO0smryqAJPU=; b=tYsXBOeE777s8HBFTLgc3xbTlfeg70tJ7caZ3B+N2TV01HcSnmnEeKFyVhkdypojCF jwJESbz3cTsHFBpfU/zabwscZezsC0uNHEa5erHZntUE6RvvEvOmHV7BecbCOthTDJP5 0kGAE3Qp2GkIQSyUWgHg6gzqgjReLxmE04NW+PQUvn+U1wp68JpU++h2Qx+2/z9AvqvU sbCjfw9RNj8VRW0uVvZB6kaqNTcFnenHzBukoptlySzNmyWEyn6IlxAAvEeA6LNEef/v ftCqDaXNcKIltKAETnpe5DyVsgcC8F2g9D1eeLYI8aXTnEAV3VnMr4BkZzcJgRUliRve 2acQ== MIME-Version: 1.0 Received: by 10.52.99.131 with SMTP id eq3mr6491826vdb.55.1355067472325; Sun, 09 Dec 2012 07:37:52 -0800 (PST) Received: by 10.220.145.5 with HTTP; Sun, 9 Dec 2012 07:37:52 -0800 (PST) In-Reply-To: <50C3AE5E.1000900@computer.org> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> Date: Sun, 9 Dec 2012 16:37:52 +0100 Message-ID: From: Abdussalam Baryun To: "" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Stan Ratliff \(sratliff\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 15:37:53 -0000 IMHO, I agree to have one new draft for the issue that includes both OLSRv2 and AODVv2, I think there was a work authored by Teco close to the concerns that maybe used for the new draft. AB On 12/8/12, Charles E. Perkins wrote: > > Hello Joe, > > Having a gateway from the MANET to the Internet is about the same > whether the routing protocol is proactive or reactive. So, if this is a > necessary feature for AODVv2, then presumably it's also a necessary > feature for OLSRv2. > > Since the specification would be similar in either case, should we > have one document to serve both cases? > > While of course I agree that we should support Internet Gateways, > I am pretty sure it doesn't have to be part of the base specification, > for the abovementioned reason as well as several other reasons. > As I mentioned before to Henning: > >> >> Not all functions that are *required* for MANETs to be useful >> have to be part of the reactive protocol specification. > > > Regards, > Charlie P. > > > > On 12/8/2012 12:48 PM, jpmacker wrote: >> I would agree these networks may be somewhat private or unique but they >> are often internetworked and are also often heterogeneous. while >> gatewaying reactive is perhaps more difficult and there may be multiple >> strategies i also feel something should be in the base specification >> >> > > -- > Regards, > Charlie P. > > From charliep@computer.org Sun Dec 9 07:55:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D9921F8C3F for ; Sun, 9 Dec 2012 07:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 zItOSNXuAsRx for ; Sun, 9 Dec 2012 07:55:25 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id C2F4B21F8C3C for ; Sun, 9 Dec 2012 07:55:25 -0800 (PST) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1ThjDw-0006XZ-FC; Sun, 09 Dec 2012 10:55:24 -0500 Message-ID: <50C4B46A.9020905@computer.org> Date: Sun, 09 Dec 2012 07:55:22 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: jpmacker References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040306030807020602090507" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86c07a7ce4871e79dc343583fca6ff5f3d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 15:55:26 -0000 This is a multi-part message in MIME format. --------------040306030807020602090507 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello Joe, O.K. I will craft some language for that. The reactive draft has for a long time had a section discussion some minimal Gateway aspects. I can strengthen some of the language to respond to your concerns. One concern in particular is that the Gateway MUST NOT inject ad hoc routes into the Internet. Regards, Charlie P. On 12/8/2012 9:09 PM, jpmacker wrote: > Well the 1st part of my comment was just supporting the fact that i > believe many of the networks you mentioned need border gateway > solutions. It sounded like there was disagreement on that. > > 2nd i said i believe "something" should be in the base specification i > did not say what or whether it goes as far as a design recommendation. > Perhaps at a minimum discuss known gatewaying issues/challenges. What > I dont want is the impression left that solutions are not needed > because I strongly believe they are needed. > > Lets discuss one document at a time. > > Sent from my iPad > > On Dec 8, 2012, at 4:17 PM, "Charles E. Perkins" > > wrote: > >> >> Hello Joe, >> >> Having a gateway from the MANET to the Internet is about the same >> whether the routing protocol is proactive or reactive. So, if this is a >> necessary feature for AODVv2, then presumably it's also a necessary >> feature for OLSRv2. >> >> Since the specification would be similar in either case, should we >> have one document to serve both cases? >> >> While of course I agree that we should support Internet Gateways, >> I am pretty sure it doesn't have to be part of the base specification, >> for the abovementioned reason as well as several other reasons. >> As I mentioned before to Henning: >> >>> >>> Not all functions that are *required* for MANETs to be useful >>> have to be part of the reactive protocol specification. >> >> >> Regards, >> Charlie P. >> >> >> >> On 12/8/2012 12:48 PM, jpmacker wrote: >>> I would agree these networks may be somewhat private or unique but they are often internetworked and are also often heterogeneous. while gatewaying reactive is perhaps more difficult and there may be multiple strategies i also feel something should be in the base specification >>> >>> >> >> -- >> Regards, >> Charlie P. -- Regards, Charlie P. --------------040306030807020602090507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hello Joe,

O.K.  I will craft some language for that.  The reactive draft has for a long
time had a section discussion some minimal Gateway aspects.  I can
strengthen some of the language to respond to your concerns.

One concern in particular is that the Gateway MUST NOT inject ad hoc
routes into the Internet.

Regards,
Charlie P.


On 12/8/2012 9:09 PM, jpmacker wrote:
Well the 1st part of my comment was just supporting the fact that i believe many of the networks you mentioned need border gateway solutions.  It sounded like there was disagreement on that.

2nd i said i believe "something" should be in the base specification i did not say what or whether it goes as far as a design recommendation.  Perhaps at a minimum discuss known gatewaying issues/challenges. What I dont want is the impression left that solutions are not needed because I strongly believe they are needed.

Lets discuss one document at a time.

Sent from my iPad

On Dec 8, 2012, at 4:17 PM, "Charles E. Perkins" <charliep@computer.org> wrote:


Hello Joe,

Having a gateway from the MANET to the Internet is about the same
whether the routing protocol is proactive or reactive.  So, if this is a
necessary feature for AODVv2, then presumably it's also a necessary
feature for OLSRv2.

Since the specification would be similar in either case, should we
have one document to serve both cases?

While of course I agree that we should support Internet Gateways,
I am pretty sure it doesn't have to be part of the base specification,
for the abovementioned reason as well as several other reasons.
As I mentioned before to Henning:


Not all functions that are *required* for MANETs to be useful
have to be part of the reactive protocol specification.


Regards,
Charlie P.



On 12/8/2012 12:48 PM, jpmacker wrote:
I would agree these networks may be somewhat private or unique but they are often internetworked and are also often heterogeneous.  while gatewaying reactive is perhaps more difficult and there may be multiple strategies i also feel something should be in the base specification




-- 
Regards,
Charlie P.


-- 
Regards,
Charlie P.
--------------040306030807020602090507-- From abdussalambaryun@gmail.com Sun Dec 9 08:04:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27DB21F85C6 for ; Sun, 9 Dec 2012 08:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 PsepgbxaqTyH for ; Sun, 9 Dec 2012 08:04:23 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D698021F849A for ; Sun, 9 Dec 2012 08:04:22 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so1942266vbb.31 for ; Sun, 09 Dec 2012 08:04:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jf1RjkOR+KWe1FtE42azlxkwyMslMuA5A696dE/rflg=; b=wkU8jrqZokA6oAHOzXcrN+ykzLOAd5/tPbZKrDB3diZdPlk8ZBZzBqhQN6Px5YOVkZ BG/Ty3DN6eqdVU4TZKH7tvklfSX7zjy3CSISe365oFMMQl4bBTzqpdKtd5vDdaeaAAvz V9VcVSprb5RblQiIQDU/7rWziH/7Cbm0ZAdUmapAtghZhJPq65wKxb8NXCXoHRLzHMtF DcwPtmi0NeG7XW5V18ViL5xIgPoWBYrEteB/FFdW8U428WeRWQxk8QaetIb1D5z50tOl kWk6BZ84xu+LB851uhZtc/jPsndt/9ZoYOLMbKd1bhj0rSFXgcfcIE6dkzqIpIG1MFtD aTQw== MIME-Version: 1.0 Received: by 10.220.149.69 with SMTP id s5mr7397151vcv.23.1355069062191; Sun, 09 Dec 2012 08:04:22 -0800 (PST) Received: by 10.220.145.5 with HTTP; Sun, 9 Dec 2012 08:04:22 -0800 (PST) In-Reply-To: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <90BDEF4B-4233-452B-948A-733FCA50B6E9@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF168B3@xmb-aln-x03.cisco.com> Date: Sun, 9 Dec 2012 17:04:22 +0100 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , Stan Ratliff Subject: Re: [manet] AODV/DYMO Gateway (was: Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 16:04:23 -0000 Hi Teco, I reading the protocol you worked on which was renew [1][2], do you think the BRDP protocol will be recommended for this MANET gateway issue? [1] http://www.ietf.org/mail-archive/web/homenet/current/msg01772.html [2] http://tools.ietf.org/id/draft-boot-brdp-framework-00.txt AB On 12/8/12, Teco Boot wrote: > > Op 7 dec. 2012, om 19:52 heeft Stan Ratliff (sratliff) het volgende > geschreven: > >> Teco, >> >> On Dec 7, 2012, at 1:23 PM, Teco Boot wrote: >> >>> I'm not a fan of a routing protocol that does not support multiple >>> borders. Still, I am interested in reactive protocols. >>> >>> Simple Internet attachment works as described in the draft. Border >>> replies for all destinations outside the network. Network has only >>> single prefix. >>> >> >> So, are you saying that a reactive protocol that has no defined method of >> ingress or egress to/from the MANET is a worthwhile pursuit? > I didn't say that. > >> If so, I disagree. I think that ingress/egress MUST be well-understood; it >> SHOULD be a part of the document. > Well, it has to be specified somewhere. BGP isn't part of OSPF. > > dymo-24 has the "Simple Internet Attachment", it permits only a single > gateway. For many use cases, this would be fine. > > I said I'm interested in the multi-homed use cases. dymo-24 doesn't support > it right now. > > Teco > >> >> Regards, >> Stan >> >> >> [snip] >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From teco@inf-net.nl Sun Dec 9 08:27:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA0F21F8BE2 for ; Sun, 9 Dec 2012 08:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 x6bc6ZqVeHIJ for ; Sun, 9 Dec 2012 08:27:48 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 224A921F8959 for ; Sun, 9 Dec 2012 08:27:47 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1226783eek.31 for ; Sun, 09 Dec 2012 08:27:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=FjRdSdPoxzdBO4Yvt6ijPO328i2GKL1DLjLBoUxYD3Y=; b=BZpSzRkxLRox6MI+9E3JN/uMcZbvHdu/owFwe+Po58T2VYgGav8CSemh5mt9D0DoT8 uqVGXPfDrM9MpsISoGDOwrMvRumS5449mMHyI85LnFB09oBebstTxxkFMWeRu1YzNyKI 007/YuOhQ2HzRfNYmRwk/FIb4MMKAXeS60JlOz7/M6lKEPwcLswfgmUXCVdcARoq2eon W7UU/LTH4mID4mpTOWF02P7gqzJjHQPKijrVPdDtigZlXTzgTRZ8hP2Ttd31QDfFtEzq xIVljAaGtbziavxmie9Uy5jlILcWQm33TWcNoMghE4rP9CT9K+kNxoZ8wI+JlmLdaWM4 4ogw== Received: by 10.14.205.198 with SMTP id j46mr39990270eeo.27.1355070466624; Sun, 09 Dec 2012 08:27:46 -0800 (PST) Received: from ?IPv6:2001:470:7a9b:1:759f:d9eb:733c:b32d? ([2001:470:7a9b:1:759f:d9eb:733c:b32d]) by mx.google.com with ESMTPS id b2sm37624389eep.9.2012.12.09.08.27.44 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 09 Dec 2012 08:27:45 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Sun, 9 Dec 2012 17:27:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6FB30031-8F81-48BF-88C8-93131E4FD441@inf-net.nl> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <90BDEF4B-4233-452B-948A-733FCA50B6E9@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF168B3@xmb-aln-x03.cisco.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmrIV3qw63VF8/hs3SYs/KPteiETj9Jasr4C32iotdtRSwANHCF8aolz0IQpPKepubw9Rxh Cc: "" , Stan Ratliff Subject: Re: [manet] AODV/DYMO Gateway (was: Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 16:27:49 -0000 BRDP would fit both proactive and reactive MANETs, although it is = proactive itself. It applies to Homenet also (see boot-homenet-brdp).=20 Teco =20 Op 9 dec. 2012, om 17:04 heeft Abdussalam Baryun het volgende = geschreven: > Hi Teco, >=20 > I reading the protocol you worked on which was renew [1][2], do you > think the BRDP protocol will be recommended for this MANET gateway > issue? >=20 > [1] http://www.ietf.org/mail-archive/web/homenet/current/msg01772.html > [2] http://tools.ietf.org/id/draft-boot-brdp-framework-00.txt >=20 > AB >=20 > On 12/8/12, Teco Boot wrote: >>=20 >> Op 7 dec. 2012, om 19:52 heeft Stan Ratliff (sratliff) het volgende >> geschreven: >>=20 >>> Teco, >>>=20 >>> On Dec 7, 2012, at 1:23 PM, Teco Boot wrote: >>>=20 >>>> I'm not a fan of a routing protocol that does not support multiple >>>> borders. Still, I am interested in reactive protocols. >>>>=20 >>>> Simple Internet attachment works as described in the draft. Border >>>> replies for all destinations outside the network. Network has only >>>> single prefix. >>>>=20 >>>=20 >>> So, are you saying that a reactive protocol that has no defined = method of >>> ingress or egress to/from the MANET is a worthwhile pursuit? >> I didn't say that. >>=20 >>> If so, I disagree. I think that ingress/egress MUST be = well-understood; it >>> SHOULD be a part of the document. >> Well, it has to be specified somewhere. BGP isn't part of OSPF. >>=20 >> dymo-24 has the "Simple Internet Attachment", it permits only a = single >> gateway. For many use cases, this would be fine. >>=20 >> I said I'm interested in the multi-homed use cases. dymo-24 doesn't = support >> it right now. >>=20 >> Teco >>=20 >>>=20 >>> Regards, >>> Stan >>>=20 >>>=20 >>> [snip] >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 From abdussalambaryun@gmail.com Mon Dec 10 02:51:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3EE21F8E7A for ; Mon, 10 Dec 2012 02:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 HbdycU4sryOP for ; Mon, 10 Dec 2012 02:51:25 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB1F21F8E79 for ; Mon, 10 Dec 2012 02:51:25 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so2551242vcb.31 for ; Mon, 10 Dec 2012 02:51:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g3bXfJ3BmR4xINh9YqNrZu2MipKptpUW/SBtDaNuqM8=; b=thwxD212GplZmatjeEESipMvOwNOa7pbed9xAMYlyv/UZRM5KeOQHqE59M5MWjVrXP 6FCStUwNmak54LYlvw/eUQ02r3kAiRR5P+Yj0ACamtjNW8PAIj06mdCKsPqiC24gwVqM M+ZihHn2c6ANUuIt/+jXDtmws1oYh70Y7I/WZ/VMReOfQBtbtN5nJrQ1wdDtWf8BJIOs IbGAIHwwOu6BCEJuzI20tAVZzQq3Dyvift/IcXl97yLZcYWo2V2yZlbG6zgSq4ZF7AsM qqRiWbuAB/ozY5JQ6JqOClCLvsMWswlis+MVbJCnX3WSZMp1oFeaVde91SwbhV0xI8uS Uf9w== MIME-Version: 1.0 Received: by 10.52.99.131 with SMTP id eq3mr7641002vdb.55.1355136684770; Mon, 10 Dec 2012 02:51:24 -0800 (PST) Received: by 10.220.145.5 with HTTP; Mon, 10 Dec 2012 02:51:24 -0800 (PST) Date: Mon, 10 Dec 2012 11:51:24 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 10:51:26 -0000 On 12/7/12, Stan Ratliff (sratliff) wrote: > > My feeling, FWIW, is that ingress/egress SHOULD be a part of the base > document. However, I understand the concerns of people that say it might = be > a problem (or extend ratification time, etc etc). So, I'm interested in > hearing other, interested opinions - both for > DYMO/AODVv2/Whatever-we're-calling-it-this-week, as well as with regard t= o > the LOADng spec. I know from my efforts that LOADng team are not welling to discuss, or reply to questions/comments, so I want to know your opinion of the status on this LOADng draft as you brought it to the list; Is it a WG draft? should we discuss individual or private work now? I remember that we answered chair questions and options given. Not sure what the chair of WG wants us to do so far, please advise, AB > > And lastly=85.. if the 5 guys were *that* important, they most likely wou= ldn't > be *playing* black-ops=85 ;-) > > Stan > > From sratliff@cisco.com Mon Dec 10 06:58:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3D521F8503 for ; Mon, 10 Dec 2012 06:58:10 -0800 (PST) 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 HpET-ySCbyYI for ; Mon, 10 Dec 2012 06:58:10 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E080A21F84FD for ; Mon, 10 Dec 2012 06:58:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3338; q=dns/txt; s=iport; t=1355151490; x=1356361090; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=B7l67gXA7UuFrkcDCC+Qht83Qa4C91HEqOG3OunLuVc=; b=Qhl4XbJuyJSTGeORmZnDBm2dyBRZwpkkywWLG+D1Qm9mGjMulOCK6m2C MwydOGujipEeNKUIE/xOjZEEmVHY3S6qwG3WRGXyZbj2QvdOFyQo6qGF7 GXdSlugy7OVJipK3y/c5To6iQxVIysCFNJoO2jO+Z7zHq9qSnNmRu6yaP I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAED3xVCtJV2b/2dsb2JhbABFvnIWc4IeAQEBAwEBAQFrCwULAgEIGAokJwslAgQOBQiIAwYMtToEjD8cg0ZhA6ZOgnOCIg X-IronPort-AV: E=McAfee;i="5400,1158,6921"; a="151272050" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 10 Dec 2012 14:58:09 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBAEw9mK015153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Dec 2012 14:58:09 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.203]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 10 Dec 2012 08:58:09 -0600 From: "Stan Ratliff (sratliff)" To: Abdussalam Baryun Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN1sRQC9RIBD6Ww0Sj7f1Ne2/6upgShJYA Date: Mon, 10 Dec 2012 14:58:09 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.42.28] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 14:58:11 -0000 Abdussalam,=20 On Dec 10, 2012, at 5:51 AM, Abdussalam Baryun wrote: > On 12/7/12, Stan Ratliff (sratliff) wrote: >>=20 >> My feeling, FWIW, is that ingress/egress SHOULD be a part of the base >> document. However, I understand the concerns of people that say it might= be >> a problem (or extend ratification time, etc etc). So, I'm interested in >> hearing other, interested opinions - both for >> DYMO/AODVv2/Whatever-we're-calling-it-this-week, as well as with regard = to >> the LOADng spec. >=20 > I know from my efforts that LOADng team are not welling to discuss, or > reply to questions/comments, so I want to know your opinion of the > status on this LOADng draft as you brought it to the list; Is it a WG > draft? should we discuss individual or private work now? >=20 > I remember that we answered chair questions and options given. Not > sure what the chair of WG wants us to do so far, please advise, It wasn't clear to me what the consensus was in Atlanta vis-a-vis the two r= eactive protocol documents. Presently, DYMO is the working group accepted r= eactive protocol document. However, there was a 2-year period of time when = DYMO was inactive, and the document was "parked". As a result of that, the = effort to create LOADng sprang up.=20 So now, we have two documents to consider. In the charter, the WG is "on th= e hook" for 1 (and only 1) reactive protocol. So the current options are:=20 1. Recognize that we cannot reach consensus with the two documents, and rem= ove the charter item for reactive protocols. To be frank, this is my prefer= red option.=20 2. Accept one of the two documents (either LOADng or DYMO), and press forwa= rd 3. Perhaps alter the charter item, and produce 2 reactive protocols, both i= n "experimental" state.=20 Now, you mentioned "Not sure what the chairs of WG want us to do so far"=85= . the best answer I can give you on that is "reach consensus on an approach= ". We as a working group haven't done that yet. There are people advocatin= g for DYMO, others advocating for LOADng, and some that want to "merge" the= technology of the two together. A "merge" was something we tried in the Va= ncouver timeframe, but that effort failed.=20 As to your statement that the LOADng team is not willing to discuss - I hav= en't seen that, do not agree with it, and would ask you to cite *specific* = examples if you have them. I've found the LOADng team to be reasonable in t= heir dealings with the WG. There is the issue of re-spinning the LOADng doc= ument without the copyright statement - The LOADng authors and the chairs h= ave reached an understanding about that issue, so I no longer have a proble= m with moving forward on that front.=20 Again, as a working group - we *MUST* either reach a consensus, or the work= item will be removed *for us*. If we do not show progress towards a goal, = it is within the power of the IESG to stop work on the issue. Regards, Stan >=20 > AB >=20 >>=20 >> And lastly=85.. if the 5 guys were *that* important, they most likely wo= uldn't >> be *playing* black-ops=85 ;-) >>=20 >> Stan >>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From d.sturek@att.net Mon Dec 10 07:27:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E022121F84FA for ; Mon, 10 Dec 2012 07:27:33 -0800 (PST) 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 XoGp+nxO0ylQ for ; Mon, 10 Dec 2012 07:27:33 -0800 (PST) Received: from nm28.access.bullet.mail.mud.yahoo.com (nm28.access.bullet.mail.mud.yahoo.com [66.94.237.93]) by ietfa.amsl.com (Postfix) with ESMTP id D4BCB21F8471 for ; Mon, 10 Dec 2012 07:27:32 -0800 (PST) Received: from [66.94.237.127] by nm28.access.bullet.mail.mud.yahoo.com with NNFMP; 10 Dec 2012 15:27:32 -0000 Received: from [68.142.198.107] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 10 Dec 2012 15:27:32 -0000 Received: from [127.0.0.1] by smtp112.sbc.mail.mud.yahoo.com with NNFMP; 10 Dec 2012 15:27:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1355153252; bh=UyGlmSZORKl7leyj8v0CNam3OOm+D55icXMr61zegvo=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=5YNzPdFy/rldMUBYI9KwnC2KOvmnKb9SJI4nDzAg6aPV8Bc1IozrmKRp94Whb16HMV3j5lYxg0aiZTQD6Kvz7Am4AQyrs/HnJH4IfGtDlMY9Z3h6mq3mP5ph+cxM9NNkM9VMC6g5dn03GWecRAQb7ZFY9oyhOzPrUEocaLGrQxM= X-Yahoo-Newman-Id: 391063.44638.bm@smtp112.sbc.mail.mud.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: xoXBJnkVM1kZtvRdlpYpZ9LUding20t1iI03QIOuGH_cjqk CgPu.7DIqT4Ne.v9UOLJlP5k4wLeWf3a9fCZDD5NoQvV76RQJC51Vx4DkLoz YVq9Jbs0._9Q.TQYKcAsMZNm7F3D.nwCatNEbywjlsyRxTsZ9wsHTUBGSxxu 34NmDAoZMefTr8OCUACFC64.mW2NZXmcf2enOaSbzbtxKUl0zQ7nGbC.BbYI oduODpO7tL2VeHbJ.nxVqvHlw6FdpcWMa7lo9gKR6fPbrvx5ATR6v55H4keE cA3RXNm8cj39OIijmaxbmc_OX2SSJ1C5OJaOiGcHkh3ncTVRa7utPBgCO13R r0rgdekzlrZfzrR6.alA27X5YfVAazbxF2fBunokPBXPEExWtJEtQYJxGWMW 7QM3MkKynh5R5Dmcg79epnri7b84Zuyn_swdJz2SiIyI78zkSdbO01U6OvWW syZNg6wnUuUG6Hsl5 X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.198] (d.sturek@69.108.50.86 with login) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 10 Dec 2012 07:27:32 -0800 PST User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 10 Dec 2012 07:26:14 -0800 From: Don Sturek To: "Stan Ratliff (sratliff)" , Abdussalam Baryun Message-ID: Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: "" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 15:27:34 -0000 +1, agree with Stan that what is captured below is the current predicament in MANET with regard to DYMO and LOADng..... Stan: What do you think the timeframe should be for choosing one of the 3 paths you enumerated below? Don On 12/10/12 6:58 AM, "Stan Ratliff (sratliff)" wrote: >Abdussalam,=20 > >On Dec 10, 2012, at 5:51 AM, Abdussalam Baryun wrote: > >> On 12/7/12, Stan Ratliff (sratliff) wrote: >>>=20 >>> My feeling, FWIW, is that ingress/egress SHOULD be a part of the base >>> document. However, I understand the concerns of people that say it >>>might be >>> a problem (or extend ratification time, etc etc). So, I'm interested in >>> hearing other, interested opinions - both for >>> DYMO/AODVv2/Whatever-we're-calling-it-this-week, as well as with >>>regard to >>> the LOADng spec. >>=20 >> I know from my efforts that LOADng team are not welling to discuss, or >> reply to questions/comments, so I want to know your opinion of the >> status on this LOADng draft as you brought it to the list; Is it a WG >> draft? should we discuss individual or private work now? >>=20 >> I remember that we answered chair questions and options given. Not >> sure what the chair of WG wants us to do so far, please advise, > >It wasn't clear to me what the consensus was in Atlanta vis-a-vis the two >reactive protocol documents. Presently, DYMO is the working group >accepted reactive protocol document. However, there was a 2-year period >of time when DYMO was inactive, and the document was "parked". As a >result of that, the effort to create LOADng sprang up. > >So now, we have two documents to consider. In the charter, the WG is "on >the hook" for 1 (and only 1) reactive protocol. So the current options >are:=20 >1. Recognize that we cannot reach consensus with the two documents, and >remove the charter item for reactive protocols. To be frank, this is my >preferred option.=20 >2. Accept one of the two documents (either LOADng or DYMO), and press >forward >3. Perhaps alter the charter item, and produce 2 reactive protocols, both >in "experimental" state. > >Now, you mentioned "Not sure what the chairs of WG want us to do so >far"=8A. the best answer I can give you on that is "reach consensus on an >approach". We as a working group haven't done that yet. There are people >advocating for DYMO, others advocating for LOADng, and some that want to >"merge" the technology of the two together. A "merge" was something we >tried in the Vancouver timeframe, but that effort failed. > >As to your statement that the LOADng team is not willing to discuss - I >haven't seen that, do not agree with it, and would ask you to cite >*specific* examples if you have them. I've found the LOADng team to be >reasonable in their dealings with the WG. There is the issue of >re-spinning the LOADng document without the copyright statement - The >LOADng authors and the chairs have reached an understanding about that >issue, so I no longer have a problem with moving forward on that front. > >Again, as a working group - we *MUST* either reach a consensus, or the >work item will be removed *for us*. If we do not show progress towards a >goal, it is within the power of the IESG to stop work on the issue. > >Regards, >Stan > > >>=20 >> AB >>=20 >>>=20 >>> And lastly=8A.. if the 5 guys were *that* important, they most likely >>>wouldn't >>> be *playing* black-ops=8A ;-) >>>=20 >>> Stan >>>=20 >>>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Mon Dec 10 07:41:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A31E21F8536 for ; Mon, 10 Dec 2012 07:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 m6DC9+h1q4Ir for ; Mon, 10 Dec 2012 07:41:07 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E526521F8534 for ; Mon, 10 Dec 2012 07:41:06 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1806691eek.31 for ; Mon, 10 Dec 2012 07:41:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=6RkvtUbeCZ3sbtIKwAR5k72yXL8O/VGW4lwJU/v/B/Q=; b=MYpVxy+ivI1X/6cqSoseQyc1dOr5AolTc6ON43R95TyeNUekJl6/OflFbTntbRgWTp xE0+cR23GUphhyyvYXjRJnOwsPsKuNuwGWTaKZkuAJGcQif3ASHBgSZypwSD/41+GqN2 3eolI56dqDlQryuL234FmDv6UQA0OGwTbKXLow3gyYUxAulSSsqoiTjThH+u8iUDJDsj BZGIKWkgFH7GPWNZULCukBZuX5ucfszwW2bQs4psELmP6m3PfunGWXbNX5GpCI9S1Reb Mig76iPBA/sQx6l8h0ih0w3caudQl6ph9+uI4cfC8xZiYcgjcBwGbazQzoNzSxjDQksK h1bg== Received: by 10.14.203.2 with SMTP id e2mr50060393eeo.20.1355154066039; Mon, 10 Dec 2012 07:41:06 -0800 (PST) Received: from [10.87.130.108] ([80.187.201.44]) by mx.google.com with ESMTPS id e2sm44199494eeo.8.2012.12.10.07.41.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Dec 2012 07:41:05 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> Date: Mon, 10 Dec 2012 16:40:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <208C25C3-CC27-4138-B83D-92BF1397F68B@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkSgzRlm/Nie1krGlK7ksWx+9id+1yIvNH0JYJ533zfXJ00ppRdyIjg/Re3Y1zvq0mX7jSC Cc: "" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 15:41:07 -0000 Op 10 dec. 2012, om 15:58 heeft Stan Ratliff (sratliff) het volgende = geschreven: > There is the issue of re-spinning the LOADng document without the = copyright statement - The LOADng authors and the chairs have reached an = understanding about that issue, so I no longer have a problem with = moving forward on that front. Can something be exposed to us? Teco From adrian@olddog.co.uk Mon Dec 10 08:59:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBA321F8529 for ; Mon, 10 Dec 2012 08:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 CnHpSR3eXT-l for ; Mon, 10 Dec 2012 08:59:43 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 87F3D21F8528 for ; Mon, 10 Dec 2012 08:59:43 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBAGxg03007110 for ; Mon, 10 Dec 2012 16:59:42 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBAGxf3e007096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 10 Dec 2012 16:59:41 GMT From: "Adrian Farrel" To: References: <20121208001858.17950.48812.idtracker@ietfa.amsl.com> In-Reply-To: <20121208001858.17950.48812.idtracker@ietfa.amsl.com> Date: Mon, 10 Dec 2012 16:59:41 -0000 Message-ID: <054201cdd6f7$bf2f32a0$3d8d97e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJSq2el8n1RMmgwS/LZn7Y3ag6F3JcIlzZQ Content-Language: en-gb Subject: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 16:59:44 -0000 FYI Discussion on the OSPF list. Adrian > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: 08 December 2012 00:19 > To: i-d-announce@ietf.org > Cc: ospf@ietf.org > Subject: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Open Shortest Path First IGP Working Group of > the IETF. > > Title : Use of OSPF-MDR in Single-Hop Broadcast Networks > Author(s) : Richard G. Ogier > Filename : draft-ietf-ospf-manet-single-hop-mdr-01.txt > Pages : 6 > Date : 2012-12-07 > > Abstract: > RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks > (MANETs) by specifying its operation on the new OSPF interface of type > MANET. This document describes the use of OSPF-MDR in a single-hop > broadcast network, which is a special case of a MANET in which each > router is a (one-hop) neighbor of each other router. Unlike an OSPF > broadcast interface, such an interface can have a different cost > associated with each neighbor. The document includes configuration > recommendations and simplified mechanisms that can be used in single-hop > broadcast networks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ospf-manet-single-hop-mdr-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-manet-single-hop-mdr-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Chris.Dearlove@baesystems.com Mon Dec 10 09:43:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1302821F84ED for ; Mon, 10 Dec 2012 09:43:17 -0800 (PST) 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 nH7DUzeWpdIo for ; Mon, 10 Dec 2012 09:43:16 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id D3D2521F84DE for ; Mon, 10 Dec 2012 09:43:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,252,1355097600"; d="scan'208";a="293006563" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 10 Dec 2012 17:43:14 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qBAHhEnw019895 for ; Mon, 10 Dec 2012 17:43:14 GMT X-IronPort-AV: E=Sophos;i="4.84,252,1355097600"; d="scan'208";a="961743" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 10 Dec 2012 17:43:13 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0309.002; Mon, 10 Dec 2012 17:43:13 +0000 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , "" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-24.txt Thread-Index: AQHNz3PdizJJy8YTn0ujf7TOKm3zcZgHFHyAgAOwKwCAALZvgIAAtL6AgAAzyoCAARwuAIAAP7gAgAAUo4CAAZfTgIAAB+wAgAEzfwCAAbUb0A== Date: Mon, 10 Dec 2012 17:43:13 +0000 Message-ID: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Stan Ratliff \(sratliff\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 17:43:17 -0000 You seem to fail to have noticed that OLSRv2 already includes support for m= ultiple gateways. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= bdussalam Baryun Sent: 09 December 2012 15:38 To: Cc: Stan Ratliff (sratliff) Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- IMHO, I agree to have one new draft for the issue that includes both OLSRv2 and AODVv2, I think there was a work authored by Teco close to the concerns that maybe used for the new draft. AB On 12/8/12, Charles E. Perkins wrote: > > Hello Joe, > > Having a gateway from the MANET to the Internet is about the same > whether the routing protocol is proactive or reactive. So, if this is a > necessary feature for AODVv2, then presumably it's also a necessary > feature for OLSRv2. > > Since the specification would be similar in either case, should we > have one document to serve both cases? > > While of course I agree that we should support Internet Gateways, > I am pretty sure it doesn't have to be part of the base specification, > for the abovementioned reason as well as several other reasons. > As I mentioned before to Henning: > >> >> Not all functions that are *required* for MANETs to be useful >> have to be part of the reactive protocol specification. > > > Regards, > Charlie P. > > > > On 12/8/2012 12:48 PM, jpmacker wrote: >> I would agree these networks may be somewhat private or unique but they >> are often internetworked and are also often heterogeneous. while >> gatewaying reactive is perhaps more difficult and there may be multiple >> strategies i also feel something should be in the base specification >> >> > > -- > Regards, > Charlie P. > > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Mon Dec 10 09:46:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E469521F8527 for ; Mon, 10 Dec 2012 09:46:26 -0800 (PST) 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 VqvvjshIgHO3 for ; Mon, 10 Dec 2012 09:46:26 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 3582D21F84F3 for ; Mon, 10 Dec 2012 09:46:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,252,1355097600"; d="scan'208";a="293007333" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 10 Dec 2012 17:46:25 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qBAHkPDH008737 for ; Mon, 10 Dec 2012 17:46:25 GMT X-IronPort-AV: E=Sophos;i="4.84,252,1355097600"; d="scan'208";a="961992" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 10 Dec 2012 17:46:25 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Mon, 10 Dec 2012 17:46:24 +0000 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , Henning Rogge Thread-Topic: [manet] Announcing prefixes... {was, Re: I-D Action: draft-ietf-manet-dymo-24.txt} Thread-Index: AQHN1LZ/z5D/Fap6bkiF0TcmgbgfYpgSUtSA Date: Mon, 10 Dec 2012 17:46:24 +0000 Message-ID: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C24C6E.30101@computer.org> In-Reply-To: <50C24C6E.30101@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Announcing prefixes... {was, Re: I-D Action: draft-ietf-manet-dymo-24.txt} X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 17:46:27 -0000 Charles E. Perkins > This feature also suggests that two different AODVv2 routers > in an RFC 5444 address block may need to advertise network > routes with different values. You then need to specify prefixes for all addresses, but no problem. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From charliep@computer.org Mon Dec 10 09:48:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD5B21F855D for ; Mon, 10 Dec 2012 09:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 HMXIFBMpRDID for ; Mon, 10 Dec 2012 09:48:38 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id B52AD21F8528 for ; Mon, 10 Dec 2012 09:48:38 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ti7T3-0004Nc-RT; Mon, 10 Dec 2012 12:48:38 -0500 Message-ID: <50C62074.2020209@computer.org> Date: Mon, 10 Dec 2012 09:48:36 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86eba97f891fb6ff8e4e6eb996c6914c1f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 17:48:39 -0000 Hello Chris, I did in fact notice that OLSRv2 supports "Gateways". As best I could tell, they are gateways for specific subnets, not the entire Internet. In fact AODVv2 also supports this functionality. AODV supported it as well. But if OLSRv2 supports Internet Gateway attachment, and if you could direct my attention to the specific part of the document, I'd like to learn more. Regards, Charlie P. On 12/10/2012 9:43 AM, Dearlove, Christopher (UK) wrote: > You seem to fail to have noticed that OLSRv2 already includes support for multiple gateways. > -- Regards, Charlie P. From Chris.Dearlove@baesystems.com Mon Dec 10 09:59:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CE721F855C for ; Mon, 10 Dec 2012 09:59:00 -0800 (PST) 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 7D1IJBgqTfjZ for ; Mon, 10 Dec 2012 09:58:59 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 7C21721F8504 for ; Mon, 10 Dec 2012 09:58:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,252,1355097600"; d="scan'208";a="248655456" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 10 Dec 2012 17:58:58 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qBAHwvou010779 for ; Mon, 10 Dec 2012 17:58:57 GMT X-IronPort-AV: E=Sophos;i="4.84,252,1355097600"; d="scan'208";a="746945" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 10 Dec 2012 17:58:57 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Mon, 10 Dec 2012 17:58:57 +0000 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , jpmacker Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-24.txt Thread-Index: AQHNz3PdizJJy8YTn0ujf7TOKm3zcZgHFHyAgAOwKwCAALZvgIAAtL6AgAAzyoCAARwuAIAAP7gAgAAUo4CAAZfTgIAAB+wAgALp+RA= Date: Mon, 10 Dec 2012 17:58:57 +0000 Message-ID: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> In-Reply-To: <50C3AE5E.1000900@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 17:59:00 -0000 Charles E. Perkins > Having a gateway from the MANET to the Internet is about the same > whether the routing protocol is proactive or reactive.=C2=A0 So, if this = is a > necessary feature for AODVv2, then presumably it's also a necessary > feature for OLSRv2. And present, with the option for multiple gateways. > Since the specification would be similar in either case, should we > have one document to serve both cases? No, because (a) it's already in OLSRv2, and (b) there are differences. What does a gateway with a connection to the Internet do when it gets an RREQ for a.b.c.d, what address is in its RREP? Ditto if its entry is a.0.0.0/8. Ditto if it has both. (OLSRv2 puts whichever of these - which may be both - it supports and wishes to advertise in its TC messages, that's it.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From hrogge@googlemail.com Mon Dec 10 10:03:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B9D21F8563 for ; Mon, 10 Dec 2012 10:03:34 -0800 (PST) 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 iDuqWs-5-E5t for ; Mon, 10 Dec 2012 10:03:33 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id B091521F8562 for ; Mon, 10 Dec 2012 10:03:33 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so2127348pad.31 for ; Mon, 10 Dec 2012 10:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cJGbK6vLoMeEbqq45zSoXT7Old3Pxikoo6/be/citwQ=; b=KMaNxuMJ890bhSnkNAIFRJuX3WRMuElb7s+PdxY5hhvF+sutyCjAns4S6t/R+NS8jC cHineZC5JVJl9I13bmppKc8C9OK5mPIpiKylOXWGtbfrjhDCRt5Y6Lb7SSAyBF6RclcT B+cZtMZHCp8ZPkDPKSSUr2tANOdVSyBZ7+GGQjZTBOw1+hM+NFNxIO5BxCoAzifeCu5L bFmIykCV6648OaTxz7T+D3vyC3pNnh/+bp0oVc0T/migg3IPImQB/ouXyy2Gpcdy/bEk kv074BZ31vMvI0dwmv7hkDtcCHRo+5wT0OBgBGXiAOK/jpUoDzmvCBGCrs2zdxdynUyV KEnw== Received: by 10.68.143.106 with SMTP id sd10mr40968872pbb.62.1355162613417; Mon, 10 Dec 2012 10:03:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.88.132 with HTTP; Mon, 10 Dec 2012 10:03:13 -0800 (PST) In-Reply-To: <50C62074.2020209@computer.org> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> From: Henning Rogge Date: Mon, 10 Dec 2012 19:03:13 +0100 Message-ID: To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 18:03:34 -0000 On Mon, Dec 10, 2012 at 6:48 PM, Charles E. Perkins wrote: > > Hello Chris, > > I did in fact notice that OLSRv2 supports "Gateways". As best I could > tell, they are gateways for specific subnets, not the entire Internet. The "entire internet" is just the prefix 0.0.0.0/0. It has been this way since OLSRv1. (the entire IPv6 internet could either be ::/0 or 2000::/3, depending on if you are only interested in the global unicast or more). Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From Chris.Dearlove@baesystems.com Mon Dec 10 10:08:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5029421F855E for ; Mon, 10 Dec 2012 10:08:23 -0800 (PST) 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 5uVXV4gQx75F for ; Mon, 10 Dec 2012 10:08:22 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA1721F8576 for ; Mon, 10 Dec 2012 10:08:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,252,1355097600"; d="scan'208";a="293011485" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 10 Dec 2012 18:08:21 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qBAI8LCN027210 for ; Mon, 10 Dec 2012 18:08:21 GMT X-IronPort-AV: E=Sophos;i="4.84,252,1355097600"; d="scan'208";a="963477" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 10 Dec 2012 18:08:21 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Mon, 10 Dec 2012 18:08:17 +0000 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , Abdussalam Baryun Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN1sRSNLIqkYlKlkqdBTQGe5TNE5gSIACAgAAynNA= Date: Mon, 10 Dec 2012 18:08:16 +0000 Message-ID: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Cc: "" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 18:08:23 -0000 Stan Ratliff (sratliff) > It wasn't clear to me what the consensus was in Atlanta vis-a-vis the two reactive protocol documents. It was clear to me that there was no consensus. Except that abandoning the work item was not favoured. But I also don't believe that the meeting was offered any opportunity to either make that clear or show me I was wrong in that assessment. > There are people advocating for DYMO, others advocating for LOADng, and some that want to "merge" > the technology of the two together. I would like to point out that my proposal, which I believe would have been the best to adopt then, doesn't neatly fit in any of those three categories. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Mon Dec 10 10:12:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B35621F8439 for ; Mon, 10 Dec 2012 10:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 iMUtG7R6VnDk for ; Mon, 10 Dec 2012 10:12:53 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E00A521F8434 for ; Mon, 10 Dec 2012 10:12:46 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so1299236eaa.31 for ; Mon, 10 Dec 2012 10:12:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=5Y8bci9IDMqRQU+YPPyJ4q5XTHjieAhHkVkb91ZNpAc=; b=Y4Z7wljeNC9sv+yguLhxzCYqeE0oXv6HkRy/jpQZfc2QEMyBMtwpN2QzWE/JVVjfPK cl972E0PNlYgoS9MfC136g4A7ZDzPItzNACv8aoQoPXvjyCmwWjPQTR1DWYCL0ewPAOt sTIwRro8RXw5W2KcKPVtGAkrkqWLY9qXUNYxy4fcCW3JKQIQ8vWtzDXLWNSY3SUb3Ayl GlAnCwUN4Q1jfKGWmQZDdM+eFkNCtHc4/uJcLIJOMQ+s2611hFKmhccOVnXbUcIfkA5Y tgx3XT6n2PIxS2xGFa6WR9ZsH1EwKoz/81+knAeiTd7Jl3moVDDMHs4F/vnZ9IrzMmwH omDw== Received: by 10.14.175.133 with SMTP id z5mr51531345eel.15.1355163165969; Mon, 10 Dec 2012 10:12:45 -0800 (PST) Received: from ?IPv6:2001:470:7a9b:1:652d:79af:67e7:8f04? ([2001:470:7a9b:1:652d:79af:67e7:8f04]) by mx.google.com with ESMTPS id r1sm44818663eeo.2.2012.12.10.10.12.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Dec 2012 10:12:44 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <50C62074.2020209@computer.org> Date: Mon, 10 Dec 2012 19:12:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> To: "Charles E. Perkins" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmSqaveGt8JmTl3o0qDD7p3ruNfpZgxPoNGwirfQk03FdU2Tz8HuWdyFmYZBS5on26qDEBC Cc: "Dearlove, Christopher \(UK\)" , "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 18:12:53 -0000 Somewhat experimental, related to this subject: we'll release an = enhanced version of the SmartGateway extension in olsr.org. SmartGateway = provides a stable connection to the Internet, even with dynamic = topology, multiple gateways and NAT. The enhancement selects best = gateway at time of connection setup and pins the selected gateway for = duration of the lifetime of that connection. A possible next-step is providing multipath to hosts. At this moment, we = don't have plans to implement such further enhancements on SmartGateway. = Next step is IPv6 and BRDP, and move to olsrv2. Don't hold your breath. Teco Op 10 dec. 2012, om 18:48 heeft Charles E. Perkins het volgende = geschreven: >=20 > Hello Chris, >=20 > I did in fact notice that OLSRv2 supports "Gateways". As best I could > tell, they are gateways for specific subnets, not the entire Internet. >=20 > In fact AODVv2 also supports this functionality. AODV supported it > as well. >=20 > But if OLSRv2 supports Internet Gateway attachment, and if you > could direct my attention to the specific part of the document, I'd > like to learn more. >=20 > Regards, > Charlie P. >=20 > On 12/10/2012 9:43 AM, Dearlove, Christopher (UK) wrote: >> You seem to fail to have noticed that OLSRv2 already includes support = for multiple gateways. >>=20 >=20 >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Mon Dec 10 10:13:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E86521F856B for ; Mon, 10 Dec 2012 10:13:20 -0800 (PST) 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 bec950yv58jh for ; Mon, 10 Dec 2012 10:13:19 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 3A85821F8570 for ; Mon, 10 Dec 2012 10:13:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,252,1355097600"; d="scan'208";a="248658358" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 10 Dec 2012 18:13:18 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qBAIDI1I019033 for ; Mon, 10 Dec 2012 18:13:18 GMT X-IronPort-AV: E=Sophos;i="4.84,252,1355097600"; d="scan'208";a="748035" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 10 Dec 2012 18:13:18 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Mon, 10 Dec 2012 18:13:18 +0000 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-24.txt Thread-Index: AQHNz3PdizJJy8YTn0ujf7TOKm3zcZgHFHyAgAOwKwCAALZvgIAAtL6AgAAzyoCAARwuAIAAP7gAgAAUo4CAAZfTgIAAB+wAgAEzfwCAAbUb0IAAAcAAgAAGnXA= Date: Mon, 10 Dec 2012 18:13:17 +0000 Message-ID: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> In-Reply-To: <50C62074.2020209@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 18:13:20 -0000 You can indicate the entire Internet with 0.0.0.0/0, as previously describe= d (I think by Henning). Nothing special. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Charles E. Perkins [mailto:charliep@computer.org]=20 Sent: 10 December 2012 17:49 To: Dearlove, Christopher (UK) Cc: Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hello Chris, I did in fact notice that OLSRv2 supports "Gateways". As best I could tell, they are gateways for specific subnets, not the entire Internet. In fact AODVv2 also supports this functionality. AODV supported it as well. But if OLSRv2 supports Internet Gateway attachment, and if you could direct my attention to the specific part of the document, I'd like to learn more. Regards, Charlie P. On 12/10/2012 9:43 AM, Dearlove, Christopher (UK) wrote: > You seem to fail to have noticed that OLSRv2 already includes support for= multiple gateways. > --=20 Regards, Charlie P. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Mon Dec 10 10:20:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DB821F8567 for ; Mon, 10 Dec 2012 10:20:50 -0800 (PST) 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 F4wUFGYRv6C7 for ; Mon, 10 Dec 2012 10:20:49 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id D619F21F84F6 for ; Mon, 10 Dec 2012 10:20:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,252,1355097600"; d="scan'208";a="248660122" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 10 Dec 2012 18:20:48 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qBAIKlOX023120 for ; Mon, 10 Dec 2012 18:20:47 GMT X-IronPort-AV: E=Sophos;i="4.84,252,1355097600"; d="scan'208";a="748517" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 10 Dec 2012 18:20:47 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Mon, 10 Dec 2012 18:20:47 +0000 From: "Dearlove, Christopher (UK)" To: Teco Boot , "Charles E. Perkins" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-24.txt Thread-Index: AQHNz3PdizJJy8YTn0ujf7TOKm3zcZgHFHyAgAOwKwCAALZvgIAAtL6AgAAzyoCAARwuAIAAP7gAgAAUo4CAAZfTgIAAB+wAgAEzfwCAAbUb0IAAAcAAgAAGvACAAADCEA== Date: Mon, 10 Dec 2012 18:20:46 +0000 Message-ID: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> In-Reply-To: <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 18:20:50 -0000 Best gateway at time of connection is already in OLSRv2 (it's trivial in OL= SRv1, just not explicitly stated). Thinking out loud, maintaining stable selection of gateway over the course= of a connection would be a change to OLSRv2, and one that isn't backwardly= compatible. If some of your routers ran OLSRv2 unmodified, and some ran so= mething attempting a stable connection (by which I assume you mean stable s= election of gateway - that information is available) by simple routing of p= ackets then that could loop. You could tunnel to the chosen gateway, then o= nly your endpoints and gateways would need to know what to do. What else? --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T= eco Boot Sent: 10 December 2012 18:13 To: Charles E. Perkins Cc: Dearlove, Christopher (UK); Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Somewhat experimental, related to this subject: we'll release an enhanced v= ersion of the SmartGateway extension in olsr.org. SmartGateway provides a s= table connection to the Internet, even with dynamic topology, multiple gate= ways and NAT. The enhancement selects best gateway at time of connection se= tup and pins the selected gateway for duration of the lifetime of that conn= ection. A possible next-step is providing multipath to hosts. At this moment, we do= n't have plans to implement such further enhancements on SmartGateway. Next= step is IPv6 and BRDP, and move to olsrv2. Don't hold your breath. Teco Op 10 dec. 2012, om 18:48 heeft Charles E. Perkins het volgende geschreven: >=20 > Hello Chris, >=20 > I did in fact notice that OLSRv2 supports "Gateways". As best I could > tell, they are gateways for specific subnets, not the entire Internet. >=20 > In fact AODVv2 also supports this functionality. AODV supported it > as well. >=20 > But if OLSRv2 supports Internet Gateway attachment, and if you > could direct my attention to the specific part of the document, I'd > like to learn more. >=20 > Regards, > Charlie P. >=20 > On 12/10/2012 9:43 AM, Dearlove, Christopher (UK) wrote: >> You seem to fail to have noticed that OLSRv2 already includes support fo= r multiple gateways. >>=20 >=20 >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From sratliff@cisco.com Mon Dec 10 10:25:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E372A21F8507 for ; Mon, 10 Dec 2012 10:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXWkTLGUQqNA for ; Mon, 10 Dec 2012 10:25:38 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 707DC21F8506 for ; Mon, 10 Dec 2012 10:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=561; q=dns/txt; s=iport; t=1355163938; x=1356373538; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/IJwdySefX7yWFRASUztJ48A1A2vx+b6I0cUD7eqNsQ=; b=S3RhKcQGFx70Pm4nA4u9oyB4M0PEUCbBWMyAuCZkmJYMU694x3af5L7d wPDsXzBMKGqNB6tmiK+G6M0ZBQBK1TVOzmGAZmtdl5Cga+TIAvPR5j4ZB bh8Jb9Yx4lFgCqAF9/ChP9USW67DGPuYhQ6YhwIanm6T/dZe18oKORPZa 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALEnxlCtJV2d/2dsb2JhbABFvwIWc4IeAQEBAwF5BQsCAQgiJDIlAgQODYgDBrdujD+DYmEDpk6Cc4Ii X-IronPort-AV: E=McAfee;i="5400,1158,6922"; a="151341821" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 10 Dec 2012 18:25:36 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBAIPZCG009859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Dec 2012 18:25:35 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.203]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 10 Dec 2012 12:25:35 -0600 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN1sRQC9RIBD6Ww0Sj7f1Ne2/6upgShJYAgAAL9QCAAC3/gA== Date: Mon, 10 Dec 2012 18:25:35 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2A62A@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <208C25C3-CC27-4138-B83D-92BF1397F68B@inf-net.nl> In-Reply-To: <208C25C3-CC27-4138-B83D-92BF1397F68B@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.40.134] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6D0752266D99E2449BAFD6239B31AA87@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 18:25:39 -0000 The content of the document would be unchanged, with the exception of remov= ing the copyright.=20 Regards, Stan On Dec 10, 2012, at 10:40 AM, Teco Boot wrote: > Op 10 dec. 2012, om 15:58 heeft Stan Ratliff (sratliff) het volgende gesc= hreven: >> There is the issue of re-spinning the LOADng document without the copyri= ght statement - The LOADng authors and the chairs have reached an understan= ding about that issue, so I no longer have a problem with moving forward on= that front. > Can something be exposed to us? >=20 > Teco >=20 From hrogge@googlemail.com Mon Dec 10 10:26:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF56321F85D2 for ; Mon, 10 Dec 2012 10:26:11 -0800 (PST) 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=[AWL=-0.000, 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 QnfB1SCAhyTP for ; Mon, 10 Dec 2012 10:26:10 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF3D921F85B1 for ; Mon, 10 Dec 2012 10:26:10 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so2141621pad.31 for ; Mon, 10 Dec 2012 10:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=VX+NZfrvJMrR0aZ7hFLvzi26wiNo45rc46Ph/ZA4XTo=; b=NFV6cZeVbKNp+iO3cxzz279F6x8J1p3/rYM9j7xZx5WxePuutVSfHbpJf31VnBvfQ7 B59r4jUYoXCBs7Qbr3NUDJmdEtjYcmN6csrLxDijv4IfoIcIHKoiGsFhnG3rDXsXFbNt XgQ9yr0sc8gz2B/7NrbqvTla/t4giP6kyXs1uP1QxsHgN2xkn8DD1KmKLvXPk/rVFn6c /bjEqtTSWJcrkrqmlEfoQEOrOrJNw8vC9pRLV28N+uaDFvFvLGCkhGQrvPKdfg7OYyvh Ejz5VLMnOgq6+NI10Kmg4qbV8CqLrT5aFtxl2bZPCvDVuinkawgArbFqUAd0ZioDTL4n lIFw== Received: by 10.68.143.106 with SMTP id sd10mr41126578pbb.62.1355163970617; Mon, 10 Dec 2012 10:26:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.88.132 with HTTP; Mon, 10 Dec 2012 10:25:50 -0800 (PST) In-Reply-To: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> From: Henning Rogge Date: Mon, 10 Dec 2012 19:25:50 +0100 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 18:26:11 -0000 On Mon, Dec 10, 2012 at 7:20 PM, Dearlove, Christopher (UK) wrote: > Best gateway at time of connection is already in OLSRv2 (it's trivial in = OLSRv1, just not explicitly stated). > > Thinking out loud, maintaining stable selection of gateway over the cour= se of a connection would be a change to OLSRv2, and one that isn't backward= ly compatible. If some of your routers ran OLSRv2 unmodified, and some ran = something attempting a stable connection (by which I assume you mean stable= selection of gateway - that information is available) by simple routing of= packets then that could loop. You could tunnel to the chosen gateway, then= only your endpoints and gateways would need to know what to do. What else? Our current "Smartgateway code" for OLSRv1 is backward compatible. We announce the presence of a "Smartgateway aware" exit node in the 0.0.0.0/0 HNA (its a bit of a hack, but it works ^^). In OLSRv2 we can do it in a clean way by adding additional tags. A "Smartgateway aware" Node that wants to connect to such a gateway use an IPIP tunnel to get its information there. Gateways and Nodes not "Smartgateway aware" work as normal. Henning Rogge -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Teco Boot > Sent: 10 December 2012 18:13 > To: Charles E. Perkins > Cc: Dearlove, Christopher (UK); > Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Somewhat experimental, related to this subject: we'll release an enhanced= version of the SmartGateway extension in olsr.org. SmartGateway provides a= stable connection to the Internet, even with dynamic topology, multiple ga= teways and NAT. The enhancement selects best gateway at time of connection = setup and pins the selected gateway for duration of the lifetime of that co= nnection. > A possible next-step is providing multipath to hosts. At this moment, we = don't have plans to implement such further enhancements on SmartGateway. Ne= xt step is IPv6 and BRDP, and move to olsrv2. Don't hold your breath. > > Teco > > Op 10 dec. 2012, om 18:48 heeft Charles E. Perkins het volgende geschreve= n: > >> >> Hello Chris, >> >> I did in fact notice that OLSRv2 supports "Gateways". As best I could >> tell, they are gateways for specific subnets, not the entire Internet. >> >> In fact AODVv2 also supports this functionality. AODV supported it >> as well. >> >> But if OLSRv2 supports Internet Gateway attachment, and if you >> could direct my attention to the specific part of the document, I'd >> like to learn more. >> >> Regards, >> Charlie P. >> >> On 12/10/2012 9:43 AM, Dearlove, Christopher (UK) wrote: >>> You seem to fail to have noticed that OLSRv2 already includes support f= or multiple gateways. >>> >> >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From Chris.Dearlove@baesystems.com Mon Dec 10 10:36:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C5E21F84FE for ; Mon, 10 Dec 2012 10:36:58 -0800 (PST) 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 d7Ax58uV+hMI for ; Mon, 10 Dec 2012 10:36:57 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id CCF0821F84F9 for ; Mon, 10 Dec 2012 10:36:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,252,1355097600"; d="scan'208";a="293018317" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 10 Dec 2012 18:36:56 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qBAIatLY013556 for ; Mon, 10 Dec 2012 18:36:56 GMT X-IronPort-AV: E=Sophos;i="4.84,252,1355097600"; d="scan'208";a="965412" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 10 Dec 2012 18:36:55 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Mon, 10 Dec 2012 18:36:55 +0000 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-24.txt Thread-Index: AQHNz3PdizJJy8YTn0ujf7TOKm3zcZgHFHyAgAOwKwCAALZvgIAAtL6AgAAzyoCAARwuAIAAP7gAgAAUo4CAAZfTgIAAB+wAgAEzfwCAAbUb0IAAAcAAgAAGvACAAADCEIAAAukAgAAAebA= Date: Mon, 10 Dec 2012 18:36:54 +0000 Message-ID: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 18:36:58 -0000 Well, my thinking out loud got to tunnel (I didn't say IP/IP, but obviously= ) as the only way I could see it working. I was about to say I couldn't see what tags you needed, but I assume what y= ou want is a TLV which when attached to an address in a TC message (possibl= y only one that also has a GATEWAY TLV - that needs more thought, I think y= ou could have a problem otherwise, and it is the clearly intended case) say= s "if you know about this protocol extension, please don't send packets to = any of these addresses, but rather tunnel them direct to me (TC sender) wit= h real destination header encapsulated. That's OK at the modified OLSRv2 level. But you need that modified OLSRv2 t= o somehow hack IP, or intercept IP packets, or something, to do the tunnell= ing. It's a more active process than standard OLSRv2 that only interacts by= "here's a routing table, use it" (plus messages). Yes? --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 10 December 2012 18:26 To: Dearlove, Christopher (UK) Cc: Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Mon, Dec 10, 2012 at 7:20 PM, Dearlove, Christopher (UK) wrote: > Best gateway at time of connection is already in OLSRv2 (it's trivial in = OLSRv1, just not explicitly stated). > > Thinking out loud, maintaining stable selection of gateway over the cour= se of a connection would be a change to OLSRv2, and one that isn't backward= ly compatible. If some of your routers ran OLSRv2 unmodified, and some ran = something attempting a stable connection (by which I assume you mean stable= selection of gateway - that information is available) by simple routing of= packets then that could loop. You could tunnel to the chosen gateway, then= only your endpoints and gateways would need to know what to do. What else? Our current "Smartgateway code" for OLSRv1 is backward compatible. We announce the presence of a "Smartgateway aware" exit node in the 0.0.0.0/0 HNA (its a bit of a hack, but it works ^^). In OLSRv2 we can do it in a clean way by adding additional tags. A "Smartgateway aware" Node that wants to connect to such a gateway use an IPIP tunnel to get its information there. Gateways and Nodes not "Smartgateway aware" work as normal. Henning Rogge -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Teco Boot > Sent: 10 December 2012 18:13 > To: Charles E. Perkins > Cc: Dearlove, Christopher (UK); > Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Somewhat experimental, related to this subject: we'll release an enhanced= version of the SmartGateway extension in olsr.org. SmartGateway provides a= stable connection to the Internet, even with dynamic topology, multiple ga= teways and NAT. The enhancement selects best gateway at time of connection = setup and pins the selected gateway for duration of the lifetime of that co= nnection. > A possible next-step is providing multipath to hosts. At this moment, we = don't have plans to implement such further enhancements on SmartGateway. Ne= xt step is IPv6 and BRDP, and move to olsrv2. Don't hold your breath. > > Teco > > Op 10 dec. 2012, om 18:48 heeft Charles E. Perkins het volgende geschreve= n: > >> >> Hello Chris, >> >> I did in fact notice that OLSRv2 supports "Gateways". As best I could >> tell, they are gateways for specific subnets, not the entire Internet. >> >> In fact AODVv2 also supports this functionality. AODV supported it >> as well. >> >> But if OLSRv2 supports Internet Gateway attachment, and if you >> could direct my attention to the specific part of the document, I'd >> like to learn more. >> >> Regards, >> Charlie P. >> >> On 12/10/2012 9:43 AM, Dearlove, Christopher (UK) wrote: >>> You seem to fail to have noticed that OLSRv2 already includes support f= or multiple gateways. >>> >> >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Mon Dec 10 10:55:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FAA21F8587 for ; Mon, 10 Dec 2012 10:55:44 -0800 (PST) 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 m-5sNqwU46se for ; Mon, 10 Dec 2012 10:55:44 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E6FEB21F8583 for ; Mon, 10 Dec 2012 10:55:43 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so2012028pbc.31 for ; Mon, 10 Dec 2012 10:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=1+VQCgHrEqfnzOtd2c76d2s/TfvSH/N8yj1dSbA2pvY=; b=szBBftXC67yUIgOAo0rYZ11iyj1nf/slxeVnpBPvP/s2oLxAD1E0+waAQiXlvy8TU6 Fg/Ho8oOH3Wuf7GS8wWw+qbhquqHRUvIHZmJydx76O/qbusG+l67ddfeMsg3ISn24Mx+ IwF+lc0xQgPA7K7oY3NzLEseaaWupygpNfehYKxqD9vQOqaFuujl1PEZXWGlJNEiefNh kFKwIYJUqYEArEj8KTWGCY+ACsR08TUKPi9a0wseF56op6Aha2iGV/0rj7SIw0AzXRpE LeB09zAPQAdbkYkfvvnP8+FjEg58mmvT0CjIXHFrB20vdmaHo7NUCo/2pIod25DKGfaZ y+8A== Received: by 10.68.209.230 with SMTP id mp6mr41296770pbc.8.1355165743662; Mon, 10 Dec 2012 10:55:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.88.132 with HTTP; Mon, 10 Dec 2012 10:55:23 -0800 (PST) In-Reply-To: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> From: Henning Rogge Date: Mon, 10 Dec 2012 19:55:23 +0100 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 18:55:44 -0000 On Mon, Dec 10, 2012 at 7:36 PM, Dearlove, Christopher (UK) wrote: > Well, my thinking out loud got to tunnel (I didn't say IP/IP, but obvious= ly) as the only way I could see it working. Its the easiest way to make it working without all nodes being aware of the feature. > I was about to say I couldn't see what tags you needed, but I assume what= you want is a TLV which when attached to an address in a TC message (possi= bly only one that also has a GATEWAY TLV - that needs more thought, I think= you could have a problem otherwise, and it is the clearly intended case) s= ays "if you know about this protocol extension, please don't send packets t= o any of these addresses, but rather tunnel them direct to me (TC sender) w= ith real destination header encapsulated. You can also send them directly. Its more a label "I am capable of receiving IPIP traffic... do what you want." And some information about the kind of gateway you can expect (datarate, ect.). > That's OK at the modified OLSRv2 level. But you need that modified OLSRv2= to somehow hack IP, or intercept IP packets, or something, to do the tunne= lling. It's a more active process than standard OLSRv2 that only interacts = by "here's a routing table, use it" (plus messages). Yes? When a local nodes is SGW capable and decides to use the IPIP feature, it sets up the tunnel and set a 0.0.0.0/0 route into the tunnel, which is put in a special (user configurable) routing table. This way the user can restrict this route to "non-mesh" interfaces to prevent traffic coming from other nodes being sucked into the tunnel. No need to hack or intercept IP at all, just a normal route setup by the routing agent. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From teco@inf-net.nl Mon Dec 10 13:56:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DEA21F8521 for ; Mon, 10 Dec 2012 13:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 AClMpRUqrM95 for ; Mon, 10 Dec 2012 13:56:30 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C983D21F851E for ; Mon, 10 Dec 2012 13:56:29 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so1380999eaa.31 for ; Mon, 10 Dec 2012 13:56:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=AAcIvzYyUqiFBhy9Hhbi6pkXh8doFxK7NiChtFkpLe0=; b=grAnefrvP0rn4JpTXlJxfbQA5uUi7/rS0SC8s3/uJ5uddNzo5HhUjeHpFYxGlPdL9o C/I1WG0aV5QQ6sLRtdK05RCcS/sCkSKWwUa5VsmE9CfQWHLB+scjTWCNOeJ77czaE8TK vACT9tlVKMOYe4vOOAF4mPHlKoq/1oCbOqW7FFfVkeXudZMqzE7JCv08LTVR4IgSTZk4 HkRZnkuhGopOVMOetKk3DKrWVWA4zunW09c4pzY9N2TucI618TJ6lUGbGe1KzgZbGa17 k/EL+orhdcHf+5835J8Al1NSwQkJRIojd2cRowxsQ3vYphcsnfXIB2DQKyNzv1i6x0C2 kDow== Received: by 10.14.213.134 with SMTP id a6mr53732498eep.45.1355176588366; Mon, 10 Dec 2012 13:56:28 -0800 (PST) Received: from [10.175.173.30] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id 44sm45927148eek.0.2012.12.10.13.56.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Dec 2012 13:56:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Mon, 10 Dec 2012 22:56:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2F9893ED-21B4-42A3-B3AE-37124BCA4B17@inf-net.nl> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQm+JRyoRoRpJmD3WQtNDX7PEUOkInK3FAEfuxmHZSKLT69gVO2OpF1vXbaBoiCuJfwgzB/C Cc: "Dearlove, Christopher \(UK\)" , "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 21:56:30 -0000 Next step is to set up a routing policy, based on conntrack. Having = such, we can pin connections to a tunnel. With IPv6 and dynamic, multiple addresses, source address can be used to = direct packets to correct gateway. Homenet is moving towards this = concept. Teco Op 10 dec. 2012, om 19:55 heeft Henning Rogge het volgende geschreven: > On Mon, Dec 10, 2012 at 7:36 PM, Dearlove, Christopher (UK) > wrote: >> Well, my thinking out loud got to tunnel (I didn't say IP/IP, but = obviously) as the only way I could see it working. >=20 > Its the easiest way to make it working without all nodes being aware > of the feature. >=20 >> I was about to say I couldn't see what tags you needed, but I assume = what you want is a TLV which when attached to an address in a TC message = (possibly only one that also has a GATEWAY TLV - that needs more = thought, I think you could have a problem otherwise, and it is the = clearly intended case) says "if you know about this protocol extension, = please don't send packets to any of these addresses, but rather tunnel = them direct to me (TC sender) with real destination header encapsulated. >=20 > You can also send them directly. Its more a label "I am capable of > receiving IPIP traffic... do what you want." And some information > about the kind of gateway you can expect (datarate, ect.). >=20 >> That's OK at the modified OLSRv2 level. But you need that modified = OLSRv2 to somehow hack IP, or intercept IP packets, or something, to do = the tunnelling. It's a more active process than standard OLSRv2 that = only interacts by "here's a routing table, use it" (plus messages). Yes? >=20 > When a local nodes is SGW capable and decides to use the IPIP feature, > it sets up the tunnel and set a 0.0.0.0/0 route into the tunnel, which > is put in a special (user configurable) routing table. This way the > user can restrict this route to "non-mesh" interfaces to prevent > traffic coming from other nodes being sucked into the tunnel. >=20 > No need to hack or intercept IP at all, just a normal route setup by > the routing agent. >=20 > Henning Rogge > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Mon Dec 10 14:21:24 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1555E21F86A5 for ; Mon, 10 Dec 2012 14:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 BJBeeMKW0IFV for ; Mon, 10 Dec 2012 14:21:23 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 7798321F86C1 for ; Mon, 10 Dec 2012 14:21:23 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TiBiy-0006rz-P1; Mon, 10 Dec 2012 17:21:20 -0500 Message-ID: <50C6605C.2070306@computer.org> Date: Mon, 10 Dec 2012 14:21:16 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Teco Boot , "Dearlove, Christopher (UK)" References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> <2F9893ED-21B4-42A3-B3AE-37124BCA4B17@inf-net.nl> In-Reply-To: <2F9893ED-21B4-42A3-B3AE-37124BCA4B17@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86e914e439dd1ab1e2c6cb7e5c9c511d01350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 22:21:24 -0000 Hello Teco and Chris, I guess you'll remember that we had quite a lot of discussion about the gateway possibilities several years ago. Here's an old draft (that does work) from Ryuji: http://tools.ietf.org/id/draft-wakikawa-manet-globalv6-05.txt If the subject matter is enlarged to include routing policy, gateway selection, tunneling, and other matters, then I think the following comment doesn't really fit: > You can indicate the entire Internet with 0.0.0.0/0, as previously described (I think by Henning). Nothing special. Maybe the notation isn't very special, but the functionality is. It isn't even even certain that IP-within-IP (or even tunneling at all) is the best solution. Of course it can be made to work. Joe Macker's comment suggested that maybe for now it's permissible to let that sleeping dog lie, and mention something about the importance of Internet Gateways without immediately attempting a full specification. I am very much in favor of pursuing the matter, but I think it needs to be in a separate document and maybe separate charter item. On 12/10/2012 1:56 PM, Teco Boot wrote: > Next step is to set up a routing policy, based on conntrack. Having such, we can pin connections to a tunnel. > > With IPv6 and dynamic, multiple addresses, source address can be used to direct packets to correct gateway. Homenet is moving towards this concept. > > Teco > -- Regards, Charlie P. From yi.jiazi@gmail.com Mon Dec 10 15:02:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A594321F86AB for ; Mon, 10 Dec 2012 15:02:13 -0800 (PST) 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 yy7Pfgf+0YXz for ; Mon, 10 Dec 2012 15:02:13 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9810821F84DB for ; Mon, 10 Dec 2012 15:02:12 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so1574460wib.13 for ; Mon, 10 Dec 2012 15:02:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=VL7Q0l9dBGhKeKIJDtxNrmY5cDimoDnh2oMnv1G5en4=; b=QF3I1V+5vk90p6FY6KfYUwE7iLU+scxRSUvJ26FIeGEKR0c0YXyr5JELSi9C3nrtyE BtOPWBUhtnzL83WqPBCNuZiIDxDPkDvwEe+hPHyXOqucvhkg38r8dWqqAoFChISkaVs9 NOBRGe2wL9qPABONjdg+VhViTfgtPS7s/Pzxi4LLmQzIgmG92HeYmdqdFViTTuShuYBZ Txe2Fv4MuhQzKlhOPKna4KtXfgjyuAiaPpPomZFzeuDw6SnYz3oWbTwbdkR16I0mTdKn KpwvxidIfgBbd2c//UkXOS1vGRDol+uiTjN9ldq6MrLsqNr1PdPUsmcmhjX0FZ7bUDXT Os8A== Received: by 10.180.109.132 with SMTP id hs4mr13553354wib.1.1355180531713; Mon, 10 Dec 2012 15:02:11 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id w5sm4972760wif.11.2012.12.10.15.02.10 (version=SSLv3 cipher=OTHER); Mon, 10 Dec 2012 15:02:11 -0800 (PST) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_9E678AD0-026B-4B82-80E1-D585B3EF5AD7" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi YI In-Reply-To: Date: Tue, 11 Dec 2012 00:02:08 +0100 Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 23:02:13 -0000 --Apple-Mail=_9E678AD0-026B-4B82-80E1-D585B3EF5AD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi,=20 Given the fact that DYMO is moving closer and closer to LOADng (the = modular approach, handling of RREP, sequence numbers, handling of RERRs, = etc...), I feel that we have already consensus on those general design = issues.=20 The next question is which is the one we should begin with. For me, it's = nature to start with the one with more operational experiences and = running code.=20 Note: I'm not saying taking one and abandoning the other. We just need = to take the one with better shape to begin with, and integrate ideas = from the other one based on WG consensus.=20 best Jiazi On Dec 10, 2012, at 7:08 PM, "Dearlove, Christopher (UK)" = wrote: > Stan Ratliff (sratliff) >> It wasn't clear to me what the consensus was in Atlanta vis-a-vis the = two reactive protocol documents. >=20 > It was clear to me that there was no consensus. Except that abandoning = the work item was not favoured. > But I also don't believe that the meeting was offered any opportunity = to either make that clear or show me > I was wrong in that assessment. >=20 >> There are people advocating for DYMO, others advocating for LOADng, = and some that want to "merge" >> the technology of the two together. >=20 > I would like to point out that my proposal, which I believe would have = been the best to adopt then, > doesn't neatly fit in any of those three categories. >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_9E678AD0-026B-4B82-80E1-D585B3EF5AD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Given the = fact that DYMO is moving closer and closer to LOADng (the modular = approach, handling of RREP, sequence numbers, handling of RERRs, = etc...), I feel that we have already consensus on those general design = issues. 
The next = question is which is the one we should begin with. For me, it's nature = to start with the one with more operational experiences and running = code. 
Note: I'm not = saying taking one and abandoning the other. We just need to take the one = with better shape to begin with, and integrate ideas from the other one = based on WG consensus. 


On Dec 10, 2012, at 7:08 PM, "Dearlove, Christopher (UK)" = <Chris.Dearlove@baesystems.co= m> wrote:

Stan Ratliff (sratliff) <sratliff@cisco.com>
It wasn't clear to me what the consensus was in Atlanta = vis-a-vis the two reactive protocol documents.

It = was clear to me that there was no consensus. Except that abandoning the = work item was not favoured.
But I also don't believe that the meeting = was offered any opportunity to either make that clear or show me
I = was wrong in that assessment.

There are = people advocating for DYMO, others advocating for LOADng, and some that = want to "merge"
the technology of the two = together.

I would like to point out that my = proposal, which I believe would have been the best to adopt = then,
doesn't neatly fit in any of those three = categories.


***************************************************= *****************
This email and any attachments are confidential to = the intended
recipient and may also be privileged. If you are not the = intended
recipient please delete it from your system and notify the = sender.
You should not copy it or use it for any purpose nor disclose = or
distribute its contents to any other = person.
***************************************************************= *****

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

= --Apple-Mail=_9E678AD0-026B-4B82-80E1-D585B3EF5AD7-- From jvasseur@cisco.com Mon Dec 10 18:15:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7171721F86CB for ; Mon, 10 Dec 2012 18:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 qOYk3iGc7B1U for ; Mon, 10 Dec 2012 18:15:42 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 625FC21F86C1 for ; Mon, 10 Dec 2012 18:15:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12727; q=dns/txt; s=iport; t=1355192142; x=1356401742; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ak5VBFSejFKU1rmP646gL6ECxTx7jicESzzO42CxiqM=; b=e1zEU54dJx19eBlR0fEhaLuTH6vowBHUJZKXM0qW3PsNzKGwIvKwx2/g Ar3FGil7wnXdpo2LnnSNNpJsWjB0GzxF9RA6eH3INqVP3FjGbmVOKQSnt HyIIiA3qs9c6+47u1Naias0VqaEDHZAFP7yUwKW8+K+hHTBbZXULEMOqP M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACSWxlCtJV2Z/2dsb2JhbABFvm8Wc4IfAQEEAQEBawsQAgEIIh0HJwsUEQIEDgUIiAkMqESQIwSMPwuDV2EDpk6CZg2BbTU X-IronPort-AV: E=McAfee;i="5400,1158,6922"; a="148488085" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 11 Dec 2012 02:15:41 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBB2FfCa002889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Dec 2012 02:15:41 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.93]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 10 Dec 2012 20:15:41 -0600 From: "JP Vasseur (jvasseur)" To: Jiazi YI Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN10VqOh6vkDdzpUKJNiIiR/f2eg== Date: Tue, 11 Dec 2012 02:15:40 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77230F7F23@xmb-rcd-x02.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.80.208] Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77230F7F23xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 02:15:43 -0000 --_000_03B78081B371D44390ED6E7BADBB4A77230F7F23xmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable don't you have the impression that we go into circles at the risk of having= the same discussion that we had 3 months ago ? On Dec 10, 2012, at 3:02 PM, Jiazi YI wrote: Hi, Given the fact that DYMO is moving closer and closer to LOADng (the modular= approach, handling of RREP, sequence numbers, handling of RERRs, etc...), = I feel that we have already consensus on those general design issues. The next question is which is the one we should begin with. For me, it's na= ture to start with the one with more operational experiences and running co= de. Note: I'm not saying taking one and abandoning the other. We just need to t= ake the one with better shape to begin with, and integrate ideas from the o= ther one based on WG consensus. best Jiazi On Dec 10, 2012, at 7:08 PM, "Dearlove, Christopher (UK)" > wrote: Stan Ratliff (sratliff) > It wasn't clear to me what the consensus was in Atlanta vis-a-vis the two r= eactive protocol documents. It was clear to me that there was no consensus. Except that abandoning the = work item was not favoured. But I also don't believe that the meeting was offered any opportunity to ei= ther make that clear or show me I was wrong in that assessment. There are people advocating for DYMO, others advocating for LOADng, and som= e that want to "merge" the technology of the two together. I would like to point out that my proposal, which I believe would have been= the best to adopt then, doesn't neatly fit in any of those three categories. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A77230F7F23xmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <0C53633BFFDA7048AEFCDB6562488CA5@cisco.com> Content-Transfer-Encoding: quoted-printable don't you have the impression that we go into circles at the risk of having= the same discussion that we had 3 months ago ?

On Dec 10, 2012, at 3:02 PM, Jiazi YI wrote:

Hi, 

Given the fact that DYMO is moving closer and closer to LOADng (the modular appr= oach, handling of RREP, sequence numbers, handling of RERRs, etc...), I fee= l that we have already consensus on those general design issues. 

The next question is which is the one we should begin with. For me, it's natur= e to start with the one with more operational experiences and running code.=  

Note: I'm not saying taking one and abandoning the other. We just need to take t= he one with better shape to begin with, and integrate ideas from the other = one based on WG consensus. 

best

Jiazi


On Dec 10, 2012, at 7:08 PM, "Dearlove, Christopher (UK)" &l= t;Chris.Dearlove@baesystem= s.com> wrote:

Stan Ratliff (sratliff) <sratliff@cisco.com>
It wasn't clear to me what the consensus was in A= tlanta vis-a-vis the two reactive protocol documents.

It was clear to me that there was no consensus. Except that abandoning the = work item was not favoured.
But I also don't believe that the meeting was offered any opportunity to ei= ther make that clear or show me
I was wrong in that assessment.

There are people advocating for DYMO, others advo= cating for LOADng, and some that want to "merge"
the technology of the two together.

I would like to point out that my proposal, which I believe would have been= the best to adopt then,
doesn't neatly fit in any of those three categories.


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

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

--_000_03B78081B371D44390ED6E7BADBB4A77230F7F23xmbrcdx02ciscoc_-- From jvasseur@cisco.com Mon Dec 10 18:19:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF28421F86CB for ; Mon, 10 Dec 2012 18:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jneQT+rt-QMs for ; Mon, 10 Dec 2012 18:19:59 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1837721F85F0 for ; Mon, 10 Dec 2012 18:19:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3748; q=dns/txt; s=iport; t=1355192399; x=1356401999; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+CVVz4Cplr72myRbzBMbUBQKj1EAVibdn5wCUCoYM+I=; b=BHWbagM/Fk2EuVVJDtflZdPCJQtXVTAlcwbHWULjYJxHLmNNMPfY/tRZ gKqfZKOpJhr2E8Az8MexzYJf3ax/ZS0Q1oxGCKeKqNxPBKlhsBhBPB0Yt /iidUSl7xx8KAgEBklVjx1K1wi6XT0jc/BGUAx2yh4ORzY/2eg8nSSgdq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHSXxlCtJV2b/2dsb2JhbABFvm8Wc4IeAQEBAwEBAQFrCwULAgEIGAokJwslAgQOBQiIAwYMqEWQJASMPxyDRmEDpk6CZg2CIg X-IronPort-AV: E=McAfee;i="5400,1158,6922"; a="151487790" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 11 Dec 2012 02:19:58 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBB2JwWf015781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Dec 2012 02:19:58 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.93]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Mon, 10 Dec 2012 20:19:56 -0600 From: "JP Vasseur (jvasseur)" To: "Stan Ratliff (sratliff)" Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN10YD58ZTcgsdX0eR1UQmu61MsA== Date: Tue, 11 Dec 2012 02:19:56 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.80.208] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 02:20:00 -0000 Hi Stan, On Dec 10, 2012, at 6:58 AM, Stan Ratliff (sratliff) wrote: > Abdussalam,=20 >=20 > On Dec 10, 2012, at 5:51 AM, Abdussalam Baryun wrote: >=20 >> On 12/7/12, Stan Ratliff (sratliff) wrote: >>>=20 >>> My feeling, FWIW, is that ingress/egress SHOULD be a part of the base >>> document. However, I understand the concerns of people that say it migh= t be >>> a problem (or extend ratification time, etc etc). So, I'm interested in >>> hearing other, interested opinions - both for >>> DYMO/AODVv2/Whatever-we're-calling-it-this-week, as well as with regard= to >>> the LOADng spec. >>=20 >> I know from my efforts that LOADng team are not welling to discuss, or >> reply to questions/comments, so I want to know your opinion of the >> status on this LOADng draft as you brought it to the list; Is it a WG >> draft? should we discuss individual or private work now? >>=20 >> I remember that we answered chair questions and options given. Not >> sure what the chair of WG wants us to do so far, please advise, >=20 > It wasn't clear to me what the consensus was in Atlanta vis-a-vis the two= reactive protocol documents. Presently, DYMO is the working group accepted= reactive protocol document. However, there was a 2-year period of time whe= n DYMO was inactive, and the document was "parked". As a result of that, th= e effort to create LOADng sprang up.=20 >=20 > So now, we have two documents to consider. In the charter, the WG is "on = the hook" for 1 (and only 1) reactive protocol. So the current options are:= =20 > 1. Recognize that we cannot reach consensus with the two documents, and r= emove the charter item for reactive protocols. To be frank, this is my pref= erred option.=20 > 2. Accept one of the two documents (either LOADng or DYMO), and press for= ward > 3. Perhaps alter the charter item, and produce 2 reactive protocols, both= in "experimental" state.=20 >=20 JP> What about putting a hard dead-line and if there is no consensus fall b= ack to 1 ? > Now, you mentioned "Not sure what the chairs of WG want us to do so far"= =85. the best answer I can give you on that is "reach consensus on an appro= ach". We as a working group haven't done that yet. There are people advoca= ting for DYMO, others advocating for LOADng, and some that want to "merge" = the technology of the two together. A "merge" was something we tried in the= Vancouver timeframe, but that effort failed.=20 >=20 > As to your statement that the LOADng team is not willing to discuss - I h= aven't seen that, do not agree with it, and would ask you to cite *specific= * examples if you have them. I've found the LOADng team to be reasonable in= their dealings with the WG. There is the issue of re-spinning the LOADng d= ocument without the copyright statement - The LOADng authors and the chairs= have reached an understanding about that issue, so I no longer have a prob= lem with moving forward on that front.=20 >=20 > Again, as a working group - we *MUST* either reach a consensus, or the wo= rk item will be removed *for us*. If we do not show progress towards a goal= , it is within the power of the IESG to stop work on the issue. >=20 > Regards, > Stan >=20 >=20 >>=20 >> AB >>=20 >>>=20 >>> And lastly=85.. if the 5 guys were *that* important, they most likely w= ouldn't >>> be *playing* black-ops=85 ;-) >>>=20 >>> Stan >>>=20 >>>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Mon Dec 10 22:34:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC57021F849F for ; Mon, 10 Dec 2012 22:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 vtzmj4gBkRwt for ; Mon, 10 Dec 2012 22:34:21 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 573BA21F84B2 for ; Mon, 10 Dec 2012 22:34:17 -0800 (PST) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TiJPy-0005b4-Po; Tue, 11 Dec 2012 01:34:15 -0500 Message-ID: <50C6D3E4.1010105@computer.org> Date: Mon, 10 Dec 2012 22:34:12 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jiazi YI References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050308060109040608010109" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86fb88171413c8da245e87cf8e7b2e2ebf350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: "manet@ietf.org List" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 06:34:23 -0000 This is a multi-part message in MIME format. --------------050308060109040608010109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Jiazi, On 12/10/2012 3:02 PM, Jiazi YI wrote: > > Given the fact that DYMO is moving closer and closer to LOADng (the > modular approach, handling of RREP, sequence numbers, handling of > RERRs, etc...), I feel that we have already consensus on those general > design issues. I find this to be an unusual comment, since the explicit goal was to be inclusive and compatible with LOADng. Moreover, I have for a long time been pointing out that it would not be difficult to produce this compatibility. > > The next question is which is the one we should begin with. For me, > it's nature to start with the one with more operational experiences > and running code. As I understand it, most of the operational experience was with non-mobile networks. I guess there has been some more recent work with mobile networks? Given that LOADng can be viewed as a set of mandatory features from the WG document along with, possibly, some optional features, and since the WG document has all along been designed for mobile networks, and to have certain scalability features, it seems natural to continue with the WG document and to take care for the needs of LOADng as well. > > Note: I'm not saying taking one and abandoning the other. We just need > to take the one with better shape to begin with, and integrate ideas > from the other one based on WG consensus. Well, after recent efforts I think the WG document is really in pretty good shape. In the near future, I'll try to suggest some various points where the LOADng document should be moved closer to where the WG document is now -- I hope to do this before Christmas. -- Regards, Charlie P. --------------050308060109040608010109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello Jiazi,

On 12/10/2012 3:02 PM, Jiazi YI wrote:

Given the fact that DYMO is moving closer and closer to LOADng (the modular approach, handling of RREP, sequence numbers, handling of RERRs, etc...), I feel that we have already consensus on those general design issues.

I find this to be an unusual comment, since the explicit goal was
to be inclusive and compatible with LOADng.  Moreover, I have for
a long time been pointing out that it would not be difficult to produce
this compatibility.


The next question is which is the one we should begin with. For me, it's nature to start with the one with more operational experiences and running code.


As I understand it, most of the operational experience was with
non-mobile networks.   I guess there has been some more recent
work with mobile networks?

Given that LOADng can be viewed as a set of mandatory features
from the WG document along with, possibly, some optional
features, and since the WG document has all along been designed
for mobile networks, and to have certain scalability features, it
seems natural to continue with the WG document and to take
care for the needs of LOADng as well.


Note: I'm not saying taking one and abandoning the other. We just need to take the one with better shape to begin with, and integrate ideas from the other one based on WG consensus.

Well, after recent efforts I think the WG document is really
in pretty good shape.   In the near future, I'll try to suggest some
various points where the LOADng document should be moved
closer to where the WG document is now -- I hope to do this
before Christmas.
-- 
Regards,
Charlie P.
--------------050308060109040608010109-- From henning.rogge@fkie.fraunhofer.de Mon Dec 10 23:07:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCF121F8718 for ; Mon, 10 Dec 2012 23:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.961 X-Spam-Level: X-Spam-Status: No, score=-0.961 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 lXvEHJRBzJxc for ; Mon, 10 Dec 2012 23:07:11 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id A6CA021F847C for ; Mon, 10 Dec 2012 23:07:10 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TiJvp-0000Kn-3h for manet@ietf.org; Tue, 11 Dec 2012 08:07:09 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TiJvp-0001TC-13 for manet@ietf.org; Tue, 11 Dec 2012 08:07:09 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 11 Dec 2012 08:07:08 +0100 Message-ID: <50C6DB95.50609@fkie.fraunhofer.de> Date: Tue, 11 Dec 2012 08:07:01 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> <2F9893ED-21B4-42A3-B3AE-37124BCA4B17@inf-net.nl> <50C6605C.2070306@computer.org> In-Reply-To: <50C6605C.2070306@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090601000307010107070401" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/15720/Tue Dec 11 03:20:00 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: ce4bc42c0f341c6b36ab5749a0b03868 Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 07:07:11 -0000 --------------ms090601000307010107070401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 12/10/2012 11:21 PM, Charles E. Perkins wrote: >> You can indicate the entire Internet with 0.0.0.0/0, as previously >> described (I think by Henning). Nothing special. > > Maybe the notation isn't very special, but the functionality is. I disagree on this point. While the /0 prefx is the largest prefix possible, you can have the same trouble with overlapping prefixes and missed smaller prefixes (including host-routes) with smaller ones. > It isn't even even certain that IP-within-IP (or even tunneling at > all) is the best solution. Of course it can be made to work. Tunneling should not be necessary to support prefixes. We only=20 integrated it in the olsr.org code because our NORMAL usecase is=20 multiple gateways (each using NAT) announcing a 0.0.0.0/0 prefix. Is there a reason why you think that your strategy for the "internet=20 uplink" will not work with other kinds of prefixes? I don't like the=20 idea to include a hack for a special case when we already see that=20 people will ask about a generic solution. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090601000307010107070401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEyMTEwNzA3MDZaMCMGCSqGSIb3DQEJBDEWBBRAzdXXxZHKedkPkOX+4vxvF8HTOzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAPfHfkb3mAPIwODnXVmdVT4RW+UQt+jMb/hnEdv68x/+a 7OWkO6ATwZ9SMmJ0sj/JK9UePQ8giyPcW6HPOtEe2hoW1Xs4FIR1KqtyRnyj9xKqE8JfRhVU dt7lCusYauQRxMwpPbqd5d+phOw2UOwNJ9uXvbWpdyWabWEJrGut7JXCCbe8OswXhCe2uRLd ZyinRIodNYvYgPaUmLfHQTYwsw8n5W2Jnnos6c0z6MYAihlH2buzTSDYWAVrFMmSPrZYWxIS KVO1WUtAf0cETb/ACBM54ji/EigyXn71qZv+E77ZaXX7j/39f6LYalj/BKfP8FOcMeDbOH4f Bu4nGwpbkAAAAAAAAA== --------------ms090601000307010107070401-- From Chris.Dearlove@baesystems.com Tue Dec 11 01:57:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1055221F86BE for ; Tue, 11 Dec 2012 01:57:59 -0800 (PST) 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 HFR-MV+Tulps for ; Tue, 11 Dec 2012 01:57:58 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEFE21F86BB for ; Tue, 11 Dec 2012 01:57:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,258,1355097600"; d="scan'208";a="248766137" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 11 Dec 2012 09:57:56 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qBB9vunY020930 for ; Tue, 11 Dec 2012 09:57:56 GMT X-IronPort-AV: E=Sophos;i="4.84,258,1355097600"; d="scan'208";a="791783" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 11 Dec 2012 09:57:55 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0309.002; Tue, 11 Dec 2012 09:57:55 +0000 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , Teco Boot Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-24.txt Thread-Index: AQHNz3PdizJJy8YTn0ujf7TOKm3zcZgHFHyAgAOwKwCAALZvgIAAtL6AgAAzyoCAARwuAIAAP7gAgAAUo4CAAZfTgIAAB+wAgAEzfwCAAbUb0IAAAcAAgAAGvACAAADCEIAAAukAgAAAebCAAAfJgIAAMpKAgAAG9ACAAMHmMA== Date: Tue, 11 Dec 2012 09:57:55 +0000 Message-ID: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50C05967.405@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> <2F9893ED-21B4-42A3-B3AE-37124BCA4B17@inf-net.nl> <50C6605C.2070306@computer.org> In-Reply-To: <50C6605C.2070306@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 09:57:59 -0000 Tunnelling is a separate process from that embodied in OLSRv2, and a totall= y separate issue.=20 But in the normal course of things, there is - for a proactive protocol - a= bsolutely nothing special about 0.0.0.0/0 (or IPv6 equivalent). --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of C= harles E. Perkins Sent: 10 December 2012 22:21 To: Teco Boot; Dearlove, Christopher (UK) Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hello Teco and Chris, I guess you'll remember that we had quite a lot of discussion about the gateway possibilities several years ago. Here's an old draft (that does work) from Ryuji: http://tools.ietf.org/id/draft-wakikawa-manet-globalv6-05.txt If the subject matter is enlarged to include routing policy, gateway selection, tunneling, and other matters, then I think the following comment doesn't really fit: > You can indicate the entire Internet with 0.0.0.0/0, as previously descri= bed (I think by Henning). Nothing special. Maybe the notation isn't very special, but the functionality is. It isn't even even certain that IP-within-IP (or even tunneling at all) is the best solution. Of course it can be made to work. Joe Macker's comment suggested that maybe for now it's permissible to let that sleeping dog lie, and mention something about the importance of Internet Gateways without immediately attempting a full specification. I am very much in favor of pursuing the matter, but I think it needs to be in a separate document and maybe separate charter item. On 12/10/2012 1:56 PM, Teco Boot wrote: > Next step is to set up a routing policy, based on conntrack. Having such,= we can pin connections to a tunnel. > > With IPv6 and dynamic, multiple addresses, source address can be used to = direct packets to correct gateway. Homenet is moving towards this concept. > > Teco > --=20 Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Tue Dec 11 02:05:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB2121F877F for ; Tue, 11 Dec 2012 02:05:47 -0800 (PST) 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 pzdOGvLauSrF for ; Tue, 11 Dec 2012 02:05:45 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 2A71821F8738 for ; Tue, 11 Dec 2012 02:05:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,258,1355097600"; d="scan'208";a="293152066" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 11 Dec 2012 10:05:40 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qBBA5ekO014886 for ; Tue, 11 Dec 2012 10:05:40 GMT X-IronPort-AV: E=Sophos;i="4.84,258,1355097600"; d="scan'208";a="1010392" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 11 Dec 2012 10:05:39 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0309.002; Tue, 11 Dec 2012 10:05:40 +0000 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-24.txt Thread-Index: AQHNz3PdizJJy8YTn0ujf7TOKm3zcZgHFHyAgAOwKwCAALZvgIAAtL6AgAAzyoCAARwuAIAAP7gAgAAUo4CAAZfTgIAAB+wAgAEzfwCAAbUb0IAAAcAAgAAGvACAAADCEIAAAukAgAAAebCAAAfJgIAAMpKAgAAG9ACAAJLkgIAAMJQw Date: Tue, 11 Dec 2012 10:05:39 +0000 Message-ID: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> <2F9893ED-21B4-42A3-B3AE-37124BCA4B17@inf-net.nl> <50C6605C.2070306@computer.org> <50C6DB95.50609@fkie.fraunhofer.de> In-Reply-To: <50C6DB95.50609@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 10:05:47 -0000 There is a generic solution - just route to nearest gateway. If you think g= ateway constancy is important, it appears that a modified protocol (which m= y interest was in understanding, and understanding compatibility of, no mor= e at this time) is possible and consistent with OLSRv2. But in neither case= is 0.0.0.0/0 special. And in neither case (especially not the OLSRv2 defau= lt, which is already specified) is whatever AODVv2 chooses to do relevant. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 11 December 2012 07:07 To: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt On 12/10/2012 11:21 PM, Charles E. Perkins wrote: >> You can indicate the entire Internet with 0.0.0.0/0, as previously >> described (I think by Henning). Nothing special. > > Maybe the notation isn't very special, but the functionality is. I disagree on this point. While the /0 prefx is the largest prefix possible, you can have the same trouble with overlapping prefixes and missed smaller prefixes (including host-routes) with smaller ones. > It isn't even even certain that IP-within-IP (or even tunneling at > all) is the best solution. Of course it can be made to work. Tunneling should not be necessary to support prefixes. We only=20 integrated it in the olsr.org code because our NORMAL usecase is=20 multiple gateways (each using NAT) announcing a 0.0.0.0/0 prefix. Is there a reason why you think that your strategy for the "internet=20 uplink" will not work with other kinds of prefixes? I don't like the=20 idea to include a hack for a special case when we already see that=20 people will ask about a generic solution. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Tue Dec 11 02:12:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A3021F84DC for ; Tue, 11 Dec 2012 02:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 co4HbVvt7Bwr for ; Tue, 11 Dec 2012 02:12:26 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 966A321F84D9 for ; Tue, 11 Dec 2012 02:12:20 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TiMp1-0003Yz-8N; Tue, 11 Dec 2012 11:12:19 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TiMp1-0006dO-5e; Tue, 11 Dec 2012 11:12:19 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 11 Dec 2012 11:12:18 +0100 Message-ID: <50C706FD.4010601@fkie.fraunhofer.de> Date: Tue, 11 Dec 2012 11:12:13 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> <2F9893ED-21B4-42A3-B3AE-37124BCA4B17@inf-net.nl> <50C6605C.2070306@computer.org> <50C6DB95.50609@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090807010104030008080300" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/15720/Tue Dec 11 03:20:00 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 2d58c557eff95fe6d1f20ba5c7a78ca3 Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 10:12:32 -0000 --------------ms090807010104030008080300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 12/11/2012 11:05 AM, Dearlove, Christopher (UK) wrote: > There is a generic solution - just route to nearest gateway. The problem with this in our usecase is the NAT on the gateways... which = breaks all your TCP sessions when you change the gateway. Imagine nodes sitting in between two 0.0.0.0/0 gateways. The normal=20 fluctuation of the routing metric will make them hop between both=20 gateways all the times. > If you > think gateway constancy is important, it appears that a modified > protocol (which my interest was in understanding, and understanding > compatibility of, no more at this time) is possible and consistent > with OLSRv2. That was our idea with SmartGateway. An extension of the current=20 protocol that works well with old nodes (both as nodes and gateways). > But in neither case is 0.0.0.0/0 special. We only do the whole tunnel/smartgw thing for 0.0.0.0/0 (and not other=20 HNAs), but that just a matter of the limited implementation. > And in neither > case (especially not the OLSRv2 default, which is already specified) > is whatever AODVv2 chooses to do relevant. Yes. But I still think that propagating prefixes is relevant for AODVv2, not=20 only the 0.0.0.0/0 prefix. Another "useful" usecase I can see is=20 allowing each Node to announce a /64 prefix in an IPV6 network, which=20 allows the node to deploy a local network behind the mesh node. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090807010104030008080300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEyMTExMDEyMTVaMCMGCSqGSIb3DQEJBDEWBBSZTYKmC0bG/4DBNWJrbMbnjQKWgzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEASR8sxWkW48rE52FLrUnAjOhDLM9sQTZWFsjl1gKL84dc 5QuTnlO8ys8rRbK+XbEwFwccSAGZD6YFp7AkaFZMA/5UBo5iIp3Dv99WozD/LfF24QX7GiM0 E4ENUZ58aPnekQWHs41h5W1WilydGQbVpQs5Af4O7g9pHVRNraReipnaKjgHDJOztVT/oX00 xSUVyGLQ7xcFkPRKPUNVq2dkl1sRdK4eP2mdraftGHBAW9ralx7mTILrGvPN6u2H/sXMIGt4 +urCYmmqxaK3sSFYHNuD7c7faLEG+shu2PL4jYx5W3FRXCA0Yz0BI+ZYEUpx66N5kbVpMydK ZcT8ctF2owAAAAAAAA== --------------ms090807010104030008080300-- From Chris.Dearlove@baesystems.com Tue Dec 11 02:23:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD78C21F87F9 for ; Tue, 11 Dec 2012 02:23:33 -0800 (PST) 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 tQieVK0OwLwQ for ; Tue, 11 Dec 2012 02:23:31 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 69A9021F87F7 for ; Tue, 11 Dec 2012 02:23:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,258,1355097600"; d="scan'208";a="293162024" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 11 Dec 2012 10:23:30 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qBBANUMN031854 for ; Tue, 11 Dec 2012 10:23:30 GMT X-IronPort-AV: E=Sophos;i="4.84,258,1355097600"; d="scan'208";a="1014721" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds017.greenlnk.net with ESMTP; 11 Dec 2012 10:23:30 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Tue, 11 Dec 2012 10:23:30 +0000 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-24.txt Thread-Index: AQHNz3PdizJJy8YTn0ujf7TOKm3zcZgHFHyAgAOwKwCAALZvgIAAtL6AgAAzyoCAARwuAIAAP7gAgAAUo4CAAZfTgIAAB+wAgAEzfwCAAbUb0IAAAcAAgAAGvACAAADCEIAAAukAgAAAebCAAAfJgIAAMpKAgAAG9ACAAJLkgIAAMJQwgAADK4CAAABSoA== Date: Tue, 11 Dec 2012 10:23:29 +0000 Message-ID: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> <2F9893ED-21B4-42A3-B3AE-37124BCA4B17@inf-net.nl> <50C6605C.2070306@computer.org> <50C6DB95.50609@fkie.fraunhofer.de> <50C706FD.4010601@fkie.fraunhofer.de> In-Reply-To: <50C706FD.4010601@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 10:23:33 -0000 I can see there could be several reasons why a consistent gateway might be = a good thing. Of course there are also cases where it is unnecessary (such = as, even with NAT, all gateways connecting to a common later egress point w= here the NAT is). And I think it is consistent with OLSRv2 in two ways - one is you can get a= mix of extension aware and unaware nodes in interwork (though if the unawa= re nodes act as sources and you have a reason for consistency, that may be = a problem). The other is that OLSRv2 doesn't actually mandate what you do w= ith the routing information you collect. It can't - that's IP's problem. Of= course it makes it clear what it expects (direct mapping to routing table)= which is what I've referred to as standard OLSRv2. But what you propose as= an extension doesn't contradict what OLSRv2 mandates itself. (Incidentally if you define this, I'm wondering whether the right TLV would= be GATEWAY with a new type extension. Unfortunately that can't replace the= standard GATEWAY TLV, only add to it.) When I say what a reactive protocol should do is a separate issue, that's n= ot to suggest a reactive protocol shouldn't have gateways - in fact that se= ems either essential or close to that. But it's a separate design issue tha= t involves RREQs, RREPs and all that, while for OLSRv2 it's about what's in= TC messages. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de]=20 Sent: 11 December 2012 10:12 To: Dearlove, Christopher (UK) Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt On 12/11/2012 11:05 AM, Dearlove, Christopher (UK) wrote: > There is a generic solution - just route to nearest gateway. The problem with this in our usecase is the NAT on the gateways... which=20 breaks all your TCP sessions when you change the gateway. Imagine nodes sitting in between two 0.0.0.0/0 gateways. The normal=20 fluctuation of the routing metric will make them hop between both=20 gateways all the times. > If you > think gateway constancy is important, it appears that a modified > protocol (which my interest was in understanding, and understanding > compatibility of, no more at this time) is possible and consistent > with OLSRv2. That was our idea with SmartGateway. An extension of the current=20 protocol that works well with old nodes (both as nodes and gateways). > But in neither case is 0.0.0.0/0 special. We only do the whole tunnel/smartgw thing for 0.0.0.0/0 (and not other=20 HNAs), but that just a matter of the limited implementation. > And in neither > case (especially not the OLSRv2 default, which is already specified) > is whatever AODVv2 chooses to do relevant. Yes. But I still think that propagating prefixes is relevant for AODVv2, not=20 only the 0.0.0.0/0 prefix. Another "useful" usecase I can see is=20 allowing each Node to announce a /64 prefix in an IPV6 network, which=20 allows the node to deploy a local network behind the mesh node. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Tue Dec 11 02:42:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AEA21F87F7 for ; Tue, 11 Dec 2012 02:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.089 X-Spam-Level: X-Spam-Status: No, score=-1.089 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 idNQs-AwQpAD for ; Tue, 11 Dec 2012 02:42:07 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 1587421F872C for ; Tue, 11 Dec 2012 02:42:07 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TiNHq-0005FJ-Es; Tue, 11 Dec 2012 11:42:06 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TiNHq-0007VK-CC; Tue, 11 Dec 2012 11:42:06 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 11 Dec 2012 11:42:05 +0100 Message-ID: <50C70DF0.4010400@fkie.fraunhofer.de> Date: Tue, 11 Dec 2012 11:41:52 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> <2F9893ED-21B4-42A3-B3AE-37124BCA4B17@inf-net.nl> <50C6605C.2070306@computer.org> <50C6DB95.50609@fkie.fraunhofer.de> <50C706FD.4010601@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090402020906050000060603" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/15720/Tue Dec 11 03:20:00 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 797bbac53b4539d3de9d70869dd0fccf Cc: "manet@ietf.org" Subject: Re: [manet] SmartGateway Feature for OLSRv2 (was I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 10:42:08 -0000 --------------ms090402020906050000060603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 12/11/2012 11:23 AM, Dearlove, Christopher (UK) wrote: > I can see there could be several reasons why a consistent gateway > might be a good thing. Of course there are also cases where it is > unnecessary (such as, even with NAT, all gateways connecting to a > common later egress point where the NAT is). > > And I think it is consistent with OLSRv2 in two ways - one is you can > get a mix of extension aware and unaware nodes in interwork (though > if the unaware nodes act as sources and you have a reason for > consistency, that may be a problem). The other is that OLSRv2 doesn't > actually mandate what you do with the routing information you > collect. It can't - that's IP's problem. Of course it makes it clear > what it expects (direct mapping to routing table) which is what I've > referred to as standard OLSRv2. But what you propose as an extension > doesn't contradict what OLSRv2 mandates itself. Yes. Thats why we only "added" a route instead of changing the behavior=20 for the rest of the mesh. Deploying a new feature that breaks old features is often too difficult. > (Incidentally if you define this, I'm wondering whether the right TLV > would be GATEWAY with a new type extension. Unfortunately that can't > replace the standard GATEWAY TLV, only add to it.) Hmm... a Gateway TLV Extension Type for defining the capability of=20 "Tunnel endpoint capability? Which would allow a node to tunnel any kind = of traffic to the node through a tunnel. Maybe it would be a good way to use the value of the TLV to define what=20 kind of tunnel you can use (IPIP, Gre, ...). In addition to this we would like to have a way for a gateway to=20 describe the capabilities of its uplink. How fast (up/down speed), if it = NATs or not and maybe the external IPv6 prefix. Some of this could be done by a different protocol (e.g. DHCP prefix=20 delegation), others are interesting for the routing protocol itself to=20 select the right gateway for a certain prefix. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090402020906050000060603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEyMTExMDQyMDRaMCMGCSqGSIb3DQEJBDEWBBTSmlzQQQObYO22tphew/A98isKIjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAv84fA757B5YpbRpbxVanPPqDp85bmOW6XSS4AfBskBRx KbOcqdyLHncGGjLoWqFR7fjfHj2Jr3EiMVNDFICN3RaLVEb4G2W082esqvYPRtQOzGTtFcrJ sOBD6hjUuz9eQvmnlNNNANhquTpi1oVDhMAt/DYbT57UmMZXoMp9vBBUEyvU+wjALvDlm4nF 8r4Szq6a9Tj3rQ6cLi+dGFgMrssWgoNS39VQvdH7fj/zkBdBdV1Na2r35Nomz1XNMS/dUDG8 128ozUo2D9l13Q8rQYHsSHls8oH7KWWHY/itv1TSdSfFwLHO91aT8Bd+YO8C2pmRFFxqAtB/ fEvNH8PxLgAAAAAAAA== --------------ms090402020906050000060603-- From ietf@thomasclausen.org Tue Dec 11 03:22:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A69621F86BB for ; Tue, 11 Dec 2012 03:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] 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 NqTxuFMDPmCV for ; Tue, 11 Dec 2012 03:22:33 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 90BBE21F84C9 for ; Tue, 11 Dec 2012 03:22:17 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 59544A3AD4 for ; Tue, 11 Dec 2012 03:22:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C68941BCCAE1; Tue, 11 Dec 2012 03:22:15 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 445AB1BCCADE; Tue, 11 Dec 2012 03:22:15 -0800 (PST) References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> <2F9893ED-21B4-42A3-B3AE-37124BCA4B17@inf-net.nl> <50C6605C.2070306@computer.org> <50C6DB95.50 609@fkie.fraunhofer.de> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <771DECBD-7746-4435-8B92-CD8FA32E9133@thomasclausen.org> X-Mailer: iPad Mail (10A523) From: Thomas Heide Clausen Date: Tue, 11 Dec 2012 12:22:14 +0100 To: "Dearlove, Christopher (UK)" Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 11:22:34 -0000 The issue (discussed at length at [HOMENE]) is source address selection in c= ase of a multi-homed (MA)NETwork - and, as Henning says, also NAT state (if u= sed). Personally, I believe that this is not a MANET-specific issue, and that we s= hould try to look to [HOMENET] to understand if their cognitions are not sim= ply generally applicable. Thomas Sent from my iPad On 11 d=C3=A9c. 2012, at 11:05, "Dearlove, Christopher (UK)" wrote: > There is a generic solution - just route to nearest gateway. If you think g= ateway constancy is important, it appears that a modified protocol (which my= interest was in understanding, and understanding compatibility of, no more a= t this time) is possible and consistent with OLSRv2. But in neither case is 0= .0.0.0/0 special. And in neither case (especially not the OLSRv2 default, wh= ich is already specified) is whatever AODVv2 chooses to do relevant. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge > Sent: 11 December 2012 07:07 > To: manet@ietf.org > Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt >=20 > On 12/10/2012 11:21 PM, Charles E. Perkins wrote: >>> You can indicate the entire Internet with 0.0.0.0/0, as previously >>> described (I think by Henning). Nothing special. >>=20 >> Maybe the notation isn't very special, but the functionality is. >=20 > I disagree on this point. While the /0 prefx is the largest prefix > possible, you can have the same trouble with overlapping prefixes and > missed smaller prefixes (including host-routes) with smaller ones. >=20 >> It isn't even even certain that IP-within-IP (or even tunneling at >> all) is the best solution. Of course it can be made to work. >=20 > Tunneling should not be necessary to support prefixes. We only=20 > integrated it in the olsr.org code because our NORMAL usecase is=20 > multiple gateways (each using NAT) announcing a 0.0.0.0/0 prefix. >=20 > Is there a reason why you think that your strategy for the "internet=20 > uplink" will not work with other kinds of prefixes? I don't like the=20 > idea to include a hack for a special case when we already see that=20 > people will ask about a generic solution. >=20 > Henning Rogge > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From yi.jiazi@gmail.com Tue Dec 11 03:39:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CEA21F852B for ; Tue, 11 Dec 2012 03:39:31 -0800 (PST) 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 Rt-haJPYmg88 for ; Tue, 11 Dec 2012 03:39:30 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 507CE21F8496 for ; Tue, 11 Dec 2012 03:39:30 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so1892880wib.13 for ; Tue, 11 Dec 2012 03:39:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=S7Y5ocfADcc3YL/vIDvkV0fB0I1nqH1fXkf7ZOjzj6g=; b=otyPX3mYAp36EzpSsL8mZdlyXuJK/t4YdyFID8qpVsa6sz/eR0JzR5OsuzPhETPLfS zxLkhrDYInrV/BIsOGkC9ljNE3VWlxH7v3cweitidHpbfQk2uKcwy7D4nUQmfuuwy1og h/q4xmsAoMlJZs6MtZsDPwvAynhscCePwzZx4LMc8aqo9GRzCZOagHvLFN4LeOpVdX3V YnRg6naxhCaD6N8vOtTr5p1giwZGEmjtG76OBUAvQigsxlFEk2PJ3sxG6JgVfXNYe5YU zlBcJAHugytFQ5kt6BFKiZOJ+cVr2HKeV1Hav68sLFmDtkCgoDPmoPiXnFbx4A1ehRyp 0CVA== Received: by 10.180.20.109 with SMTP id m13mr16277290wie.16.1355225966227; Tue, 11 Dec 2012 03:39:26 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id u6sm15942330wif.2.2012.12.11.03.39.24 (version=SSLv3 cipher=OTHER); Tue, 11 Dec 2012 03:39:25 -0800 (PST) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_441E6746-716C-469A-9A74-AA05B7659831" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi YI In-Reply-To: <50C6D3E4.1010105@computer.org> Date: Tue, 11 Dec 2012 12:17:05 +0100 Message-Id: <2DE09B23-0544-4436-87D2-F266B9338A4E@jiaziyi.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <50C6D3E4.1010105@computer.org> To: Charles E. Perkins X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org List" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 11:39:31 -0000 --Apple-Mail=_441E6746-716C-469A-9A74-AA05B7659831 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Charlie,=20 On Dec 11, 2012, at 7:34 AM, Charles E. Perkins = wrote: >=20 > Hello Jiazi, >=20 > On 12/10/2012 3:02 PM, Jiazi YI wrote: >>=20 >> Given the fact that DYMO is moving closer and closer to LOADng (the = modular approach, handling of RREP, sequence numbers, handling of RERRs, = etc...), I feel that we have already consensus on those general design = issues. >=20 > I find this to be an unusual comment, since the explicit goal was > to be inclusive and compatible with LOADng. Moreover, I have for > a long time been pointing out that it would not be difficult to = produce > this compatibility. I didn't find any controversial between what you said (the *goal*) and = what I mentioned (the *result*).=20 I think to be *compatible* with LOADng, the fact is that DYMO is getting = more closer to LOADng. I made a small list after comparing dymo-21 and = dymo-24, it's not hard to have this conclusion.=20 In the meantime, even dymo and LOADng are having the similar approaches, = as one who participated in most interop events of LOADng, I find it's = hard to have dymo compatible with LOADng, without significant changes of = DYMO (packet format, flags, message processing...) >=20 >>=20 >> The next question is which is the one we should begin with. For me, = it's nature to start with the one with more operational experiences and = running code. >=20 >=20 > As I understand it, most of the operational experience was with > non-mobile networks. I guess there has been some more recent > work with mobile networks? I have to say, I didn't mention which one is the protocol that has more = operational experiences and running code. Because I'm only familiar with = the situation of LOADng (interop events, large implementation, etc...) I believe when you are saying above, you admit that LOADng is having = more operational experiences? Or can you share some of dymo (either = non-mobile, or mobile)? >=20 > Given that LOADng can be viewed as a set of mandatory features > from the WG document along with, possibly, some optional > features, and since the WG document has all along been designed > for mobile networks, and to have certain scalability features, it > seems natural to continue with the WG document and to take > care for the needs of LOADng as well. As a lot of people have mentioned, because DYMO and LOADng generally = share the same mechanism, they won't have significant difference in = performance. That's why I said we should begin with the one with more = operational experience.=20 Personally, I'm very careful when making assessment. When I'm saying = LOADng has scalability features, and can have interoperable = implementations, there is running code to prove that. I think it's the "running code", which is believed in IETF, am I wrong? = So if I need to choose between the "running code", and "some optional = features that are not verified", my choice is quite clear, especially = for a standard track protocol.=20 >=20 >>=20 >> Note: I'm not saying taking one and abandoning the other. We just = need to take the one with better shape to begin with, and integrate = ideas from the other one based on WG consensus. >=20 > Well, after recent efforts I think the WG document is really > in pretty good shape. In the near future, I'll try to suggest some > various points where the LOADng document should be moved > closer to where the WG document is now -- I hope to do this > before Christmas. I'm aware that there are some issues still need to addressed for LOADng, = and there are still a lot of tickets under active discussion in the = LOADng bugtracker. Any comments that can be helpful to improve the = existed tickets, or new issues of LOADng, are welcome.=20 best Jiazi > --=20 > Regards, > Charlie P. --Apple-Mail=_441E6746-716C-469A-9A74-AA05B7659831 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
Hi Charlie, 


On Dec 11, 2012, at 7:34 AM, Charles E. Perkins <charliep@computer.org> wrote:


Hello Jiazi,

On 12/10/2012 3:02 PM, Jiazi YI wrote:

Given the fact that DYMO is moving closer and closer to LOADng (the modular approach, handling of RREP, sequence numbers, handling of RERRs, etc...), I feel that we have already consensus on those general design issues.

I find this to be an unusual comment, since the explicit goal was
to be inclusive and compatible with LOADng.  Moreover, I have for
a long time been pointing out that it would not be difficult to produce
this compatibility.

I didn't find any controversial between what you said (the *goal*) and what I mentioned (the *result*). 
I think to be *compatible* with LOADng, the fact is that DYMO is getting more closer to LOADng. I made a small list after comparing dymo-21 and dymo-24, it's not hard to have this conclusion. 
In the meantime, even dymo and LOADng are having the similar approaches, as one who participated in most interop events of LOADng, I find it's hard to have dymo compatible with LOADng, without significant changes of DYMO (packet format, flags, message processing...)




The next question is which is the one we should begin with. For me, it's nature to start with the one with more operational experiences and running code.


As I understand it, most of the operational experience was with
non-mobile networks.   I guess there has been some more recent
work with mobile networks?

I have to say, I didn't mention which one is the protocol that has more operational experiences and running code. Because I'm only familiar with the situation of LOADng (interop events, large implementation, etc...)
I believe when you are saying above, you admit that LOADng is having more operational experiences? Or can you share some of dymo (either non-mobile, or mobile)?



Given that LOADng can be viewed as a set of mandatory features
from the WG document along with, possibly, some optional
features, and since the WG document has all along been designed
for mobile networks, and to have certain scalability features, it
seems natural to continue with the WG document and to take
care for the needs of LOADng as well.

As a lot of people have mentioned, because DYMO and LOADng generally share the same mechanism, they won't have significant difference in performance. That's why I said we should begin with the one with more operational experience. 
Personally, I'm very careful when making assessment. When I'm saying LOADng has scalability features, and can have interoperable implementations, there is running code to prove that.
I think it's the "running code",  which is believed in IETF, am I wrong? So if I need to choose between the "running code", and "some optional features that are not verified", my choice is quite clear, especially for a standard track protocol. 




Note: I'm not saying taking one and abandoning the other. We just need to take the one with better shape to begin with, and integrate ideas from the other one based on WG consensus.

Well, after recent efforts I think the WG document is really
in pretty good shape.   In the near future, I'll try to suggest some
various points where the LOADng document should be moved
closer to where the WG document is now -- I hope to do this
before Christmas.

I'm aware that there are some issues still need to addressed for LOADng, and there are still a lot of tickets under active discussion in the LOADng bugtracker. Any comments that can be helpful to improve the existed tickets, or new issues of LOADng, are welcome. 

best

Jiazi

-- 
Regards,
Charlie P.

--Apple-Mail=_441E6746-716C-469A-9A74-AA05B7659831-- From yi.jiazi@gmail.com Tue Dec 11 03:51:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1E221F880B for ; Tue, 11 Dec 2012 03:51:51 -0800 (PST) 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=[AWL=-0.000, 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 eOLHp1k+021a for ; Tue, 11 Dec 2012 03:51:50 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 056C021F8809 for ; Tue, 11 Dec 2012 03:51:45 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so1664536bku.31 for ; Tue, 11 Dec 2012 03:51:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=jIy5/UanROgNmZlln+gZXzMjYhmAGG05Xpgp/iUXyek=; b=JvvlJ5csiyOhoe52SABgbjJYioySST6udfIfh6jVgkLaCJJSTSY19QfsJgrPuVSeS7 XS+7qpQ492ckMFiUsYGh2rKX4DINY8mvCSltW6nvfAu5KK0Q64Qnvd3WFj863MdcEZml Pylk37AXxzcD3VWGOwoxxI3vJrUjKxOTSCXtaSzfZqgwbrZ3iGimVLPMsOJwlVtsfqOA zhOVwPzOKaJrXjGgbNewPSArxGhZM0Dw04xZjD6CoGaNvIabXJAU8YI1XM/64dAjTS0I Gruh/X0U1ex5It5mj9jXJtkFXxo+97VMfJsIWIYwAdkvg5fibNNodDgBG3G8lwmrIU+j TSbA== Received: by 10.204.149.88 with SMTP id s24mr6291355bkv.14.1355226705090; Tue, 11 Dec 2012 03:51:45 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id c10sm16697693bkw.1.2012.12.11.03.51.43 (version=SSLv3 cipher=OTHER); Tue, 11 Dec 2012 03:51:44 -0800 (PST) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_CAD4E29A-66B9-4630-8021-040B8B37B1FD" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi YI In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77230F7F23@xmb-rcd-x02.cisco.com> Date: Tue, 11 Dec 2012 12:51:43 +0100 Message-Id: <9C6CFA99-9FC7-4838-9309-804183B2B291@jiaziyi.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F23@xmb-rcd-x02.cisco.com> To: JP Vasseur (jvasseur) X-Mailer: Apple Mail (2.1499) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 11:51:53 -0000 --Apple-Mail=_CAD4E29A-66B9-4630-8021-040B8B37B1FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi JP, On Dec 11, 2012, at 3:15 AM, JP Vasseur (jvasseur) = wrote: > don't you have the impression that we go into circles at the risk of = having the same discussion that we had 3 months ago ? That's what I'm afraid of. That's why LOADng authors are relatively = quiet in the last several months after the IETF meeting, as the WG = chairs suggested, to wait for a response about how to go forward.=20 However, there is comment to LOADng authors on this issue (and be blamed = for not willing to discuss) now, I think we should reply, no? I would like some advices from WG chairs, to avoid having the same = discussion again. Because the situation is generally the same with 3 = months ago.=20 best Jiazi >=20 > On Dec 10, 2012, at 3:02 PM, Jiazi YI wrote: >=20 >> Hi,=20 >>=20 >> Given the fact that DYMO is moving closer and closer to LOADng (the = modular approach, handling of RREP, sequence numbers, handling of RERRs, = etc...), I feel that we have already consensus on those general design = issues.=20 >>=20 >> The next question is which is the one we should begin with. For me, = it's nature to start with the one with more operational experiences and = running code.=20 >>=20 >> Note: I'm not saying taking one and abandoning the other. We just = need to take the one with better shape to begin with, and integrate = ideas from the other one based on WG consensus.=20 >>=20 >> best >>=20 >> Jiazi >>=20 >>=20 >> On Dec 10, 2012, at 7:08 PM, "Dearlove, Christopher (UK)" = wrote: >>=20 >>> Stan Ratliff (sratliff) >>>> It wasn't clear to me what the consensus was in Atlanta vis-a-vis = the two reactive protocol documents. >>>=20 >>> It was clear to me that there was no consensus. Except that = abandoning the work item was not favoured. >>> But I also don't believe that the meeting was offered any = opportunity to either make that clear or show me >>> I was wrong in that assessment. >>>=20 >>>> There are people advocating for DYMO, others advocating for LOADng, = and some that want to "merge" >>>> the technology of the two together. >>>=20 >>> I would like to point out that my proposal, which I believe would = have been the best to adopt then, >>> doesn't neatly fit in any of those three categories. >>>=20 >>>=20 >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ******************************************************************** >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail=_CAD4E29A-66B9-4630-8021-040B8B37B1FD Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Hi JP,


On Dec 11, 2012, at 3:15 AM, JP Vasseur (jvasseur) <jvasseur@cisco.com> wrote:

don't you have the impression that we go into circles at the risk of having the same discussion that we had 3 months ago ?


That's what I'm afraid of. That's why LOADng authors are relatively quiet in the last several months after the IETF meeting, as the WG chairs suggested, to wait for a response about how to go forward. 
However, there is comment to LOADng authors on this issue (and be blamed for not willing to discuss) now, I think we should reply, no?

I would like some advices from WG chairs, to avoid having the same discussion again. Because the situation is generally the same with 3 months ago. 

best

Jiazi



On Dec 10, 2012, at 3:02 PM, Jiazi YI wrote:

Hi, 

Given the fact that DYMO is moving closer and closer to LOADng (the modular approach, handling of RREP, sequence numbers, handling of RERRs, etc...), I feel that we have already consensus on those general design issues. 

The next question is which is the one we should begin with. For me, it's nature to start with the one with more operational experiences and running code. 

Note: I'm not saying taking one and abandoning the other. We just need to take the one with better shape to begin with, and integrate ideas from the other one based on WG consensus. 

best

Jiazi


On Dec 10, 2012, at 7:08 PM, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> wrote:

Stan Ratliff (sratliff) <sratliff@cisco.com>
It wasn't clear to me what the consensus was in Atlanta vis-a-vis the two reactive protocol documents.

It was clear to me that there was no consensus. Except that abandoning the work item was not favoured.
But I also don't believe that the meeting was offered any opportunity to either make that clear or show me
I was wrong in that assessment.

There are people advocating for DYMO, others advocating for LOADng, and some that want to "merge"
the technology of the two together.

I would like to point out that my proposal, which I believe would have been the best to adopt then,
doesn't neatly fit in any of those three categories.


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

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

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


--Apple-Mail=_CAD4E29A-66B9-4630-8021-040B8B37B1FD-- From c.chauvenet@watteco.com Tue Dec 11 04:37:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1EA121F847B for ; Tue, 11 Dec 2012 04:37:32 -0800 (PST) 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 gSZh0pP-84zv for ; Tue, 11 Dec 2012 04:37:32 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id CDF6421F8475 for ; Tue, 11 Dec 2012 04:37:31 -0800 (PST) Received: from mail191-co1-R.bigfish.com (10.243.78.240) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.23; Tue, 11 Dec 2012 12:37:30 +0000 Received: from mail191-co1 (localhost [127.0.0.1]) by mail191-co1-R.bigfish.com (Postfix) with ESMTP id 9D8CBB8013B; Tue, 11 Dec 2012 12:37:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT003.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI98dI9371Ic89bh15bfK1102Ic85dhzz1de0h1202h1e76h1d1ah1d2ahzz1033IL18c673h8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail191-co1 (localhost.localdomain [127.0.0.1]) by mail191-co1 (MessageSwitch) id 135522944734859_32286; Tue, 11 Dec 2012 12:37:27 +0000 (UTC) Received: from CO1EHSMHS010.bigfish.com (unknown [10.243.78.231]) by mail191-co1.bigfish.com (Postfix) with ESMTP id EE2B38006A; Tue, 11 Dec 2012 12:37:26 +0000 (UTC) Received: from DBXPRD0510HT003.eurprd05.prod.outlook.com (157.56.252.165) by CO1EHSMHS010.bigfish.com (10.243.66.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 11 Dec 2012 12:37:26 +0000 Received: from DBXPRD0510MB359.eurprd05.prod.outlook.com ([169.254.8.205]) by DBXPRD0510HT003.eurprd05.prod.outlook.com ([10.255.67.166]) with mapi id 14.16.0245.002; Tue, 11 Dec 2012 12:37:25 +0000 From: C Chauvenet To: Jiazi YI Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN1ypur5BhbOs9hESr7C5QZLEj7JgTJLsAgABPCYCAABZcAA== Date: Tue, 11 Dec 2012 12:37:24 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D223C9D14@DBXPRD0510MB359.eurprd05.prod.outlook.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <50C6D3E4.1010105@computer.org> <2DE09B23-0544-4436-87D2-F266B9338A4E@jiaziyi.com> In-Reply-To: <2DE09B23-0544-4436-87D2-F266B9338A4E@jiaziyi.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.42.4] Content-Type: multipart/alternative; boundary="_000_97B69B30E0EF244B940B65EA541E3F2D223C9D14DBXPRD0510MB359_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "manet@ietf.org List" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 12:37:33 -0000 --_000_97B69B30E0EF244B940B65EA541E3F2D223C9D14DBXPRD0510MB359_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, See inline. Le 11 d=E9c. 2012 =E0 12:17, Jiazi YI a =E9crit : Hi Charlie, On Dec 11, 2012, at 7:34 AM, Charles E. Perkins > wrote: Hello Jiazi, On 12/10/2012 3:02 PM, Jiazi YI wrote: Given the fact that DYMO is moving closer and closer to LOADng (the modular= approach, handling of RREP, sequence numbers, handling of RERRs, etc...), = I feel that we have already consensus on those general design issues. I find this to be an unusual comment, since the explicit goal was to be inclusive and compatible with LOADng. Moreover, I have for a long time been pointing out that it would not be difficult to produce this compatibility. I didn't find any controversial between what you said (the *goal*) and what= I mentioned (the *result*). I think to be *compatible* with LOADng, the fact is that DYMO is getting mo= re closer to LOADng. I made a small list after comparing dymo-21 and dymo-2= 4, it's not hard to have this conclusion. In the meantime, even dymo and LOADng are having the similar approaches, as= one who participated in most interop events of LOADng, I find it's hard to= have dymo compatible with LOADng, without significant changes of DYMO (pac= ket format, flags, message processing...) The next question is which is the one we should begin with. For me, it's na= ture to start with the one with more operational experiences and running co= de. As I understand it, most of the operational experience was with non-mobile networks. I guess there has been some more recent work with mobile networks? I have to say, I didn't mention which one is the protocol that has more ope= rational experiences and running code. Because I'm only familiar with the s= ituation of LOADng (interop events, large implementation, etc...) I believe when you are saying above, you admit that LOADng is having more o= perational experiences? Or can you share some of dymo (either non-mobile, o= r mobile)? Given that LOADng can be viewed as a set of mandatory features from the WG document along with, possibly, some optional features, and since the WG document has all along been designed for mobile networks, and to have certain scalability features, it seems natural to continue with the WG document and to take care for the needs of LOADng as well. As a lot of people have mentioned, because DYMO and LOADng generally share = the same mechanism, they won't have significant difference in performance. = That's why I said we should begin with the one with more operational experi= ence. Personally, I'm very careful when making assessment. When I'm saying LOADng= has scalability features, and can have interoperable implementations, ther= e is running code to prove that. I think it's the "running code", which is believed in IETF, am I wrong? So= if I need to choose between the "running code", and "some optional feature= s that are not verified", my choice is quite clear, especially for a standa= rd track protocol. I guess that was the point of charlie above : if there was some other exper= iences than the PLC deployment *mentioned* on this list (no publication or = official material was shared about it). If "running code" is a good metric (chairs may have an opinion on how much = "running code" is needed for a standard track), then the WG should be aware= of existing deployments, for both protocols. For now, I can just count 1 d= eployment of LOADng, and did not see material yet on an DYMO/AODVv2 deploym= ent. Charlie, do you have some or I missed something ? If there are some confidentiality or restriction around theses deployments = and no material can be provide or share, then it seems hard to rely on this= parameter... My opinion is that such a parameter is fairly hard to evaluate because peop= le don't want to share so much on their secret sauce, so we may end up with= some pieces of informations that are hard to evaluate. Best, C=E9dric. Note: I'm not saying taking one and abandoning the other. We just need to t= ake the one with better shape to begin with, and integrate ideas from the o= ther one based on WG consensus. Well, after recent efforts I think the WG document is really in pretty good shape. In the near future, I'll try to suggest some various points where the LOADng document should be moved closer to where the WG document is now -- I hope to do this before Christmas. I'm aware that there are some issues still need to addressed for LOADng, an= d there are still a lot of tickets under active discussion in the LOADng bu= gtracker. Any comments that can be helpful to improve the existed tickets, = or new issues of LOADng, are welcome. best Jiazi -- Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_97B69B30E0EF244B940B65EA541E3F2D223C9D14DBXPRD0510MB359_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <22BC5467A423F747BEBE75618B7B883C@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi, 

See inline.

Le 11 d=E9c. 2012 =E0 12:17, Jiazi YI a =E9crit :

Hi Charlie, 


On Dec 11, 2012, at 7:34 AM, Charles E. Perkins <charliep@computer.org> wrote:


Hello Jiazi,

On 12/10/2012 3:02 PM, Jiazi YI wrote:

Given the fact that DYMO is moving closer and closer to LOADng (the modular appr= oach, handling of RREP, sequence numbers, handling of RERRs, etc...), I fee= l that we have already consensus on those general design issues.

I find this to be an unusual comment, since the explicit goal was
to be inclusive and compatible with LOADng.  Moreover, I have for
a long time been pointing out that it would not be difficult to produce
this compatibility.

I didn't find any controversial between what you said (the *goal*) and= what I mentioned (the *result*). 
I think to be *compatible* with LOADng, the fact is that DYMO is getti= ng more closer to LOADng. I made a small list after comparing dymo-21 and d= ymo-24, it's not hard to have this conclusion. 
In the meantime, even dymo and LOADng are having the similar approache= s, as one who participated in most interop events of LOADng, I find it's ha= rd to have dymo compatible with LOADng, without significant changes of DYMO= (packet format, flags, message processing...)




The next question is which is the one we should begin with. For me, it's natur= e to start with the one with more operational experiences and running code.=


As I understand it, most of the operational experience was with
non-mobile networks.   I guess there has been some more recent work with mobile networks?

I have to say, I didn't mention which one is the protocol that has mor= e operational experiences and running code. Because I'm only familiar with = the situation of LOADng (interop events, large implementation, etc...)
I believe when you are saying above, you admit that LOADng is having m= ore operational experiences? Or can you share some of dymo (either non-mobi= le, or mobile)?



Given that LOADng can be viewed as a set of mandatory features
from the WG document along with, possibly, some optional
features, and since the WG document has all along been designed
for mobile networks, and to have certain scalability features, it
seems natural to continue with the WG document and to take
care for the needs of LOADng as well.

As a lot of people have mentioned, because DYMO and LOADng generally s= hare the same mechanism, they won't have significant difference in performa= nce. That's why I said we should begin with the one with more operational e= xperience. 
Personally, I'm very careful when making assessment. When I'm saying L= OADng has scalability features, and can have interoperable implementations,= there is running code to prove that.
I think it's the "running code",  which is believed in = IETF, am I wrong? So if I need to choose between the "running code&quo= t;, and "some optional features that are not verified", my choice= is quite clear, especially for a standard track protocol. 

I guess that was the point of charlie above : if there was some other = experiences than the PLC deployment *mentioned* on this list (no publicatio= n or official material was shared about it).

If "running code" is a good metric (chairs may have an opini= on on how much "running code" is needed for a standard track), th= en the WG should be aware of existing deployments, for both protocols. For = now, I can just count 1 deployment of LOADng, and did not see material yet on an DYMO/AODVv2 deployment. Charlie, do you have so= me or I missed something ?
If there are some confidentiality or restriction around theses deploym= ents and no material can be provide or share, then it seems hard to rely on= this parameter...

My opinion is that such a parameter is fairly hard to evaluate because= people don't want to share so much on their secret sauce, so we may end up= with some pieces of informations that are hard to evaluate. 

Best,

C=E9dric.





Note: I'm not saying taking one and abandoning the other. We just need to take t= he one with better shape to begin with, and integrate ideas from the other = one based on WG consensus.

Well, after recent efforts I think the WG document is really
in pretty good shape.   In the near future, I'll try to suggest s= ome
various points where the LOADng document should be moved
closer to where the WG document is now -- I hope to do this
before Christmas.

I'm aware that there are some issues still need to addressed for LOADn= g, and there are still a lot of tickets under active discussion in the LOAD= ng bugtracker. Any comments that can be helpful to improve the existed tick= ets, or new issues of LOADng, are welcome. 

best

Jiazi

--=20
Regards,
Charlie P.

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

--_000_97B69B30E0EF244B940B65EA541E3F2D223C9D14DBXPRD0510MB359_-- From abdussalambaryun@gmail.com Tue Dec 11 05:56:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D6321F87EA for ; Tue, 11 Dec 2012 05:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 GCLatevjtJIq for ; Tue, 11 Dec 2012 05:56:36 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3885621F879F for ; Tue, 11 Dec 2012 05:56:36 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so4020378vcb.31 for ; Tue, 11 Dec 2012 05:56:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zc1uMg2tPuV/8/DB/VYIEPvjAUzEt1dadTbsod40B/A=; b=ogllVs/MlhJgMDXuReSC0I47EbGrzbLxnX/mXApmE+TREGiiDvw6KpURL4nmA3XFJ7 nloFtGx7Eli7vZNnc6QwZ7XULQsgPQQIOKS+232Cqe2yyMpjciKc49AyBwwF4dlmeDLH gEgdyKhLrsl1e8q0UYCMHXZ26JuBg0mKJSY7Q1OBKbzsWOJHCsCK5y7gS/tVFTyzw0YT Oha66wAVphsUF/3sfcbGGxrFOeNe0wsWwWfJRDHQLzKlPBmN5Z4UGGXD/Mzx5unEPB26 OGa/ag+mFndnzPpSll1nmeQ2VUQKxdxIqq2gkGYd1UarvAtixjX8pBySyjQXbFLEuXMm KllQ== MIME-Version: 1.0 Received: by 10.220.115.20 with SMTP id g20mr11054901vcq.31.1355234193048; Tue, 11 Dec 2012 05:56:33 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 11 Dec 2012 05:56:32 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> Date: Tue, 11 Dec 2012 14:56:32 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 13:56:37 -0000 Hi Stan, I thank you for the explaination because we need that from time to time to understand how the discussion will go forward without waste of efforts. Regarding the examples I will provide you when I got available time to report them. Regarding LOADng my questions are; 1) why there was a discussion off the list or off the meeting about removing the copyright of this proposing WG document. 2) Why the LOADng team didn't mention that while their proposal or does that mean that we have no right to update the document if we adopt it. 3) Is it possible for the document to mention a section of such authors rights and rights of the WG that are applied by the document, because if we just accept to remove copyright what does that mean (I think it means accepts me without clear rights)? 4) will this copyright issue affect the choose of the WG participants regarding DYMO or LOADng as I think the DYMO did not remove copyrights to IETF-WG? Finally, now I understand the position of the WG regarding the future WG discussions about reactive protocol. Thanking you. AB On 12/10/12, Stan Ratliff (sratliff) wrote: > Abdussalam, > > On Dec 10, 2012, at 5:51 AM, Abdussalam Baryun wrote: > >> On 12/7/12, Stan Ratliff (sratliff) wrote: >>> >>> My feeling, FWIW, is that ingress/egress SHOULD be a part of the base >>> document. However, I understand the concerns of people that say it migh= t >>> be >>> a problem (or extend ratification time, etc etc). So, I'm interested in >>> hearing other, interested opinions - both for >>> DYMO/AODVv2/Whatever-we're-calling-it-this-week, as well as with regard >>> to >>> the LOADng spec. >> >> I know from my efforts that LOADng team are not welling to discuss, or >> reply to questions/comments, so I want to know your opinion of the >> status on this LOADng draft as you brought it to the list; Is it a WG >> draft? should we discuss individual or private work now? >> >> I remember that we answered chair questions and options given. Not >> sure what the chair of WG wants us to do so far, please advise, > > It wasn't clear to me what the consensus was in Atlanta vis-a-vis the two > reactive protocol documents. Presently, DYMO is the working group accepte= d > reactive protocol document. However, there was a 2-year period of time wh= en > DYMO was inactive, and the document was "parked". As a result of that, th= e > effort to create LOADng sprang up. > > So now, we have two documents to consider. In the charter, the WG is "on = the > hook" for 1 (and only 1) reactive protocol. So the current options are: > 1. Recognize that we cannot reach consensus with the two documents, and > remove the charter item for reactive protocols. To be frank, this is my > preferred option. > 2. Accept one of the two documents (either LOADng or DYMO), and press > forward > 3. Perhaps alter the charter item, and produce 2 reactive protocols, both= in > "experimental" state. > > Now, you mentioned "Not sure what the chairs of WG want us to do so far"= =85. > the best answer I can give you on that is "reach consensus on an approach= ". > We as a working group haven't done that yet. There are people advocating = for > DYMO, others advocating for LOADng, and some that want to "merge" the > technology of the two together. A "merge" was something we tried in the > Vancouver timeframe, but that effort failed. > > As to your statement that the LOADng team is not willing to discuss - I > haven't seen that, do not agree with it, and would ask you to cite > *specific* examples if you have them. I've found the LOADng team to be > reasonable in their dealings with the WG. There is the issue of re-spinni= ng > the LOADng document without the copyright statement - The LOADng authors = and > the chairs have reached an understanding about that issue, so I no longer > have a problem with moving forward on that front. > > Again, as a working group - we *MUST* either reach a consensus, or the wo= rk > item will be removed *for us*. If we do not show progress towards a goal,= it > is within the power of the IESG to stop work on the issue. > > Regards, > Stan > > >> >> AB >> >>> >>> And lastly=85.. if the 5 guys were *that* important, they most likely >>> wouldn't >>> be *playing* black-ops=85 ;-) >>> >>> Stan >>> >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From jvasseur@cisco.com Tue Dec 11 06:25:27 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E151421F8776 for ; Tue, 11 Dec 2012 06:25:27 -0800 (PST) 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 wcknj7Qrdkde for ; Tue, 11 Dec 2012 06:25:26 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B5EDF21F8746 for ; Tue, 11 Dec 2012 06:25:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4206; q=dns/txt; s=iport; t=1355235926; x=1356445526; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=20OqAWwUqoY4J8xMRrnTxCQfnKDYfQSZBQLPh/k+mMg=; b=dhIB48ZUNQRCA1YH21KMlBM5+I4vuMjWssTNxfdcEiEzkOQ50wgKdokI PdzN+h2iveEANbs90xDb3k86wNzKfgs+484MealK0z5Othft4m1bkZYcg 2OKJOfde2Y7zYYSX8WzZqRCunKLr3KAw6qDfLjEgJJow/bFDzvTHlD6xF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAK5Bx1CtJV2a/2dsb2JhbABFvkQWc4IeAQEBAwEBAQFSGQsFBwQCAQgRBAEBAQodBycLFAkIAgQOBQgTh3AGDKpGkGiMSgsKg01hA4grjniPLIJzgWQJFx4 X-IronPort-AV: E=McAfee;i="5400,1158,6922"; a="151450479" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 11 Dec 2012 14:25:26 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBBEPQmR004374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Dec 2012 14:25:26 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.93]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 11 Dec 2012 08:25:25 -0600 From: "JP Vasseur (jvasseur)" To: Thomas Heide Clausen Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-24.txt Thread-Index: AQHNz3PdizJJy8YTn0ujf7TOKm3zcQ== Date: Tue, 11 Dec 2012 14:25:25 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77230FB63A@xmb-rcd-x02.cisco.com> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF09E53@xmb-aln-x03.cisco.com> <50C11C77.8020400@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF13166@xmb-aln-x03.cisco.com> <50C2404E.5080803@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF16BF5@xmb-aln-x03.cisco.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> <2F9893ED-21B4-42A3-B3AE-37124BCA4B17@inf-net.nl> <50C6605C.2070306@computer.org> <50C6DB95.50 609@fkie.fraunhofer.de> <771DECBD-7746-4435-8B92-CD8FA32E9133@thomasclausen.org> In-Reply-To: <771DECBD-7746-4435-8B92-CD8FA32E9133@thomasclausen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.80.48] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <091F13A55A1D7646BA5BB77DD91C9A5B@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 14:25:28 -0000 On Dec 11, 2012, at 3:22 AM, Thomas Heide Clausen wrote: > The issue (discussed at length at [HOMENE]) is source address selection i= n case of a multi-homed (MA)NETwork - and, as Henning says, also NAT state = (if used). >=20 > Personally, I believe that this is not a MANET-specific issue, and that w= e should try to look to [HOMENET] to understand if their cognitions are not= simply generally applicable. >=20 Yes I completely agree. > Thomas >=20 > Sent from my iPad >=20 > On 11 d=E9c. 2012, at 11:05, "Dearlove, Christopher (UK)" wrote: >=20 >> There is a generic solution - just route to nearest gateway. If you thin= k gateway constancy is important, it appears that a modified protocol (whic= h my interest was in understanding, and understanding compatibility of, no = more at this time) is possible and consistent with OLSRv2. But in neither c= ase is 0.0.0.0/0 special. And in neither case (especially not the OLSRv2 de= fault, which is already specified) is whatever AODVv2 chooses to do relevan= t. >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f Henning Rogge >> Sent: 11 December 2012 07:07 >> To: manet@ietf.org >> Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt >>=20 >> On 12/10/2012 11:21 PM, Charles E. Perkins wrote: >>>> You can indicate the entire Internet with 0.0.0.0/0, as previously >>>> described (I think by Henning). Nothing special. >>>=20 >>> Maybe the notation isn't very special, but the functionality is. >>=20 >> I disagree on this point. While the /0 prefx is the largest prefix >> possible, you can have the same trouble with overlapping prefixes and >> missed smaller prefixes (including host-routes) with smaller ones. >>=20 >>> It isn't even even certain that IP-within-IP (or even tunneling at >>> all) is the best solution. Of course it can be made to work. >>=20 >> Tunneling should not be necessary to support prefixes. We only=20 >> integrated it in the olsr.org code because our NORMAL usecase is=20 >> multiple gateways (each using NAT) announcing a 0.0.0.0/0 prefix. >>=20 >> Is there a reason why you think that your strategy for the "internet=20 >> uplink" will not work with other kinds of prefixes? I don't like the=20 >> idea to include a hack for a special case when we already see that=20 >> people will ask about a generic solution. >>=20 >> Henning Rogge >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >>=20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From dyoung@pixotech.com Tue Dec 11 07:49:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A282921F8477 for ; Tue, 11 Dec 2012 07:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 vNn1LQ1c+Fmw for ; Tue, 11 Dec 2012 07:49:31 -0800 (PST) Received: from elmendorf.ojctech.com (elmendorf.ojctech.com [IPv6:2002:4cbf:1101:1:20e:cff:febc:8cc]) by ietfa.amsl.com (Postfix) with ESMTP id F183921F8473 for ; Tue, 11 Dec 2012 07:49:30 -0800 (PST) Received: by elmendorf.ojctech.com (Postfix, from userid 1000) id 8D3FA1BF3CA; Tue, 11 Dec 2012 09:49:22 -0600 (CST) Date: Tue, 11 Dec 2012 09:49:22 -0600 From: David Young To: manet@ietf.org Message-ID: <20121211154922.GQ17551@pixotech.com> Mail-Followup-To: manet@ietf.org References: <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> <2F9893ED-21B4-42A3-B3AE-37124BCA4B17@inf-net.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F9893ED-21B4-42A3-B3AE-37124BCA4B17@inf-net.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [manet] multiple gateway protocols (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 15:49:31 -0000 On Mon, Dec 10, 2012 at 10:56:23PM +0100, Teco Boot wrote: > Next step is to set up a routing policy, based on conntrack. Having > such, we can pin connections to a tunnel. This sounds like the multiple-gateways software we developed for the local community wireless network with the help of a graduate student and the Google Summer of Code. It sounds like you are pretty far along, but just in case it is helpful, the student wrote his M.S. thesis on the topic: Earnhart, Michael Jeffery. "A multiple gateway protocol for wireless mesh networks." University of Illinois at Urbana-Champaign, 2007. Dave -- David Young dyoung@pobox.com Urbana, IL (217) 721-9981 From sratliff@cisco.com Tue Dec 11 11:03:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F8221F87C7 for ; Tue, 11 Dec 2012 11:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.469 X-Spam-Level: X-Spam-Status: No, score=-10.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 VYRY0iqwEWae for ; Tue, 11 Dec 2012 11:03:48 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id DD57E21F8778 for ; Tue, 11 Dec 2012 11:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4801; q=dns/txt; s=iport; t=1355252628; x=1356462228; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XWm11+sR30Q2fXsPiY1y0cDuySrO77Gf0RIhHExJEeM=; b=kcPTrgckKXctvel/OmbKXidnMTEnH1JcIg0QvAxE0IJbxlcCwPbbKMtE 1+ap/tShXjJH32LiVHqH/klvaVM0ApYbs5yif/3sVVtX37Cp5lxmYrStW tSArdxWy+9PIfk2X/MaRwkNW3JPvskgvdWsWCQP1vrLCmj5vryY5t3c0m 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD6Dx1CtJXG+/2dsb2JhbABEvkUWc4IeAQEBAwEBAQFrCwULAgEIGAokJwslAgQOBQgRh3IGDKsYkFIEjEocg0ZhA6ZPgnOCIg X-IronPort-AV: E=McAfee;i="5400,1158,6923"; a="151803458" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 11 Dec 2012 19:03:47 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBBJ3lhc003271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Dec 2012 19:03:47 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.203]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Tue, 11 Dec 2012 13:03:47 -0600 From: "Stan Ratliff (sratliff)" To: "JP Vasseur (jvasseur)" Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN1sRQC9RIBD6Ww0Sj7f1Ne2/6upgShJYAgAC+fACAARh2gA== Date: Tue, 11 Dec 2012 19:03:45 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.116] Content-Type: text/plain; charset="Windows-1252" Content-ID: <051A360F7543C040AAA503B1BFF1EFE0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 19:03:49 -0000 JP,=20 On Dec 10, 2012, at 9:19 PM, JP Vasseur (jvasseur) wrote: > Hi Stan, >=20 > On Dec 10, 2012, at 6:58 AM, Stan Ratliff (sratliff) wrote: >=20 >> Abdussalam,=20 >>=20 >> On Dec 10, 2012, at 5:51 AM, Abdussalam Baryun wrote: >>=20 >>> On 12/7/12, Stan Ratliff (sratliff) wrote: >>>>=20 >>>> My feeling, FWIW, is that ingress/egress SHOULD be a part of the base >>>> document. However, I understand the concerns of people that say it mig= ht be >>>> a problem (or extend ratification time, etc etc). So, I'm interested i= n >>>> hearing other, interested opinions - both for >>>> DYMO/AODVv2/Whatever-we're-calling-it-this-week, as well as with regar= d to >>>> the LOADng spec. >>>=20 >>> I know from my efforts that LOADng team are not welling to discuss, or >>> reply to questions/comments, so I want to know your opinion of the >>> status on this LOADng draft as you brought it to the list; Is it a WG >>> draft? should we discuss individual or private work now? >>>=20 >>> I remember that we answered chair questions and options given. Not >>> sure what the chair of WG wants us to do so far, please advise, >>=20 >> It wasn't clear to me what the consensus was in Atlanta vis-a-vis the tw= o reactive protocol documents. Presently, DYMO is the working group accepte= d reactive protocol document. However, there was a 2-year period of time wh= en DYMO was inactive, and the document was "parked". As a result of that, t= he effort to create LOADng sprang up.=20 >>=20 >> So now, we have two documents to consider. In the charter, the WG is "on= the hook" for 1 (and only 1) reactive protocol. So the current options are= :=20 >> 1. Recognize that we cannot reach consensus with the two documents, and = remove the charter item for reactive protocols. To be frank, this is my pre= ferred option.=20 >> 2. Accept one of the two documents (either LOADng or DYMO), and press fo= rward >> 3. Perhaps alter the charter item, and produce 2 reactive protocols, bot= h in "experimental" state.=20 >>=20 >=20 > JP> What about putting a hard dead-line and if there is no consensus fall= back to 1 ? There's only one problem with that - It's already happened, and the deadlin= e has already passed without conclusion=85 ;-) It happened in Vancouver, w= ith a deadline of Atlanta.=20 To the working group at large -=20 I'm not seeing a high level of interest here. People seem to only have "pas= sing interest" - enough to keep the efforts on life support, but not enough= to really progress things. By and large, only the authors have the inclina= tion to push their respective opinions, and nothing has really changed.=20 So, I call once again - I think it's time to remove the work item from the = charter, and recognize that we're not going to be able to work together on = this issue. After more than a year of trying to get people to work together= to make the technology better, just don't see it happening. It's time to = end the misery. Regards, Stan >=20 >> Now, you mentioned "Not sure what the chairs of WG want us to do so far"= =85. the best answer I can give you on that is "reach consensus on an appro= ach". We as a working group haven't done that yet. There are people advoca= ting for DYMO, others advocating for LOADng, and some that want to "merge" = the technology of the two together. A "merge" was something we tried in the= Vancouver timeframe, but that effort failed.=20 >>=20 >> As to your statement that the LOADng team is not willing to discuss - I = haven't seen that, do not agree with it, and would ask you to cite *specifi= c* examples if you have them. I've found the LOADng team to be reasonable i= n their dealings with the WG. There is the issue of re-spinning the LOADng = document without the copyright statement - The LOADng authors and the chair= s have reached an understanding about that issue, so I no longer have a pro= blem with moving forward on that front.=20 >>=20 >> Again, as a working group - we *MUST* either reach a consensus, or the w= ork item will be removed *for us*. If we do not show progress towards a goa= l, it is within the power of the IESG to stop work on the issue. >>=20 >> Regards, >> Stan >>=20 >>=20 >>>=20 >>> AB >>>=20 >>>>=20 >>>> And lastly=85.. if the 5 guys were *that* important, they most likely = wouldn't >>>> be *playing* black-ops=85 ;-) >>>>=20 >>>> Stan >>>>=20 >>>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From sratliff@cisco.com Tue Dec 11 11:17:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE6721F859F for ; Tue, 11 Dec 2012 11:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.487 X-Spam-Level: X-Spam-Status: No, score=-10.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 Is70rzTov7UQ for ; Tue, 11 Dec 2012 11:17:03 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B6E1C21F8597 for ; Tue, 11 Dec 2012 11:16:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5493; q=dns/txt; s=iport; t=1355253423; x=1356463023; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ObPU1Km1SRdqoshgniVMfXNuzVba0bhh6Z8UjSNGZLA=; b=D+ZV8dCdyVpu1g8wWJzhsoUyTt/s4qCve6DpmvTfDNYNtfbrMI+f1aiw g/PApW7Z+NXUFatiYssFt822a+ezZSm9M/GIR0R/XuSa5xGbNnu19KyPX g+QBw1loXBn93VKg/ZRFr9PQJKjRxfmCHnZn1PFilz6bBSaaFBR79addF s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADaFx1CtJV2d/2dsb2JhbABEvk4Wc4IeAQEBAwEBAQFrCwULAgEIGAokJwslAgQOBQiIAwYMqxSQUQSMSgsRg0ZhA6ZPgnOBbTU X-IronPort-AV: E=McAfee;i="5400,1158,6923"; a="151808751" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 11 Dec 2012 19:16:55 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBBJGtlK027791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Dec 2012 19:16:55 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.203]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 11 Dec 2012 13:16:54 -0600 From: "Stan Ratliff (sratliff)" To: Abdussalam Baryun Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN1sRQC9RIBD6Ww0Sj7f1Ne2/6upgShJYAgAGBHQCAAFmCAA== Date: Tue, 11 Dec 2012 19:16:54 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BCFC@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.116] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4AD3A494059C84429ED1F8C5ECA3659D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 19:17:04 -0000 Abdussalam,=20 So, it would appear to me that your concerns are summed up with the copyrig= ht statement. Understood. It's not that the LOADng team was being unrespons= ive, there were other issues in play. Due to the nature of those issues, I = do not feel as though I should release any details - but IMHO, the LOADng a= uthors have acted with the utmost of professionalism throughout. I understa= nd the rationale for the current verbiage, and as far as I'm concerned, the= issue is closed - if the WG accepts LOAD as a working group document (see = my earlier email for my thoughts on that), the copyright will be removed. Regards, Stan On Dec 11, 2012, at 8:56 AM, Abdussalam Baryun wrote: > Hi Stan, >=20 > I thank you for the explaination because we need that from time to > time to understand how the discussion will go forward without waste of > efforts. Regarding the examples I will provide you when I got > available time to report them. Regarding LOADng my questions are; 1) > why there was a discussion off the list or off the meeting about > removing the copyright of this proposing WG document. 2) Why the > LOADng team didn't mention that while their proposal or does that mean > that we have no right to update the document if we adopt it. 3) Is it > possible for the document to mention a section of such authors rights > and rights of the WG that are applied by the document, because if we > just accept to remove copyright what does that mean (I think it means > accepts me without clear rights)? 4) will this copyright issue affect > the choose of the WG participants regarding DYMO or LOADng as I think > the DYMO did not remove copyrights to IETF-WG? >=20 > Finally, now I understand the position of the WG regarding the future > WG discussions about reactive protocol. Thanking you. >=20 > AB >=20 > On 12/10/12, Stan Ratliff (sratliff) wrote: >> Abdussalam, >>=20 >> On Dec 10, 2012, at 5:51 AM, Abdussalam Baryun wrote: >>=20 >>> On 12/7/12, Stan Ratliff (sratliff) wrote: >>>>=20 >>>> My feeling, FWIW, is that ingress/egress SHOULD be a part of the base >>>> document. However, I understand the concerns of people that say it mig= ht >>>> be >>>> a problem (or extend ratification time, etc etc). So, I'm interested i= n >>>> hearing other, interested opinions - both for >>>> DYMO/AODVv2/Whatever-we're-calling-it-this-week, as well as with regar= d >>>> to >>>> the LOADng spec. >>>=20 >>> I know from my efforts that LOADng team are not welling to discuss, or >>> reply to questions/comments, so I want to know your opinion of the >>> status on this LOADng draft as you brought it to the list; Is it a WG >>> draft? should we discuss individual or private work now? >>>=20 >>> I remember that we answered chair questions and options given. Not >>> sure what the chair of WG wants us to do so far, please advise, >>=20 >> It wasn't clear to me what the consensus was in Atlanta vis-a-vis the tw= o >> reactive protocol documents. Presently, DYMO is the working group accept= ed >> reactive protocol document. However, there was a 2-year period of time w= hen >> DYMO was inactive, and the document was "parked". As a result of that, t= he >> effort to create LOADng sprang up. >>=20 >> So now, we have two documents to consider. In the charter, the WG is "on= the >> hook" for 1 (and only 1) reactive protocol. So the current options are: >> 1. Recognize that we cannot reach consensus with the two documents, and >> remove the charter item for reactive protocols. To be frank, this is my >> preferred option. >> 2. Accept one of the two documents (either LOADng or DYMO), and press >> forward >> 3. Perhaps alter the charter item, and produce 2 reactive protocols, bot= h in >> "experimental" state. >>=20 >> Now, you mentioned "Not sure what the chairs of WG want us to do so far"= =85. >> the best answer I can give you on that is "reach consensus on an approac= h". >> We as a working group haven't done that yet. There are people advocating= for >> DYMO, others advocating for LOADng, and some that want to "merge" the >> technology of the two together. A "merge" was something we tried in the >> Vancouver timeframe, but that effort failed. >>=20 >> As to your statement that the LOADng team is not willing to discuss - I >> haven't seen that, do not agree with it, and would ask you to cite >> *specific* examples if you have them. I've found the LOADng team to be >> reasonable in their dealings with the WG. There is the issue of re-spinn= ing >> the LOADng document without the copyright statement - The LOADng authors= and >> the chairs have reached an understanding about that issue, so I no longe= r >> have a problem with moving forward on that front. >>=20 >> Again, as a working group - we *MUST* either reach a consensus, or the w= ork >> item will be removed *for us*. If we do not show progress towards a goal= , it >> is within the power of the IESG to stop work on the issue. >>=20 >> Regards, >> Stan >>=20 >>=20 >>>=20 >>> AB >>>=20 >>>>=20 >>>> And lastly=85.. if the 5 guys were *that* important, they most likely >>>> wouldn't >>>> be *playing* black-ops=85 ;-) >>>>=20 >>>> Stan >>>>=20 >>>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 From yi.jiazi@gmail.com Tue Dec 11 14:47:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF5421F8625 for ; Tue, 11 Dec 2012 14:47:47 -0800 (PST) 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 IgxFRwYK50oU for ; Tue, 11 Dec 2012 14:47:46 -0800 (PST) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id C7AF321F855A for ; Tue, 11 Dec 2012 14:47:43 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id r6so49wey.24 for ; Tue, 11 Dec 2012 14:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:subject:date:references:to:message-id :mime-version:x-mailer; bh=cyV3a4bWkRC3fENQ3p4EgDlPOOfpV1U4VUBL8oNHfJc=; b=Bjz35z5fDEpNdUtNItl3AAXQturxVFxthlHbQ1qf4nNJbT/VuMUAx1+lZS6F8zXtRO qzc4AAdLbHmThT2wFlimxkuEt6TYS05jLgG4VS7kYqGgy9R5YG87zG3mimPQtQXXR7MI qyDvhMfx7Yt/SFYwlHsGucEcAT2aJb9+6Fqf0H/RqRl6tbtuzHDK7ueFPqToFZvDJRWB tPDaFI9rPnReDtABvRxjQD7i7Hj/A7FsItf8GH9QC8jJ078NT4I0lu+f5zy3V0480FAG li5vVFJyW4Sfym9MT2MC/XPE71FLN4tuFdzbv0BBHj/5nRmXPTTvCEeEEhGPkGskZ7Z9 FTMw== Received: by 10.180.80.168 with SMTP id s8mr5331248wix.8.1355266062247; Tue, 11 Dec 2012 14:47:42 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id cf6sm18447774wib.3.2012.12.11.14.47.40 (version=SSLv3 cipher=OTHER); Tue, 11 Dec 2012 14:47:40 -0800 (PST) Sender: Jiazi YI From: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_47756C0E-E153-423B-AD9D-9C30AEB2E7CA" Date: Tue, 11 Dec 2012 23:47:35 +0100 References: <20121211212601.1963.72822.idtracker@ietfa.amsl.com> To: "manet@ietf.org List" Message-Id: <43919D7D-016D-4AC5-8BAA-A339487A5EC5@jiaziyi.com> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [manet] Fwd: New Version Notification for draft-lavenu-lln-loadng-interoperability-report-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 22:47:47 -0000 --Apple-Mail=_47756C0E-E153-423B-AD9D-9C30AEB2E7CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all,=20 A new revision of LOADng-interop report has been submitted.=20 The new revision documented the latest interop event in Vancouver, and = tested co-exist of multiple metric types in the network. Some = improvements are also proposed based on interop results.=20 best Jiazi Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-lavenu-lln-loadng-interoperability-report-04.txt > Date: December 11, 2012 10:26:01 PM GMT+01:00 > To: jiazi@jiaziyi.com > Cc: axel@axelcdv.com, t.clausen@computer.org, ulrich@herberg.name, = cedric-2.lavenu@edf.fr, hiroki.satoh.yj@hitachi.com, = yuichi.igarashi.hb@hitachi.com, alberto@albertocamacho.com, = yoko.morii.cs@hitachi.com >=20 >=20 > A new version of I-D, = draft-lavenu-lln-loadng-interoperability-report-04.txt > has been successfully submitted by Jiazi Yi and posted to the > IETF repository. >=20 > Filename: draft-lavenu-lln-loadng-interoperability-report > Revision: 04 > Title: Interoperability Report for the Lightweight = On-demand Ad hoc Distance- vector Routing Protocol - Next Generation = (LOADng) > Creation date: 2012-12-11 > WG ID: Individual Submission > Number of pages: 46 > URL: = http://www.ietf.org/internet-drafts/draft-lavenu-lln-loadng-interoperabili= ty-report-04.txt > Status: = http://datatracker.ietf.org/doc/draft-lavenu-lln-loadng-interoperability-r= eport > Htmlized: = http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-report= -04 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-lavenu-lln-loadng-interoperabilit= y-report-04 >=20 > Abstract: > This document reports experience with the LOADng routing protocol, = as > obtained by way of a number of interoperability tests during the > protocol development. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 --Apple-Mail=_47756C0E-E153-423B-AD9D-9C30AEB2E7CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all, 
A new = revision of LOADng-interop report has been = submitted. 
The new = revision documented the latest interop event in Vancouver, and tested = co-exist of multiple metric types in the network. Some improvements are = also proposed based on interop results. 
Jiazi


Begin forwarded message:

Subject: New Version Notification for = draft-lavenu-lln-loadng-interoperability-report-04.txt
Date: December 11, 2012 = 10:26:01 PM GMT+01:00
Cc: axel@axelcdv.com, t.clausen@computer.org, ulrich@herberg.name, cedric-2.lavenu@edf.fr, hiroki.satoh.yj@hitachi.com, yuichi.igarashi.hb@hitachi.= com, alberto@albertocamacho.com,= yoko.morii.cs@hitachi.com


A new version of I-D, = draft-lavenu-lln-loadng-interoperability-report-04.txt
has been = successfully submitted by Jiazi Yi and posted to the
IETF = repository.

Filename: = draft-lavenu-lln-loadng-interoperability-report
Revision: = 04
Title: = = Interoperability Report for the Lightweight On-demand Ad hoc = Distance- vector Routing Protocol - Next Generation (LOADng)
Creation = date: = 2012-12-11
WG ID: Individual Submission
Number = of pages: 46
URL: =             http://www.ietf.org/internet-drafts/draft-lavenu= -lln-loadng-interoperability-report-04.txt
Status: =          http://datatracker.ietf.org/doc/draft-lavenu-lln-loadng-int= eroperability-report
Htmlized: =        http://tools.ietf.org/html/draft-lavenu-lln-loadng-interopera= bility-report-04
Diff: =            http://www.ietf.org/rfcdiff?url2=3Ddraft-lavenu-lln-l= oadng-interoperability-report-04

Abstract:
=   This document reports experience with the LOADng routing = protocol, as
  obtained by way of a number of = interoperability tests during the
  protocol = development.




The IETF = Secretariat


= --Apple-Mail=_47756C0E-E153-423B-AD9D-9C30AEB2E7CA-- From axel-ietf@axelcdv.com Tue Dec 11 15:01:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2D121E808D for ; Tue, 11 Dec 2012 15:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] 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 KYZuMcZoccMh for ; Tue, 11 Dec 2012 15:01:33 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id B6C9A21E8039 for ; Tue, 11 Dec 2012 15:01:33 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 5BABCA6F4C for ; Tue, 11 Dec 2012 15:01:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9AC891C070D; Tue, 11 Dec 2012 15:01:28 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.1.1.200] (Cs-136-214.CS.UCLA.EDU [131.179.136.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 5A5C31C068A; Tue, 11 Dec 2012 15:01:28 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?windows-1252?Q?Axel_Colin_de_Verdi=E8re?= In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> Date: Tue, 11 Dec 2012 15:01:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3E873090-C8D3-4563-A7A4-331D2D599917@axelcdv.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1499) Cc: "" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 23:01:34 -0000 Hi Stan, Le 11 d=E9c. 2012 =E0 11:03, Stan Ratliff (sratliff) = a =E9crit : > JP,=20 >=20 > On Dec 10, 2012, at 9:19 PM, JP Vasseur (jvasseur) wrote: >=20 >> Hi Stan, >>=20 >> On Dec 10, 2012, at 6:58 AM, Stan Ratliff (sratliff) wrote: >>=20 >>> Abdussalam,=20 >>>=20 >>> On Dec 10, 2012, at 5:51 AM, Abdussalam Baryun wrote: >>>=20 >>>> On 12/7/12, Stan Ratliff (sratliff) wrote: >>>>>=20 >>>>> My feeling, FWIW, is that ingress/egress SHOULD be a part of the = base >>>>> document. However, I understand the concerns of people that say it = might be >>>>> a problem (or extend ratification time, etc etc). So, I'm = interested in >>>>> hearing other, interested opinions - both for >>>>> DYMO/AODVv2/Whatever-we're-calling-it-this-week, as well as with = regard to >>>>> the LOADng spec. >>>>=20 >>>> I know from my efforts that LOADng team are not welling to discuss, = or >>>> reply to questions/comments, so I want to know your opinion of the >>>> status on this LOADng draft as you brought it to the list; Is it a = WG >>>> draft? should we discuss individual or private work now? >>>>=20 >>>> I remember that we answered chair questions and options given. Not >>>> sure what the chair of WG wants us to do so far, please advise, >>>=20 >>> It wasn't clear to me what the consensus was in Atlanta vis-a-vis = the two reactive protocol documents. Presently, DYMO is the working = group accepted reactive protocol document. However, there was a 2-year = period of time when DYMO was inactive, and the document was "parked". As = a result of that, the effort to create LOADng sprang up.=20 >>>=20 >>> So now, we have two documents to consider. In the charter, the WG is = "on the hook" for 1 (and only 1) reactive protocol. So the current = options are:=20 >>> 1. Recognize that we cannot reach consensus with the two documents, = and remove the charter item for reactive protocols. To be frank, this is = my preferred option.=20 >>> 2. Accept one of the two documents (either LOADng or DYMO), and = press forward >>> 3. Perhaps alter the charter item, and produce 2 reactive protocols, = both in "experimental" state.=20 >>>=20 >>=20 >> JP> What about putting a hard dead-line and if there is no consensus = fall back to 1 ? >=20 > There's only one problem with that - It's already happened, and the = deadline has already passed without conclusion=85 ;-) It happened in = Vancouver, with a deadline of Atlanta.=20 >=20 > To the working group at large -=20 >=20 > I'm not seeing a high level of interest here. People seem to only have = "passing interest" - enough to keep the efforts on life support, but not = enough to really progress things. By and large, only the authors have = the inclination to push their respective opinions, and nothing has = really changed.=20 I'm a bit surprised here: it seems weird to me that you can just dismiss = a 10 people behind a document, with strong industrial support (including = actual deployments) as "passing", or even "not enough" interest. = Furthermore, I've seen that we (the LOADng authors) are far from the = only ones participating on this topic. >=20 > So, I call once again - I think it's time to remove the work item from = the charter, and recognize that we're not going to be able to work = together on this issue. After more than a year of trying to get people = to work together to make the technology better, just don't see it = happening. It's time to end the misery. I understand your position, I think you made that clear relatively early = in the process, but I don't think "not enough interest" is really a good = reason here. Best, Axel >=20 > Regards, > Stan >=20 >=20 >=20 >>=20 >>> Now, you mentioned "Not sure what the chairs of WG want us to do so = far"=85. the best answer I can give you on that is "reach consensus on = an approach". We as a working group haven't done that yet. There are = people advocating for DYMO, others advocating for LOADng, and some that = want to "merge" the technology of the two together. A "merge" was = something we tried in the Vancouver timeframe, but that effort failed.=20= >>>=20 >>> As to your statement that the LOADng team is not willing to discuss = - I haven't seen that, do not agree with it, and would ask you to cite = *specific* examples if you have them. I've found the LOADng team to be = reasonable in their dealings with the WG. There is the issue of = re-spinning the LOADng document without the copyright statement - The = LOADng authors and the chairs have reached an understanding about that = issue, so I no longer have a problem with moving forward on that front.=20= >>>=20 >>> Again, as a working group - we *MUST* either reach a consensus, or = the work item will be removed *for us*. If we do not show progress = towards a goal, it is within the power of the IESG to stop work on the = issue. >>>=20 >>> Regards, >>> Stan >>>=20 >>>=20 >>>>=20 >>>> AB >>>>=20 >>>>>=20 >>>>> And lastly=85.. if the 5 guys were *that* important, they most = likely wouldn't >>>>> be *playing* black-ops=85 ;-) >>>>>=20 >>>>> Stan >>>>>=20 >>>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Tue Dec 11 19:44:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EE121F87F5 for ; Tue, 11 Dec 2012 19:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 t1Fofpc6zDlg for ; Tue, 11 Dec 2012 19:44:53 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE1121F87FE for ; Tue, 11 Dec 2012 19:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17364; q=dns/txt; s=iport; t=1355283893; x=1356493493; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zihJNwMKDlsXsPDwV1EADE3bKsjelisR/X/ujtGh/GE=; b=CE2Pg0zvbSR3b7PjRECoXOSvFLwqC5XtspCPlVTfIFK7/zrZVXX+hCCk YnL5GHpkf8SM3Lhgx3oHbJVq7CNG6AsOgduIdaJs0dwKNftDq1thVDg8o eQlYF01lldP+eavzQ0KU5BuEZG7F00ux62gB6va2PUOzC1O/s7JR3ZFJo o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMP8x1CtJXG+/2dsb2JhbAA/Br5yFnOCHwEBBAEBAWsLEAIBCCIdBycLFBECBA4FCIgJDK1fjiMEjEolAoM7YQOIK54kgmYNgiI X-IronPort-AV: E=Sophos;i="4.84,264,1355097600"; d="scan'208,217";a="151945153" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 12 Dec 2012 03:44:53 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBC3iqwP001415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Dec 2012 03:44:52 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.93]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Tue, 11 Dec 2012 21:44:52 -0600 From: "JP Vasseur (jvasseur)" To: C Chauvenet Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN2BsLpyttk+PckkKXysBZyGQwmQ== Date: Wed, 12 Dec 2012 03:44:52 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77230FDDC0@xmb-rcd-x02.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <50C6D3E4.1010105@computer.org> <2DE09B23-0544-4436-87D2-F266B9338A4E@jiaziyi.com> <97B69B30E0EF244B940B65EA541E3F2D223C9D14@DBXPRD0510MB359.eurprd05.prod.outlook.com> In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D223C9D14@DBXPRD0510MB359.eurprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.115.9] Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77230FDDC0xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 03:44:55 -0000 --_000_03B78081B371D44390ED6E7BADBB4A77230FDDC0xmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Dec 11, 2012, at 4:37 AM, C Chauvenet wrote: Hi, See inline. Le 11 d=E9c. 2012 =E0 12:17, Jiazi YI a =E9crit : Hi Charlie, On Dec 11, 2012, at 7:34 AM, Charles E. Perkins > wrote: Hello Jiazi, On 12/10/2012 3:02 PM, Jiazi YI wrote: Given the fact that DYMO is moving closer and closer to LOADng (the modular= approach, handling of RREP, sequence numbers, handling of RERRs, etc...), = I feel that we have already consensus on those general design issues. I find this to be an unusual comment, since the explicit goal was to be inclusive and compatible with LOADng. Moreover, I have for a long time been pointing out that it would not be difficult to produce this compatibility. I didn't find any controversial between what you said (the *goal*) and what= I mentioned (the *result*). I think to be *compatible* with LOADng, the fact is that DYMO is getting mo= re closer to LOADng. I made a small list after comparing dymo-21 and dymo-2= 4, it's not hard to have this conclusion. In the meantime, even dymo and LOADng are having the similar approaches, as= one who participated in most interop events of LOADng, I find it's hard to= have dymo compatible with LOADng, without significant changes of DYMO (pac= ket format, flags, message processing...) The next question is which is the one we should begin with. For me, it's na= ture to start with the one with more operational experiences and running co= de. As I understand it, most of the operational experience was with non-mobile networks. I guess there has been some more recent work with mobile networks? I have to say, I didn't mention which one is the protocol that has more ope= rational experiences and running code. Because I'm only familiar with the s= ituation of LOADng (interop events, large implementation, etc...) I believe when you are saying above, you admit that LOADng is having more o= perational experiences? Or can you share some of dymo (either non-mobile, o= r mobile)? Given that LOADng can be viewed as a set of mandatory features from the WG document along with, possibly, some optional features, and since the WG document has all along been designed for mobile networks, and to have certain scalability features, it seems natural to continue with the WG document and to take care for the needs of LOADng as well. As a lot of people have mentioned, because DYMO and LOADng generally share = the same mechanism, they won't have significant difference in performance. = That's why I said we should begin with the one with more operational experi= ence. Personally, I'm very careful when making assessment. When I'm saying LOADng= has scalability features, and can have interoperable implementations, ther= e is running code to prove that. I think it's the "running code", which is believed in IETF, am I wrong? So= if I need to choose between the "running code", and "some optional feature= s that are not verified", my choice is quite clear, especially for a standa= rd track protocol. I guess that was the point of charlie above : if there was some other exper= iences than the PLC deployment *mentioned* on this list (no publication or = official material was shared about it). If "running code" is a good metric (chairs may have an opinion on how much = "running code" is needed for a standard track), then the WG should be aware= of existing deployments, for both protocols. For now, I can just count 1 d= eployment of LOADng, and did not see material yet on an DYMO/AODVv2 deploym= ent. Charlie, do you have some or I missed something ? If there are some confidentiality or restriction around theses deployments = and no material can be provide or share, then it seems hard to rely on this= parameter... My opinion is that such a parameter is fairly hard to evaluate because peop= le don't want to share so much on their secret sauce, so we may end up with= some pieces of informations that are hard to evaluate. Agree with Cedric and we do not have details about the one deployment. Best, C=E9dric. Note: I'm not saying taking one and abandoning the other. We just need to t= ake the one with better shape to begin with, and integrate ideas from the o= ther one based on WG consensus. Well, after recent efforts I think the WG document is really in pretty good shape. In the near future, I'll try to suggest some various points where the LOADng document should be moved closer to where the WG document is now -- I hope to do this before Christmas. I'm aware that there are some issues still need to addressed for LOADng, an= d there are still a lot of tickets under active discussion in the LOADng bu= gtracker. Any comments that can be helpful to improve the existed tickets, = or new issues of LOADng, are welcome. best Jiazi -- Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A77230FDDC0xmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <5AE0FCF6956C664B8439A9FD84B25F5C@cisco.com> Content-Transfer-Encoding: quoted-printable
On Dec 11, 2012, at 4:37 AM, C Chauvenet wrote:

Hi, 

See inline.

Le 11 d=E9c. 2012 =E0 12:17, Jiazi YI a =E9crit :

Hi Charlie, 


On Dec 11, 2012, at 7:34 AM, Charles E. Perkins <charliep@computer.org> wrote:


Hello Jiazi,

On 12/10/2012 3:02 PM, Jiazi YI wrote:

Given the fact that DYMO is moving closer and closer to LOADng (the modular appr= oach, handling of RREP, sequence numbers, handling of RERRs, etc...), I fee= l that we have already consensus on those general design issues.

I find this to be an unusual comment, since the explicit goal was
to be inclusive and compatible with LOADng.  Moreover, I have for
a long time been pointing out that it would not be difficult to produce
this compatibility.

I didn't find any controversial between what you said (the *goal*) and= what I mentioned (the *result*). 
I think to be *compatible* with LOADng, the fact is that DYMO is getti= ng more closer to LOADng. I made a small list after comparing dymo-21 and d= ymo-24, it's not hard to have this conclusion. 
In the meantime, even dymo and LOADng are having the similar approache= s, as one who participated in most interop events of LOADng, I find it's ha= rd to have dymo compatible with LOADng, without significant changes of DYMO= (packet format, flags, message processing...)




The next question is which is the one we should begin with. For me, it's natur= e to start with the one with more operational experiences and running code.=


As I understand it, most of the operational experience was with
non-mobile networks.   I guess there has been some more recent work with mobile networks?

I have to say, I didn't mention which one is the protocol that has mor= e operational experiences and running code. Because I'm only familiar with = the situation of LOADng (interop events, large implementation, etc...)
I believe when you are saying above, you admit that LOADng is having m= ore operational experiences? Or can you share some of dymo (either non-mobi= le, or mobile)?



Given that LOADng can be viewed as a set of mandatory features
from the WG document along with, possibly, some optional
features, and since the WG document has all along been designed
for mobile networks, and to have certain scalability features, it
seems natural to continue with the WG document and to take
care for the needs of LOADng as well.

As a lot of people have mentioned, because DYMO and LOADng generally s= hare the same mechanism, they won't have significant difference in performa= nce. That's why I said we should begin with the one with more operational e= xperience. 
Personally, I'm very careful when making assessment. When I'm saying L= OADng has scalability features, and can have interoperable implementations,= there is running code to prove that.
I think it's the "running code",  which is believed in = IETF, am I wrong? So if I need to choose between the "running code&quo= t;, and "some optional features that are not verified", my choice= is quite clear, especially for a standard track protocol. 

I guess that was the point of charlie above : if there was some other = experiences than the PLC deployment *mentioned* on this list (no publicatio= n or official material was shared about it).

If "running code" is a good metric (chairs may have an opini= on on how much "running code" is needed for a standard track), th= en the WG should be aware of existing deployments, for both protocols. For = now, I can just count 1 deployment of LOADng, and did not see material yet on an DYMO/AODVv2 deployment. Charlie, do you have so= me or I missed something ?
If there are some confidentiality or restriction around theses deploym= ents and no material can be provide or share, then it seems hard to rely on= this parameter...

My opinion is that such a parameter is fairly hard to evaluate because= people don't want to share so much on their secret sauce, so we may end up= with some pieces of informations that are hard to evaluate. 


Agree with Cedric and we do not have details about the one deployment.=

Best,

C=E9dric.





Note: I'm not saying taking one and abandoning the other. We just need to take t= he one with better shape to begin with, and integrate ideas from the other = one based on WG consensus.

Well, after recent efforts I think the WG document is really
in pretty good shape.   In the near future, I'll try to suggest s= ome
various points where the LOADng document should be moved
closer to where the WG document is now -- I hope to do this
before Christmas.

I'm aware that there are some issues still need to addressed for LOADn= g, and there are still a lot of tickets under active discussion in the LOAD= ng bugtracker. Any comments that can be helpful to improve the existed tick= ets, or new issues of LOADng, are welcome. 

best

Jiazi

--=20
Regards,
Charlie P.

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

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

--_000_03B78081B371D44390ED6E7BADBB4A77230FDDC0xmbrcdx02ciscoc_-- From henning.rogge@fkie.fraunhofer.de Tue Dec 11 22:41:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D2621F8617 for ; Tue, 11 Dec 2012 22:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 tRcVsxwFtlPY for ; Tue, 11 Dec 2012 22:41:02 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id B7FD221F8624 for ; Tue, 11 Dec 2012 22:40:54 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tifzw-0005Uv-Pd for manet@ietf.org; Wed, 12 Dec 2012 07:40:52 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tifzw-0001PD-Mw for manet@ietf.org; Wed, 12 Dec 2012 07:40:52 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 12 Dec 2012 07:40:52 +0100 Message-ID: <50C826ED.80309@fkie.fraunhofer.de> Date: Wed, 12 Dec 2012 07:40:45 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> <2F9893ED-21B4-42A3-B3AE-37124BCA4B17@inf-net.nl> <50C6605C.2070306@computer.org> <50C6DB95.50 609@fkie.fraunhofer.de> <771DECBD-7746-4435-8B92-CD8FA32E9133@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A77230FB63A@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77230FB63A@xmb-rcd-x02.cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010908050904010104010202" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/15735/Wed Dec 12 05:37:26 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8835b956789c73e36836d429bb2623bb Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 06:41:13 -0000 --------------ms010908050904010104010202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 12/11/2012 03:25 PM, JP Vasseur (jvasseur) wrote: > > On Dec 11, 2012, at 3:22 AM, Thomas Heide Clausen wrote: > >> The issue (discussed at length at [HOMENE]) is source address >> selection in case of a multi-homed (MA)NETwork - and, as Henning >> says, also NAT state (if used). >> >> Personally, I believe that this is not a MANET-specific issue, and >> that we should try to look to [HOMENET] to understand if their >> cognitions are not simply generally applicable. >> > > Yes I completely agree. I had already a short talk with Teco about BRDP and how we might be able to use it in a MANET. If I understand the current BRDP-draft correctly we will have to add a forwarding layer for BRDP on a MANET, but that should be not that difficult to do. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms010908050904010104010202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEyMTIwNjQwNTBaMCMGCSqGSIb3DQEJBDEWBBRC1XVshmgvPMqQN7CR0dLwx4NGgDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAo0V/vUEtrUkQHJmWsnBNPORAUOSXapbS7wE/QFDNMqt2 z8XvkGLXXOyMm9H0ycwAB+p1WYkmyzmA6leboyfmiwnJc6vpfyIQzvA/XzjSkdyqdUJZ2ria ZH47BtOxRzjatVXuYhLznhilMfDEcPJiGE/DK+bGFopY9916FZFrGnd4Tkqh15mYaG/5KsfI 2NbsNpm77EeSJBEYEwlbuyLCmLuv/PzmKE9m+dV9eYG+3xoZGRggM9e4F5MpLvGn7qAxdHRW LEVz6yE9SQkpXlmm1edL8OCeWIsk8jp2m8WzXFeQ13iVoYz9UPVNHmmGnCEetJ1rk+HO1yFq G5YwBRT+YQAAAAAAAA== --------------ms010908050904010104010202-- From Chris.Dearlove@baesystems.com Wed Dec 12 02:18:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944B921F8909 for ; Wed, 12 Dec 2012 02:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 SpJegeyA3qjK for ; Wed, 12 Dec 2012 02:18:56 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5EC21F882A for ; Wed, 12 Dec 2012 02:18:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,265,1355097600"; d="scan'208,217";a="293512572" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 12 Dec 2012 10:18:54 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qBCAIseN004669 for ; Wed, 12 Dec 2012 10:18:54 GMT X-IronPort-AV: E=Sophos;i="4.84,265,1355097600"; d="scan'208,217";a="1144316" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds017.greenlnk.net with ESMTP; 12 Dec 2012 10:18:53 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Wed, 12 Dec 2012 10:18:54 +0000 From: "Dearlove, Christopher (UK)" To: "JP Vasseur (jvasseur)" , C Chauvenet Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN2BsbPMi+SJtSGUKvWyPcOuoNr5gU82Lg Date: Wed, 12 Dec 2012 10:18:53 +0000 Message-ID: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <50C6D3E4.1010105@computer.org> <2DE09B23-0544-4436-87D2-F266B9338A4E@jiaziyi.com> <97B69B30E0EF244B940B65EA541E3F2D223C9D14@DBXPRD0510MB359.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A77230FDDC0@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77230FDDC0@xmb-rcd-x02.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FD5012GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 10:18:57 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FD5012GLKXM0002VGREEN_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Can I just say that as no contributions are marked, I find this an impossib= le posting to work out who said what. On Dec 11, 2012, at 4:37 AM, C Chauvenet wrote: Hi, See inline. Le 11 d=E9c. 2012 =E0 12:17, Jiazi YI a =E9crit : Hi Charlie, On Dec 11, 2012, at 7:34 AM, Charles E. Perkins > wrote: Hello Jiazi, On 12/10/2012 3:02 PM, Jiazi YI wrote: Given the fact that DYMO is moving closer and closer to LOADng (the modular= approach, handling of RREP, sequence numbers, handling of RERRs, etc...), = I feel that we have already consensus on those general design issues. I find this to be an unusual comment, since the explicit goal was to be inclusive and compatible with LOADng. Moreover, I have for a long time been pointing out that it would not be difficult to produce this compatibility. I didn't find any controversial between what you said (the *goal*) and what= I mentioned (the *result*). I think to be *compatible* with LOADng, the fact is that DYMO is getting mo= re closer to LOADng. I made a small list after comparing dymo-21 and dymo-2= 4, it's not hard to have this conclusion. In the meantime, even dymo and LOADng are having the similar approaches, as= one who participated in most interop events of LOADng, I find it's hard to= have dymo compatible with LOADng, without significant changes of DYMO (pac= ket format, flags, message processing...) The next question is which is the one we should begin with. For me, it's na= ture to start with the one with more operational experiences and running co= de. As I understand it, most of the operational experience was with non-mobile networks. I guess there has been some more recent work with mobile networks? I have to say, I didn't mention which one is the protocol that has more ope= rational experiences and running code. Because I'm only familiar with the s= ituation of LOADng (interop events, large implementation, etc...) I believe when you are saying above, you admit that LOADng is having more o= perational experiences? Or can you share some of dymo (either non-mobile, o= r mobile)? Given that LOADng can be viewed as a set of mandatory features from the WG document along with, possibly, some optional features, and since the WG document has all along been designed for mobile networks, and to have certain scalability features, it seems natural to continue with the WG document and to take care for the needs of LOADng as well. As a lot of people have mentioned, because DYMO and LOADng generally share = the same mechanism, they won't have significant difference in performance. = That's why I said we should begin with the one with more operational experi= ence. Personally, I'm very careful when making assessment. When I'm saying LOADng= has scalability features, and can have interoperable implementations, ther= e is running code to prove that. I think it's the "running code", which is believed in IETF, am I wrong? So= if I need to choose between the "running code", and "some optional feature= s that are not verified", my choice is quite clear, especially for a standa= rd track protocol. I guess that was the point of charlie above : if there was some other exper= iences than the PLC deployment *mentioned* on this list (no publication or = official material was shared about it). If "running code" is a good metric (chairs may have an opinion on how much = "running code" is needed for a standard track), then the WG should be aware= of existing deployments, for both protocols. For now, I can just count 1 d= eployment of LOADng, and did not see material yet on an DYMO/AODVv2 deploym= ent. Charlie, do you have some or I missed something ? If there are some confidentiality or restriction around theses deployments = and no material can be provide or share, then it seems hard to rely on this= parameter... My opinion is that such a parameter is fairly hard to evaluate because peop= le don't want to share so much on their secret sauce, so we may end up with= some pieces of informations that are hard to evaluate. Agree with Cedric and we do not have details about the one deployment. Best, C=E9dric. Note: I'm not saying taking one and abandoning the other. We just need to t= ake the one with better shape to begin with, and integrate ideas from the o= ther one based on WG consensus. Well, after recent efforts I think the WG document is really in pretty good shape. In the near future, I'll try to suggest some various points where the LOADng document should be moved closer to where the WG document is now -- I hope to do this before Christmas. I'm aware that there are some issues still need to addressed for LOADng, an= d there are still a lot of tickets under active discussion in the LOADng bu= gtracker. Any comments that can be helpful to improve the existed tickets, = or new issues of LOADng, are welcome. best Jiazi -- Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FD5012GLKXM0002VGREEN_ Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Can I just say that as no= contributions are marked, I find this an impossible posting to work out wh= o said what.

 <= /p>

 

On Dec 11, 2012, at 4:37 AM, C Chauvenet wrote:=



Hi, 

 

See inline.

 

Le 11 d=E9c. 2012 =E0 12:17, Jiazi YI a =E9crit :



Hi C= harlie, 

 

On Dec 11, 2012, at 7:34 AM, Charles E. Perkins <= charliep@computer.org> wrot= e:




Hello Jiazi,

On 12/10/2012 3:02 PM, Jiazi YI wrote:



Give= n the fact that DYMO is moving closer and closer to LOADng (the modular app= roach, handling of RREP, sequence numbers, handling of RERRs, etc...), I feel that we have already consensus on those general design iss= ues.


I find this to be an unusual comment, since the explicit goal was
to be inclusive and compatible with LOADng.  Moreover, I have for
a long time been pointing out that it would not be difficult to produce
this compatibility.

 

I didn't find any controversial between what you sai= d (the *goal*) and what I mentioned (the *result*). 

I think to be *compatible* with LOADng, the fact is = that DYMO is getting more closer to LOADng. I made a small list after compa= ring dymo-21 and dymo-24, it's not hard to have this conclusion. =

In the meantime, even dymo and LOADng are having the= similar approaches, as one who participated in most interop events of LOAD= ng, I find it's hard to have dymo compatible with LOADng, without significa= nt changes of DYMO (packet format, flags, message processing...)

 







The = next question is which is the one we should begin with. For me, it's nature= to start with the one with more operational experiences and running code.



As I understand it, most of the operational experience was with
non-mobile networks.   I guess there has been some more recent work with mobile networks?

 

I have to say, I didn't mention which one is the pro= tocol that has more operational experiences and running code. Because I'm o= nly familiar with the situation of LOADng (interop events, large implementa= tion, etc...)

I believe when you are saying above, you admit that = LOADng is having more operational experiences? Or can you share some of dym= o (either non-mobile, or mobile)?

 




Given that LOADng can be viewed as a set of mandatory features
from the WG document along with, possibly, some optional
features, and since the WG document has all along been designed
for mobile networks, and to have certain scalability features, it
seems natural to continue with the WG document and to take
care for the needs of LOADng as well.

 

As a lot of people have mentioned, because DYMO and = LOADng generally share the same mechanism, they won't have significant diff= erence in performance. That's why I said we should begin with the one with = more operational experience. 

Personally, I'm very careful when making assessment.= When I'm saying LOADng has scalability features, and can have interoperabl= e implementations, there is running code to prove that.

I think it's the "running code",  whi= ch is believed in IETF, am I wrong? So if I need to choose between the &quo= t;running code", and "some optional features that are not verifie= d", my choice is quite clear, especially for a standard track protocol= . 

 

I guess that was the point of charlie above : if the= re was some other experiences than the PLC deployment *mentioned* on this l= ist (no publication or official material was shared about it).

 

If "running code" is a good metric (chairs= may have an opinion on how much "running code" is needed for a s= tandard track), then the WG should be aware of existing deployments, for bo= th protocols. For now, I can just count 1 deployment of LOADng, and did not see material yet on an DYMO/AODVv2 deployment. Charlie= , do you have some or I missed something ?

If there are some confidentiality or restriction aro= und theses deployments and no material can be provide or share, then it see= ms hard to rely on this parameter...

 

My opinion is that such a parameter is fairly hard t= o evaluate because people don't want to share so much on their secret sauce= , so we may end up with some pieces of informations that are hard to evalua= te. 

 

 

Agree with Cedric and we do not have details about t= he one deployment.



Best,

 

C=E9dric.



 







Note= : I'm not saying taking one and abandoning the other. We just need to take = the one with better shape to begin with, and integrate ideas from the other one based on WG consensus.


Well, after recent efforts I think the WG document is really
in pretty good shape.   In the near future, I'll try to suggest s= ome
various points where the LOADng document should be moved
closer to where the WG document is now -- I hope to do this
before Christmas.

 

I'm aware that there are some issues still need to a= ddressed for LOADng, and there are still a lot of tickets under active disc= ussion in the LOADng bugtracker. Any comments that can be helpful to improv= e the existed tickets, or new issues of LOADng, are welcome. 

 

best

 

Jiazi



-- 
Regards,
Charlie P.

 

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

 

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

 


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FD5012GLKXM0002VGREEN_-- From Chris.Dearlove@baesystems.com Wed Dec 12 02:19:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC3221F89AB for ; Wed, 12 Dec 2012 02:19:48 -0800 (PST) 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 GUdFCsgdn1qC for ; Wed, 12 Dec 2012 02:19:47 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0E021F8909 for ; Wed, 12 Dec 2012 02:19:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,265,1355097600"; d="scan'208";a="249080661" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 12 Dec 2012 10:19:46 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qBCAJkvZ011151 for ; Wed, 12 Dec 2012 10:19:46 GMT X-IronPort-AV: E=Sophos;i="4.84,265,1355097600"; d="scan'208";a="926570" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 12 Dec 2012 10:19:45 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0309.002; Wed, 12 Dec 2012 10:19:45 +0000 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , "JP Vasseur (jvasseur)" Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN1sRSNLIqkYlKlkqdBTQGe5TNE5gSIACAgAC+fQCAARh2gIAA/Z+g Date: Wed, 12 Dec 2012 10:19:44 +0000 Message-ID: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 10:19:48 -0000 We have two drafts, and people who seem prepared to work on them. To sugges= t that neither should proceed because we are having difficulties deciding w= hich seems entirely wrong. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S= tan Ratliff (sratliff) Sent: 11 December 2012 19:04 To: JP Vasseur (jvasseur) Cc: Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.t= xt) ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- JP,=20 On Dec 10, 2012, at 9:19 PM, JP Vasseur (jvasseur) wrote: > Hi Stan, >=20 > On Dec 10, 2012, at 6:58 AM, Stan Ratliff (sratliff) wrote: >=20 >> Abdussalam,=20 >>=20 >> On Dec 10, 2012, at 5:51 AM, Abdussalam Baryun wrote: >>=20 >>> On 12/7/12, Stan Ratliff (sratliff) wrote: >>>>=20 >>>> My feeling, FWIW, is that ingress/egress SHOULD be a part of the base >>>> document. However, I understand the concerns of people that say it mig= ht be >>>> a problem (or extend ratification time, etc etc). So, I'm interested i= n >>>> hearing other, interested opinions - both for >>>> DYMO/AODVv2/Whatever-we're-calling-it-this-week, as well as with regar= d to >>>> the LOADng spec. >>>=20 >>> I know from my efforts that LOADng team are not welling to discuss, or >>> reply to questions/comments, so I want to know your opinion of the >>> status on this LOADng draft as you brought it to the list; Is it a WG >>> draft? should we discuss individual or private work now? >>>=20 >>> I remember that we answered chair questions and options given. Not >>> sure what the chair of WG wants us to do so far, please advise, >>=20 >> It wasn't clear to me what the consensus was in Atlanta vis-a-vis the tw= o reactive protocol documents. Presently, DYMO is the working group accepte= d reactive protocol document. However, there was a 2-year period of time wh= en DYMO was inactive, and the document was "parked". As a result of that, t= he effort to create LOADng sprang up.=20 >>=20 >> So now, we have two documents to consider. In the charter, the WG is "on= the hook" for 1 (and only 1) reactive protocol. So the current options are= :=20 >> 1. Recognize that we cannot reach consensus with the two documents, and = remove the charter item for reactive protocols. To be frank, this is my pre= ferred option.=20 >> 2. Accept one of the two documents (either LOADng or DYMO), and press fo= rward >> 3. Perhaps alter the charter item, and produce 2 reactive protocols, bot= h in "experimental" state.=20 >>=20 >=20 > JP> What about putting a hard dead-line and if there is no consensus fall= back to 1 ? There's only one problem with that - It's already happened, and the deadlin= e has already passed without conclusion. ;-) It happened in Vancouver, wit= h a deadline of Atlanta.=20 To the working group at large -=20 I'm not seeing a high level of interest here. People seem to only have "pas= sing interest" - enough to keep the efforts on life support, but not enough= to really progress things. By and large, only the authors have the inclina= tion to push their respective opinions, and nothing has really changed.=20 So, I call once again - I think it's time to remove the work item from the = charter, and recognize that we're not going to be able to work together on = this issue. After more than a year of trying to get people to work together= to make the technology better, just don't see it happening. It's time to = end the misery. Regards, Stan >=20 >> Now, you mentioned "Not sure what the chairs of WG want us to do so far"= .. the best answer I can give you on that is "reach consensus on an approac= h". We as a working group haven't done that yet. There are people advocati= ng for DYMO, others advocating for LOADng, and some that want to "merge" th= e technology of the two together. A "merge" was something we tried in the V= ancouver timeframe, but that effort failed.=20 >>=20 >> As to your statement that the LOADng team is not willing to discuss - I = haven't seen that, do not agree with it, and would ask you to cite *specifi= c* examples if you have them. I've found the LOADng team to be reasonable i= n their dealings with the WG. There is the issue of re-spinning the LOADng = document without the copyright statement - The LOADng authors and the chair= s have reached an understanding about that issue, so I no longer have a pro= blem with moving forward on that front.=20 >>=20 >> Again, as a working group - we *MUST* either reach a consensus, or the w= ork item will be removed *for us*. If we do not show progress towards a goa= l, it is within the power of the IESG to stop work on the issue. >>=20 >> Regards, >> Stan >>=20 >>=20 >>>=20 >>> AB >>>=20 >>>>=20 >>>> And lastly... if the 5 guys were *that* important, they most likely wo= uldn't >>>> be *playing* black-ops. ;-) >>>>=20 >>>> Stan >>>>=20 >>>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From jvasseur@cisco.com Wed Dec 12 02:30:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C53F21F89A9 for ; Wed, 12 Dec 2012 02:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdSmBBzHOLOs for ; Wed, 12 Dec 2012 02:30:57 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4856421F890D for ; Wed, 12 Dec 2012 02:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7186; q=dns/txt; s=iport; t=1355308257; x=1356517857; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UeL55vuWxhw/LnVmrJSc6gadm7KIAihpkwhnDS9YDXM=; b=DjqQZj0YoM91T/0gqtqyTJQbpg89dHN/iYbd0JoSUaOeJ1flaMGDc7SK d/RtnP2s/mR24r7RLv0OchNspHaFk54JOosGYmqfZOhifc789V5IvEUA2 k+9IiJn3k2eIvJhEw7OBPRilh4F20vtWwJIG5ZksEGRDh7ZzsaL5Q3jla E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALRbyFCtJV2Z/2dsb2JhbABFvyIWc4IeAQEBAwEBAQFSGQMIBQcEAgEIEQQBAQEKHQcnCxQJCAIEDgUIEYdyBgy8TYxLCwoHB4M/YQOIK54kgnOBZAkXHg X-IronPort-AV: E=Sophos;i="4.84,265,1355097600"; d="scan'208";a="149040577" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 12 Dec 2012 10:30:56 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBCAUur8031618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Dec 2012 10:30:56 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.93]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Wed, 12 Dec 2012 04:30:56 -0600 From: "JP Vasseur (jvasseur)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN10YD58ZTcgsdX0eR1UQmu61MsA== Date: Wed, 12 Dec 2012 10:30:55 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.94.31] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <214923238857DB46A6E8D6EB6C8CF384@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 10:30:58 -0000 the point was that there is (no, little ?) progress in converging toward of= the two options .. On Dec 12, 2012, at 2:19 AM, Dearlove, Christopher (UK) wrote: > We have two drafts, and people who seem prepared to work on them. To sugg= est that neither should proceed because we are having difficulties deciding= which seems entirely wrong. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Stan Ratliff (sratliff) > Sent: 11 December 2012 19:04 > To: JP Vasseur (jvasseur) > Cc: > Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24= .txt) >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > JP,=20 >=20 > On Dec 10, 2012, at 9:19 PM, JP Vasseur (jvasseur) wrote: >=20 >> Hi Stan, >>=20 >> On Dec 10, 2012, at 6:58 AM, Stan Ratliff (sratliff) wrote: >>=20 >>> Abdussalam,=20 >>>=20 >>> On Dec 10, 2012, at 5:51 AM, Abdussalam Baryun wrote: >>>=20 >>>> On 12/7/12, Stan Ratliff (sratliff) wrote: >>>>>=20 >>>>> My feeling, FWIW, is that ingress/egress SHOULD be a part of the base >>>>> document. However, I understand the concerns of people that say it mi= ght be >>>>> a problem (or extend ratification time, etc etc). So, I'm interested = in >>>>> hearing other, interested opinions - both for >>>>> DYMO/AODVv2/Whatever-we're-calling-it-this-week, as well as with rega= rd to >>>>> the LOADng spec. >>>>=20 >>>> I know from my efforts that LOADng team are not welling to discuss, or >>>> reply to questions/comments, so I want to know your opinion of the >>>> status on this LOADng draft as you brought it to the list; Is it a WG >>>> draft? should we discuss individual or private work now? >>>>=20 >>>> I remember that we answered chair questions and options given. Not >>>> sure what the chair of WG wants us to do so far, please advise, >>>=20 >>> It wasn't clear to me what the consensus was in Atlanta vis-a-vis the t= wo reactive protocol documents. Presently, DYMO is the working group accept= ed reactive protocol document. However, there was a 2-year period of time w= hen DYMO was inactive, and the document was "parked". As a result of that, = the effort to create LOADng sprang up.=20 >>>=20 >>> So now, we have two documents to consider. In the charter, the WG is "o= n the hook" for 1 (and only 1) reactive protocol. So the current options ar= e:=20 >>> 1. Recognize that we cannot reach consensus with the two documents, and= remove the charter item for reactive protocols. To be frank, this is my pr= eferred option.=20 >>> 2. Accept one of the two documents (either LOADng or DYMO), and press f= orward >>> 3. Perhaps alter the charter item, and produce 2 reactive protocols, bo= th in "experimental" state.=20 >>>=20 >>=20 >> JP> What about putting a hard dead-line and if there is no consensus fal= l back to 1 ? >=20 > There's only one problem with that - It's already happened, and the deadl= ine has already passed without conclusion. ;-) It happened in Vancouver, w= ith a deadline of Atlanta.=20 >=20 > To the working group at large -=20 >=20 > I'm not seeing a high level of interest here. People seem to only have "p= assing interest" - enough to keep the efforts on life support, but not enou= gh to really progress things. By and large, only the authors have the incli= nation to push their respective opinions, and nothing has really changed.=20 >=20 > So, I call once again - I think it's time to remove the work item from th= e charter, and recognize that we're not going to be able to work together o= n this issue. After more than a year of trying to get people to work togeth= er to make the technology better, just don't see it happening. It's time t= o end the misery. >=20 > Regards, > Stan >=20 >=20 >=20 >>=20 >>> Now, you mentioned "Not sure what the chairs of WG want us to do so far= ".. the best answer I can give you on that is "reach consensus on an approa= ch". We as a working group haven't done that yet. There are people advocat= ing for DYMO, others advocating for LOADng, and some that want to "merge" t= he technology of the two together. A "merge" was something we tried in the = Vancouver timeframe, but that effort failed.=20 >>>=20 >>> As to your statement that the LOADng team is not willing to discuss - I= haven't seen that, do not agree with it, and would ask you to cite *specif= ic* examples if you have them. I've found the LOADng team to be reasonable = in their dealings with the WG. There is the issue of re-spinning the LOADng= document without the copyright statement - The LOADng authors and the chai= rs have reached an understanding about that issue, so I no longer have a pr= oblem with moving forward on that front.=20 >>>=20 >>> Again, as a working group - we *MUST* either reach a consensus, or the = work item will be removed *for us*. If we do not show progress towards a go= al, it is within the power of the IESG to stop work on the issue. >>>=20 >>> Regards, >>> Stan >>>=20 >>>=20 >>>>=20 >>>> AB >>>>=20 >>>>>=20 >>>>> And lastly... if the 5 guys were *that* important, they most likely w= ouldn't >>>>> be *playing* black-ops. ;-) >>>>>=20 >>>>> Stan >>>>>=20 >>>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 From teco@inf-net.nl Wed Dec 12 02:45:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D4C21F895B for ; Wed, 12 Dec 2012 02:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 Q9yaJpGyDLe1 for ; Wed, 12 Dec 2012 02:45:12 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id AAF4D21F8955 for ; Wed, 12 Dec 2012 02:45:11 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so177206eaa.31 for ; Wed, 12 Dec 2012 02:45:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=s6TDpt8mNqmE4ByONW2qhfZVCMki7biTRDVRgn4vHjY=; b=g1AN+WpOm6hNSja2MNwTbQcSGU9PCt0JASkLT1UrhFwQvsKj+cYrdqH8quEVmkh+tc dJaMZd0DKCsn/Al9BxoTDm2/r2BtUXyz7uAW+oK4KnnHDw39dB5z8B1vkp84RTuB8L99 q8XRMU814xKJbHx/vINozU1iRtvn9vrMcGM9VIHzvYVnJsrPgTc6HO7Sja7aus93DOSx l2vVnZ0IAAfrIZMCmOMsPYXVFzQ+v+lW2USvBnq7uGepYv25jXZ3GseaKiq2WcClDodQ +V9lX7GItOD4BGS4Zm9A95KcOdv2SE8o8fCGLY1dRR21Jca+MqHUfIA0/XpNdb/hhjhA EJFw== Received: by 10.14.225.4 with SMTP id y4mr1698968eep.6.1355309110313; Wed, 12 Dec 2012 02:45:10 -0800 (PST) Received: from [172.16.4.197] ([188.205.88.52]) by mx.google.com with ESMTPS id w3sm55192367eel.17.2012.12.12.02.45.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2012 02:45:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <50C826ED.80309@fkie.fraunhofer.de> Date: Wed, 12 Dec 2012 11:45:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8E7E7FF5-B8B4-4B24-A5A9-4D7A26F333CA@inf-net.nl> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <52B2C78A-0542-4BF2-A46F-7864D370DEFF@gmail.com> <50C3AE5E.1000900@computer.org> <50C62074.2020209@computer.org> <9A48798D-852A-4950-8F6A-85A97AF1CC7E@inf-net.nl> <2F9893ED-21B4-42A3-B3AE-37124BCA4B17@inf-net.nl> <50C6605C.2070306@computer.org> <50C6DB95.50 609@fkie.fraunhofer.de> <771DECBD-7746-4435-8B92-CD8FA32E9133@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A77230FB63A@xmb-rcd-x02.cisco.com> <50C826ED.80309@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkWm2Mxy4XHtlCModxmTQHCSxr/ShT6ypkanJ9bxD2rKCPEOtT/tVh24n64Xfw0exmq4Rv9 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 10:45:12 -0000 Op 12 dec. 2012, om 07:40 heeft Henning Rogge het volgende geschreven: > On 12/11/2012 03:25 PM, JP Vasseur (jvasseur) wrote: >>=20 >> On Dec 11, 2012, at 3:22 AM, Thomas Heide Clausen wrote: >>=20 >>> The issue (discussed at length at [HOMENE]) is source address >>> selection in case of a multi-homed (MA)NETwork - and, as Henning >>> says, also NAT state (if used). >>>=20 >>> Personally, I believe that this is not a MANET-specific issue, and >>> that we should try to look to [HOMENET] to understand if their >>> cognitions are not simply generally applicable. >>>=20 >>=20 >> Yes I completely agree. >=20 > I had already a short talk with Teco about BRDP and how we might be = able > to use it in a MANET. If I understand the current BRDP-draft correctly > we will have to add a forwarding layer for BRDP on a MANET, but that > should be not that difficult to do. There was an interop test at Atlanta, based on OSPF extensions for = Homenet. I'm not quite happy with their approach, which needs a SA&DA = forwarding table for each SA prefix. Inner topology (the DA part) in all = tables is equivalent, so high overhead. I suggest a singe DA forwarding = table, with extension for default routes based on SA. Default routes = point to BR for each SA prefix. Can be optimized for those that do not = want the recursive lookup. I also suggest border discovery that is not dependent of a routing = protocol and that provides info to hosts, for address selection. I don't = think attached hosts should listen and decode routing protocol messages. = That is why I suggest to run BRDP on top of ND. Teco >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Wed Dec 12 05:16:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FE821F8A15 for ; Wed, 12 Dec 2012 05:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 p7EGyaIdMSNg for ; Wed, 12 Dec 2012 05:16:37 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC6A721F8A14 for ; Wed, 12 Dec 2012 05:16:27 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so692442vbb.31 for ; Wed, 12 Dec 2012 05:16:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9ybbl+B9qr0TeLh/sbRXMd5EDRST24Su9fe4KBkJs4I=; b=rhq2mXuak+AbEqJ7VIzfIUbuj1du6DPn+YyLrJjohr3w7C3CckZkKMoxOPBljsZHK5 042CsEDvgdTctjZ6w1w6KQ32HJGJWEOE7LDjxp0L09vgIDiHXs1ntkx3zOSN2FJqNa69 CVjF3nfWk7mLxxFKxDFYhMIkoRtPfyYxp1z7r5p5kfZq7dS6TkIYKqRh1dYejw6eCYNX FEnOijmGQSoSepV51PEfHLt9B73FGSKxmcEz5Lp98winB1/Di4YtH1ZbDmHsncmuYjkA alp5pCtf6lunVVPRBdAvr7ctqBXS34jnelcEGQao/M1SDhAKbMZ8FZOpa1mKAO2kGC7X 8V6g== MIME-Version: 1.0 Received: by 10.52.76.73 with SMTP id i9mr415994vdw.25.1355318187312; Wed, 12 Dec 2012 05:16:27 -0800 (PST) Received: by 10.220.145.5 with HTTP; Wed, 12 Dec 2012 05:16:27 -0800 (PST) In-Reply-To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> Date: Wed, 12 Dec 2012 14:16:27 +0100 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 13:16:38 -0000 That is why I asked questions to know the position of such discussions. Seems that management want that any of both work should proceed at authors' end and stop at the WG until cooperation. I think the issue was/is, that both drafts were to be merged and something happend made the difficulty to work together, and all WG want a reactive protocol even if the authors of both drafts could not work together. I recommended that we should add more author team into the drafts. I read the situation that the IETF management wanted the DYMO and LOADng merge but could not make it progress so far, and now pushing for removing from charter, while the community don't want that. In the last meeting their was signs of changing minds. I hope some party (drafts' authors, management, community) changes their mind or cooperate for all the WG best. IMHO only the community should make the final decision of such item-removal of charter. AB On 12/12/12, Dearlove, Christopher (UK) wrote: > We have two drafts, and people who seem prepared to work on them. To suggest > that neither should proceed because we are having difficulties deciding > which seems entirely wrong. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > From sratliff@cisco.com Wed Dec 12 07:58:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D02421F896C for ; Wed, 12 Dec 2012 07:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 wU5ZEWcPmqcW for ; Wed, 12 Dec 2012 07:58:07 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 51C5421F8937 for ; Wed, 12 Dec 2012 07:58:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6806; q=dns/txt; s=iport; t=1355327886; x=1356537486; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=L4NzsaJFsvRT2QLByhSoFv9fHcArI/dzZf4bl2FiHu8=; b=KAEYRe8Q+Obuw7Wjzafu/M/UFxImyjD4PA2n6nUKF6UmcqlMJIJbucoB SLfWIk4fuYBSSZW0xMal80QpgARDgId7Gu/rKvXy/UNCec2R/NDSCz2rj zhRUvoCITKHWCp9YTXw9UI7HfHL5wtOm/BRaga1tpt/8hUxKxK4TOGpzA 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIGoyFCtJV2Y/2dsb2JhbABFvxUWc4IeAQEBAwEBAQFrCwULAgEIGAokJwslAgQOBQgRh3IGDL0uBIxLHINGYQOmUYJzgiI X-IronPort-AV: E=Sophos;i="4.84,267,1355097600"; d="scan'208";a="152145914" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 12 Dec 2012 15:58:05 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBCFw5hM019531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Dec 2012 15:58:05 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.18]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Wed, 12 Dec 2012 09:58:05 -0600 From: "Stan Ratliff (sratliff)" To: =?Windows-1252?Q?Axel_Colin_de_Verdi=E8re?= Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN1sRQC9RIBD6Ww0Sj7f1Ne2/6upgShJYAgAC+fACAARh2gIAAQmiAgAEcDAA= Date: Wed, 12 Dec 2012 15:58:04 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF389CF@xmb-rcd-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <3E873090-C8D3-4563-A7A4-331D2D599917@axelcdv.com> In-Reply-To: <3E873090-C8D3-4563-A7A4-331D2D599917@axelcdv.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.40.198] Content-Type: text/plain; charset="Windows-1252" Content-ID: <10C7721DBEC36840A6AAAF7E3C4B4E76@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:58:15 -0000 Axel,=20 On Dec 11, 2012, at 6:01 PM, Axel Colin de Verdi=E8re wrote: > Hi Stan, >=20 > Le 11 d=E9c. 2012 =E0 11:03, Stan Ratliff (sratliff) = a =E9crit : >=20 >> JP,=20 >>=20 >> On Dec 10, 2012, at 9:19 PM, JP Vasseur (jvasseur) wrote: >>=20 >>> Hi Stan, >>>=20 >>> On Dec 10, 2012, at 6:58 AM, Stan Ratliff (sratliff) wrote: >>>=20 >>>> Abdussalam,=20 >>>>=20 >>>> On Dec 10, 2012, at 5:51 AM, Abdussalam Baryun wrote: >>>>=20 >>>>> On 12/7/12, Stan Ratliff (sratliff) wrote: >>>>>>=20 >>>>>> My feeling, FWIW, is that ingress/egress SHOULD be a part of the bas= e >>>>>> document. However, I understand the concerns of people that say it m= ight be >>>>>> a problem (or extend ratification time, etc etc). So, I'm interested= in >>>>>> hearing other, interested opinions - both for >>>>>> DYMO/AODVv2/Whatever-we're-calling-it-this-week, as well as with reg= ard to >>>>>> the LOADng spec. >>>>>=20 >>>>> I know from my efforts that LOADng team are not welling to discuss, o= r >>>>> reply to questions/comments, so I want to know your opinion of the >>>>> status on this LOADng draft as you brought it to the list; Is it a WG >>>>> draft? should we discuss individual or private work now? >>>>>=20 >>>>> I remember that we answered chair questions and options given. Not >>>>> sure what the chair of WG wants us to do so far, please advise, >>>>=20 >>>> It wasn't clear to me what the consensus was in Atlanta vis-a-vis the = two reactive protocol documents. Presently, DYMO is the working group accep= ted reactive protocol document. However, there was a 2-year period of time = when DYMO was inactive, and the document was "parked". As a result of that,= the effort to create LOADng sprang up.=20 >>>>=20 >>>> So now, we have two documents to consider. In the charter, the WG is "= on the hook" for 1 (and only 1) reactive protocol. So the current options a= re:=20 >>>> 1. Recognize that we cannot reach consensus with the two documents, an= d remove the charter item for reactive protocols. To be frank, this is my p= referred option.=20 >>>> 2. Accept one of the two documents (either LOADng or DYMO), and press = forward >>>> 3. Perhaps alter the charter item, and produce 2 reactive protocols, b= oth in "experimental" state.=20 >>>>=20 >>>=20 >>> JP> What about putting a hard dead-line and if there is no consensus fa= ll back to 1 ? >>=20 >> There's only one problem with that - It's already happened, and the dead= line has already passed without conclusion=85 ;-) It happened in Vancouver= , with a deadline of Atlanta.=20 >>=20 >> To the working group at large -=20 >>=20 >> I'm not seeing a high level of interest here. People seem to only have "= passing interest" - enough to keep the efforts on life support, but not eno= ugh to really progress things. By and large, only the authors have the incl= ination to push their respective opinions, and nothing has really changed.= =20 >=20 > I'm a bit surprised here: it seems weird to me that you can just dismiss = a 10 people behind a document, with strong industrial support (including ac= tual deployments) as "passing", or even "not enough" interest. Furthermore,= I've seen that we (the LOADng authors) are far from the only ones particip= ating on this topic. >=20 >>=20 >> So, I call once again - I think it's time to remove the work item from t= he charter, and recognize that we're not going to be able to work together = on this issue. After more than a year of trying to get people to work toget= her to make the technology better, just don't see it happening. It's time = to end the misery. >=20 > I understand your position, I think you made that clear relatively early = in the process, but I don't think "not enough interest" is really a good re= ason here. To the contrary, "Not enough interest" is a perfectly good reason for stopp= ing work. So is "we can't agree on an outcome". IMHO, *both* of these situa= tions are in effect here. Compared to the WG as a whole, there is a small s= et of people whirring and spinning on a couple of documents. Outside of tha= t small clique, we're not seeing a lot of interest (activity) on the mailin= g list. To simply state that "=85we (the LOADng authors) are far from the o= nly ones participating=85", without examples, is not proof - it's merely an= assertion. The call of whether there is "sufficient support" in the WG is = admittedly subjective. However, given the amount of strife on the topic, th= e likelihood that the WG will reach consensus, and the level of interest th= at I gauge - I stand by my position. IMO, as co-chair, this work should be = terminated.=20 Stan >=20 > Best, >=20 > Axel >=20 >>=20 >> Regards, >> Stan >>=20 >>=20 >>=20 >>>=20 >>>> Now, you mentioned "Not sure what the chairs of WG want us to do so fa= r"=85. the best answer I can give you on that is "reach consensus on an app= roach". We as a working group haven't done that yet. There are people advo= cating for DYMO, others advocating for LOADng, and some that want to "merge= " the technology of the two together. A "merge" was something we tried in t= he Vancouver timeframe, but that effort failed.=20 >>>>=20 >>>> As to your statement that the LOADng team is not willing to discuss - = I haven't seen that, do not agree with it, and would ask you to cite *speci= fic* examples if you have them. I've found the LOADng team to be reasonable= in their dealings with the WG. There is the issue of re-spinning the LOADn= g document without the copyright statement - The LOADng authors and the cha= irs have reached an understanding about that issue, so I no longer have a p= roblem with moving forward on that front.=20 >>>>=20 >>>> Again, as a working group - we *MUST* either reach a consensus, or the= work item will be removed *for us*. If we do not show progress towards a g= oal, it is within the power of the IESG to stop work on the issue. >>>>=20 >>>> Regards, >>>> Stan >>>>=20 >>>>=20 >>>>>=20 >>>>> AB >>>>>=20 >>>>>>=20 >>>>>> And lastly=85.. if the 5 guys were *that* important, they most likel= y wouldn't >>>>>> be *playing* black-ops=85 ;-) >>>>>>=20 >>>>>> Stan >>>>>>=20 >>>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From charliep@computer.org Wed Dec 12 09:10:27 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08BE421F88CA for ; Wed, 12 Dec 2012 09:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 x8l7fzXcr7EH for ; Wed, 12 Dec 2012 09:10:26 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id EF4E121F887D for ; Wed, 12 Dec 2012 09:10:25 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TippB-0001PT-3n; Wed, 12 Dec 2012 12:10:25 -0500 Message-ID: <50C8BA7E.8050200@computer.org> Date: Wed, 12 Dec 2012 09:10:22 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "JP Vasseur (jvasseur)" References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad865406f4e6488cea6f69ff879dfcae1697350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:10:27 -0000 Hello folks, On 12/12/2012 2:30 AM, JP Vasseur (jvasseur) wrote: > the point was that there is (no, little ?) progress in converging toward of the two options .. To be clear, I am now and always have been in favor of converging these two drafts. After many months and two unsatisfactory "maintenance" releases of the WG document, I finally took unilateral action to the WG document to be fully RFC 5444 compliant as well as compatible with the design needs of LOADng, as I have discussed before. I hope that, technically at least, this process will be viewed as progressing. I remain quite open to further evolution of the draft as may be needed, but by now i hope that at least the feature set will be viewed as complete. Then what remains is resolving whatever technical difficulties remain with the existing features, and wordsmithing. Bottom line: in most technical aspects, I view that that process of convergence has gotten to a pretty good state. On 12/12/2012 2:30 AM, JP Vasseur (jvasseur) wrote: > the point was that there is (no, little ?) progress in converging toward of the two options .. > > -- Regards, Charlie P. From Chris.Dearlove@baesystems.com Wed Dec 12 10:03:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C7021E80BC for ; Wed, 12 Dec 2012 10:03:57 -0800 (PST) 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 OxmqUbVwQ9SJ for ; Wed, 12 Dec 2012 10:03:54 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 9D91A21F880C for ; Wed, 12 Dec 2012 10:03:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,267,1355097600"; d="scan'208";a="249258442" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 12 Dec 2012 18:03:47 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qBCI3lhH025253 for ; Wed, 12 Dec 2012 18:03:47 GMT X-IronPort-AV: E=Sophos;i="4.84,267,1355097600"; d="scan'208";a="1005195" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 12 Dec 2012 18:03:47 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Wed, 12 Dec 2012 18:03:46 +0000 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , "JP Vasseur (jvasseur)" Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN2IuZWIOSJ3CR40WTCJGPZDoeY5gVc/qA Date: Wed, 12 Dec 2012 18:03:46 +0000 Message-ID: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> In-Reply-To: <50C8BA7E.8050200@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:03:57 -0000 I think given that there was discussion just in the last week or two on the= status of gateways, that's just one example where features aren't stable. = And I don't believe the WG has actually expressed a view on much of what's = in or not in the document. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of C= harles E. Perkins Sent: 12 December 2012 17:10 To: JP Vasseur (jvasseur) Cc: Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.t= xt) ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hello folks, On 12/12/2012 2:30 AM, JP Vasseur (jvasseur) wrote: > the point was that there is (no, little ?) progress in converging toward = of the two options .. To be clear, I am now and always have been in favor of converging these two drafts. After many months and two unsatisfactory "maintenance" releases of the WG document, I finally took unilateral action to the WG document to be fully RFC 5444 compliant as well as compatible with the design needs of LOADng, as I have discussed before. I hope that, technically at least, this process will be viewed as progressing. I remain quite open to further evolution of the draft as may be needed, but by now i hope that at least the feature set will be viewed as complete. Then what remains is resolving whatever technical difficulties remain with the existing features, and wordsmithing. Bottom line: in most technical aspects, I view that that process of convergence has gotten to a pretty good state. On 12/12/2012 2:30 AM, JP Vasseur (jvasseur) wrote: > the point was that there is (no, little ?) progress in converging toward = of the two options .. > > --=20 Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Wed Dec 12 10:11:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6295121F845E for ; Wed, 12 Dec 2012 10:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 zUL6GwT8FmIA for ; Wed, 12 Dec 2012 10:11:03 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id A48CE21F884B for ; Wed, 12 Dec 2012 10:11:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,267,1355097600"; d="scan'208";a="293715344" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 12 Dec 2012 18:10:55 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qBCIAsj2021099 for ; Wed, 12 Dec 2012 18:10:54 GMT X-IronPort-AV: E=Sophos;i="4.84,267,1355097600"; d="scan'208";a="1222801" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 12 Dec 2012 18:10:54 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0309.002; Wed, 12 Dec 2012 18:10:54 +0000 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN2IGau/UGjpjpokSVzrTdXQtBtZgVcd0A Date: Wed, 12 Dec 2012 18:10:54 +0000 Message-ID: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <3E873090-C8D3-4563-A7A4-331D2D599917@axelcdv.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF389CF@xmb-rcd-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF389CF@xmb-rcd-x03.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:11:04 -0000 I think this is self-contradictory. It says there's a lot of strife but no = interest. Strife does tend to happen more when there is interest. I think the limited amount of technical discussion on the drafts is signifi= cantly in part because people are waiting to work out which draft they shou= ld comment on. (And it's also not a great time of year.) And even so today = I see at least two people who are not authors making technical points (and = there were more over the last few days). And some points (common to both dr= afts) a week or two ago from people who aren't regulars, let alone authors. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S= tan Ratliff (sratliff) Sent: 12 December 2012 15:58 To: Axel Colin de Verdi=E8re Cc: Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.t= xt) ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Axel,=20 On Dec 11, 2012, at 6:01 PM, Axel Colin de Verdi=E8re wrote: > Hi Stan, >=20 > Le 11 d=E9c. 2012 =E0 11:03, Stan Ratliff (sratliff) = a =E9crit : >=20 >> JP,=20 >>=20 >> On Dec 10, 2012, at 9:19 PM, JP Vasseur (jvasseur) wrote: >>=20 >>> Hi Stan, >>>=20 >>> On Dec 10, 2012, at 6:58 AM, Stan Ratliff (sratliff) wrote: >>>=20 >>>> Abdussalam,=20 >>>>=20 >>>> On Dec 10, 2012, at 5:51 AM, Abdussalam Baryun wrote: >>>>=20 >>>>> On 12/7/12, Stan Ratliff (sratliff) wrote: >>>>>>=20 >>>>>> My feeling, FWIW, is that ingress/egress SHOULD be a part of the bas= e >>>>>> document. However, I understand the concerns of people that say it m= ight be >>>>>> a problem (or extend ratification time, etc etc). So, I'm interested= in >>>>>> hearing other, interested opinions - both for >>>>>> DYMO/AODVv2/Whatever-we're-calling-it-this-week, as well as with reg= ard to >>>>>> the LOADng spec. >>>>>=20 >>>>> I know from my efforts that LOADng team are not welling to discuss, o= r >>>>> reply to questions/comments, so I want to know your opinion of the >>>>> status on this LOADng draft as you brought it to the list; Is it a WG >>>>> draft? should we discuss individual or private work now? >>>>>=20 >>>>> I remember that we answered chair questions and options given. Not >>>>> sure what the chair of WG wants us to do so far, please advise, >>>>=20 >>>> It wasn't clear to me what the consensus was in Atlanta vis-a-vis the = two reactive protocol documents. Presently, DYMO is the working group accep= ted reactive protocol document. However, there was a 2-year period of time = when DYMO was inactive, and the document was "parked". As a result of that,= the effort to create LOADng sprang up.=20 >>>>=20 >>>> So now, we have two documents to consider. In the charter, the WG is "= on the hook" for 1 (and only 1) reactive protocol. So the current options a= re:=20 >>>> 1. Recognize that we cannot reach consensus with the two documents, an= d remove the charter item for reactive protocols. To be frank, this is my p= referred option.=20 >>>> 2. Accept one of the two documents (either LOADng or DYMO), and press = forward >>>> 3. Perhaps alter the charter item, and produce 2 reactive protocols, b= oth in "experimental" state.=20 >>>>=20 >>>=20 >>> JP> What about putting a hard dead-line and if there is no consensus fa= ll back to 1 ? >>=20 >> There's only one problem with that - It's already happened, and the dead= line has already passed without conclusion. ;-) It happened in Vancouver, = with a deadline of Atlanta.=20 >>=20 >> To the working group at large -=20 >>=20 >> I'm not seeing a high level of interest here. People seem to only have "= passing interest" - enough to keep the efforts on life support, but not eno= ugh to really progress things. By and large, only the authors have the incl= ination to push their respective opinions, and nothing has really changed.= =20 >=20 > I'm a bit surprised here: it seems weird to me that you can just dismiss = a 10 people behind a document, with strong industrial support (including ac= tual deployments) as "passing", or even "not enough" interest. Furthermore,= I've seen that we (the LOADng authors) are far from the only ones particip= ating on this topic. >=20 >>=20 >> So, I call once again - I think it's time to remove the work item from t= he charter, and recognize that we're not going to be able to work together = on this issue. After more than a year of trying to get people to work toget= her to make the technology better, just don't see it happening. It's time = to end the misery. >=20 > I understand your position, I think you made that clear relatively early = in the process, but I don't think "not enough interest" is really a good re= ason here. To the contrary, "Not enough interest" is a perfectly good reason for stopp= ing work. So is "we can't agree on an outcome". IMHO, *both* of these situa= tions are in effect here. Compared to the WG as a whole, there is a small s= et of people whirring and spinning on a couple of documents. Outside of tha= t small clique, we're not seeing a lot of interest (activity) on the mailin= g list. To simply state that ".we (the LOADng authors) are far from the onl= y ones participating.", without examples, is not proof - it's merely an ass= ertion. The call of whether there is "sufficient support" in the WG is admi= ttedly subjective. However, given the amount of strife on the topic, the li= kelihood that the WG will reach consensus, and the level of interest that I= gauge - I stand by my position. IMO, as co-chair, this work should be term= inated.=20 Stan >=20 > Best, >=20 > Axel >=20 >>=20 >> Regards, >> Stan >>=20 >>=20 >>=20 >>>=20 >>>> Now, you mentioned "Not sure what the chairs of WG want us to do so fa= r".. the best answer I can give you on that is "reach consensus on an appro= ach". We as a working group haven't done that yet. There are people advoca= ting for DYMO, others advocating for LOADng, and some that want to "merge" = the technology of the two together. A "merge" was something we tried in the= Vancouver timeframe, but that effort failed.=20 >>>>=20 >>>> As to your statement that the LOADng team is not willing to discuss - = I haven't seen that, do not agree with it, and would ask you to cite *speci= fic* examples if you have them. I've found the LOADng team to be reasonable= in their dealings with the WG. There is the issue of re-spinning the LOADn= g document without the copyright statement - The LOADng authors and the cha= irs have reached an understanding about that issue, so I no longer have a p= roblem with moving forward on that front.=20 >>>>=20 >>>> Again, as a working group - we *MUST* either reach a consensus, or the= work item will be removed *for us*. If we do not show progress towards a g= oal, it is within the power of the IESG to stop work on the issue. >>>>=20 >>>> Regards, >>>> Stan >>>>=20 >>>>=20 >>>>>=20 >>>>> AB >>>>>=20 >>>>>>=20 >>>>>> And lastly... if the 5 guys were *that* important, they most likely = wouldn't >>>>>> be *playing* black-ops. ;-) >>>>>>=20 >>>>>> Stan >>>>>>=20 >>>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From charliep@computer.org Wed Dec 12 10:39:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2B91F0CC7 for ; Wed, 12 Dec 2012 10:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 hH2lE4zR7YQD for ; Wed, 12 Dec 2012 10:39:52 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id C26F71F0CCE for ; Wed, 12 Dec 2012 10:39:52 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TirDk-000703-6i; Wed, 12 Dec 2012 13:39:52 -0500 Message-ID: <50C8CF75.1090406@computer.org> Date: Wed, 12 Dec 2012 10:39:49 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8687581b627542112bc1d6a0c68b1caee5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "" Subject: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:39:55 -0000 Hello Chris, Yes, if the WG decides to put in something about gateways in the document, that will require more work. I don't know if you had a look at the expired document that I posted a few days ago on the subject of gateways, but the discussion on the list also in my opinion shows that the matter is not settled for OLSRv2 either. I'm sure you can sift through the emails and find various points that are not settled and still worthy of discussion. I strongly believe that the subject is important enough to merit a separate effort. And, while it is true that proactive is easier, there are many design issues in common, so that a separate document could be made to apply to both proactive and reactive. Perhaps after my local fires (IEEE, etc.) have died down in a few more days, I'll write up a requirements draft for Gateways that enumerates the issues raised here on the list as well as others discussed in the past. It's not as easy as just saying "0/0". On 12/12/2012 10:03 AM, Dearlove, Christopher (UK) wrote: > I think given that there was discussion just in the last week or two on the status of gateways, that's just one example where features aren't stable. And I don't believe the WG has actually expressed a view on much of what's in or not in the document. > -- Regards, Charlie P. From adrian@olddog.co.uk Wed Dec 12 10:40:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7511F0CC2 for ; Wed, 12 Dec 2012 10:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 e54uEv92J4dN for ; Wed, 12 Dec 2012 10:40:47 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1991F0CBE for ; Wed, 12 Dec 2012 10:40:47 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBCIejbW010566 for ; Wed, 12 Dec 2012 18:40:45 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBCIeiYJ010556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 12 Dec 2012 18:40:44 GMT From: "Adrian Farrel" To: Date: Wed, 12 Dec 2012 18:40:42 -0000 Message-ID: <09e601cdd898$311598e0$9340caa0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3YmC9YjM2PhmecQ7Ot0wVXEVhD6Q== Content-Language: en-gb Subject: [manet] OLSR deployments X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:40:50 -0000 Hi, Could people (on or off list) let me know of any OLSR deployments (carrying live traffic) of which they are aware. These may be long-term (as community networks) or short-term (as disaster relief). I would also like to know whether they are self-contained networks or allow access (through some kind of gateway) to the Internet. Thanks, Adrian From teco@inf-net.nl Wed Dec 12 11:12:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0018B21E811F for ; Wed, 12 Dec 2012 11:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] 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 UTSuTvcGwZOi for ; Wed, 12 Dec 2012 11:12:25 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF2021E808D for ; Wed, 12 Dec 2012 11:12:23 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so372017eaa.31 for ; Wed, 12 Dec 2012 11:12:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=i098GvR9k711VoAOyVRVl26HPWsz2qTVMUY7YuvQOsc=; b=BZERAogB0lr7UvKsR5ZR7n2yESzBJFq7hiSARK2AtrPqMrrGGLSZbG1m+pABhTJd1O GHzsZdkcC55jcE/hxLLxiUsEE8YN3da0H4EVCzHtqXbCcYxPeZFkO6z6PO9fkG80P/5L d5wEHmLq5nxJGqQ++OFoPhLPGIRRq2J1LTQu3KirxEEJ+8KKd4ak7bPT6wOf2xTCeypb zSbbJ9DWC3xWsxh9n8g73pwruI2vKoKVqJHuGBCFfFbttwlBmCnY7gx0wWsuyNPRgKVM iJtPwrTYCvMeMya7o1U8PL4KjayRdC1y/yC2ifrMGXIvjpHCCjGoV9yji90e5oeDgjQ/ ldHg== Received: by 10.14.206.197 with SMTP id l45mr5269784eeo.17.1355339542441; Wed, 12 Dec 2012 11:12:22 -0800 (PST) Received: from [10.175.173.30] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id q44sm57690052eep.5.2012.12.12.11.12.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2012 11:12:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <09e601cdd898$311598e0$9340caa0$@olddog.co.uk> Date: Wed, 12 Dec 2012 20:12:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <09e601cdd898$311598e0$9340caa0$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkp8dX4MfHgmG1IGzfte905ShwWCC01MpMlRbfkx8aB0FKwSu5ss0BLeZULEWNVz4k8BMtm Cc: manet@ietf.org Subject: Re: [manet] OLSR deployments X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 19:12:31 -0000 I'm involved in a operational pilot network for public safety, that uses = olsr.org code. It runs ETX, thus non-RFC-compliant mode. Network is = rather small (~30 nodes). There are more links to the Internet than the = number of nodes. That is because nodes have at least one link to the = Internet. Some have multiple. Without ETX, it didn't work well. Better link metrics is work in = progress. Peer discovery (similar to mdns) is supported. Implementing SmartGateway (the enhanced version) is work in progress. Follow-up expanding the network will come. Takes time. Update to olsrv2 is not a short term goal. Same for IPv6. Teco Op 12 dec. 2012, om 19:40 heeft Adrian Farrel het volgende geschreven: > Hi, >=20 > Could people (on or off list) let me know of any OLSR deployments = (carrying live > traffic) of which they are aware. >=20 > These may be long-term (as community networks) or short-term (as = disaster > relief). >=20 > I would also like to know whether they are self-contained networks or = allow > access (through some kind of gateway) to the Internet. >=20 > Thanks, > Adrian >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From aaron@lo-res.org Wed Dec 12 14:13:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DC121F882C for ; Wed, 12 Dec 2012 14:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RDNS_DYNAMIC=0.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 DSW9pnO4zMLE for ; Wed, 12 Dec 2012 14:13:22 -0800 (PST) Received: from mate.lo-res.org (mate.lo-res.org [193.238.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id E203921F8848 for ; Wed, 12 Dec 2012 14:13:21 -0800 (PST) Received: by mate.lo-res.org (Postfix, from userid 65534) id 176EB405FB; Wed, 12 Dec 2012 23:13:19 +0100 (CET) Received: from [192.168.101.103] (chello080108029230.5.11.vie.surfer.at [80.108.29.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mate.lo-res.org (Postfix) with ESMTPSA id 4F04440444; Wed, 12 Dec 2012 23:13:15 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "L. Aaron Kaplan" In-Reply-To: <09e601cdd898$311598e0$9340caa0$@olddog.co.uk> Date: Wed, 12 Dec 2012 23:13:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <09e601cdd898$311598e0$9340caa0$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1499) Cc: manet@ietf.org Subject: Re: [manet] OLSR deployments X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 22:13:23 -0000 Adrian, I can only talk about wireless *community* networks. There are lots = of other OLSR deployments in the military and in other contexts. to the best of my knowledge, most community wireless *mesh* (in the = sense of MANET) networks use OLSR.org's OLSR implementation. This has a couple of reasons: * it was the first working mesh protocol and in ~ 2003 when most = community wireless networks got started and ant to full speed, that was = the only solid solution we had * the community wireless networks (Funkfeuer, Freifunk) invested lots = of time and money to turn OLSR.org's implementation into a = "product"-grade solution (read: it does not suck that much anymore) * our results were published as open source on wikis, hence people = copied and adapted our work. I am aware that there are large wireless community Wi-Fi networks which = mainly use BGP (internal BGP). Usually the reason for this is that the = Mikrotik platform has a BGP implementation but no well rounded "mesh" = implementation (at least multiple people who tried it were not happy = with that implementation). Mikrotik is pretty much a turn key solution and wide spread in the WISP = scene. Please also have a look at (the incomplete list at): = http://en.wikipedia.org/wiki/List_of_wireless_community_networks_by_region= https://personaltelco.net/wiki/WirelessCommunities I hope this answers some of your questions.=20 =20 Aaron. On Dec 12, 2012, at 7:40 PM, Adrian Farrel wrote: > Hi, >=20 > Could people (on or off list) let me know of any OLSR deployments = (carrying live > traffic) of which they are aware. >=20 > These may be long-term (as community networks) or short-term (as = disaster > relief). >=20 > I would also like to know whether they are self-contained networks or = allow > access (through some kind of gateway) to the Internet. >=20 > Thanks, > Adrian >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From marius@itee.uq.edu.au Wed Dec 12 17:25:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE0221F8A93 for ; Wed, 12 Dec 2012 17:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.687 X-Spam-Level: X-Spam-Status: No, score=-0.687 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] 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 Kq11IpWrjorO for ; Wed, 12 Dec 2012 17:25:44 -0800 (PST) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by ietfa.amsl.com (Postfix) with ESMTP id 6942421F8A78 for ; Wed, 12 Dec 2012 17:25:42 -0800 (PST) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id qBD1PabV019508; Thu, 13 Dec 2012 11:25:36 +1000 Received: from UQEXET2.soe.uq.edu.au (uqexet2.soe.uq.edu.au [130.102.129.39]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id qBD1PaDH030678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Dec 2012 11:25:36 +1000 Received: from uqexht4.soe.uq.edu.au (130.102.129.73) by UQEXET2.soe.uq.edu.au (130.102.129.39) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 13 Dec 2012 11:25:36 +1000 Received: from UQEXMDA8.soe.uq.edu.au ([169.254.5.195]) by uqexht4.soe.uq.edu.au ([130.102.129.73]) with mapi id 14.01.0355.002; Thu, 13 Dec 2012 11:25:36 +1000 From: Marius Portmann To: Abdussalam Baryun Thread-Topic: [manet] DYMO/AODVv2 and LOADng -- Problems and Proposed Solutions Thread-Index: AQHN0jCtRmCvxt76pEi0HB90Lq5yaJgV09Xw Date: Thu, 13 Dec 2012 01:25:34 +0000 Message-ID: <55276FFE1B06A541A659C0B360E8066F181433@UQEXMDA8.soe.uq.edu.au> References: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.102.64.21] Content-Type: multipart/alternative; boundary="_000_55276FFE1B06A541A659C0B360E8066F181433UQEXMDA8soeuqedua_" MIME-Version: 1.0 X-UQ-FilterTime: 1355361938 X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub Cc: "manet@ietf.org" Subject: Re: [manet] DYMO/AODVv2 and LOADng -- Problems and Proposed Solutions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 01:25:48 -0000 --_000_55276FFE1B06A541A659C0B360E8066F181433UQEXMDA8soeuqedua_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Abdussalam, Thanks for your feedback, and apologies for the delayed reply. > Thanks for your feedback and references, but your analysis will be > more interesting if I know when/how such disadvantages happen in > your work done so far. Could you inform on the list of the > evaluation you done as including number of nodes, mobility model, etc. So far we have not performed any experimental quantitative evaluation on an= y particular network scenarios. However, we believe if there is an identified limitation in a protocol, eve= n if the corresponding problem might occur relatively rarely, and if the li= mitation has a simple, robust and low cost solution, it is worth implementi= ng it. > No protocol is perfect in general :) True, but protocols should be as good as possible, within all the given con= straints. :) Cheers Rob, Peter, Marius and Wee Lum From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: Wednesday, 5 December 2012 1:05 AM To: Marius Portmann Cc: manet@ietf.org Subject: Re: [manet] DYMO/AODVv2 and LOADng -- Problems and Proposed Soluti= ons Hi Marius Thanks for your feedback and references, but your analysis will be more int= eresting if I know when/how such disadvantages happen in your work done so = far. Could you inform on the list of the evaluation you done as including n= umber of nodes, mobility model, etc. However, when I get time to read your = references I can reply better. No protocol is perfect in general :) AB On Tue, Dec 4, 2012 at 5:21 AM, Marius Portmann > wrote: We have been following the recent discussion on DYMO and LOADng with intere= st, and would like to share some of our findings and experience in this con= text, in the hope of being able to make a constructive contribution. Any fe= edback is appreciated. Based on a careful analysis of AODV, we have encountered problems that stil= l persist in both DYMO (ver 23) and LOADng (ver 6). (1) Non-Optimal Routes -------------------------------- On-demand/reactive routing protocols (such as AODV, DYMO and LOADng) often = fail to discover the best (shortest) routes [1,2]. The problem is that during route discovery the destination (target) node do= es not forward route requests; so, nodes that lie downstream of the destina= tion node frequently create non-optimal routes to the source. Knightly and = Miskovic [1] have shown that "poorly selected paths can have significantly = higher routing-metric costs, and their duration can extend to minute time s= cales". We have verified that this problem exists in DYMO and LOADng. As a possible solution, we propose that route requests are always forwarded= , even by nodes generating a route reply [2,3]. The forwarded request shoul= d include a flag stating that a reply has already been initiated. In [3] it= is shown that this increases the quality of routes. Of course this could i= ncrease the overhead of control messages, but in most of the cases the addi= tional overhead is minimal, since a request floods the entire network anywa= y. (2) Route Reply Loss ----------------------------- AODV can lose route replies (http://www.ietf.org/mail-archive/web/manet/cur= rent/msg05702.html). The reason is that route replies are only forwarded by an intermediate node= when the node updates its routing table. This problem has partly been solved in DYMO and LOADng by increasing sequen= ce numbers when initiating a route reply. However, a careful analysis shows that replies can still be lost; yielding = again non-optimal routes or route discovery failures. Namely, if one route = reply overtakes another, i.e., a newer reply reaches a node earlier than an= older one, then the older route reply is dropped [4]. A solution consists of intermediate nodes always forwarding route replies. = Surely, forwarding (unicasting) replies increases the number of messages in= the network. But, (a) route discovery is more likely and (b) re-sending a = route request to establish a route would yield another broadcast cycle, wh= ich is much more expensive w.r.t. network load. (3) Route Request Loss --------------------------------------------- Similar to (2), route requests might be lost in DYMO and LOADng. Namely, if one route request overtakes another, i.e., a newer request reach= es a node earlier than an older one, then the older route request is droppe= d. This problem does not occur in AODV, thanks to the use of a list of previou= sly seen RREQ IDs. --------------------------------------------- If requested we can provide more detailed explanations and examples. Rob van Glabbeek Peter H=F6fner Marius Portmann Wee Lum Tan (a team of networks and formal methods researchers at NICTA, working on for= mally modelling and analysing MANET routing protocols) cheers Marius References --------------- [1] S. Miskovic and E. W. Knightly, "Routing primitives for wireless mesh n= etworks: Design, analysis and experiments", in Conference on Information Co= mmunications (INFOCOM'10). IEEE, 2010, pp. 2793-2801. networks.rice.edu/papers/MeshRoutingPrimitives.pdf [2] P. H=F6fner, R. J. van Glabbeek, W. L. Tan, M. Portmann, A. McIver, and= A. Fehnker, "A rigorous analysis of AODV and its variants", in Modeling, A= nalysis and Simulation of Wireless and Mobile Systems (MSWIM'12). ACM Press= , 2012. doi:10.1145/2387238.2387274 http://www.cse.unsw.edu.au/~rvg/pub/mswim12.pdf [3] A. Fehnker, R. J. van Glabbeek, P. H=F6fner, A. McIver, M. Portmann, an= d W. L. Tan, "Automated analysis of AODV using UPPAAL", in Tools and Algori= thms for the Construction and Analysis of Systems (TACAS'12), LNCS, C. Flan= agan and B. K=F6nig, Eds., vol. 7214. Springer, 2012, pp. 173-187. doi:10.1= 007/978-3-642-28756-5_13 http://www.cse.unsw.edu.au/~rvg/pub/tacas12.pdf [4] P. H=F6fner, and S. Edenhofer, "Towards a Rigorous Analysis of AODVv2 (= DYMO)", in Workshop on Rigorous Protocol Engineering, IEEE http://www.nicta.com.au/pub?id=3D6169 ---------------------------------------------------------------------- Dr Marius Portmann School of ITEE The University of Queensland Brisbane 4072, Australia CRICOS Provider No: 00025B Tel: +61 7 3300 8561, Fax: +61 7 3365 4999 ---------------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_55276FFE1B06A541A659C0B360E8066F181433UQEXMDA8soeuqedua_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Abdussalam,

 

Thanks for your feedback, and apologies for the delayed r= eply.

 

> Thanks for your feedback and references, but your an= alysis will be

> more interesting if I know when/how such disadvantag= es happen in

> your work done so far. Could you inform on the list = of the

> evaluation you done as including number of nodes, mo= bility model, etc.

 

So far we have not performed any experimental quantitativ= e evaluation on any particular network scenarios.<= /p>

 

However, we believe if there is an identified limitation = in a protocol, even if the corresponding problem might occur relatively rar= ely, and if the limitation has a simple, robust and low cost solution, it is worth implementing it.

 

> No protocol is perfect in general :)

 

True, but protocols should be as good as possible, within= all the given constraints. J

 

Cheers

Rob, Peter, Marius and Wee Lum

=  

=  

=  

=  

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: Wednesday, 5 December = 2012 1:05 AM
To: Marius Portmann
Cc: manet@ietf.org
Subject: Re: [manet] DYMO/AO= DVv2 and LOADng -- Problems and Proposed Solutions=

 

Hi Marius

 

Thanks for your feedback and references, but your an= alysis will be more interesting if I know when/how such disadvantages happe= n in your work done so far. Could you inform on the list of the evaluation you done as including number of nodes, mobil= ity model, etc. However, when I get time to read your references I can repl= y better.

 

No protocol is perfect in general :)

 

AB<= /font>

On Tue, Dec 4, 2012 at 5:21 AM, Marius Portmann <= marius@itee.uq.e= du.au> wrote:

We have been follow= ing the recent discussion on DYMO and LOADng with interest, and would like to share some of our findings and experience in this context, i= n the hope of being able to make a constructive contribution. Any feedback = is appreciated.

 

Based on a careful = analysis of AODV, we have encountered problems that still persist in both DYMO (ver 23) and LOADng (ver 6).

 

(1) Non-Optimal Rou= tes

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

On-demand/reactive = routing protocols (such as AODV, DYMO and LOADng) often fail to discover the best (shortest) routes [1,2].

 

The problem is that= during route discovery the destination (target) node does not forward route requests; so, nodes that lie downstream of the destinat= ion node frequently create non-optimal routes to the source. Knightly = and Miskovic [1] have shown that "poorly selected paths can have = significantly higher routing-metric costs, and their duration can extend to minute time scales". <= /o:p>

We have verified th= at this problem exists in DYMO and LOADng.

 

As a possible solut= ion, we propose that route requests are always forwarded, even by nodes generating a route reply [2,3]. The forwarded request should= include a flag stating that a reply has already been initiated. In [3] it = is shown that this increases the quality of routes. Of course this cou= ld increase the overhead of control messages, but in most of the cases the additional overhead is minimal, since&nb= sp;a request floods the entire network anyway.

  =

(2) Route Reply Los= s

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

AODV can lose route= replies (http://www.ietf.org/mail-archive/web/manet/cu= rrent/msg05702.html). 

The reason is that = route replies are only forwarded by an intermediate node when the node updates its routing table. 

This problem has pa= rtly been solved in DYMO and LOADng by increasing sequence numbers when initiating a route reply.

However, a careful = analysis shows that replies can still be lost; yielding again non-optimal routes or route discovery failures. Namely, if one route = reply overtakes another, i.e., a newer reply reaches a node earlier than an= older one, then the older route reply is dropped [4].

 

A solution consists= of intermediate nodes always forwarding route replies. Surely, forwarding (unicasting) replies increases the number of messages in the ne= twork. But, (a) route discovery is more likely and (b) re-sending a route r= equest to establish a route would yield another broadcast  cycle, whic= h is much more expensive w.r.t. network load.

 

(3) Route Request L= oss

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

Similar to (2),&nbs= p;route requests might be lost in DYMO and LOADng.=

Namely, if one rout= e request overtakes another, i.e., a newer request reaches a node earlier than an older one, then the older route request is dropped.=

This problem does n= ot occur in AODV, thanks to the use of a list of previously seen RREQ IDs.

 

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


If requested we can provide  more detailed explanations and examples.<= /span>

 

 

Rob van Glabbeek

Peter H=F6fner

Marius Portmann

Wee Lum Tan<= /font>

(a team of networks= and formal methods researchers at NICTA, working on formally modelling and analysing MANET routing protocols)<= /p>

 

 

cheers

Marius

 

 

 

References

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

[1] S. Miskovic and= E. W. Knightly, "Routing primitives for wireless mesh networks: Design, analysis and experiments", in Conference on Information Commu= nications (INFOCOM’10). IEEE, 2010, pp. 2793-2801.=

networ= ks.rice.edu/papers/MeshRoutingPrimitives.pdf

[2] P. H=F6fner, R.= J. van Glabbeek, W. L. Tan, M. Portmann, A. McIver, and A. Fehnker, "A rigorous analysis of AODV and its variants", in Modeling, Ana= lysis and Simulation of Wireless and Mobile Systems (MSWIM’12). ACM&n= bsp;Press, 2012. doi:10.1145/2387238.2387274<= /p>

http://www.cse.u= nsw.edu.au/~rvg/pub/mswim12.pdf

[3] A. Fehnker= , R. J. van Glabbeek, P. H=F6fner, A. McIver, M. Portmann, and W. L. Tan, "Automated analysis of AODV using UPPAAL", in Tools and Alg= orithms for the Construction and Analysis of Systems (TACAS’12), LNCS= , C. Flanagan and B. K=F6nig, Eds., vol. 7214. Springer, 2012, pp. 173̵= 1;187. doi:10.1007/978-3-642-28756-5_13

http://www.cse.u= nsw.edu.au/~rvg/pub/tacas12.pdf

[4] P. H=F6fner, and S. E= denhofer, "Towards a Rigorous Analysis of AODVv2 (DYMO)", in Work= shop on Rigorous Protocol Engineering, IEEE
http://= www.nicta.com.au/pub?id=3D6169

 =

 =

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

Dr Marius Portmann=

School of ITEE

The University of Queensl= and

Brisbane 4072, Australia<= /span>

CRICOS Provider No: 00025= B

Tel: +61 7 3300 85= 61, Fax: +61 7 3365 4999

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

 

 =


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

 

--_000_55276FFE1B06A541A659C0B360E8066F181433UQEXMDA8soeuqedua_-- From marius@itee.uq.edu.au Wed Dec 12 17:50:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A49A21E808F for ; Wed, 12 Dec 2012 17:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.291 X-Spam-Level: X-Spam-Status: No, score=-1.291 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] 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 DVbCOHIS7EEO for ; Wed, 12 Dec 2012 17:50:44 -0800 (PST) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by ietfa.amsl.com (Postfix) with ESMTP id 5245F21E8039 for ; Wed, 12 Dec 2012 17:50:43 -0800 (PST) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id qBD1odZP024895; Thu, 13 Dec 2012 11:50:39 +1000 Received: from UQEXET2.soe.uq.edu.au (uqexet2.soe.uq.edu.au [130.102.129.39]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id qBD1odH4011251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Dec 2012 11:50:39 +1000 Received: from UQEXHT1.soe.uq.edu.au (130.102.129.70) by UQEXET2.soe.uq.edu.au (130.102.129.39) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 13 Dec 2012 11:50:38 +1000 Received: from UQEXMDA8.soe.uq.edu.au ([169.254.5.195]) by UQEXHT1.soe.uq.edu.au ([130.102.129.70]) with mapi id 14.01.0355.002; Thu, 13 Dec 2012 11:50:38 +1000 From: Marius Portmann To: "'Jiazi YI'" Thread-Topic: [manet] DYMO/AODVv2 and LOADng -- Problems and Proposed Solutions Thread-Index: AQHN0w6+uFA+Akn6XUeqUe1ZJEY26pgWADMg Date: Thu, 13 Dec 2012 01:50:37 +0000 Message-ID: <55276FFE1B06A541A659C0B360E8066F18151D@UQEXMDA8.soe.uq.edu.au> References: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.102.64.21] Content-Type: multipart/alternative; boundary="_000_55276FFE1B06A541A659C0B360E8066F18151DUQEXMDA8soeuqedua_" MIME-Version: 1.0 X-UQ-FilterTime: 1355363441 X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub Cc: "'manet@ietf.org'" Subject: Re: [manet] DYMO/AODVv2 and LOADng -- Problems and Proposed Solutions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 01:50:48 -0000 --_000_55276FFE1B06A541A659C0B360E8066F18151DUQEXMDA8soeuqedua_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Jiazi, >> (1) Non-Optimal Routes >> ---------------------- >> On-demand/reactive routing protocols (such as AODV, DYMO and >> LOADng) often fails to discover the best (shortest) routes [1,2]. > In LOADng, only bi-directional routes are used by default, i.e. only > the routes that are verified by RREP are used. So I think the example > you mentioned in figure 2 of [3,4] shouldn't be a problem for LOADng. As of yet we are not convinced that this covers all cases. Isn't it the case that in LOADng a bidirectional routing entry can be updated with new information from a RREQ message, and keep its flag saying that the route is bidirectional? If yes, then we can adapt our example to apply to LOADng: see http://www.cse.unsw.edu.au/~rvg/LOADng-non-optimal-routes.pdf >> (2) Route Reply Loss >> -------------------- >> AODV can lose route replies (http://www.ietf.org/mail-archive/web/manet/= current/msg05702.html). >> The reason is that route replies are only forwarded by an >> intermediate node when the node updates its routing table. > I think it would be safe to forward every unicast RREPs. > > In the meantime, I'm wondering how often the situation that you > mentioned in fig 1 of [4] would happen. Because it requires 1) two > RREPs are generated in very short time interval and 2) The route > set up by broadcasting two RREQs between the two nodes (B and T in > your example) are different. True. But even if the situation doesn't occur that often, we think a the proposed fix comes without significant cost in communication overhead, and thus is preferable to accepting the occasional loss of RREPs. >> (3) Route Request Loss >> ---------------------- >> Similar to (2), route requests might be lost in DYMO and LOADng. >> Namely, if one route request overtakes another, i.e., a newer >> request reaches a node earlier than an older one, then the older >> route request is dropped. This problem does not occur in AODV, >> thanks to the use of a list of previously seen RREQ IDs. > Could you please have an example of this? We created one at http://www.cse.unsw.edu.au/~rvg/route-request-loss.pdf > What you said, the case that a newer RREQ reaches a node earlier > than an older one, shouldn't happen. Because in LOADng, the > originator of RREQ has a rate limit, i.e. certain interval. If an > old RREQ came to an intermediate router that slow, probably it > shouldn't be forwarded anyway, because it has great possibility to > carry bad route information. In the example in the above link, the dropped RREQ1 does come along a route that is no longer optimal, but it should be forwarded anyway to make sure the destination d learns about the request. Forwarding will result in a bidirectional route between s and d that doesn't use the detour= . We hope this makes sense. Best regards, Rob, Peter, Marius and Wee Lum References --------------- [1] S. Miskovic and E. W. Knightly, "Routing primitives for wireless mesh n= etworks: Design, analysis and experiments", in Conference on Information Co= mmunications (INFOCOM'10). IEEE, 2010, pp. 2793-2801. networks.rice.edu/papers/MeshRoutingPrimitives.pdf [2] P. H=F6fner, R. J. van Glabbeek, W. L. Tan, M. Portmann, A. McIver, and= A. Fehnker, "A rigorous analysis of AODV and its variants", in Modeling, A= nalysis and Simulation of Wireless and Mobile Systems (MSWIM'12). ACM Press= , 2012. doi:10.1145/2387238.2387274 http://www.cse.unsw.edu.au/~rvg/pub/mswim12.pdf [3] A. Fehnker, R. J. van Glabbeek, P. H=F6fner, A. McIver, M. Portmann, an= d W. L. Tan, "Automated analysis of AODV using UPPAAL", in Tools and Algori= thms for the Construction and Analysis of Systems (TACAS'12), LNCS, C. Flan= agan and B. K=F6nig, Eds., vol. 7214. Springer, 2012, pp. 173-187. doi:10.1= 007/978-3-642-28756-5_13 http://www.cse.unsw.edu.au/~rvg/pub/tacas12.pdf [4] P. H=F6fner, and S. Edenhofer, "Towards a Rigorous Analysis of AODVv2 (= DYMO)", in Workshop on Rigorous Protocol Engineering, IEEE http://www.nicta.com.au/pub?id=3D6169 --_000_55276FFE1B06A541A659C0B360E8066F18151DUQEXMDA8soeuqedua_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Jiazi,

>> (1) Non-Optimal Routes
>> ----------------------
>> On-demand/reactive routing protocols (such as AODV, DYMO and
>> LOADng) often fails to discover the best (shortest) routes [1,2].<= br>


> In LOADng, only bi-directional routes are used by default, i.e. only > the routes that are verified by RREP are used. So I think the example<= br> > you mentioned in figure 2 of [3,4] shouldn't be a problem for LOADng. =  

As of yet we are not convinced that this covers all cases.
Isn't it the case that in LOADng a bidirectional routing entry can be
updated with new information from a RREQ message, and keep its flag saying<= br> that the route is bidirectional? If yes, then we can adapt our example
to apply to LOADng: see
   http://www.cse.unsw.edu.au/~rvg/LOADng-non-optimal-routes.= pdf

>> (2) Route Reply Loss
>> --------------------
>> AODV can lose route replies (http://www.ietf.org/mail-archive/we= b/manet/current/msg05702.html).
>> The reason is that route replies are only forwarded by an
>> intermediate node when the node updates its routing table.


> I think it would be safe to forward every unicast RREPs.
>
> In the meantime, I'm wondering how often the situation that you
> mentioned in fig 1 of [4] would happen. Because it requires 1) two
> RREPs are generated in very short time interval and 2) The route<= /o:p>

> set up by broadcasting two RREQs between the tw= o nodes (B and T in
> your example) are different.

True. But even if the situation doesn't occur that often, we think a
the proposed fix comes without significant cost in communication overhead,<= br> and thus is preferable to accepting the occasional loss of RREPs.

>> (3) Route Request Loss
>> ----------------------
>> Similar to (2), route requests might be lost in DYMO and LOADng. >> Namely, if one route request overtakes another, i.e., a newer
>> request reaches a node earlier than an older one, then the older >> route request is dropped.  This problem does not occur in AOD= V,
>> thanks to the use of a list of previously seen RREQ IDs.

> Could you please have an example of this?

We created one at http://www.cse.unsw.edu.au/~rvg/route-request-loss.pdf

> What you said, the case that a newer RREQ reaches a node earlier
> than an older one, shouldn't happen. Because in LOADng, the
> originator of RREQ has a rate limit, i.e. certain interval. If an
> old RREQ came to an intermediate router that slow, probably it
> shouldn't be forwarded anyway, because it has great possibility to
> carry bad route information.

In the example in the above link, the dropped RREQ1 does come along a
route that is no longer optimal, but it should be forwarded anyway to
make sure the destination d learns about the request. Forwarding will
result in a bidirectional route between s and d that doesn't use the detour= .

 

We hope this makes sense.

Best regards,
Rob, Peter, Marius and Wee Lum

=  

=  

=  

Refer= ences

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

[1] S= . Miskovic and E. W. Knightly, "Routing primitives for wireless mesh n= etworks: Design, analysis and experiments", in Conference on Informati= on Communications (INFOCOM’10). IEEE, 2010, pp. 2793-2801.

networks.rice.edu/papers/MeshRout= ingPrimitives.pdf

[2] P= . H=F6fner, R. J. van Glabbeek, W. L. Tan, M. Portmann, A. McIver, and A. F= ehnker, "A rigorous analysis of AODV and its variants", in Modeli= ng, Analysis and Simulation of Wireless and Mobile Systems (MSWIM’12). A= CM Press, 2012. doi:10.1145/2387238.2387274

http://www.cse.unsw.edu.au/~rvg/pub/mswim12= .pdf

[3]&n= bsp;A. Fehnker, R. J. van Glabbeek, P. H=F6fner, A. McIver, M. Portmann, an= d W. L. Tan, "Automated analysis of AODV using UPPAAL", in Tools = and Algorithms for the Construction and Analysis of Systems (TACAS’12), = LNCS, C. Flanagan and B. K=F6nig, Eds., vol. 7214. Springer, 2012, pp. 173&= #8211;187. doi:10.1007/978-3-642-28756-5_13

http://www.cse.unsw.edu.au/~rvg/pub/tacas12= .pdf

[4] P. H=F6fner, and S. Edenhofer, "Towards = a Rigorous Analysis of AODVv2 (DYMO)", in Workshop on Rigorous Protoco= l Engineering, IEEE
http://www.nicta.= com.au/pub?id=3D6169

--_000_55276FFE1B06A541A659C0B360E8066F18151DUQEXMDA8soeuqedua_-- From henning.rogge@fkie.fraunhofer.de Wed Dec 12 23:39:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FBA21F8A8F for ; Wed, 12 Dec 2012 23:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.152 X-Spam-Level: X-Spam-Status: No, score=-1.152 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 f4SBh01Wdq+Y for ; Wed, 12 Dec 2012 23:39:54 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 0824321F88B2 for ; Wed, 12 Dec 2012 23:39:53 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tj3OZ-0001FV-WE for manet@ietf.org; Thu, 13 Dec 2012 08:39:52 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tj3OZ-0001Uz-Tb for manet@ietf.org; Thu, 13 Dec 2012 08:39:51 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 13 Dec 2012 08:39:51 +0100 Message-ID: <50C98640.7010001@fkie.fraunhofer.de> Date: Thu, 13 Dec 2012 08:39:44 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> In-Reply-To: <50C8CF75.1090406@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020609090406040209090808" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/15759/Thu Dec 13 07:37:38 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: ce4bc42c0f341c6b36ab5749a0b03868 Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 07:39:55 -0000 --------------ms020609090406040209090808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 12/12/2012 07:39 PM, Charles E. Perkins wrote: > > Hello Chris, > > Yes, if the WG decides to put in something about gateways in the > document, that will require more work. I don't know if you had > a look at the expired document that I posted a few days ago on > the subject of gateways, but the discussion on the list also in my > opinion shows that the matter is not settled for OLSRv2 either. > I'm sure you can sift through the emails and find various points > that are not settled and still worthy of discussion. The difference is that OLSRv2 (and OLSRv1) contains the tool to handle=20 all kind of network situations be propagating any kind of prefix through = the network. This is the basis of internet uplinks and attached networks.= AODVv2 does not. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms020609090406040209090808 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEyMTMwNzM5NDlaMCMGCSqGSIb3DQEJBDEWBBToVIoMx/XZluOPykrmn7yLs+JLejBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAMVqZ25X/p8Xon4Uf28zA7cYdks52bz8TikijN46IKvmm cjlWJ1FjizAc3tHc+eyKafOB14J2TPdd6K5Fy4x9p1csWgga+aZ+Sxe0SeBnZFh5fuDgjpwA es3IW+dF5AIOqPOY9DzQb5Iuw3xr9DswpgTyVTLr8cqiO/21QtHoaMvnUxMmrmxVsls/2X18 A30eJyBl247JZaucKasZyxdmdwJpMe1VpRq8blDRrADp7Ah+EwRZZjZ77YWWj3junITFRyn5 d5nFIvelBMJjf2aKcSboxYPqbJ3eNn+/8bcWURo+l+zSROzlo1BZGgqKBtmtr7iJiaUu7tbF DYinjZHeSgAAAAAAAA== --------------ms020609090406040209090808-- From yi.jiazi@gmail.com Thu Dec 13 05:56:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BC621F8AD2 for ; Thu, 13 Dec 2012 05:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 3dqCDnU7XU-3 for ; Thu, 13 Dec 2012 05:56:19 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 890E421F8AD1 for ; Thu, 13 Dec 2012 05:56:18 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1303200eek.31 for ; Thu, 13 Dec 2012 05:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=6WDZA3MmAylFbnBL5+srquwVwSaf/x3BE19DEMY4/2Q=; b=KUKVr8tjZrIN6A537BgAsFiqb8tjR+fssqf6D+CneKTKANcbcEDm3ySfRLn1hzWVsq hecUZOSbVS2HfU+AKIFFPzKxK+2ln/3SiP3Qhqmvk9505Vm9IOw4grJl5nwl5UhiEcUI uyu0CzuVkRcyP2GnGYxsqATd+PsoNvM3ETJ1GSrI2ngriCQtsW733MvfUr84x3Q1ZdFm ElTIgsQUYT36HXesMkj1Z1zazXVZE2EWIVDfu45ELD8QBuY9HkKw1VMho6Gva/JL+Qog /2WgmW5+nXdHm8fR/rErl4+bST4YQYiZKmKeks+rVOKAZ0wLAMdSK35YxKB4DlfQDvKl c+FQ== Received: by 10.14.175.133 with SMTP id z5mr5550629eel.15.1355406977580; Thu, 13 Dec 2012 05:56:17 -0800 (PST) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id r1sm3149294eeo.2.2012.12.13.05.56.16 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 05:56:17 -0800 (PST) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_9A5CFA7F-99C2-4165-9D3B-827A44086F60" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi YI In-Reply-To: <55276FFE1B06A541A659C0B360E8066F18151D@UQEXMDA8.soe.uq.edu.au> Date: Thu, 13 Dec 2012 14:56:12 +0100 Message-Id: <45D5364A-4C21-4053-BE77-23F323C15276@jiaziyi.com> References: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> <55276FFE1B06A541A659C0B360E8066F18151D@UQEXMDA8.soe.uq.edu.au> To: Marius Portmann X-Mailer: Apple Mail (2.1499) Cc: "'manet@ietf.org'" Subject: Re: [manet] DYMO/AODVv2 and LOADng -- Problems and Proposed Solutions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 13:56:20 -0000 --Apple-Mail=_9A5CFA7F-99C2-4165-9D3B-827A44086F60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Marius, thanks for your detailed reply, those figures are great :) please check inline: On Dec 13, 2012, at 2:50 AM, Marius Portmann = wrote: > Dear Jiazi, >=20 > >> (1) Non-Optimal Routes > >> ---------------------- > >> On-demand/reactive routing protocols (such as AODV, DYMO and > >> LOADng) often fails to discover the best (shortest) routes [1,2]. >=20 >=20 > > In LOADng, only bi-directional routes are used by default, i.e. only > > the routes that are verified by RREP are used. So I think the = example > > you mentioned in figure 2 of [3,4] shouldn't be a problem for = LOADng. =20 >=20 > As of yet we are not convinced that this covers all cases. > Isn't it the case that in LOADng a bidirectional routing entry can be > updated with new information from a RREQ message, and keep its flag = saying > that the route is bidirectional? If yes, then we can adapt our example > to apply to LOADng: see > http://www.cse.unsw.edu.au/~rvg/LOADng-non-optimal-routes.pdf >=20 There are two issues regarding this topic.=20 1) The first is the difference between route using only bi-directional = links, and bi-directional route.=20 Currently, LOADng only supports finding route using only bi-directional = links, not the latter. In another words, only the originator of the = route discovery knows that there is a route using bi-directional links = to the destination. For example, in your figure 1(a), knows = there is a route to with bidirectional flag set to TRUE. For = , even there is an available route to , he is not = aware of that (so the bidirectional flag is FALSE).=20 To build bi-directional route, another end-to-end RREP from originator = to destination is needed, like three-way handshake. The LOADng authors = have already a lot of discussions on this, but no consensus on it yet. = Maybe I can put some of that discussion, and you can share some of your = experience later.=20 So, in your example Figure 1(a), router a won't have a route to router s = with bi-directional flag set to TRUE in the first place.=20 2) Your argument is still valid, if it's sending a RREQ to = in figure 2(b). In that case, will reset the route = with the sub-optimal one.=20 By having the destination router also broadcast the RREQ can solve the = problem, but it would also result in more overhead. In certain = scenarios, the overhead would be significant. In fact, what we are = trying to do is to limit the broadcast region of RREQ, and there are = some results in=20 http://jiaziyi.com/documents/smart_rreq_full.pdf I'll first think about the tradeoff and if there is other solutions, and = then come back to you, is that OK? > >> (2) Route Reply Loss > >> -------------------- > >> AODV can lose route replies = (http://www.ietf.org/mail-archive/web/manet/current/msg05702.html).=20 > >> The reason is that route replies are only forwarded by an > >> intermediate node when the node updates its routing table. >=20 >=20 > > I think it would be safe to forward every unicast RREPs.=20 > >=20 > > In the meantime, I'm wondering how often the situation that you > > mentioned in fig 1 of [4] would happen. Because it requires 1) two > > RREPs are generated in very short time interval and 2) The route > > set up by broadcasting two RREQs between the two nodes (B and T in > > your example) are different.=20 >=20 > True. But even if the situation doesn't occur that often, we think a > the proposed fix comes without significant cost in communication = overhead, > and thus is preferable to accepting the occasional loss of RREPs. It's noted. And we will see if there is consensus to make this change.=20= >=20 > >> (3) Route Request Loss > >> ---------------------- > >> Similar to (2), route requests might be lost in DYMO and LOADng. > >> Namely, if one route request overtakes another, i.e., a newer > >> request reaches a node earlier than an older one, then the older > >> route request is dropped. This problem does not occur in AODV, > >> thanks to the use of a list of previously seen RREQ IDs. >=20 > > Could you please have an example of this? >=20 > We created one at = http://www.cse.unsw.edu.au/~rvg/route-request-loss.pdf >=20 > > What you said, the case that a newer RREQ reaches a node earlier > > than an older one, shouldn't happen. Because in LOADng, the > > originator of RREQ has a rate limit, i.e. certain interval. If an > > old RREQ came to an intermediate router that slow, probably it > > shouldn't be forwarded anyway, because it has great possibility to > > carry bad route information. >=20 > In the example in the above link, the dropped RREQ1 does come along a > route that is no longer optimal, but it should be forwarded anyway to > make sure the destination d learns about the request. Forwarding will > result in a bidirectional route between s and d that doesn't use the = detour. By allowing stale RREQ broadcasting can have significant overhead in the = network.=20 As I said, for LOADng, there is a rate control at the originator of the = RREQ, i.e., the RREQ is initiated with certain interval (for example, = 0.1s).=20 In your example, if the time for RREQ1 (t1) needed to get to = is greater than traversal time of RREQ2 (t2) plus interval, then I think = the route shouldn't be considered because of bad quality and long delay. = In this case, I think what should do is wait for the route = discovery timeout, and then initiate a new one for .=20 > =20 > We hope this makes sense. all your comments are very helpful and will be carefully considered. = thanks again.=20 regards Jiazi >=20 > Best regards, > Rob, Peter, Marius and Wee Lum > =20 > =20 > =20 > References > --------------- > [1] S. Miskovic and E. W. Knightly, "Routing primitives for wireless = mesh networks: Design, analysis and experiments", in Conference on = Information Communications (INFOCOM=9210). IEEE, 2010, pp. 2793-2801. > networks.rice.edu/papers/MeshRoutingPrimitives.pdf > [2] P. H=F6fner, R. J. van Glabbeek, W. L. Tan, M. Portmann, A. = McIver, and A. Fehnker, "A rigorous analysis of AODV and its variants", = in Modeling, Analysis and Simulation of Wireless and Mobile Systems = (MSWIM=9212). ACM Press, 2012. doi:10.1145/2387238.2387274 > http://www.cse.unsw.edu.au/~rvg/pub/mswim12.pdf > [3] A. Fehnker, R. J. van Glabbeek, P. H=F6fner, A. McIver, M. = Portmann, and W. L. Tan, "Automated analysis of AODV using UPPAAL", in = Tools and Algorithms for the Construction and Analysis of Systems = (TACAS=9212), LNCS, C. Flanagan and B. K=F6nig, Eds., vol. 7214. = Springer, 2012, pp. 173=96187. doi:10.1007/978-3-642-28756-5_13 > http://www.cse.unsw.edu.au/~rvg/pub/tacas12.pdf > [4] P. H=F6fner, and S. Edenhofer, "Towards a Rigorous Analysis of = AODVv2 (DYMO)", in Workshop on Rigorous Protocol Engineering, IEEE > http://www.nicta.com.au/pub?id=3D6169 >=20 --Apple-Mail=_9A5CFA7F-99C2-4165-9D3B-827A44086F60 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Dear = Marius,
thanks for = your detailed reply, those figures are great :)
please check = inline:


On Dec 13, 2012, at 2:50 AM, Marius Portmann <marius@itee.uq.edu.au> = wrote:

Dear Jiazi,

>> (1) Non-Optimal = Routes
>> ----------------------
>> On-demand/reactive = routing protocols (such as AODV, DYMO and
>> LOADng) often = fails to discover the best (shortest) routes = [1,2].


> In LOADng, only bi-directional routes are used by = default, i.e. only
> the routes that are verified by RREP are = used. So I think the example
> you mentioned in figure 2 of [3,4] = shouldn't be a problem for LOADng.  

As of yet we are not = convinced that this covers all cases.
Isn't it the case that in = LOADng a bidirectional routing entry can be
updated with new = information from a RREQ message, and keep its flag saying
that the = route is bidirectional? If yes, then we can adapt our example
to = apply to LOADng: see
   http://jiaziyi.c= om/documents/smart_rreq_full.pdf

I'll first = think about the tradeoff and if there is other solutions, and then come = back to you, is that OK?


It's noted. And we will see if there is consensus to make this = change. 


>> (3) Route Request = Loss
>> ----------------------
>> Similar to (2), = route requests might be lost in DYMO and LOADng.
>> Namely, if = one route request overtakes another, i.e., a newer
>> request = reaches a node earlier than an older one, then the older
>> = route request is dropped.  This problem does not occur in = AODV,
>> thanks to the use of a list of previously seen RREQ = IDs.

> Could you please have an example of this?

We = created one at 

> What you said, the case that a = newer RREQ reaches a node earlier
> than an older one, shouldn't = happen. Because in LOADng, the
> originator of RREQ has a rate = limit, i.e. certain interval. If an
> old RREQ came to an = intermediate router that slow, probably it
> shouldn't be = forwarded anyway, because it has great possibility to
> carry bad = route information.

In the example in the above link, the dropped = RREQ1 does come along a
route that is no longer optimal, but it = should be forwarded anyway to
make sure the destination d learns = about the request. Forwarding will
result in a bidirectional route = between s and d that doesn't use the = detour.


 
We hope this makes = sense.






Best = regards,
Rob, Peter, Marius and Wee = Lum
 
 
 
[1] S. Miskovic and E. W. = Knightly, "Routing primitives for wireless mesh networks: Design, = analysis and experiments", in Conference on Information Communications = (INFOCOM=9210). IEEE, 2010, pp. = 2793-2801.
[4] P. H=F6fner, and S. Edenhofer, "Towards a = Rigorous Analysis of AODVv2 (DYMO)", in Workshop on Rigorous Protocol = Engineering, IEEE
 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:40:44 -0000 I agree that there are interets in both drafts, but the interest is more about a reactive protocol that WG progresses in. The problem was that some participants changed their interest now to support another draft than the WG work in progress, just because WG draft was parked. I see that we stick with our interest of reactive protocol, but just we need to find a way to discuss good/technical reasons (e.g. the reason of the WG-draft was parked is not a good reason, but it was all our responsibility or failure to proceed) for such support choice . AB On 12/12/12, Dearlove, Christopher (UK) wro= te: > I think this is self-contradictory. It says there's a lot of strife but n= o > interest. Strife does tend to happen more when there is interest. > > I think the limited amount of technical discussion on the drafts is > significantly in part because people are waiting to work out which draft > they should comment on. (And it's also not a great time of year.) And eve= n > so today I see at least two people who are not authors making technical > points (and there were more over the last few days). And some points (com= mon > to both drafts) a week or two ago from people who aren't regulars, let al= one > authors. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Stan Ratliff (sratliff) > Sent: 12 December 2012 15:58 > To: Axel Colin de Verdi=E8re > Cc: > Subject: Re: [manet] LOADng (was Re: I-D Action: > draft-ietf-manet-dymo-24.txt) > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Axel, > > On Dec 11, 2012, at 6:01 PM, Axel Colin de Verdi=E8re wrote: > >> Hi Stan, >> >> Le 11 d=E9c. 2012 =E0 11:03, Stan Ratliff (sratliff) a >> =E9crit : >> >>> JP, >>> >>> On Dec 10, 2012, at 9:19 PM, JP Vasseur (jvasseur) wrote: >>> >>>> Hi Stan, >>>> >>>> On Dec 10, 2012, at 6:58 AM, Stan Ratliff (sratliff) wrote: >>>> >>>>> Abdussalam, >>>>> >>>>> On Dec 10, 2012, at 5:51 AM, Abdussalam Baryun wrote: >>>>> >>>>>> On 12/7/12, Stan Ratliff (sratliff) wrote: >>>>>>> >>>>>>> My feeling, FWIW, is that ingress/egress SHOULD be a part of the >>>>>>> base >>>>>>> document. However, I understand the concerns of people that say it >>>>>>> might be >>>>>>> a problem (or extend ratification time, etc etc). So, I'm intereste= d >>>>>>> in >>>>>>> hearing other, interested opinions - both for >>>>>>> DYMO/AODVv2/Whatever-we're-calling-it-this-week, as well as with >>>>>>> regard to >>>>>>> the LOADng spec. >>>>>> >>>>>> I know from my efforts that LOADng team are not welling to discuss, >>>>>> or >>>>>> reply to questions/comments, so I want to know your opinion of the >>>>>> status on this LOADng draft as you brought it to the list; Is it a W= G >>>>>> draft? should we discuss individual or private work now? >>>>>> >>>>>> I remember that we answered chair questions and options given. Not >>>>>> sure what the chair of WG wants us to do so far, please advise, >>>>> >>>>> It wasn't clear to me what the consensus was in Atlanta vis-a-vis the >>>>> two reactive protocol documents. Presently, DYMO is the working group >>>>> accepted reactive protocol document. However, there was a 2-year peri= od >>>>> of time when DYMO was inactive, and the document was "parked". As a >>>>> result of that, the effort to create LOADng sprang up. >>>>> >>>>> So now, we have two documents to consider. In the charter, the WG is >>>>> "on the hook" for 1 (and only 1) reactive protocol. So the current >>>>> options are: >>>>> 1. Recognize that we cannot reach consensus with the two documents, a= nd >>>>> remove the charter item for reactive protocols. To be frank, this is = my >>>>> preferred option. >>>>> 2. Accept one of the two documents (either LOADng or DYMO), and press >>>>> forward >>>>> 3. Perhaps alter the charter item, and produce 2 reactive protocols, >>>>> both in "experimental" state. >>>>> >>>> >>>> JP> What about putting a hard dead-line and if there is no consensus >>>> fall back to 1 ? >>> >>> There's only one problem with that - It's already happened, and the >>> deadline has already passed without conclusion. ;-) It happened in >>> Vancouver, with a deadline of Atlanta. >>> >>> To the working group at large - >>> >>> I'm not seeing a high level of interest here. People seem to only have >>> "passing interest" - enough to keep the efforts on life support, but no= t >>> enough to really progress things. By and large, only the authors have t= he >>> inclination to push their respective opinions, and nothing has really >>> changed. >> >> I'm a bit surprised here: it seems weird to me that you can just dismiss= a >> 10 people behind a document, with strong industrial support (including >> actual deployments) as "passing", or even "not enough" interest. >> Furthermore, I've seen that we (the LOADng authors) are far from the onl= y >> ones participating on this topic. >> >>> >>> So, I call once again - I think it's time to remove the work item from >>> the charter, and recognize that we're not going to be able to work >>> together on this issue. After more than a year of trying to get people = to >>> work together to make the technology better, just don't see it >>> happening. It's time to end the misery. >> >> I understand your position, I think you made that clear relatively early >> in the process, but I don't think "not enough interest" is really a good >> reason here. > > To the contrary, "Not enough interest" is a perfectly good reason for > stopping work. So is "we can't agree on an outcome". IMHO, *both* of thes= e > situations are in effect here. Compared to the WG as a whole, there is a > small set of people whirring and spinning on a couple of documents. Outsi= de > of that small clique, we're not seeing a lot of interest (activity) on th= e > mailing list. To simply state that ".we (the LOADng authors) are far from > the only ones participating.", without examples, is not proof - it's mere= ly > an assertion. The call of whether there is "sufficient support" in the WG= is > admittedly subjective. However, given the amount of strife on the topic, = the > likelihood that the WG will reach consensus, and the level of interest th= at > I gauge - I stand by my position. IMO, as co-chair, this work should be > terminated. > > Stan > > > >> >> Best, >> >> Axel >> >>> >>> Regards, >>> Stan >>> >>> >>> >>>> >>>>> Now, you mentioned "Not sure what the chairs of WG want us to do so >>>>> far".. the best answer I can give you on that is "reach consensus on = an >>>>> approach". We as a working group haven't done that yet. There are >>>>> people advocating for DYMO, others advocating for LOADng, and some th= at >>>>> want to "merge" the technology of the two together. A "merge" was >>>>> something we tried in the Vancouver timeframe, but that effort failed= . >>>>> >>>>> >>>>> As to your statement that the LOADng team is not willing to discuss -= I >>>>> haven't seen that, do not agree with it, and would ask you to cite >>>>> *specific* examples if you have them. I've found the LOADng team to b= e >>>>> reasonable in their dealings with the WG. There is the issue of >>>>> re-spinning the LOADng document without the copyright statement - The >>>>> LOADng authors and the chairs have reached an understanding about tha= t >>>>> issue, so I no longer have a problem with moving forward on that fron= t. >>>>> >>>>> >>>>> Again, as a working group - we *MUST* either reach a consensus, or th= e >>>>> work item will be removed *for us*. If we do not show progress toward= s >>>>> a goal, it is within the power of the IESG to stop work on the issue. >>>>> >>>>> Regards, >>>>> Stan >>>>> >>>>> >>>>>> >>>>>> AB >>>>>> >>>>>>> >>>>>>> And lastly... if the 5 guys were *that* important, they most likely >>>>>>> wouldn't >>>>>>> be *playing* black-ops. ;-) >>>>>>> >>>>>>> Stan >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From marius@itee.uq.edu.au Thu Dec 13 18:09:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA0821F8B9D for ; Thu, 13 Dec 2012 18:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.492 X-Spam-Level: X-Spam-Status: No, score=-1.492 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] 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 ybmkn8+1fiNr for ; Thu, 13 Dec 2012 18:09:52 -0800 (PST) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id E375421F8BA7 for ; Thu, 13 Dec 2012 18:09:51 -0800 (PST) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id qBE29avI030783; Fri, 14 Dec 2012 12:09:36 +1000 Received: from UQEXET2.soe.uq.edu.au (uqexet2.soe.uq.edu.au [130.102.129.39]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id qBE29aNt013363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 14 Dec 2012 12:09:36 +1000 Received: from uqexht3.soe.uq.edu.au (130.102.129.72) by UQEXET2.soe.uq.edu.au (130.102.129.39) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 14 Dec 2012 12:09:36 +1000 Received: from UQEXMDA8.soe.uq.edu.au ([169.254.5.195]) by uqexht3.soe.uq.edu.au ([130.102.129.72]) with mapi id 14.01.0355.002; Fri, 14 Dec 2012 12:09:36 +1000 From: Marius Portmann To: "Charles E. Perkins" Thread-Topic: [manet] DYMO/AODVv2 and LOADng -- Problems and Proposed Solutions Thread-Index: AQHN0kzaca8r7Q84n0mkTxkXF/riWZgJ8pkAgA2lYRA= Date: Fri, 14 Dec 2012 02:09:35 +0000 Message-ID: <55276FFE1B06A541A659C0B360E8066F181C42@UQEXMDA8.soe.uq.edu.au> References: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> <50BE4036.30507@computer.org> <50BFA190.7050908@computer.org> In-Reply-To: <50BFA190.7050908@computer.org> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.102.64.21] Content-Type: multipart/alternative; boundary="_000_55276FFE1B06A541A659C0B360E8066F181C42UQEXMDA8soeuqedua_" MIME-Version: 1.0 X-UQ-FilterTime: 1355450979 X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub Cc: "'manet@ietf.org'" Subject: Re: [manet] DYMO/AODVv2 and LOADng -- Problems and Proposed Solutions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 02:09:57 -0000 --_000_55276FFE1B06A541A659C0B360E8066F181C42UQEXMDA8soeuqedua_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Charlie, >> (1) Non-Optimal Routes >> ---------------------- >> On-demand/reactive routing protocols (such as AODV, DYMO and >> LOADng) often fails to discover the best (shortest) routes [1,2]. > This is certainly true. ... However, the nodes which establish > non-optimal routes to the source are also unlikely to use those > routes. Of course it is quite possible that these 'indirectly discovered' non-optim= al routes will never or rarely be used. However, as far as we understand, DYMO/AODVv2 supports the option of 'path = accumulation' (as it used to be called), where nodes can include 'AddedNod= e routing information' discovered indirectly, i.e. not via the source or de= stination of a route discover process. Assuming the 'path accumulation' fea= ture is beneficial, and nodes will use this 'indirectly discovered' routing= information, we think it is likely that non-optimal routes will be used as= a consequence. >> As a possible solution, we propose that route requests are always >> forwarded, even by nodes generating a route reply [2,3]. The >> forwarded request should include a flag stating that a reply has >> already been initiated. In [3] it is shown that this increases the >> quality of routes. Of course this could increase the overhead of >> control messages, but in most of the cases the additional overhead >> is minimal, since a request floods the entire network anyway. > This can be made into an optional behavior, controllable either by a > system-wide configuration parameter, or a new RREQ option. I would > not expect that it should be the default behavior. This is obviously a trade off between the cost and the benefit of this mech= anism. We believe that overhead is small enough for it to be considered as a defau= lt option. Unfortunately, we don't have any quantitative results to back this up at th= e moment. >> (2) Route Reply Loss >> -------------------- >> AODV can lose route replies (http://www.ietf.org/mail-archive/web/manet/= current/msg05702.html). >> The reason is that route replies are only forwarded by an >> intermediate node when the node updates its routing table. > I guess you mean that the two RREPs under discussion were going > towards two distinct Originating Nodes. Otherwise, it would be good > for the older RREP to be dropped. Yes, indeed. > The relevant point is that an AODVv2 router retransmits the RREQ or > RREP regardless of whether the AODVv2 router used the incoming > routing information to update its route table. > > I thought there might be some wording to the contrary, but after > reading the relevant parts of the specification several times I > haven't found any such wording. Please let me know what I have missed. Our analysis was based on DYMO/AODVv2 version 23. It now appears that in ve= rsion 24, the specification has changed such that it is similar to what we = are proposing, i.e. to let the AODVv2 routers always forward the RREQ/RREP = messages. All the best, Rob, Peter, Marius and Wee Lum From: Charles E. Perkins [mailto:charliep@computer.org] Sent: Thursday, 6 December 2012 5:34 AM To: Marius Portmann Cc: 'manet@ietf.org' Subject: Re: [manet] DYMO/AODVv2 and LOADng -- Problems and Proposed Soluti= ons Hello again Marius, I have been looking for the protocol error, and up until now have not found it. I probably should have looked closer before sending my reply to you yesterday. Here is a summary of the relevant protocol details that affect processing (and, retransmission) of RREQ and RREP messages. - Check that the RREQ or RREP is "valid" - Test all the routing information and use when permissible - Update certain fields of the incoming message - Decide whether to advertise availability for forwarding - If so, retransmit (or, consume the RREQ and transmit RREP) The relevant point is that an AODVv2 router retransmits the RREQ or RREP regardless of whether the AODVv2 router used the incoming routing information to update its route table. I thought there might be some wording to the contrary, but after reading the relevant parts of the specification several times I haven't found any such wording. Please let me know what I have missed. Otherwise, since the AODVv2 routers typically do retransmit route discovery messages even when not using the routing information contained by those route discovery messages, I think the problem you identified for earlier protocols does not arise. Regards, Charlie P. On 12/4/2012 10:25 AM, Charles E. Perkins wrote: Hello Marius, Interesting results. I have some follow-up questions. On 12/3/2012 9:21 PM, Marius Portmann wrote: (1) Non-Optimal Routes -------------------------------- On-demand/reactive routing protocols (such as AODV, DYMO and LOADng) often = fail to discover the best (shortest) routes [1,2]. This is certainly true. There have been measurements about how far from op= timal the routes can be, and if I remember correctly it's typically somewhere in = the neighborhood of 10%, depending on congestion and node mobility. The problem is that during route discovery the destination (target) node do= es not forward route requests; so, nodes that lie downstream of the destina= tion node frequently create non-optimal routes to the source. Knightly and = Miskovic [1] have shown that "poorly selected paths can have significantly = higher routing-metric costs, and their duration can extend to minute time s= cales". We have verified that this problem exists in DYMO and LOADng. Moreover, the result makes intuitive sense. However, the nodes which estab= lish non-optimal routes to the source are also unlikely to use those routes. As a possible solution, we propose that route requests are always forwarded= , even by nodes generating a route reply [2,3]. The forwarded request shoul= d include a flag stating that a reply has already been initiated. In [3] it= is shown that this increases the quality of routes. Of course this could i= ncrease the overhead of control messages, but in most of the cases the addi= tional overhead is minimal, since a request floods the entire network anywa= y. This can be made into an optional behavior, controllable either by a system-wide configuration parameter, or a new RREQ option. I would not expect that it should be the default behavior. (2) Route Reply Loss ----------------------------- AODV can lose route replies (http://www.ietf.org/mail-archive/web/manet/cur= rent/msg05702.html). The reason is that route replies are only forwarded by an intermediate node= when the node updates its routing table. This problem has partly been solved in DYMO and LOADng by increasing sequen= ce numbers when initiating a route reply. However, a careful analysis shows that replies can still be lost; yielding = again non-optimal routes or route discovery failures. Namely, if one route = reply overtakes another, i.e., a newer reply reaches a node earlier than an= older one, then the older route reply is dropped [4]. I guess you mean that the two RREPs under discussion were going towards two distinct Originating Nodes. Otherwise, it would be good for the older = RREP to be dropped. For the case of two distinct Originating Nodes, the behavior is a protocol error that needs to be fixed. "Always forwarding" RREPs is one alternative= , and certainly preferable to a new Route Discovery cycle in the network. I am confident that there is a better solution, and I will work on finding and specifying it. (3) Route Request Loss --------------------------------------------- Similar to (2), route requests might be lost in DYMO and LOADng. Namely, if one route request overtakes another, i.e., a newer request reach= es a node earlier than an older one, then the older route request is droppe= d. This problem does not occur in AODV, thanks to the use of a list of previou= sly seen RREQ IDs. I think that a "better" solution for (2) will also resolve this problem. Here, the solution of "always forwarding" seems much less palatable. Thanks much for reporting these error cases, and for providing the references. -- Regards, Charlie P. -- Regards, Charlie P. --_000_55276FFE1B06A541A659C0B360E8066F181C42UQEXMDA8soeuqedua_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_55276FFE1B06A541A659C0B360E8066F181C42UQEXMDA8soeuqedua_-- From sratliff@cisco.com Fri Dec 14 07:20:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D72821F8810 for ; Fri, 14 Dec 2012 07:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.501 X-Spam-Level: X-Spam-Status: No, score=-10.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 DzWHv0408kK0 for ; Fri, 14 Dec 2012 07:20:04 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3848721F84ED for ; Fri, 14 Dec 2012 07:19:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9928; q=dns/txt; s=iport; t=1355498398; x=1356707998; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e5U6J9EcXWMTBRGr2ZuFLef7Gqm86HkAQRmKIg+o5CQ=; b=N+guJtwx8SfaBsp/uvw65vFEsyqoAn0LD50EJCc81TYVu3vF7d6IeDDO DUlJLew+vOXZIfhnAz9PydCnx9imXFWGR62nY9LUpUbGvx5YjGwC4kjHG VMVYqlzFmYCUik5NlyDv3EZBUsohuSaf4HUHwLMW+opko6Z0JAA3/CWCi 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANtBy1CtJV2Z/2dsb2JhbABFvwMWc4IeAQEBAwEBAQFSGQMIBQcEAgEIEQQBAQEKHQcnCxQJCAIEDgUIEYd0Bgy8YYxXCwoHB4M/YQOmUYJzgWQJFx4 X-IronPort-AV: E=Sophos;i="4.84,281,1355097600"; d="scan'208";a="153048729" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 14 Dec 2012 15:19:57 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBEFJvxn007838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Dec 2012 15:19:57 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.203]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Fri, 14 Dec 2012 09:19:57 -0600 From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN1sRQC9RIBD6Ww0Sj7f1Ne2/6upgShJYAgAC+fACAARh2gIAAQmiAgAEcDACAACUdAIAC9OUA Date: Fri, 14 Dec 2012 15:19:56 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF45A2E@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <3E873090-C8D3-4563-A7A4-331D2D599917@axelcdv.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF389CF@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.116] Content-Type: text/plain; charset="Windows-1252" Content-ID: <22EB9A90B68E0343BC57BACE338855CA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 15:20:07 -0000 Chris,=20 On Dec 12, 2012, at 1:10 PM, Dearlove, Christopher (UK) wrote: > I think this is self-contradictory. It says there's a lot of strife but n= o interest. Strife does tend to happen more when there is interest. Fair point. Let me see if I can clarify. I liken this to 10 guys in a Pub b= rawl. They are fighting over who should lead the government, whilst 150 (or= so) other Pub-goers are standing around, watching the melee. In that situa= tion, I'd say there's a lot of strife, but not a lot of interest in mountin= g a revolution=85. ;-) Regards, Stan >=20 > I think the limited amount of technical discussion on the drafts is signi= ficantly in part because people are waiting to work out which draft they sh= ould comment on. (And it's also not a great time of year.) And even so toda= y I see at least two people who are not authors making technical points (an= d there were more over the last few days). And some points (common to both = drafts) a week or two ago from people who aren't regulars, let alone author= s. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Stan Ratliff (sratliff) > Sent: 12 December 2012 15:58 > To: Axel Colin de Verdi=E8re > Cc: > Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24= .txt) >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Axel,=20 >=20 > On Dec 11, 2012, at 6:01 PM, Axel Colin de Verdi=E8re wrote: >=20 >> Hi Stan, >>=20 >> Le 11 d=E9c. 2012 =E0 11:03, Stan Ratliff (sratliff) a =E9crit : >>=20 >>> JP,=20 >>>=20 >>> On Dec 10, 2012, at 9:19 PM, JP Vasseur (jvasseur) wrote: >>>=20 >>>> Hi Stan, >>>>=20 >>>> On Dec 10, 2012, at 6:58 AM, Stan Ratliff (sratliff) wrote: >>>>=20 >>>>> Abdussalam,=20 >>>>>=20 >>>>> On Dec 10, 2012, at 5:51 AM, Abdussalam Baryun wrote: >>>>>=20 >>>>>> On 12/7/12, Stan Ratliff (sratliff) wrote: >>>>>>>=20 >>>>>>> My feeling, FWIW, is that ingress/egress SHOULD be a part of the ba= se >>>>>>> document. However, I understand the concerns of people that say it = might be >>>>>>> a problem (or extend ratification time, etc etc). So, I'm intereste= d in >>>>>>> hearing other, interested opinions - both for >>>>>>> DYMO/AODVv2/Whatever-we're-calling-it-this-week, as well as with re= gard to >>>>>>> the LOADng spec. >>>>>>=20 >>>>>> I know from my efforts that LOADng team are not welling to discuss, = or >>>>>> reply to questions/comments, so I want to know your opinion of the >>>>>> status on this LOADng draft as you brought it to the list; Is it a W= G >>>>>> draft? should we discuss individual or private work now? >>>>>>=20 >>>>>> I remember that we answered chair questions and options given. Not >>>>>> sure what the chair of WG wants us to do so far, please advise, >>>>>=20 >>>>> It wasn't clear to me what the consensus was in Atlanta vis-a-vis the= two reactive protocol documents. Presently, DYMO is the working group acce= pted reactive protocol document. However, there was a 2-year period of time= when DYMO was inactive, and the document was "parked". As a result of that= , the effort to create LOADng sprang up.=20 >>>>>=20 >>>>> So now, we have two documents to consider. In the charter, the WG is = "on the hook" for 1 (and only 1) reactive protocol. So the current options = are:=20 >>>>> 1. Recognize that we cannot reach consensus with the two documents, a= nd remove the charter item for reactive protocols. To be frank, this is my = preferred option.=20 >>>>> 2. Accept one of the two documents (either LOADng or DYMO), and press= forward >>>>> 3. Perhaps alter the charter item, and produce 2 reactive protocols, = both in "experimental" state.=20 >>>>>=20 >>>>=20 >>>> JP> What about putting a hard dead-line and if there is no consensus f= all back to 1 ? >>>=20 >>> There's only one problem with that - It's already happened, and the dea= dline has already passed without conclusion. ;-) It happened in Vancouver,= with a deadline of Atlanta.=20 >>>=20 >>> To the working group at large -=20 >>>=20 >>> I'm not seeing a high level of interest here. People seem to only have = "passing interest" - enough to keep the efforts on life support, but not en= ough to really progress things. By and large, only the authors have the inc= lination to push their respective opinions, and nothing has really changed.= =20 >>=20 >> I'm a bit surprised here: it seems weird to me that you can just dismiss= a 10 people behind a document, with strong industrial support (including a= ctual deployments) as "passing", or even "not enough" interest. Furthermore= , I've seen that we (the LOADng authors) are far from the only ones partici= pating on this topic. >>=20 >>>=20 >>> So, I call once again - I think it's time to remove the work item from = the charter, and recognize that we're not going to be able to work together= on this issue. After more than a year of trying to get people to work toge= ther to make the technology better, just don't see it happening. It's time= to end the misery. >>=20 >> I understand your position, I think you made that clear relatively early= in the process, but I don't think "not enough interest" is really a good r= eason here. >=20 > To the contrary, "Not enough interest" is a perfectly good reason for sto= pping work. So is "we can't agree on an outcome". IMHO, *both* of these sit= uations are in effect here. Compared to the WG as a whole, there is a small= set of people whirring and spinning on a couple of documents. Outside of t= hat small clique, we're not seeing a lot of interest (activity) on the mail= ing list. To simply state that ".we (the LOADng authors) are far from the o= nly ones participating.", without examples, is not proof - it's merely an a= ssertion. The call of whether there is "sufficient support" in the WG is ad= mittedly subjective. However, given the amount of strife on the topic, the = likelihood that the WG will reach consensus, and the level of interest that= I gauge - I stand by my position. IMO, as co-chair, this work should be te= rminated.=20 >=20 > Stan >=20 >=20 >=20 >>=20 >> Best, >>=20 >> Axel >>=20 >>>=20 >>> Regards, >>> Stan >>>=20 >>>=20 >>>=20 >>>>=20 >>>>> Now, you mentioned "Not sure what the chairs of WG want us to do so f= ar".. the best answer I can give you on that is "reach consensus on an appr= oach". We as a working group haven't done that yet. There are people advoc= ating for DYMO, others advocating for LOADng, and some that want to "merge"= the technology of the two together. A "merge" was something we tried in th= e Vancouver timeframe, but that effort failed.=20 >>>>>=20 >>>>> As to your statement that the LOADng team is not willing to discuss -= I haven't seen that, do not agree with it, and would ask you to cite *spec= ific* examples if you have them. I've found the LOADng team to be reasonabl= e in their dealings with the WG. There is the issue of re-spinning the LOAD= ng document without the copyright statement - The LOADng authors and the ch= airs have reached an understanding about that issue, so I no longer have a = problem with moving forward on that front.=20 >>>>>=20 >>>>> Again, as a working group - we *MUST* either reach a consensus, or th= e work item will be removed *for us*. If we do not show progress towards a = goal, it is within the power of the IESG to stop work on the issue. >>>>>=20 >>>>> Regards, >>>>> Stan >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> AB >>>>>>=20 >>>>>>>=20 >>>>>>> And lastly... if the 5 guys were *that* important, they most likely= wouldn't >>>>>>> be *playing* black-ops. ;-) >>>>>>>=20 >>>>>>> Stan >>>>>>>=20 >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 From hrogge@googlemail.com Fri Dec 14 07:36:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBBE21F87FE for ; Fri, 14 Dec 2012 07:36:57 -0800 (PST) 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 Sh9IA2Zq6Arf for ; Fri, 14 Dec 2012 07:36:56 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E64721F87D2 for ; Fri, 14 Dec 2012 07:36:56 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so1427275dae.31 for ; Fri, 14 Dec 2012 07:36:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=11DjHP73mCtvw5DOArI/8rdfY4mgYdzrQHRdDvTYl4s=; b=09GyxFqjSXB20LHo42GV+P2OTx6D+02qY5mQOojvvfVoWJoR7tDYN+9co5VQyJEKzm VCFuG7U19Hk3L4ioc3R4uq5gEXGbqObFFZd791mqta/+SXhH7VEpfJX4FXoV8NHmRP6I 6UBvhVPTonFgH3XsK9rAAlISKaA5c3tvcjlYtOXkxT83CHAj45cKXAwU2MBKue6GlyF8 5wsjenou/ZIRJmjj4a4F75tKR1OYj4cJOlPDtmUzr9aoNc8WZwKH2RxKqOgJVR/3FGMO HNUOQkeL1E32Yj32OL4cATCBzrI0znsH9nSrawEtqbTwfXyro9kqKDT2igFRn7vfqxkM Au2g== Received: by 10.68.230.200 with SMTP id ta8mr16613207pbc.13.1355499416446; Fri, 14 Dec 2012 07:36:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.88.132 with HTTP; Fri, 14 Dec 2012 07:36:36 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF45A2E@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <3E873090-C8D3-4563-A7A4-331D2D599917@axelcdv.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF389CF@xmb-rcd-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF45A2E@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Fri, 14 Dec 2012 16:36:36 +0100 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , "" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 15:36:57 -0000 On Fri, Dec 14, 2012 at 4:19 PM, Stan Ratliff (sratliff) wrote: > Chris, > > On Dec 12, 2012, at 1:10 PM, Dearlove, Christopher (UK) wrote: > >> I think this is self-contradictory. It says there's a lot of strife but = no interest. Strife does tend to happen more when there is interest. > > Fair point. Let me see if I can clarify. I liken this to 10 guys in a Pub= brawl. They are fighting over who should lead the government, whilst 150 (= or so) other Pub-goers are standing around, watching the melee. In that sit= uation, I'd say there's a lot of strife, but not a lot of interest in mount= ing a revolution=85. ;-) But at least 120 of your pub-goers have been asleep for a few years. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ulrich@herberg.name Fri Dec 14 09:44:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C06021F8548 for ; Fri, 14 Dec 2012 09:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 kB7OK4cCdB7T for ; Fri, 14 Dec 2012 09:44:07 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2569A21F89AF for ; Fri, 14 Dec 2012 09:44:07 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so4297325vbb.31 for ; Fri, 14 Dec 2012 09:44:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RfN7ZUStXIlca4lzqiIVrKUZI/PLqhMfvjZ2AnMLMaU=; b=v+/BY4elYzTCQj0pxfLdM7zERcvkQHcxoAj7RmxXQ8g4Fh8+W/RvZrJcCvt8oil40g Oi/DlYaxMYk0wR5eP6MuSvqRXrc7nqrYA2q/Go+JLSULEYeimGrSIqE4IdV6w6FbCEhj +s+IhFQVcAGQkXpoKWDMpwOLVt0JoJLbzF8wU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=RfN7ZUStXIlca4lzqiIVrKUZI/PLqhMfvjZ2AnMLMaU=; b=ViLgcpjh6P/l6MaENyuuNdayJnczgapQA1+L2UFBgAbXFC4L+U3E93K2mCwOPEq7Qk NY7VbZQzKGA1oOUFYeipNcHy1d0fOz6ySYUayhKJLVp7sex2YKrNgsOTvm9aIshxaSSB +WRNlYdYGMMMnx5Rz8sp9zIA9Iw5lPuHc2s9SiCI+hvFMU4lG54k6sach/dmcy7x6yfn AeDA/qBm/0QsA/zYP+5ov6Qeax4WGUzF81kma9fhIMLW+DIMFJDrbjox5mwa43AuckBM bVhIJDPpCWU57thTHPXVkLA9mJmN+71qM2tmj4yUuUp+xKSplx0MEuPiC3nIUCt9fbiP 6KuA== MIME-Version: 1.0 Received: by 10.59.6.70 with SMTP id cs6mr10436245ved.60.1355507046458; Fri, 14 Dec 2012 09:44:06 -0800 (PST) Received: by 10.220.157.1 with HTTP; Fri, 14 Dec 2012 09:44:06 -0800 (PST) In-Reply-To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <3E873090-C8D3-4563-A7A4-331D2D599917@axelcdv.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF389CF@xmb-rcd-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF45A2E@xmb-aln-x03.cisco.com> Date: Fri, 14 Dec 2012 09:44:06 -0800 Message-ID: From: Ulrich Herberg To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7bf0effefea69304d0d39347 X-Gm-Message-State: ALoCoQkVo5E/mPRwiVQVqaGq5ERbZficF9dAfkz8Mh1/EWwiTw0kMIQoCbhzuo9m/x2VugWd6he6 Cc: "Dearlove, Christopher \(UK\)" , "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:44:08 -0000 --047d7bf0effefea69304d0d39347 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Stan, I think the argument could not be further from the truth. There are many active authors on the LOADng draft, from many different companies / universities, with many interoperable implementations (documented in an I-D), deployments, strong interest to drive the work forward. Moreover, other people were very actively discussing on the list and in the last meeting. We discussed for 1 hour 20 minutes! How can you say that there is no interest? For me, what we propose represents "rough consensus and running code". If I remember correctly, that is something the IETF supports very much. Best regards Ulrich On Fri, Dec 14, 2012 at 7:36 AM, Henning Rogge wrote= : > On Fri, Dec 14, 2012 at 4:19 PM, Stan Ratliff (sratliff) > wrote: > > Chris, > > > > On Dec 12, 2012, at 1:10 PM, Dearlove, Christopher (UK) wrote: > > > >> I think this is self-contradictory. It says there's a lot of strife bu= t > no interest. Strife does tend to happen more when there is interest. > > > > Fair point. Let me see if I can clarify. I liken this to 10 guys in a > Pub brawl. They are fighting over who should lead the government, whilst > 150 (or so) other Pub-goers are standing around, watching the melee. In > that situation, I'd say there's a lot of strife, but not a lot of interes= t > in mounting a revolution=85. ;-) > > But at least 120 of your pub-goers have been asleep for a few years. > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7bf0effefea69304d0d39347 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Stan,

I think the argument could not be further from the= truth. There are many active authors on the LOADng draft, from many differ= ent companies / universities, with many interoperable implementations (docu= mented in an I-D), deployments, strong interest to drive the work forward. = Moreover, other people were very actively discussing on the list and in the= last meeting. We discussed for 1 hour 20 minutes! How can you say that the= re is no interest?=A0
For me, what we propose represents "rough consensus and running c= ode". If I remember correctly, that is something the IETF supports ver= y much.

Best regards
Ulrich


On Fri, Dec 14, 2012 at 7:36 AM, Henning= Rogge <hrogge@googlemail.com> wrote:
On Fri, Dec 14, 2012 at 4:19 PM, Stan Ratliff (sratliff)<= br> <sratliff@cisco.com> wrote:=
> Chris,
>
> On Dec 12, 2012, at 1:10 PM, Dearlove, Christopher (UK) wrote:
>
>> I think this is self-contradictory. It says there's a lot of s= trife but no interest. Strife does tend to happen more when there is intere= st.
>
> Fair point. Let me see if I can clarify. I liken this to 10 guys in a = Pub brawl. They are fighting over who should lead the government, whilst 15= 0 (or so) other Pub-goers are standing around, watching the melee. In that = situation, I'd say there's a lot of strife, but not a lot of intere= st in mounting a revolution=85. ;-)

But at least 120 of your pub-goers have been asleep for a few years.<= br>
Henning Rogge
--
Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that
was before the present government."
_____________________= __________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--047d7bf0effefea69304d0d39347-- From adrian@olddog.co.uk Fri Dec 14 15:20:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DF721F8B6E for ; Fri, 14 Dec 2012 15:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 YaEjYB2m95bI for ; Fri, 14 Dec 2012 15:20:13 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 5409821F8B3B for ; Fri, 14 Dec 2012 15:20:13 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBENKCNF027312; Fri, 14 Dec 2012 23:20:12 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBENKB57027305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Dec 2012 23:20:11 GMT From: "Adrian Farrel" To: Date: Fri, 14 Dec 2012 23:20:09 -0000 Message-ID: <01c701cdda51$8f829bc0$ae87d340$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3aUW5dmAh873mIQh6tNk6GzxGUWA== Content-Language: en-gb Cc: manet@ietf.org Subject: [manet] AD review of draft-ietf-manet-olsrv2-metrics-rationale X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 23:20:15 -0000 Hi, I have done my usual AD review of your draft prior to issuing IETF last call. The purpose of the review is to clear up any issues that might arise during last call or IESG evaluation to save other reviewers time, and to smooth the passage of the draft in those stages. This document looks in pretty good shape to me. As a calibration, I noted a number of questions as I went along, only to find you answered them about half a page later. Thanks for all the work you must have put in. I have a number of comments, but only the first two really need attention. The others would be "nice to have". If you can respin the document addressing these comments, I will issue last call. As usual, all my comments are open for discussion. Thanks, Adrian --- The punctuation and clause order in the Abstract is a little ambiguous. The document does not "describe in order to allow routing". I have some suggested wording which I have rolled into my next point. --- The document was clearly useful during the production of OLSRv2, and after discussion with the WG chairs I understand why the WG wants to pursue publication even after all of the decisions have been made and OLSRv2 accepted for publication. However, the *current* purpose of the document is not particularly clear so I have two suggestions: In the Abstract add a few words as follows. I have also re-ordered the clauses to cover my previous point. OLSRv2 includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for and design considerations behind how link metrics were included in OLSRv2. Add a new 3rd paragraph in Section 1 During the development of OLSRv2 the working group and authors repeatedly revisited discussion with others about how and why some choices were made in the protocol specification particularly at the metric integration level. Some of the issues were non-intuitive and this document is presented as a record of the considerations and decisions to provide informational discussion about motivation and historic design choices. This will be a useful reference document when those questions arise again. The wording on these is not mandatory, but the inclusion of some sort of statement is going to make the document more useful and get it through the IESG more easily. (BTW. Thank you for Section 3.) --- Section 1 bullets The use of "can use only" is a bit confusing. Suggest... OLD routers can use only metrics of the physical type that they are configured to use. NEW routers can be configured to use only a subset of the available metric types. END --- There is a mismatched double quote at symmetric link in the middle paragraph. --- I wonder whether you want to make any comments about node metrics. Obviously, you don't have them (neighbor metrics being a different thing), but you could comment on why you don't have them (if this was ever discussed). The question is slightly touched on in 5.2 in discussion of "delay". --- Section 8 Were there any security considerations that cropped up while designing metric support in OSLRv2? If so, here would be the place to mention them. From jvasseur@cisco.com Sat Dec 15 12:57:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C35E21F849A for ; Sat, 15 Dec 2012 12:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 pNtyqpn8Tjp9 for ; Sat, 15 Dec 2012 12:57:27 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3C06C21F8481 for ; Sat, 15 Dec 2012 12:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6466; q=dns/txt; s=iport; t=1355605047; x=1356814647; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=l/sUg55cFbu6ei+43lD2cgK7X80uuzGK7r8/uVwrBi8=; b=jra6s1EPe3yP6VdwJj9LT2kW1WA7odyL6dwpjBW5yXpDk88+Ak4UanXR pZ+nOIpLzeAG2IT+pl2Wv/4CV8pesQRowetdFRedgXriv+i36Tu4QSUb0 d/GzqMmWA8rM+35LdQBYDa2JQH+owpEZGcRa0ft3bwVjtjips8t8sOsEF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANbjzFCtJXHA/2dsb2JhbABFvlMWc4IeAQEBBAEBAWsBChACAQgYCh0HJwsUEQIEDgUIh3kDDwyxJw2JUQSLdGmDYmEDplKCc4Ii X-IronPort-AV: E=Sophos;i="4.84,291,1355097600"; d="scan'208,217";a="153394299" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 15 Dec 2012 20:57:24 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qBFKvO8w007506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Dec 2012 20:57:24 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.93]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Sat, 15 Dec 2012 14:57:23 -0600 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN2wbHzVdHJe76406gatnHGN1Fvg== Date: Sat, 15 Dec 2012 20:57:22 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7723111FD4@xmb-rcd-x02.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <3E873090-C8D3-4563-A7A4-331D2D599917@axelcdv.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF389CF@xmb-rcd-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF45A2E@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.235] Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7723111FD4xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 20:57:28 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7723111FD4xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ulrich, Let's try to stick the technical discussion and not restart a "marketing" w= ar, =85 these arguments have been spelled out on this list at least a hundr= ed of time. Let's go back to the technical arguments of AODV2 and Load-ng and see if we= can converge. Thanks. JP. On Dec 14, 2012, at 6:44 PM, Ulrich Herberg wrote: Stan, I think the argument could not be further from the truth. There are many ac= tive authors on the LOADng draft, from many different companies / universit= ies, with many interoperable implementations (documented in an I-D), deploy= ments, strong interest to drive the work forward. Moreover, other people we= re very actively discussing on the list and in the last meeting. We discuss= ed for 1 hour 20 minutes! How can you say that there is no interest? For me, what we propose represents "rough consensus and running code". If I= remember correctly, that is something the IETF supports very much. Best regards Ulrich On Fri, Dec 14, 2012 at 7:36 AM, Henning Rogge > wrote: On Fri, Dec 14, 2012 at 4:19 PM, Stan Ratliff (sratliff) > wrote: > Chris, > > On Dec 12, 2012, at 1:10 PM, Dearlove, Christopher (UK) wrote: > >> I think this is self-contradictory. It says there's a lot of strife but = no interest. Strife does tend to happen more when there is interest. > > Fair point. Let me see if I can clarify. I liken this to 10 guys in a Pub= brawl. They are fighting over who should lead the government, whilst 150 (= or so) other Pub-goers are standing around, watching the melee. In that sit= uation, I'd say there's a lot of strife, but not a lot of interest in mount= ing a revolution=85. ;-) But at least 120 of your pub-goers have been asleep for a few years. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7723111FD4xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <59F171474E82684C838D301D2DE16568@cisco.com> Content-Transfer-Encoding: quoted-printable Hi Ulrich,

Let's try to stick the technical discussion and not restart a "ma= rketing" war, =85 these arguments have been spelled out on this list a= t least a hundred of time.
Let's go back to the technical arguments of AODV2 and Load-ng and see = if we can converge.

Thanks.

JP.


On Dec 14, 2012, at 6:44 PM, Ulrich Herberg wrote:

Stan,

I think the argument could not be further from the truth. There are ma= ny active authors on the LOADng draft, from many different companies / univ= ersities, with many interoperable implementations (documented in an I-D), d= eployments, strong interest to drive the work forward. Moreover, other people were very actively discussing on = the list and in the last meeting. We discussed for 1 hour 20 minutes! How c= an you say that there is no interest? 
For me, what we propose represents "rough consensus and running c= ode". If I remember correctly, that is something the IETF supports ver= y much.

Best regards
Ulrich


On Fri, Dec 14, 2012 at 7:36 AM, Henning Rogge <= span dir=3D"ltr"> <hrogge@googl= email.com> wrote:
On Fri, Dec 14, 2012 at 4:19 PM, Stan Ratliff (sratliff)<= br> <sratliff@cisco.com> wrote:=
> Chris,
>
> On Dec 12, 2012, at 1:10 PM, Dearlove, Christopher (UK) wrote:
>
>> I think this is self-contradictory. It says there's a lot of strif= e but no interest. Strife does tend to happen more when there is interest.<= br> >
> Fair point. Let me see if I can clarify. I liken this to 10 guys in a = Pub brawl. They are fighting over who should lead the government, whilst 15= 0 (or so) other Pub-goers are standing around, watching the melee. In that = situation, I'd say there's a lot of strife, but not a lot of interest in mounting a revolution=85. ;-)

But at least 120 of your pub-goers have been asleep for a few years.

Henning Rogge
--
Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that
was before the present government."
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

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

--_000_03B78081B371D44390ED6E7BADBB4A7723111FD4xmbrcdx02ciscoc_-- From Chris.Dearlove@baesystems.com Mon Dec 17 02:19:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03B721F8A6B for ; Mon, 17 Dec 2012 02:19:46 -0800 (PST) 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 ZDWhfdYIt+B0 for ; Mon, 17 Dec 2012 02:19:45 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8BF21F8A63 for ; Mon, 17 Dec 2012 02:19:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,300,1355097600"; d="scan'208";a="250121869" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 17 Dec 2012 10:19:44 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qBHAJgQ9021942 for ; Mon, 17 Dec 2012 10:19:43 GMT X-IronPort-AV: E=Sophos;i="4.84,300,1355097600"; d="scan'208";a="1356895" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 17 Dec 2012 10:19:39 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0309.002; Mon, 17 Dec 2012 10:19:36 +0000 From: "Dearlove, Christopher (UK)" To: "adrian@olddog.co.uk" , "draft-ietf-manet-olsrv2-metrics-rationale.all@tools.ietf.org" Thread-Topic: [manet] AD review of draft-ietf-manet-olsrv2-metrics-rationale Thread-Index: Ac3aUW5dmAh873mIQh6tNk6GzxGUWAB7lK2A Date: Mon, 17 Dec 2012 10:19:32 +0000 Message-ID: References: <01c701cdda51$8f829bc0$ae87d340$@olddog.co.uk> In-Reply-To: <01c701cdda51$8f829bc0$ae87d340$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] AD review of draft-ietf-manet-olsrv2-metrics-rationale X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 10:19:47 -0000 A quick comment to say, thanks for this Adrian, but I'm unlikely to get to = this before the New Year (end of year deadlines, and we shut down next week= ). In the meanwhile a Merry Christmas and Happy New Year to all who get this. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= drian Farrel Sent: 14 December 2012 23:20 To: draft-ietf-manet-olsrv2-metrics-rationale.all@tools.ietf.org Cc: manet@ietf.org Subject: [manet] AD review of draft-ietf-manet-olsrv2-metrics-rationale ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi, I have done my usual AD review of your draft prior to issuing IETF last call. The purpose of the review is to clear up any issues that might arise during last call or IESG evaluation to save other reviewers time, and to smooth the passage of the draft in those stages. This document looks in pretty good shape to me. As a calibration, I noted a number of questions as I went along, only to find you answered them about half a page later. Thanks for all the work you must have put in.=20 I have a number of comments, but only the first two really need attention. The others would be "nice to have". If you can respin the document addressing these comments, I will issue last call. As usual, all my comments are open for discussion. Thanks, Adrian --- The punctuation and clause order in the Abstract is a little ambiguous. The document does not "describe in order to allow routing". I have=20 some suggested wording which I have rolled into my next point. --- The document was clearly useful during the production of OLSRv2, and=20 after discussion with the WG chairs I understand why the WG wants to pursue publication even after all of the decisions have been made and OLSRv2 accepted for publication. However, the *current* purpose of the document is not particularly clear so I have two suggestions: In the Abstract add a few words as follows. I have also re-ordered the clauses to cover my previous point. OLSRv2 includes the ability to assign metrics to links and to use=20 those metrics to allow routing by other than minimum hop count=20 routes. This document provides a historic record of the rationale for and design considerations behind how link metrics were included in OLSRv2. Add a new 3rd paragraph in Section 1 During the development of OLSRv2 the working group and authors=20 repeatedly revisited discussion with others about how and why some choices were made in the protocol specification particularly at the metric integration level. Some of the issues were non-intuitive=20 and this document is presented as a record of the considerations and decisions to provide informational discussion about motivation and=20 historic design choices. This will be a useful reference document when those questions arise again. The wording on these is not mandatory, but the inclusion of some sort=20 of statement is going to make the document more useful and get it=20 through the IESG more easily. (BTW. Thank you for Section 3.) --- Section 1 bullets The use of "can use only" is a bit confusing. Suggest... OLD routers can use only metrics of the physical type that they are configured to use. NEW routers can be configured to use only a subset of the available metric types. END --- There is a mismatched double quote at symmetric link in the middle paragraph. --- = =20 I wonder whether you want to make any comments about node metrics. Obviously, you don't have them (neighbor metrics being a different=20 thing), but you could comment on why you don't have them (if this was ever discussed). The question is slightly touched on in 5.2 in discussion of "delay". --- Section 8 Were there any security considerations that cropped up while designing metric support in OSLRv2? If so, here would be the place to mention them. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Mon Dec 17 02:24:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2040E21F89F9 for ; Mon, 17 Dec 2012 02:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 g+oAQd6W1OyL for ; Mon, 17 Dec 2012 02:24:08 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 6916721F8A63 for ; Mon, 17 Dec 2012 02:24:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,300,1355097600"; d="scan'208,217";a="250123968" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 17 Dec 2012 10:24:06 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qBHAO6jp025174 for ; Mon, 17 Dec 2012 10:24:06 GMT X-IronPort-AV: E=Sophos;i="4.84,300,1355097600"; d="scan'208,217";a="1357814" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 17 Dec 2012 10:24:06 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Mon, 17 Dec 2012 10:24:06 +0000 From: "Dearlove, Christopher (UK)" To: "JP Vasseur (jvasseur)" , Ulrich Herberg Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN2wba7oSZLgvLy0Gg5C2NTuMtSZgcyiWQ Date: Mon, 17 Dec 2012 10:24:05 +0000 Message-ID: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <3E873090-C8D3-4563-A7A4-331D2D599917@axelcdv.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF389CF@xmb-rcd-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF45A2E@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723111FD4@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7723111FD4@xmb-rcd-x02.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FD9F23GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 10:24:11 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FD9F23GLKXM0002VGREEN_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Our WG co-chair has explicitly raised non-technical issues of participation, so I'm afraid your wrong here JP. Much as I would like to just do the technical thing. But to be honest, I doubt anyone is participating much right now, especially anyone with a business year than is the calendar year. I would expect we may come back to this in the new year. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur) Sent: 15 December 2012 20:57 To: Ulrich Herberg Cc: Dearlove, Christopher (UK); ; Stan Ratliff (sratliff) Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) *** WARNING *** This message originates from outside our organisation, either from an external partner or the internet. Keep this in mind if you answer this message. Please see this process on how to deal with suspicious emails. Hi Ulrich, Let's try to stick the technical discussion and not restart a "marketing" war, ... these arguments have been spelled out on this list at least a hundred of time. Let's go back to the technical arguments of AODV2 and Load-ng and see if we can converge. Thanks. JP. On Dec 14, 2012, at 6:44 PM, Ulrich Herberg wrote: Stan, I think the argument could not be further from the truth. There are many active authors on the LOADng draft, from many different companies / universities, with many interoperable implementations (documented in an I-D), deployments, strong interest to drive the work forward. Moreover, other people were very actively discussing on the list and in the last meeting. We discussed for 1 hour 20 minutes! How can you say that there is no interest? For me, what we propose represents "rough consensus and running code". If I remember correctly, that is something the IETF supports very much. Best regards Ulrich On Fri, Dec 14, 2012 at 7:36 AM, Henning Rogge > wrote: On Fri, Dec 14, 2012 at 4:19 PM, Stan Ratliff (sratliff) > wrote: > Chris, > > On Dec 12, 2012, at 1:10 PM, Dearlove, Christopher (UK) wrote: > >> I think this is self-contradictory. It says there's a lot of strife but no interest. Strife does tend to happen more when there is interest. > > Fair point. Let me see if I can clarify. I liken this to 10 guys in a Pub brawl. They are fighting over who should lead the government, whilst 150 (or so) other Pub-goers are standing around, watching the melee. In that situation, I'd say there's a lot of strife, but not a lot of interest in mounting a revolution.... ;-) But at least 120 of your pub-goers have been asleep for a few years. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FD9F23GLKXM0002VGREEN_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Our WG co-chair has explicitly raised non-technical issues of participation, so I'm afraid your wrong here JP. Much as I would like to just do the technical thing.

 

But to be honest, I doubt anyone is participating much right now, especially anyone with a business year than is the calendar year. I would expect we may come back to this in the new year.

 

--

Christopher Dearlove

Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur)
Sent: 15 December 2012 20:57
To: Ulrich Herberg
Cc: Dearlove, Christopher (UK); <manet@ietf.org>; Stan Ratliff (sratliff)
Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt)

 

 

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

Hi Ulrich,

 

Let's try to stick the technical discussion and not restart a "marketing" war, … these arguments have been spelled out on this list at least a hundred of time.

Let's go back to the technical arguments of AODV2 and Load-ng and see if we can converge.

 

Thanks.

 

JP.

 

 

On Dec 14, 2012, at 6:44 PM, Ulrich Herberg wrote:



Stan,

 

I think the argument could not be further from the truth. There are many active authors on the LOADng draft, from many different companies / universities, with many interoperable implementations (documented in an I-D), deployments, strong interest to drive the work forward. Moreover, other people were very actively discussing on the list and in the last meeting. We discussed for 1 hour 20 minutes! How can you say that there is no interest? 

For me, what we propose represents "rough consensus and running code". If I remember correctly, that is something the IETF supports very much.

 

Best regards

Ulrich

 

On Fri, Dec 14, 2012 at 7:36 AM, Henning Rogge <hrogge@googlemail.com> wrote:

On Fri, Dec 14, 2012 at 4:19 PM, Stan Ratliff (sratliff)
<sratliff@cisco.com> wrote:
> Chris,
>
> On Dec 12, 2012, at 1:10 PM, Dearlove, Christopher (UK) wrote:
>
>> I think this is self-contradictory. It says there's a lot of strife but no interest. Strife does tend to happen more when there is interest.
>
> Fair point. Let me see if I can clarify. I liken this to 10 guys in a Pub brawl. They are fighting over who should lead the government, whilst 150 (or so) other Pub-goers are standing around, watching the melee. In that situation, I'd say there's a lot of strife, but not a lot of interest in mounting a revolution…. ;-)

But at least 120 of your pub-goers have been asleep for a few years.

Henning Rogge
--
Steven Hawkings about cosmic inflation: "An increase of billions of
billions of percent in a tiny fraction of a second. Of course, that
was before the present government."

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

 

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

 


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FD9F23GLKXM0002VGREEN_-- From abdussalambaryun@gmail.com Mon Dec 17 07:03:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927B721F8530 for ; Mon, 17 Dec 2012 07:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 cCgngA8-lmw8 for ; Mon, 17 Dec 2012 07:03:14 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D91A821F84E7 for ; Mon, 17 Dec 2012 07:03:13 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so7284272vcb.31 for ; Mon, 17 Dec 2012 07:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VishLHcnZgAOo9+hFd94RIYG50iipXiqjk0jNCp7JfY=; b=tb0NDM61NpiHW8fITXnwU8E597XALwAQHo8Ka9wwKB/IZi6AmhHfxDBVRVzgAL6ACd JEsP2iU2esDA1j82HPNhoJyZs8qO5R3gM/sCSqRP2k3pkzU6N7mIAh4tVNwqJ8TxHx6M SZygk40B7kcrnrnpC/C6N1Nwq30wqdsFAPsFlK8R2J34btttEXvhvZwubk8/sKiTRq+q qjvZFNwhE5wg19gOLbAcNUufmfVERXkNdYBV8X8PwxG2elwHjpiPPkehfYYqkEaROVHg C2JTsA6vr70e6sp2v+bLGdsXX13D7qEcsy168vs77zG8RSFyFvMMd6ddsN2j4+EPDc0u 42iA== MIME-Version: 1.0 Received: by 10.220.115.20 with SMTP id g20mr23778137vcq.31.1355756593185; Mon, 17 Dec 2012 07:03:13 -0800 (PST) Received: by 10.220.145.5 with HTTP; Mon, 17 Dec 2012 07:03:13 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF45A2E@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <3E873090-C8D3-4563-A7A4-331D2D599917@axelcdv.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF389CF@xmb-rcd-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF45A2E@xmb-aln-x03.cisco.com> Date: Mon, 17 Dec 2012 16:03:13 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 15:03:20 -0000 Hi Stan, I agree that there are alot not interested in mounting a revolution, but I think there is no doubt we need leadership (not government) to solve our problems, but only reasonable/technical discussions used by leaders can convince the 150 :) AB On 12/14/12, Stan Ratliff (sratliff) wrote: > Chris, > > On Dec 12, 2012, at 1:10 PM, Dearlove, Christopher (UK) wrote: > >> I think this is self-contradictory. It says there's a lot of strife but = no >> interest. Strife does tend to happen more when there is interest. > > Fair point. Let me see if I can clarify. I liken this to 10 guys in a Pub > brawl. They are fighting over who should lead the government, whilst 150 = (or > so) other Pub-goers are standing around, watching the melee. In that > situation, I'd say there's a lot of strife, but not a lot of interest in > mounting a revolution=85. ;-) > > Regards, > Stan > > >> >> I think the limited amount of technical discussion on the drafts is >> significantly in part because people are waiting to work out which draft >> they should comment on. (And it's also not a great time of year.) And ev= en >> so today I see at least two people who are not authors making technical >> points (and there were more over the last few days). And some points >> (common to both drafts) a week or two ago from people who aren't regular= s, >> let alone authors. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, >> Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f >> Stan Ratliff (sratliff) >> Sent: 12 December 2012 15:58 >> To: Axel Colin de Verdi=E8re >> Cc: >> Subject: Re: [manet] LOADng (was Re: I-D Action: >> draft-ietf-manet-dymo-24.txt) >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> Axel, >> >> On Dec 11, 2012, at 6:01 PM, Axel Colin de Verdi=E8re wrote: >> >>> Hi Stan, >>> >>> Le 11 d=E9c. 2012 =E0 11:03, Stan Ratliff (sratliff) a >>> =E9crit : >>> >>>> JP, >>>> >>>> On Dec 10, 2012, at 9:19 PM, JP Vasseur (jvasseur) wrote: >>>> >>>>> Hi Stan, >>>>> >>>>> On Dec 10, 2012, at 6:58 AM, Stan Ratliff (sratliff) wrote: >>>>> >>>>>> Abdussalam, >>>>>> >>>>>> On Dec 10, 2012, at 5:51 AM, Abdussalam Baryun wrote: >>>>>> >>>>>>> On 12/7/12, Stan Ratliff (sratliff) wrote: >>>>>>>> >>>>>>>> My feeling, FWIW, is that ingress/egress SHOULD be a part of the >>>>>>>> base >>>>>>>> document. However, I understand the concerns of people that say it >>>>>>>> might be >>>>>>>> a problem (or extend ratification time, etc etc). So, I'm interest= ed >>>>>>>> in >>>>>>>> hearing other, interested opinions - both for >>>>>>>> DYMO/AODVv2/Whatever-we're-calling-it-this-week, as well as with >>>>>>>> regard to >>>>>>>> the LOADng spec. >>>>>>> >>>>>>> I know from my efforts that LOADng team are not welling to discuss, >>>>>>> or >>>>>>> reply to questions/comments, so I want to know your opinion of the >>>>>>> status on this LOADng draft as you brought it to the list; Is it a >>>>>>> WG >>>>>>> draft? should we discuss individual or private work now? >>>>>>> >>>>>>> I remember that we answered chair questions and options given. Not >>>>>>> sure what the chair of WG wants us to do so far, please advise, >>>>>> >>>>>> It wasn't clear to me what the consensus was in Atlanta vis-a-vis th= e >>>>>> two reactive protocol documents. Presently, DYMO is the working grou= p >>>>>> accepted reactive protocol document. However, there was a 2-year >>>>>> period of time when DYMO was inactive, and the document was "parked"= . >>>>>> As a result of that, the effort to create LOADng sprang up. >>>>>> >>>>>> So now, we have two documents to consider. In the charter, the WG is >>>>>> "on the hook" for 1 (and only 1) reactive protocol. So the current >>>>>> options are: >>>>>> 1. Recognize that we cannot reach consensus with the two documents, >>>>>> and remove the charter item for reactive protocols. To be frank, thi= s >>>>>> is my preferred option. >>>>>> 2. Accept one of the two documents (either LOADng or DYMO), and pres= s >>>>>> forward >>>>>> 3. Perhaps alter the charter item, and produce 2 reactive protocols, >>>>>> both in "experimental" state. >>>>>> >>>>> >>>>> JP> What about putting a hard dead-line and if there is no consensus >>>>> fall back to 1 ? >>>> >>>> There's only one problem with that - It's already happened, and the >>>> deadline has already passed without conclusion. ;-) It happened in >>>> Vancouver, with a deadline of Atlanta. >>>> >>>> To the working group at large - >>>> >>>> I'm not seeing a high level of interest here. People seem to only have >>>> "passing interest" - enough to keep the efforts on life support, but n= ot >>>> enough to really progress things. By and large, only the authors have >>>> the inclination to push their respective opinions, and nothing has >>>> really changed. >>> >>> I'm a bit surprised here: it seems weird to me that you can just dismis= s >>> a 10 people behind a document, with strong industrial support (includin= g >>> actual deployments) as "passing", or even "not enough" interest. >>> Furthermore, I've seen that we (the LOADng authors) are far from the on= ly >>> ones participating on this topic. >>> >>>> >>>> So, I call once again - I think it's time to remove the work item from >>>> the charter, and recognize that we're not going to be able to work >>>> together on this issue. After more than a year of trying to get people >>>> to work together to make the technology better, just don't see it >>>> happening. It's time to end the misery. >>> >>> I understand your position, I think you made that clear relatively earl= y >>> in the process, but I don't think "not enough interest" is really a goo= d >>> reason here. >> >> To the contrary, "Not enough interest" is a perfectly good reason for >> stopping work. So is "we can't agree on an outcome". IMHO, *both* of the= se >> situations are in effect here. Compared to the WG as a whole, there is a >> small set of people whirring and spinning on a couple of documents. >> Outside of that small clique, we're not seeing a lot of interest >> (activity) on the mailing list. To simply state that ".we (the LOADng >> authors) are far from the only ones participating.", without examples, i= s >> not proof - it's merely an assertion. The call of whether there is >> "sufficient support" in the WG is admittedly subjective. However, given >> the amount of strife on the topic, the likelihood that the WG will reach >> consensus, and the level of interest that I gauge - I stand by my >> position. IMO, as co-chair, this work should be terminated. >> >> Stan >> >> >> >>> >>> Best, >>> >>> Axel >>> >>>> >>>> Regards, >>>> Stan >>>> >>>> >>>> >>>>> >>>>>> Now, you mentioned "Not sure what the chairs of WG want us to do so >>>>>> far".. the best answer I can give you on that is "reach consensus on >>>>>> an approach". We as a working group haven't done that yet. There ar= e >>>>>> people advocating for DYMO, others advocating for LOADng, and some >>>>>> that want to "merge" the technology of the two together. A "merge" w= as >>>>>> something we tried in the Vancouver timeframe, but that effort faile= d. >>>>>> >>>>>> >>>>>> As to your statement that the LOADng team is not willing to discuss = - >>>>>> I haven't seen that, do not agree with it, and would ask you to cite >>>>>> *specific* examples if you have them. I've found the LOADng team to = be >>>>>> reasonable in their dealings with the WG. There is the issue of >>>>>> re-spinning the LOADng document without the copyright statement - Th= e >>>>>> LOADng authors and the chairs have reached an understanding about th= at >>>>>> issue, so I no longer have a problem with moving forward on that >>>>>> front. >>>>>> >>>>>> Again, as a working group - we *MUST* either reach a consensus, or t= he >>>>>> work item will be removed *for us*. If we do not show progress towar= ds >>>>>> a goal, it is within the power of the IESG to stop work on the issue= . >>>>>> >>>>>> Regards, >>>>>> Stan >>>>>> >>>>>> >>>>>>> >>>>>>> AB >>>>>>> >>>>>>>> >>>>>>>> And lastly... if the 5 guys were *that* important, they most likel= y >>>>>>>> wouldn't >>>>>>>> be *playing* black-ops. ;-) >>>>>>>> >>>>>>>> Stan >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>> >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Mon Dec 17 07:15:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0988421F8ADD for ; Mon, 17 Dec 2012 07:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 MGUE1rAbnFHd for ; Mon, 17 Dec 2012 07:15:38 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD8321F8AD4 for ; Mon, 17 Dec 2012 07:15:38 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so7192455vbb.31 for ; Mon, 17 Dec 2012 07:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bXkgPttRH0GchH91jYllchUvH7MV/qZtfI1WosGVktQ=; b=mN8qJDnHMSVg3qGYjGfD0gavKezlNeAAZSQLEb+U0UesBb3X2qoyDxDEXsp6z+YQF8 b/N/zzeWyuki+yNt/gc2iMJn3VER+AfBpBD6xEUbA8fd7j631PhQevNQCHC3GpHcT5i1 hlFpbiQ/Ah5UDFs3O7AvxL1v2SnBjdwicfoiO2F7FPEyISL9ohg5OneMAcCAziN/CESK ZKEXCOz0JPlXh4lAY7WSQCIF20ZqfaeeiX667JCK6E4ijA4NSIZ2HFKHLsuYpcRAI+aS gXiT6cuxjT26NGt65ugI0nh8MLuBc8gkXi1POou2dBcHpEMtWSQBZ/9PF2zByaXBWjut kxYA== MIME-Version: 1.0 Received: by 10.220.115.20 with SMTP id g20mr23854802vcq.31.1355757337759; Mon, 17 Dec 2012 07:15:37 -0800 (PST) Received: by 10.220.145.5 with HTTP; Mon, 17 Dec 2012 07:15:37 -0800 (PST) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7723111FD4@xmb-rcd-x02.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <3E873090-C8D3-4563-A7A4-331D2D599917@axelcdv.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF389CF@xmb-rcd-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF45A2E@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723111FD4@xmb-rcd-x02.cisco.com> Date: Mon, 17 Dec 2012 16:15:37 +0100 Message-ID: From: Abdussalam Baryun To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 15:15:39 -0000 Hi JP I agree with you to focus on the documents and technical issues. also hope that we find a reasonable way to solve this issue as soon as possible. I hope this issue does not happen in the future with another parking WG document. I recommend the chairs and AD advise the authors of both document and then report to us why there is no end in this issue (the merge idea was agreed by one party but then changed). Really I think the authors already went through discussing the merge under the chair request off the list (without 150 monitoring, an example mentioned before of other participants). The problem was they discussed the merge technical issues off the list, so we cannot know the reasons why we are in this problem. Problems/confusions only happen when there is no clear/traced discussions. AB On 12/15/12, JP Vasseur (jvasseur) wrote: > Hi Ulrich, > > Let's try to stick the technical discussion and not restart a "marketing" > war, =85 these arguments have been spelled out on this list at least a hu= ndred > of time. > Let's go back to the technical arguments of AODV2 and Load-ng and see if = we > can converge. > > Thanks. > > JP. > > > On Dec 14, 2012, at 6:44 PM, Ulrich Herberg wrote: > > Stan, > > I think the argument could not be further from the truth. There are many > active authors on the LOADng draft, from many different companies / > universities, with many interoperable implementations (documented in an > I-D), deployments, strong interest to drive the work forward. Moreover, > other people were very actively discussing on the list and in the last > meeting. We discussed for 1 hour 20 minutes! How can you say that there i= s > no interest? > For me, what we propose represents "rough consensus and running code". If= I > remember correctly, that is something the IETF supports very much. > > Best regards > Ulrich > > > On Fri, Dec 14, 2012 at 7:36 AM, Henning Rogge > > wrote: > On Fri, Dec 14, 2012 at 4:19 PM, Stan Ratliff (sratliff) > > wrote: >> Chris, >> >> On Dec 12, 2012, at 1:10 PM, Dearlove, Christopher (UK) wrote: >> >>> I think this is self-contradictory. It says there's a lot of strife but >>> no interest. Strife does tend to happen more when there is interest. >> >> Fair point. Let me see if I can clarify. I liken this to 10 guys in a Pu= b >> brawl. They are fighting over who should lead the government, whilst 150 >> (or so) other Pub-goers are standing around, watching the melee. In that >> situation, I'd say there's a lot of strife, but not a lot of interest in >> mounting a revolution=85. ;-) > > But at least 120 of your pub-goers have been asleep for a few years. > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > From adrian@olddog.co.uk Mon Dec 17 10:55:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216F221F8AC4 for ; Mon, 17 Dec 2012 10:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 MhSr71jN3q5V for ; Mon, 17 Dec 2012 10:55:40 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id A6DA521F8853 for ; Mon, 17 Dec 2012 10:55:37 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBHItaYu008894 for ; Mon, 17 Dec 2012 18:55:36 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBHItZqt008881 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 17 Dec 2012 18:55:35 GMT From: "Adrian Farrel" To: Date: Mon, 17 Dec 2012 18:55:34 -0000 Message-ID: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3ciBJ3/vN1pAf+Rv2ZbFjt/Xl/Hg== Content-Language: en-gb Subject: [manet] Resolving the Reactive Protocol issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 18:55:41 -0000 Hi MANET, In the spirit of all good examination papers, please read all the way to the end of this email before starting to write your response. I have been watching the discussions on the MANET list with care and talking with the chairs. All three of us have, I know, received plenty of private emails on the subject as well. In my opinion, the debate about documents has almost (but not completely) obscured the technical work. This is neither helpful nor in the spirit of an engineering organisation. As AD it falls to me to unblock this log jam and enable the working group to do useful work. I think I see people explicitly asking for AD intervention. In Atlanta, there remained interest in having a reactive protocol produced by the working group. There is clearly still some interest on the list. But it is not clear to me how the WG feels on this since there may be many who are watching and wishing they could get on with other work in a quieter environment. Therefore: ===== Question 1 to the working group: Would you prefer to have "Standards track Reactive protocol" removed from the charter? A "yes/no" answer is all that I want to hear. ===== It is clear to me that attempts to merge or choose documents have failed. There is no value in discussing how or why, nor to what extent they might be partially successful, or how resolution could be potentially reached. Therefore: ===== Question 2 to the working group: Would you like the AD to select one of the documents (and, obviously, I will not tell you in advance which I might select!) and require that the WG works on that one document? In this case, publication of the other document with AD sponsorship or through the ISE is unlikely. Again, a "yes/no" answer is all I want to hear, but respondents must understand that saying "yes" implies a willingness to cooperate, to provide text, and to have the WG make any modifications to the document all in the normal IETF way. ===== Failing the selection of just one document, and absent abandoning the work item, there remains the possibility of progressing both documents within the working group. As AD I will not allow the working group to produce two standards track RFCs for reactive protocols, and I therefore see no benefit in having two working group drafts claiming to be intended for standards track publication. So this leads to: ===== Question 3 to the working group: Would you be prepared to work on two documents describing reactive protocols that are intended for publication as Experimental RFCs? Yet again, a "yes/no" answer is what I want to hear, but respondents need to understand that saying "yes" implies a willingness to see both documents published as Experimental RFCs and that, owing to the lower bar on Experimental work, it would not be acceptable to attempt to block the progress of either document with protracted technical discussions. We might (in the operational spirit of the MANET working group) come back after some time and experience with the RFCs to re-charter and select just one solution for the standards track, but that is for the distant future. ===== I need to explain to the working group that the default position will be to remove this item from the WG charter. That is, if the WG overwhelmingly says "no" to both Q2 and Q3, I will work with the IESG to remove reactive protocols from the MANET charter regardless of the answer to Q1. How to answer this email: Send responses in the form of 1 [yes/no] 2 [yes/no] 3 [yes/no] This is not a vote, but I am taking the mood of the working group in order to inform my decision. Conditional answers such as "yes, but only if foo" are within your rights, but will not be very helpful to me, I know that many people are busy with work or enjoying themselves at this time of year, but this decisions needs to be made soon. I am inclined to make my decision before the end of 2012, but in deference to the festivities, I will announce it in the week of January 7th. Thanks, Adrian From abdussalambaryun@gmail.com Tue Dec 18 06:53:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC80D21F888C for ; Tue, 18 Dec 2012 06:53:49 -0800 (PST) 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=[AWL=-0.000, 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 t9fVO1ZLy2p7 for ; Tue, 18 Dec 2012 06:53:49 -0800 (PST) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by ietfa.amsl.com (Postfix) with ESMTP id EA82921F8820 for ; Tue, 18 Dec 2012 06:53:48 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id p1so939252vbi.32 for ; Tue, 18 Dec 2012 06:53:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=liJ7gr0ZHExqQs5OGuy4VvUx/Nqj4CKEnbQp9D2cn1k=; b=ny1RHnw8SipvDwDAZC+rAhA0jmmpl4CfXdbCaxsAU1Vy5IHb2QJwEPErrmQcOw1zK7 wBJERjUdKMFLbqjtDhlB8jaRIs4fL8YuEbOcOMUxbySB2paeDTAxCnKjPL8a4pMIahjC 3Fu4gd6JCxkEdfOIg4OGzZWCVFzhOAE+sSB2Gk3cYHDfzpWGKvlCSHUcXQAPmGh7vtJ0 VByjSk/SSZDppr7hu+eIPfKcBTEFFK0jxc1GhW2OZJZVLRnTIUPmeI7Dy5V6Eh0kDRbm hdPuCDQldTFo/Qs4YOeu0SVHE8TPqGpmHzJBUe05DP8Wgn/WJu8yDscbPWyFUpuwGF2Q 0WeQ== MIME-Version: 1.0 Received: by 10.52.70.46 with SMTP id j14mr2862559vdu.99.1355842428334; Tue, 18 Dec 2012 06:53:48 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 18 Dec 2012 06:53:48 -0800 (PST) In-Reply-To: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> References: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> Date: Tue, 18 Dec 2012 14:53:48 +0000 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=20cf307f39aa4ff39c04d121aaab Cc: manet@ietf.org Subject: Re: [manet] Resolving the Reactive Protocol issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 14:53:49 -0000 --20cf307f39aa4ff39c04d121aaab Content-Type: text/plain; charset=ISO-8859-1 Hi Adrian, The WG AD my answers as per your request; Q1 [no] Q2 [yes] Q3 [no] Thank you for the solution and help for WG progress, wishing you and all WG participants a happy new year :) Best Regards AB --20cf307f39aa4ff39c04d121aaab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Adrian,
The=A0WG AD
=A0
my answers as= per your request;
=A0
Q1 [no]
Q2 [yes]
Q3 [no]
Thank you for the=A0solution and help for WG progress, wishing= you and all WG participants a happy new year :)
=A0
Best Regards
AB
--20cf307f39aa4ff39c04d121aaab-- From adrian@olddog.co.uk Tue Dec 18 08:57:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9B321F8A79 for ; Tue, 18 Dec 2012 08:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 AL4YPr7+NKyl for ; Tue, 18 Dec 2012 08:57:46 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id EB40921F8566 for ; Tue, 18 Dec 2012 08:57:45 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBIGvils030943 for ; Tue, 18 Dec 2012 16:57:44 GMT Received: from 950129200 (ixe-nat1.juniper.net [193.110.54.36]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBIGvhWR030935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 18 Dec 2012 16:57:44 GMT From: "Adrian Farrel" To: References: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> In-Reply-To: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> Date: Tue, 18 Dec 2012 16:57:41 -0000 Message-ID: <031b01cddd40$cb961af0$62c250d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGcuryqLQrd02p/qvpG6pCeEookJpiBC7VQ Content-Language: en-gb Subject: Re: [manet] Resolving the Reactive Protocol issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 16:57:47 -0000 Since I have now had 6 responses and only 1 was on the list, can I just say: that's OK. Reponses in private are just fine. I am not trying to build WG consensus, but (as the ITU might say) take the mood of the room. Thanks, Adrian > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: 17 December 2012 18:56 > To: manet@ietf.org > Subject: [manet] Resolving the Reactive Protocol issue > > Hi MANET, > > In the spirit of all good examination papers, please read all the way to the end > of this email before starting to write your response. > > I have been watching the discussions on the MANET list with care and talking > with the chairs. All three of us have, I know, received plenty of private emails > on the subject as well. > > In my opinion, the debate about documents has almost (but not completely) > obscured the technical work. This is neither helpful nor in the spirit of an > engineering organisation. > > As AD it falls to me to unblock this log jam and enable the working group to do > useful work. I think I see people explicitly asking for AD intervention. > > In Atlanta, there remained interest in having a reactive protocol produced by > the working group. There is clearly still some interest on the list. But it is > not clear to me how the WG feels on this since there may be many who are > watching and wishing they could get on with other work in a quieter > environment. > Therefore: > > ===== > Question 1 to the working group: Would you prefer to have "Standards track > Reactive protocol" removed from the charter? A "yes/no" answer is all that I > want to hear. > ===== > > It is clear to me that attempts to merge or choose documents have failed. There > is no value in discussing how or why, nor to what extent they might be partially > successful, or how resolution could be potentially reached. Therefore: > > ===== > Question 2 to the working group: Would you like the AD to select one of the > documents (and, obviously, I will not tell you in advance which I might select!) > and require that the WG works on that one document? In this case, publication of > the other document with AD sponsorship or through the ISE is unlikely. Again, a > "yes/no" answer is all I want to hear, but respondents must understand that > saying "yes" implies a willingness to cooperate, to provide text, and to have > the WG make any modifications to the document all in the normal IETF way. > ===== > > Failing the selection of just one document, and absent abandoning the work > item, > there remains the possibility of progressing both documents within the working > group. As AD I will not allow the working group to produce two standards track > RFCs for reactive protocols, and I therefore see no benefit in having two > working group drafts claiming to be intended for standards track publication. So > this leads to: > > ===== > Question 3 to the working group: Would you be prepared to work on two > documents > describing reactive protocols that are intended for publication as Experimental > RFCs? Yet again, a "yes/no" answer is what I want to hear, but respondents need > to understand that saying "yes" implies a willingness to see both documents > published as Experimental RFCs and that, owing to the lower bar on Experimental > work, it would not be acceptable to attempt to block the progress of either > document with protracted technical discussions. We might (in the operational > spirit of the MANET working group) come back after some time and experience > with > the RFCs to re-charter and select just one solution for the standards track, but > that is for the distant future. > ===== > > I need to explain to the working group that the default position will be to > remove this item from the WG charter. That is, if the WG overwhelmingly says > "no" to both Q2 and Q3, I will work with the IESG to remove reactive protocols > from the MANET charter regardless of the answer to Q1. > > > How to answer this email: Send responses in the form of > 1 [yes/no] > 2 [yes/no] > 3 [yes/no] > This is not a vote, but I am taking the mood of the working group in order to > inform my decision. > Conditional answers such as "yes, but only if foo" are within your rights, but > will not be very helpful to me, > > I know that many people are busy with work or enjoying themselves at this time > of year, but this decisions needs to be made soon. I am inclined to make my > decision before the end of 2012, but in deference to the festivities, I will > announce it in the week of January 7th. > > Thanks, > Adrian > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Tue Dec 18 09:01:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F293B21F8A92 for ; Tue, 18 Dec 2012 09:01:22 -0800 (PST) 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 UursbWEbwPQR for ; Tue, 18 Dec 2012 09:01:22 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2F07521F88A3 for ; Tue, 18 Dec 2012 09:01:21 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id j13so765722lah.13 for ; Tue, 18 Dec 2012 09:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=s98SlMH4raF9KMyUd+1eLcgLR6z8rrYcI5YONIMQb5w=; b=d6B0/reXxahTBf3JJX1BNcuFXdHM1F9f9dNPb4MSiAUKIepYv/ME2gn1oeXE1zCUzk RV0DmoFZQxWHs2SW7m92nDrQDWgfdCXjYcdTYprPGijVAW3lMWAaaW02WCVN+zgJjK39 eEEfJhwwWv7Roh5du9QXRN2qRMMsevwW/qWvLeg7GoBLzMgqB5XjPO7PsLW9SaHPG5uO CGi3QPsUOfVNWI6hmX9CPu3ndCxv0ITLv7GcH5A+Uxahs5A/77CY+hwHQJIy38rnI+Di npNzS2dxFX9jdE+RJviOSQoX8OU9FtP/X2ZPZreAzn8EpBGlv11pbJhULYW6Cr+2rFzM u4HA== Received: by 10.152.105.134 with SMTP id gm6mr2507730lab.31.1355850081110; Tue, 18 Dec 2012 09:01:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Tue, 18 Dec 2012 09:01:00 -0800 (PST) In-Reply-To: <031b01cddd40$cb961af0$62c250d0$@olddog.co.uk> References: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> <031b01cddd40$cb961af0$62c250d0$@olddog.co.uk> From: Henning Rogge Date: Tue, 18 Dec 2012 18:01:00 +0100 Message-ID: To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Resolving the Reactive Protocol issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 17:01:23 -0000 On Tue, Dec 18, 2012 at 5:57 PM, Adrian Farrel wrote: > Since I have now had 6 responses and only 1 was on the list, can I just say: > that's OK. > > Reponses in private are just fine. I am not trying to build WG consensus, but > (as the ITU might say) take the mood of the room. Does this mean this "taking the mood" will turn into a vote later? ;) Yes, I am also for getting a reactive protocol done. I think AODV2 and LOADng are not that far from each other, but the LOADng draft is much easier to read and to implement. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From charliep@computer.org Tue Dec 18 10:05:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B87A21F880E for ; Tue, 18 Dec 2012 10:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 XJgEnMeXK1DW for ; Tue, 18 Dec 2012 10:05:54 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3544921F87CA for ; Tue, 18 Dec 2012 10:05:53 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Tl1Y8-00014F-Td; Tue, 18 Dec 2012 13:05:53 -0500 Message-ID: <50D0B077.2020307@computer.org> Date: Tue, 18 Dec 2012 10:05:43 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> In-Reply-To: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86980fff5e78552d0ba12d328c13287aeb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: manet@ietf.org Subject: Re: [manet] Resolving the Reactive Protocol issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 18:05:55 -0000 Hello Adrian, 1[removed from the charter ]: no 2[AD select one ]: yes 3[publication as Experimental ]: no Regards. Charlie P. On 12/17/2012 10:55 AM, Adrian Farrel wrote: > Hi MANET, > > In the spirit of all good examination papers, please read all the way to the end > of this email before starting to write your response. > > I have been watching the discussions on the MANET list with care and talking > with the chairs. All three of us have, I know, received plenty of private emails > on the subject as well. > > In my opinion, the debate about documents has almost (but not completely) > obscured the technical work. This is neither helpful nor in the spirit of an > engineering organisation. > > As AD it falls to me to unblock this log jam and enable the working group to do > useful work. I think I see people explicitly asking for AD intervention. > > In Atlanta, there remained interest in having a reactive protocol produced by > the working group. There is clearly still some interest on the list. But it is > not clear to me how the WG feels on this since there may be many who are > watching and wishing they could get on with other work in a quieter environment. > Therefore: > > ===== > Question 1 to the working group: Would you prefer to have "Standards track > Reactive protocol" removed from the charter? A "yes/no" answer is all that I > want to hear. > ===== > > It is clear to me that attempts to merge or choose documents have failed. There > is no value in discussing how or why, nor to what extent they might be partially > successful, or how resolution could be potentially reached. Therefore: > > ===== > Question 2 to the working group: Would you like the AD to select one of the > documents (and, obviously, I will not tell you in advance which I might select!) > and require that the WG works on that one document? In this case, publication of > the other document with AD sponsorship or through the ISE is unlikely. Again, a > "yes/no" answer is all I want to hear, but respondents must understand that > saying "yes" implies a willingness to cooperate, to provide text, and to have > the WG make any modifications to the document all in the normal IETF way. > ===== > > Failing the selection of just one document, and absent abandoning the work item, > there remains the possibility of progressing both documents within the working > group. As AD I will not allow the working group to produce two standards track > RFCs for reactive protocols, and I therefore see no benefit in having two > working group drafts claiming to be intended for standards track publication. So > this leads to: > > ===== > Question 3 to the working group: Would you be prepared to work on two documents > describing reactive protocols that are intended for publication as Experimental > RFCs? Yet again, a "yes/no" answer is what I want to hear, but respondents need > to understand that saying "yes" implies a willingness to see both documents > published as Experimental RFCs and that, owing to the lower bar on Experimental > work, it would not be acceptable to attempt to block the progress of either > document with protracted technical discussions. We might (in the operational > spirit of the MANET working group) come back after some time and experience with > the RFCs to re-charter and select just one solution for the standards track, but > that is for the distant future. > ===== > > I need to explain to the working group that the default position will be to > remove this item from the WG charter. That is, if the WG overwhelmingly says > "no" to both Q2 and Q3, I will work with the IESG to remove reactive protocols > from the MANET charter regardless of the answer to Q1. > > > How to answer this email: Send responses in the form of > 1 [yes/no] > 2 [yes/no] > 3 [yes/no] > This is not a vote, but I am taking the mood of the working group in order to > inform my decision. > Conditional answers such as "yes, but only if foo" are within your rights, but > will not be very helpful to me, > > I know that many people are busy with work or enjoying themselves at this time > of year, but this decisions needs to be made soon. I am inclined to make my > decision before the end of 2012, but in deference to the festivities, I will > announce it in the week of January 7th. > > Thanks, > Adrian > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From abdussalambaryun@gmail.com Tue Dec 18 10:07:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C6221F8AC3 for ; Tue, 18 Dec 2012 10:07:18 -0800 (PST) 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=[AWL=-0.000, 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 wey2OBh+1Klt for ; Tue, 18 Dec 2012 10:07:18 -0800 (PST) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id BFADB21F880E for ; Tue, 18 Dec 2012 10:07:17 -0800 (PST) Received: by mail-vb0-f43.google.com with SMTP id fs19so1231273vbb.2 for ; Tue, 18 Dec 2012 10:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=kOylgmVe+8VelFS3lqHTSDjdv+D9jz5foV/oUn/ZDB4=; b=ncA/ncXAG4795BprCABxael9aCC4QqyJ532J8fi2dA5U3j/W1GIW1kbzQhvgllW4ta TD8np5pSgTTJ1136Hv0+z8HYthzQFLhZXH95XSxEn6Z+lqGriwFAYpmHYKeXP5hUb209 5lGcUZpMGjPdZ4OMVF20DBxPBZLVnU1NGXVe/tDk6si0V1tVUi7gxw/U1G0HF9h+cwxy jnJWQY9DdDQSOAWZeHyWgr7MCqfjqd1zl1PJcL39xTHckyD7rlguJENRm5pj6AfN/Qtv YU0FATfHyWkqyjwHakd8XYUiK/agTsNpUqMxGsdrdBXTznz8rUYdaUJMLjzzxRLFDh5F VaAw== MIME-Version: 1.0 Received: by 10.58.198.135 with SMTP id jc7mr4466382vec.51.1355854036979; Tue, 18 Dec 2012 10:07:16 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 18 Dec 2012 10:07:16 -0800 (PST) Date: Tue, 18 Dec 2012 18:07:16 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7b5d8cd73dd00a04d1245e61 Cc: manet@ietf.org Subject: [manet] AODVv2 (was RE: Resolving the Reactive Protocol issue) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 18:07:18 -0000 --047d7b5d8cd73dd00a04d1245e61 Content-Type: text/plain; charset=ISO-8859-1 Hi Henning, I agree that both DYMO and LOADng are a new version of AODV. After I understood from the co-chair the WG position, I got to a point that I just want a solution not later than the next meeting, AB On Tue, Dec 18, 2012 at 5:01 PM, Henning Rogge wrote: > On Tue, Dec 18, 2012 at 5:57 PM, Adrian Farrel > wrote: > > Since I have now had 6 responses and only 1 was on the list, can I just > say: > > that's OK. > > > > Reponses in private are just fine. I am not trying to build WG > consensus, but > > (as the ITU might say) take the mood of the room. > > Does this mean this "taking the mood" will turn into a vote later? ;) > > Yes, I am also for getting a reactive protocol done. I think AODV2 and > LOADng are not that far from each other, but the LOADng draft is much > easier to read and to implement. > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7b5d8cd73dd00a04d1245e61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Henning,
=A0
I agree that both DYMO and LOADng = are a new version of AODV. After I understood from the co-chair the WG posi= tion, I got to a point=A0that I just want a solution not later than the=A0n= ext meeting,
=A0
AB

On Tue, Dec 1= 8, 2012 at 5:01 PM, Henning Rogge <hrogge@googlemail.com> wrote:
On Tue, Dec 18, 2012 at 5:57 PM, Adrian = Farrel <adrian@olddog.co.uk&g= t; wrote:
> Since I have now had 6 responses and only 1 was on the list, can I jus= t say:
> that's OK.
>
> Reponses in private are just fine. I am not trying to build WG consens= us, but
> (as the ITU might say) take the mood of the room.

Does this mean this "taking the mood" will turn into a vote= later? ;)

Yes, I am also for getting a reactive protocol done. I think AODV2 and
LOADng are not that far from each other, but the LOADng draft is much
easier to read and to implement.

Henning Rogge
--
Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that
was before the present government."
_____________________= __________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--047d7b5d8cd73dd00a04d1245e61-- From charliep@computer.org Tue Dec 18 10:18:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E2C21E8045 for ; Tue, 18 Dec 2012 10:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 NXsXg839H0jW for ; Tue, 18 Dec 2012 10:18:02 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id B9F9121E803D for ; Tue, 18 Dec 2012 10:18:02 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Tl1ju-0004U7-7J for manet@ietf.org; Tue, 18 Dec 2012 13:18:02 -0500 Message-ID: <50D0B352.6030904@computer.org> Date: Tue, 18 Dec 2012 10:17:54 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: manet@ietf.org References: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> In-Reply-To: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86563662d08a22e818e438efa7007bfa95350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Subject: Re: [manet] Resolving the Reactive Protocol issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 18:18:03 -0000 Hello folks, I can't change the past events that have brought us to this point. But I'd at least like to encourage optimism about the progress of the existing WG document. Here is why: - The last WG document revision submitted is also the first one which logistically I was able to bring up to a good standard of correctness, and readability. It shows my commitment to produce a high-quality document. - I reiterate that LOADng should be supported as a set of choices from among the optional features of the WG reactive protocol specification. While I was not able to accomplish this by working with the other LOADng authors to merge the documents, I have always been explicit that this was the desired outcome. Well, that's about as far as I know how to get into the political waters. I've always set about doing the things I promised to do, and so far during the last year I have done so. That also includes to make a consensus and good quality WG document. Regards, Charlie P. On 12/17/2012 10:55 AM, Adrian Farrel wrote: > Hi MANET, > > In the spirit of all good examination papers, please read all the way to the end > of this email before starting to write your response. > > I have been watching the discussions on the MANET list with care and talking > with the chairs. All three of us have, I know, received plenty of private emails > on the subject as well. > > In my opinion, the debate about documents has almost (but not completely) > obscured the technical work. This is neither helpful nor in the spirit of an > engineering organisation. > > As AD it falls to me to unblock this log jam and enable the working group to do > useful work. I think I see people explicitly asking for AD intervention. > > In Atlanta, there remained interest in having a reactive protocol produced by > the working group. There is clearly still some interest on the list. But it is > not clear to me how the WG feels on this since there may be many who are > watching and wishing they could get on with other work in a quieter environment. > Therefore: > > ===== > Question 1 to the working group: Would you prefer to have "Standards track > Reactive protocol" removed from the charter? A "yes/no" answer is all that I > want to hear. > ===== > > It is clear to me that attempts to merge or choose documents have failed. There > is no value in discussing how or why, nor to what extent they might be partially > successful, or how resolution could be potentially reached. Therefore: > > ===== > Question 2 to the working group: Would you like the AD to select one of the > documents (and, obviously, I will not tell you in advance which I might select!) > and require that the WG works on that one document? In this case, publication of > the other document with AD sponsorship or through the ISE is unlikely. Again, a > "yes/no" answer is all I want to hear, but respondents must understand that > saying "yes" implies a willingness to cooperate, to provide text, and to have > the WG make any modifications to the document all in the normal IETF way. > ===== > > Failing the selection of just one document, and absent abandoning the work item, > there remains the possibility of progressing both documents within the working > group. As AD I will not allow the working group to produce two standards track > RFCs for reactive protocols, and I therefore see no benefit in having two > working group drafts claiming to be intended for standards track publication. So > this leads to: > > ===== > Question 3 to the working group: Would you be prepared to work on two documents > describing reactive protocols that are intended for publication as Experimental > RFCs? Yet again, a "yes/no" answer is what I want to hear, but respondents need > to understand that saying "yes" implies a willingness to see both documents > published as Experimental RFCs and that, owing to the lower bar on Experimental > work, it would not be acceptable to attempt to block the progress of either > document with protracted technical discussions. We might (in the operational > spirit of the MANET working group) come back after some time and experience with > the RFCs to re-charter and select just one solution for the standards track, but > that is for the distant future. > ===== > > I need to explain to the working group that the default position will be to > remove this item from the WG charter. That is, if the WG overwhelmingly says > "no" to both Q2 and Q3, I will work with the IESG to remove reactive protocols > from the MANET charter regardless of the answer to Q1. > > > How to answer this email: Send responses in the form of > 1 [yes/no] > 2 [yes/no] > 3 [yes/no] > This is not a vote, but I am taking the mood of the working group in order to > inform my decision. > Conditional answers such as "yes, but only if foo" are within your rights, but > will not be very helpful to me, > > I know that many people are busy with work or enjoying themselves at this time > of year, but this decisions needs to be made soon. I am inclined to make my > decision before the end of 2012, but in deference to the festivities, I will > announce it in the week of January 7th. > > Thanks, > Adrian > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From sratliff@cisco.com Tue Dec 18 11:06:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E5C21F8A98 for ; Tue, 18 Dec 2012 11:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.512 X-Spam-Level: X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 PnP9nuGOHzw7 for ; Tue, 18 Dec 2012 11:06:27 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 84BFD21F8A80 for ; Tue, 18 Dec 2012 11:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=147; q=dns/txt; s=iport; t=1355857587; x=1357067187; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wg2FtohJu1MjNPTo1YODuhfCYpIAPiZQcNhwgDBkcic=; b=MRlJ/Hrr1/gKkKK6rQtdTHI8aHbiBaD4mpviRGEDpIjGHE6bTclXTTHK LFMqeJC36jSe3lZr+8gJ5+cn8UH70spwT9aj8nk69q3gaa+dT3SMd+Zky 9sEi7RY72yYzSsuG/9GswrM7a43czIIvbdUYAx8pzys9g+j4oQ1hx+950 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFu+0FCtJV2b/2dsb2JhbABFvigWc4IfAQEEOj8QAgEIIhQQMiUBAQQODYgLqByQPpArYQOmUoJzgiI X-IronPort-AV: E=Sophos;i="4.84,310,1355097600"; d="scan'208";a="154364854" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 18 Dec 2012 19:06:24 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBIJ6NRG023484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Dec 2012 19:06:24 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.209]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 18 Dec 2012 13:06:23 -0600 From: "Stan Ratliff (sratliff)" To: "" Thread-Topic: [manet] Resolving the Reactive Protocol issue Thread-Index: Ac3ciBJ3/vN1pAf+Rv2ZbFjt/Xl/HgA6wK6AAAR+qoA= Date: Tue, 18 Dec 2012 19:06:23 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF5D831@xmb-aln-x03.cisco.com> References: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> <031b01cddd40$cb961af0$62c250d0$@olddog.co.uk> In-Reply-To: <031b01cddd40$cb961af0$62c250d0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.116] Content-Type: text/plain; charset="us-ascii" Content-ID: <26DD7A7C8B28894CB7A2EF3E6CAC75C0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Resolving the Reactive Protocol issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 19:06:29 -0000 Speaking as a WG participant:=20 Question 1: Yes Question 2: No (But this is a reasonable "Plan B") Question 3: No Regards, Stan From abdussalambaryun@gmail.com Tue Dec 18 16:48:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA08921F86CD for ; Tue, 18 Dec 2012 16:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 IfoI8y-MU6vv for ; Tue, 18 Dec 2012 16:48:03 -0800 (PST) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id 34DEE21F86D4 for ; Tue, 18 Dec 2012 16:48:03 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id p16so1704091vcq.11 for ; Tue, 18 Dec 2012 16:48:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=8exz5Wv26e+7jbsI5oUE9pYpxVTDinZkpB9G16Dl/+I=; b=pOXe+iDqkkcr+nAPL6Rk+UgTUWiVKJDzqVU/6w6yH4o2rdmXG2jHEmVI4A2lO66MPC mtwLViUop/sb8vH++3hMpuHACBrMOzh/BI4tW5qwXy06kunczJo/QREqIXJb8T/Jy2CQ a57ho1DOEjfAEY/qP4dpMxN1ekTOFADJKFjVcyfF+LVgW572wiXk+pSjy6ubzh79m96c gfgOL0e9BgXtiSr7pLUprTSRX37od4b+R57z1WFpW+YvyGuQ77YPuY1Ylg4qDeusUENZ XKyIihtA3+LbCjQzeMUeWnYA00DoT9bh6EHJ0m/y/XC6IOxEGzda4cStYK8PEVNcKIPx rtyw== MIME-Version: 1.0 Received: by 10.220.115.20 with SMTP id g20mr6259162vcq.31.1355878082474; Tue, 18 Dec 2012 16:48:02 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 18 Dec 2012 16:48:02 -0800 (PST) Date: Wed, 19 Dec 2012 01:48:02 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] AODVv2 (was RE: Resolving the Reactive Protocol issue) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 00:48:04 -0000 Hi Charlie, I agree with you totally and I thank you for all your input. Also, I am always with the WG documents/efforts and commitments, and never like to change my position or commitment. When MANET WG in the past have taken the DYMO doc as WG doc it made a commitment and many participants have spend time and efforts to make it as standard. On the other hand, I understood that the MANET WG chair indicated that if a work was parked then no WG commitment to parking documents, which I don't know if it is a past/old/present IETF rule. DYMO was parked not because no commitment, but maybe due to the WG was bussy. However, that rule if was true as IETF practice will never encourage future participants to participate or progress within long term work flow. Therefore, the proposed solution will help to force for progress. IMHO, the AODVv2 is the best document to be standard for the first reactive protocol in IETF, and if not chosen, then I recommend that it should be submitted to any other organisation under the copyright of the authors and remove the IETF. AB On 12/18/12, Charles E. Perkins wrote: > > Hello folks, > > I can't change the past events that have brought us to this > point. But I'd at least like to encourage optimism about the > progress of the existing WG document. Here is why: > > - The last WG document revision submitted is also the first > one which logistically I was able to bring up to a good > standard of correctness, and readability. It shows my > commitment to produce a high-quality document. > > - I reiterate that LOADng should be supported as a set of > choices from among the optional features of the WG reactive > protocol specification. While I was not able to accomplish > this by working with the other LOADng authors to merge > the documents, I have always been explicit that this was the > desired outcome. > > Well, that's about as far as I know how to get into the political > waters. I've always set about doing the things I promised to > do, and so far during the last year I have done so. That also > includes to make a consensus and good quality WG document. > > Regards, > Charlie P. From abdussalambaryun@gmail.com Tue Dec 18 16:59:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5608E21F87C8 for ; Tue, 18 Dec 2012 16:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 dSVTyK+1DH+Z for ; Tue, 18 Dec 2012 16:59:12 -0800 (PST) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3305A21F8431 for ; Tue, 18 Dec 2012 16:59:06 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id fq11so1669241vbb.38 for ; Tue, 18 Dec 2012 16:59:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=744fW7VbYzOnwqP3EE2zLOQZdOXWkw7e4zAK8joJ8xM=; b=V1sVeVnms4U43i/AqFFE9EPbMrrVU56m95AHKcXUzvKy8u0rE+3VQo4aZM09yDBxdv k0667q9yDyH4L1+pcNn9V/iDhNKoJCg/IpTX4yWA4XT/wwfEiqOmxSTn8UGUPGgMbzat wn2hADsnDUSF69Cgp2d4jAmeXhpKPYfuBaMMFGmxG2OsdphHx7KAAgN4Z+wxbpj4SERV uVeetfUPl46DL8jZwkut+qxKLeMaEVFL37oL63QSao5WIGwbDCqk/19p3odqhs5MaT+B SjCA1YombTGqBxzf4PGhpdZKwDafGeKCJCiK8mf6cl+nCOIEZ4HOYaruMnrchHyt61nB 8GvQ== MIME-Version: 1.0 Received: by 10.220.107.5 with SMTP id z5mr6319524vco.22.1355878745649; Tue, 18 Dec 2012 16:59:05 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 18 Dec 2012 16:59:05 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BCFC@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BCFC@xmb-aln-x03.cisco.com> Date: Wed, 19 Dec 2012 01:59:05 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 00:59:13 -0000 On 12/11/12, Stan Ratliff (sratliff) wrote: >- if the WG accepts LOAD as a working group > document (see my earlier email for my thoughts on that), the copyright will > be removed. If this input-document (draft-clausen-lln-loadng-06) was chosen as WG darft and removing IETF copyright, how do I make advise/input to such document that does not give its copyright to IETF and while any of participants input has copyright of IETF. I don't understand how can I spend time on such document that does not give equality to any input. Sorry if my question is crazy but I trying to understand these things in IETF. AB > > On Dec 11, 2012, at 8:56 AM, Abdussalam Baryun wrote: > >> Hi Stan, >> >> I thank you for the explaination because we need that from time to >> time to understand how the discussion will go forward without waste of >> efforts. Regarding the examples I will provide you when I got >> available time to report them. Regarding LOADng my questions are; 1) >> why there was a discussion off the list or off the meeting about >> removing the copyright of this proposing WG document. 2) Why the >> LOADng team didn't mention that while their proposal or does that mean >> that we have no right to update the document if we adopt it. 3) Is it >> possible for the document to mention a section of such authors rights >> and rights of the WG that are applied by the document, because if we >> just accept to remove copyright what does that mean (I think it means >> accepts me without clear rights)? 4) will this copyright issue affect >> the choose of the WG participants regarding DYMO or LOADng as I think >> the DYMO did not remove copyrights to IETF-WG? >> >> Finally, now I understand the position of the WG regarding the future >> WG discussions about reactive protocol. Thanking you. >> >> AB >> From jvasseur@cisco.com Thu Dec 20 03:32:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B795F21F841C for ; Thu, 20 Dec 2012 03:32:05 -0800 (PST) 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 ILlUhliZ8xPD for ; Thu, 20 Dec 2012 03:32:04 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id AEDFE21F8168 for ; Thu, 20 Dec 2012 03:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4833; q=dns/txt; s=iport; t=1356003124; x=1357212724; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=p5rxHWmSZmhcFMOEswCBdD/FQjA16ojRaB3UpJL4nxc=; b=cpuCNXEz00aebxJLUbsP4wbtvjA4GP8bZPjGYSMh5QP3WZ+pgE8+v+2F L4ImzNo+XlbL6Wk+0drp/hpEomBSYF8nDHT9bRs5CwHPm0N7ngyALza1D rS21ajfxkBJjDjD9zSmIQwAabfgLmZX/auHn2zPtp1ynIvtliOSwJRtjb w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGT20lCtJV2Z/2dsb2JhbABEvWwWc4IeAQEBAwEBAQE3NAsFCwIBCCIUECcLJQIEDgUIE4dyBgy5CASMUguDV2EDi1OHBYoNiW6CdIFtNQ X-IronPort-AV: E=Sophos;i="4.84,322,1355097600"; d="scan'208";a="155056530" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 20 Dec 2012 11:32:04 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBKBW4eI030447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Dec 2012 11:32:04 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.222]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 05:32:03 -0600 From: "JP Vasseur (jvasseur)" To: "" Thread-Topic: [manet] Resolving the Reactive Protocol issue Thread-Index: AQHN3qWidgeYGP3FGUSPia5sacLisw== Date: Thu, 20 Dec 2012 11:32:03 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77231408AC@xmb-rcd-x02.cisco.com> References: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> In-Reply-To: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.235] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Resolving the Reactive Protocol issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 11:32:05 -0000 Hi Adrian, As requested here are my answers (with no more than Yes/No): Question 1: No Question 2: Yes Question 3: No Happy holidays to all of you ! JP. On Dec 17, 2012, at 7:55 PM, Adrian Farrel wrote: > Hi MANET, >=20 > In the spirit of all good examination papers, please read all the way to = the end > of this email before starting to write your response. >=20 > I have been watching the discussions on the MANET list with care and talk= ing > with the chairs. All three of us have, I know, received plenty of private= emails > on the subject as well. >=20 > In my opinion, the debate about documents has almost (but not completely) > obscured the technical work. This is neither helpful nor in the spirit of= an > engineering organisation. >=20 > As AD it falls to me to unblock this log jam and enable the working group= to do > useful work. I think I see people explicitly asking for AD intervention. >=20 > In Atlanta, there remained interest in having a reactive protocol produce= d by > the working group. There is clearly still some interest on the list. But = it is > not clear to me how the WG feels on this since there may be many who are > watching and wishing they could get on with other work in a quieter envir= onment. > Therefore:=20 >=20 > =3D=3D=3D=3D=3D > Question 1 to the working group: Would you prefer to have "Standards trac= k > Reactive protocol" removed from the charter? A "yes/no" answer is all tha= t I > want to hear. > =3D=3D=3D=3D=3D >=20 > It is clear to me that attempts to merge or choose documents have failed.= There > is no value in discussing how or why, nor to what extent they might be pa= rtially > successful, or how resolution could be potentially reached. Therefore: >=20 > =3D=3D=3D=3D=3D > Question 2 to the working group: Would you like the AD to select one of t= he > documents (and, obviously, I will not tell you in advance which I might s= elect!) > and require that the WG works on that one document? In this case, publica= tion of > the other document with AD sponsorship or through the ISE is unlikely. Ag= ain, a > "yes/no" answer is all I want to hear, but respondents must understand th= at > saying "yes" implies a willingness to cooperate, to provide text, and to = have > the WG make any modifications to the document all in the normal IETF way. > =3D=3D=3D=3D=3D >=20 > Failing the selection of just one document, and absent abandoning the wor= k item, > there remains the possibility of progressing both documents within the wo= rking > group. As AD I will not allow the working group to produce two standards = track > RFCs for reactive protocols, and I therefore see no benefit in having two > working group drafts claiming to be intended for standards track publicat= ion. So > this leads to: >=20 > =3D=3D=3D=3D=3D > Question 3 to the working group: Would you be prepared to work on two doc= uments > describing reactive protocols that are intended for publication as Experi= mental > RFCs? Yet again, a "yes/no" answer is what I want to hear, but respondent= s need > to understand that saying "yes" implies a willingness to see both documen= ts > published as Experimental RFCs and that, owing to the lower bar on Experi= mental > work, it would not be acceptable to attempt to block the progress of eith= er > document with protracted technical discussions. We might (in the operatio= nal > spirit of the MANET working group) come back after some time and experien= ce with > the RFCs to re-charter and select just one solution for the standards tra= ck, but > that is for the distant future.=09 > =3D=3D=3D=3D=3D >=20 > I need to explain to the working group that the default position will be = to > remove this item from the WG charter. That is, if the WG overwhelmingly s= ays > "no" to both Q2 and Q3, I will work with the IESG to remove reactive prot= ocols > from the MANET charter regardless of the answer to Q1. >=20 >=20 > How to answer this email: Send responses in the form of > 1 [yes/no] > 2 [yes/no] > 3 [yes/no] > This is not a vote, but I am taking the mood of the working group in orde= r to > inform my decision. > Conditional answers such as "yes, but only if foo" are within your rights= , but > will not be very helpful to me,=20 >=20 > I know that many people are busy with work or enjoying themselves at this= time > of year, but this decisions needs to be made soon. I am inclined to make = my > decision before the end of 2012, but in deference to the festivities, I w= ill > announce it in the week of January 7th. >=20 > Thanks, > Adrian >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From brian.adamson@nrl.navy.mil Thu Dec 20 07:36:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5434121F86F6 for ; Thu, 20 Dec 2012 07:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 TJAngiaKOpc8 for ; Thu, 20 Dec 2012 07:36:22 -0800 (PST) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE0321F86C1 for ; Thu, 20 Dec 2012 07:36:21 -0800 (PST) Received: from macsimus.itd.nrl.navy.mil (macsimus.itd.nrl.navy.mil [132.250.92.151]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id qBKFaHUX015697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 20 Dec 2012 10:36:17 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-146--246691636 From: Brian Adamson In-Reply-To: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> Date: Thu, 20 Dec 2012 10:33:50 -0500 Message-Id: References: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1085) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Cc: manet@ietf.org Subject: Re: [manet] Resolving the Reactive Protocol issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 15:36:25 -0000 --Apple-Mail-146--246691636 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii My input to you questions: Question 1: no Question 2: yes Question 3: yes, but this is not independent of Question #2 (a single = specification here is preferable to me given their functional = similarity), and I think the documents' statuses (Experimental vs. = Proposed Standard) for each respective protocol should be assessed on = each individual protocol's maturity with respect to experience, = deployment, etc.=20 Brian Adamson brian.adamson@nrl.navy.mil On Dec 17, 2012, at 1:55 PM, Adrian Farrel wrote: > Hi MANET, >=20 > In the spirit of all good examination papers, please read all the way = to the end > of this email before starting to write your response. >=20 > I have been watching the discussions on the MANET list with care and = talking > with the chairs. All three of us have, I know, received plenty of = private emails > on the subject as well. >=20 > In my opinion, the debate about documents has almost (but not = completely) > obscured the technical work. This is neither helpful nor in the spirit = of an > engineering organisation. >=20 > As AD it falls to me to unblock this log jam and enable the working = group to do > useful work. I think I see people explicitly asking for AD = intervention. >=20 > In Atlanta, there remained interest in having a reactive protocol = produced by > the working group. There is clearly still some interest on the list. = But it is > not clear to me how the WG feels on this since there may be many who = are > watching and wishing they could get on with other work in a quieter = environment. > Therefore:=20 >=20 > =3D=3D=3D=3D=3D > Question 1 to the working group: Would you prefer to have "Standards = track > Reactive protocol" removed from the charter? A "yes/no" answer is all = that I > want to hear. > =3D=3D=3D=3D=3D >=20 > It is clear to me that attempts to merge or choose documents have = failed. There > is no value in discussing how or why, nor to what extent they might be = partially > successful, or how resolution could be potentially reached. Therefore: >=20 > =3D=3D=3D=3D=3D > Question 2 to the working group: Would you like the AD to select one = of the > documents (and, obviously, I will not tell you in advance which I = might select!) > and require that the WG works on that one document? In this case, = publication of > the other document with AD sponsorship or through the ISE is unlikely. = Again, a > "yes/no" answer is all I want to hear, but respondents must understand = that > saying "yes" implies a willingness to cooperate, to provide text, and = to have > the WG make any modifications to the document all in the normal IETF = way. > =3D=3D=3D=3D=3D >=20 > Failing the selection of just one document, and absent abandoning the = work item, > there remains the possibility of progressing both documents within the = working > group. As AD I will not allow the working group to produce two = standards track > RFCs for reactive protocols, and I therefore see no benefit in having = two > working group drafts claiming to be intended for standards track = publication. So > this leads to: >=20 > =3D=3D=3D=3D=3D > Question 3 to the working group: Would you be prepared to work on two = documents > describing reactive protocols that are intended for publication as = Experimental > RFCs? Yet again, a "yes/no" answer is what I want to hear, but = respondents need > to understand that saying "yes" implies a willingness to see both = documents > published as Experimental RFCs and that, owing to the lower bar on = Experimental > work, it would not be acceptable to attempt to block the progress of = either > document with protracted technical discussions. We might (in the = operational > spirit of the MANET working group) come back after some time and = experience with > the RFCs to re-charter and select just one solution for the standards = track, but > that is for the distant future.=09 > =3D=3D=3D=3D=3D >=20 > I need to explain to the working group that the default position will = be to > remove this item from the WG charter. That is, if the WG = overwhelmingly says > "no" to both Q2 and Q3, I will work with the IESG to remove reactive = protocols > from the MANET charter regardless of the answer to Q1. >=20 >=20 > How to answer this email: Send responses in the form of > 1 [yes/no] > 2 [yes/no] > 3 [yes/no] > This is not a vote, but I am taking the mood of the working group in = order to > inform my decision. > Conditional answers such as "yes, but only if foo" are within your = rights, but > will not be very helpful to me,=20 >=20 > I know that many people are busy with work or enjoying themselves at = this time > of year, but this decisions needs to be made soon. I am inclined to = make my > decision before the end of 2012, but in deference to the festivities, = I will > announce it in the week of January 7th. >=20 > Thanks, > Adrian >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-146--246691636 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii My = input to you questions:

Question 1: = no

Question 2: = yes

Question 3: yes,  but this is not = independent of Question #2 (a single specification here is preferable to = me given their functional similarity), and I think the documents' = statuses (Experimental vs. Proposed Standard) for each respective = protocol should be assessed on each individual protocol's maturity with = respect to experience, deployment, = etc. 


Brian = Adamson



On Dec 17, 2012, at 1:55 PM, Adrian Farrel wrote:

Hi = MANET,

In the spirit of all good examination papers, please read = all the way to the end
of this email before starting to write your = response.

I have been watching the discussions on the MANET list = with care and talking
with the chairs. All three of us have, I know, = received plenty of private emails
on the subject as well.

In = my opinion, the debate about documents has almost (but not = completely)
obscured the technical work. This is neither helpful nor = in the spirit of an
engineering organisation.

As AD it falls = to me to unblock this log jam and enable the working group to = do
useful work. I think I see people explicitly asking for AD = intervention.

In Atlanta, there remained interest in having a = reactive protocol produced by
the working group. There is clearly = still some interest on the list. But it is
not clear to me how the WG = feels on this since there may be many who are
watching and wishing = they could get on with other work in a quieter = environment.
Therefore:

=3D=3D=3D=3D=3D
Question 1 to the = working group: Would you prefer to have "Standards track
Reactive = protocol" removed from the charter? A "yes/no" answer is all that = I
want to hear.
=3D=3D=3D=3D=3D

It is clear to me that = attempts to merge or choose documents have failed. There
is no value = in discussing how or why, nor to what extent they might be = partially
successful, or how resolution could be potentially reached. = Therefore:

=3D=3D=3D=3D=3D
Question 2 to the working group: = Would you like the AD to select one of the
documents (and, obviously, = I will not tell you in advance which I might select!)
and require = that the WG works on that one document? In this case, publication = of
the other document with AD sponsorship or through the ISE is = unlikely. Again, a
"yes/no" answer is all I want to hear, but = respondents must understand that
saying "yes" implies a willingness = to cooperate, to provide text, and to have
the WG make any = modifications to the document all in the normal IETF = way.
=3D=3D=3D=3D=3D

Failing the selection of just one = document, and absent abandoning the work item,
there remains the = possibility of progressing both documents within the working
group. = As AD I will not allow the working group to produce two standards = track
RFCs for reactive protocols, and I therefore see no benefit in = having two
working group drafts claiming to be intended for standards = track publication. So
this leads to:

=3D=3D=3D=3D=3D
Question= 3 to the working group: Would you be prepared to work on two = documents
describing reactive protocols that are intended for = publication as Experimental
RFCs? Yet again, a "yes/no" answer is = what I want to hear, but respondents need
to understand that saying = "yes" implies a willingness to see both documents
published as = Experimental RFCs and that, owing to the lower bar on = Experimental
work, it would not be acceptable to attempt to block the = progress of either
document with protracted technical discussions. We = might (in the operational
spirit of the MANET working group) come = back after some time and experience with
the RFCs to re-charter and = select just one solution for the standards track, but
that is for the = distant future. =
=3D=3D=3D=3D=3D

I need to explain to the working group = that the default position will be to
remove this item from the WG = charter. That is, if the WG overwhelmingly says
"no" to both Q2 and = Q3, I will work with the IESG to remove reactive protocols
from the = MANET charter regardless of the answer to Q1.


How to answer = this email: Send responses in the form of
1 [yes/no]
2 = [yes/no]
3 [yes/no]
This is not a vote, but I am taking the mood = of the working group in order to
inform my decision.
Conditional = answers such as "yes, but only if foo" are within your rights, = but
will not be very helpful to me,

I know that many people = are busy with work or enjoying themselves at this time
of year, but = this decisions needs to be made soon. I am inclined to make = my
decision before the end of 2012, but in deference to the = festivities, I will
announce it in the week of January = 7th.

Thanks,
Adrian

_____________________________________= __________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail-146--246691636-- From hrogge@googlemail.com Thu Dec 20 08:44:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D0821F8556 for ; Thu, 20 Dec 2012 08:44:38 -0800 (PST) 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 oIWt5P2s7FfN for ; Thu, 20 Dec 2012 08:44:37 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8160021F8473 for ; Thu, 20 Dec 2012 08:44:37 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id c11so4808976ieb.5 for ; Thu, 20 Dec 2012 08:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=70fVFJgf0Vg7soPd495YiMfyXj3nUrNRBIujahTR2Jg=; b=KlVtuTLv2lbCWtGA51l52pJLquEs9I2lIqwLLT6O09fG+9ilLbc5HeNP/30LdIbhCR StD/lLjLwR6oVElcjs9coJF5IVAN0piQKsEOyewekzymxvxO/N/o3bWbB840Pmrnj9w9 WPnB4aCAjKxmX6gKmySZJt0CjRP0tPtrsDx4KQUo4d0fVSj9JFJO8gH02YmmCzR00jX9 BTpzCzK2CEUkzKXR4vh6wgJa7cjtXxCWvV/OXDKb6zBnWzk40g5roffRtI4SpuimBz5m KWEHZiFQahX0JEJgZ+2i9i3S7Dd5NuRYs12UiJoNOmfkK4vxs3UnTYRyS5OuLueH3TN+ HYWQ== Received: by 10.43.114.4 with SMTP id ey4mr9523344icc.27.1356021877031; Thu, 20 Dec 2012 08:44:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.26.7 with HTTP; Thu, 20 Dec 2012 08:44:16 -0800 (PST) In-Reply-To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BCFC@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Thu, 20 Dec 2012 17:44:16 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 16:44:38 -0000 On Wed, Dec 19, 2012 at 1:59 AM, Abdussalam Baryun wrote: > On 12/11/12, Stan Ratliff (sratliff) wrote: >>- if the WG accepts LOAD as a working group >> document (see my earlier email for my thoughts on that), the copyright will >> be removed. > > If this input-document (draft-clausen-lln-loadng-06) was chosen as WG > darft and removing IETF copyright, how do I make advise/input to such > document that does not give its copyright to IETF and while any of > participants input has copyright of IETF. I don't understand how can I > spend time on such document that does not give equality to any input. > Sorry if my question is crazy but I trying to understand these things > in IETF. Stan talked about the copyright part of LOADng that prevents other protocols from copying parts of it. As soon as LOADng would be a workinggroup draft, it would have the NORMAL IETF copyright notice as every other normal workinggroup draft. At least thats MY understanding. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From Chris.Dearlove@baesystems.com Thu Dec 20 09:07:35 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686D021F86C1 for ; Thu, 20 Dec 2012 09:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.584 X-Spam-Level: X-Spam-Status: No, score=-10.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 ftjpqyTjG74l for ; Thu, 20 Dec 2012 09:07:34 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id CD75221F85DA for ; Thu, 20 Dec 2012 09:07:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,324,1355097600"; d="scan'208";a="295844219" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 20 Dec 2012 17:07:32 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qBKH7VNR004472 for ; Thu, 20 Dec 2012 17:07:31 GMT X-IronPort-AV: E=Sophos;i="4.84,324,1355097600"; d="scan'208";a="1991036" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 20 Dec 2012 17:07:31 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Thu, 20 Dec 2012 17:07:31 +0000 From: "Dearlove, Christopher (UK)" To: "adrian@olddog.co.uk" , "manet@ietf.org" Thread-Topic: [manet] Resolving the Reactive Protocol issue Thread-Index: Ac3ciBJ3/vN1pAf+Rv2ZbFjt/Xl/HgCSywpg Date: Thu, 20 Dec 2012 17:07:30 +0000 Message-ID: References: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> In-Reply-To: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] Resolving the Reactive Protocol issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:07:35 -0000 I've given my answers to Adrian privately (I had assumed that was the requi= rement). I will note here what I said in that, which is that Q3 has a slightly diffe= rent nature. Q1 and Q2 ask about what should happen. Q3 asks would I work o= n two documents. (I will note that as I'm an author on six WG documents, even if I say no to= Q3 I think no one could say I'm not doing my bit here.) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= drian Farrel Sent: 17 December 2012 18:56 To: manet@ietf.org Subject: [manet] Resolving the Reactive Protocol issue ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi MANET, In the spirit of all good examination papers, please read all the way to th= e end of this email before starting to write your response. I have been watching the discussions on the MANET list with care and talkin= g with the chairs. All three of us have, I know, received plenty of private e= mails on the subject as well. In my opinion, the debate about documents has almost (but not completely) obscured the technical work. This is neither helpful nor in the spirit of a= n engineering organisation. As AD it falls to me to unblock this log jam and enable the working group t= o do useful work. I think I see people explicitly asking for AD intervention. In Atlanta, there remained interest in having a reactive protocol produced = by the working group. There is clearly still some interest on the list. But it= is not clear to me how the WG feels on this since there may be many who are watching and wishing they could get on with other work in a quieter environ= ment. Therefore:=20 =3D=3D=3D=3D=3D Question 1 to the working group: Would you prefer to have "Standards track Reactive protocol" removed from the charter? A "yes/no" answer is all that = I want to hear. =3D=3D=3D=3D=3D It is clear to me that attempts to merge or choose documents have failed. T= here is no value in discussing how or why, nor to what extent they might be part= ially successful, or how resolution could be potentially reached. Therefore: =3D=3D=3D=3D=3D Question 2 to the working group: Would you like the AD to select one of the documents (and, obviously, I will not tell you in advance which I might sel= ect!) and require that the WG works on that one document? In this case, publicati= on of the other document with AD sponsorship or through the ISE is unlikely. Agai= n, a "yes/no" answer is all I want to hear, but respondents must understand that saying "yes" implies a willingness to cooperate, to provide text, and to ha= ve the WG make any modifications to the document all in the normal IETF way. =3D=3D=3D=3D=3D Failing the selection of just one document, and absent abandoning the work = item, there remains the possibility of progressing both documents within the work= ing group. As AD I will not allow the working group to produce two standards tr= ack RFCs for reactive protocols, and I therefore see no benefit in having two working group drafts claiming to be intended for standards track publicatio= n. So this leads to: =3D=3D=3D=3D=3D Question 3 to the working group: Would you be prepared to work on two docum= ents describing reactive protocols that are intended for publication as Experime= ntal RFCs? Yet again, a "yes/no" answer is what I want to hear, but respondents = need to understand that saying "yes" implies a willingness to see both documents published as Experimental RFCs and that, owing to the lower bar on Experime= ntal work, it would not be acceptable to attempt to block the progress of either document with protracted technical discussions. We might (in the operationa= l spirit of the MANET working group) come back after some time and experience= with the RFCs to re-charter and select just one solution for the standards track= , but that is for the distant future.=09 =3D=3D=3D=3D=3D I need to explain to the working group that the default position will be to remove this item from the WG charter. That is, if the WG overwhelmingly say= s "no" to both Q2 and Q3, I will work with the IESG to remove reactive protoc= ols from the MANET charter regardless of the answer to Q1. How to answer this email: Send responses in the form of 1 [yes/no] 2 [yes/no] 3 [yes/no] This is not a vote, but I am taking the mood of the working group in order = to inform my decision. Conditional answers such as "yes, but only if foo" are within your rights, = but will not be very helpful to me,=20 I know that many people are busy with work or enjoying themselves at this t= ime of year, but this decisions needs to be made soon. I am inclined to make my decision before the end of 2012, but in deference to the festivities, I wil= l announce it in the week of January 7th. Thanks, Adrian _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From sratliff@cisco.com Thu Dec 20 09:25:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813B421F8A57 for ; Thu, 20 Dec 2012 09:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.521 X-Spam-Level: X-Spam-Status: No, score=-10.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 ptFbWIHMJlel for ; Thu, 20 Dec 2012 09:25:25 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id CFB3A21F8960 for ; Thu, 20 Dec 2012 09:25:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1517; q=dns/txt; s=iport; t=1356024322; x=1357233922; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tmKIqSIBuFgYWMe/YYUT4nZHFE/7WSKLdNIEctJrmZg=; b=j/NQ0KeP1I3t6oq6c1GX21Sy/Ry9UmzStRoUbomzYa8zxFUoHASE0g0Z eP1LUK3l8szzV2N/1MegfPs2AuKpvYtyOgSSaLzNi9eGQ8vlXdxNmx24y bma7Lwl7FZVLJdIa7IYenyOhVVq6/r3HWsQCseK7abWV5agGt/4LzFfy/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGxI01CtJXHA/2dsb2JhbABFvXEWc4IeAQEBAwEBAQE3NAsFCwIBCA4KChQQIQYLJQIEDgUIh3kDCQYMr2gNiVEEi2lpC4NXYQOUNY0NhRGCdIFtNQ X-IronPort-AV: E=Sophos;i="4.84,324,1355097600"; d="scan'208";a="155156189" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 20 Dec 2012 17:25:22 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qBKHPMMA029403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Dec 2012 17:25:22 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.209]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 11:25:21 -0600 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) Thread-Index: AQHN3tFPw626BUfdBUK8Gk7Y2/TDrJgiVOsA Date: Thu, 20 Dec 2012 17:25:21 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF614AF@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BCFC@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.116] Content-Type: text/plain; charset="us-ascii" Content-ID: <49FDB6EFE1E70F43A2358BBA0321E6FD@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:25:38 -0000 X-List-Received-Date: Thu, 20 Dec 2012 17:25:38 -0000 On Dec 20, 2012, at 11:44 AM, Henning Rogge wrote: > On Wed, Dec 19, 2012 at 1:59 AM, Abdussalam Baryun > wrote: >> On 12/11/12, Stan Ratliff (sratliff) wrote: >>> - if the WG accepts LOAD as a working group >>> document (see my earlier email for my thoughts on that), the copyright = will >>> be removed. >>=20 >> If this input-document (draft-clausen-lln-loadng-06) was chosen as WG >> darft and removing IETF copyright, how do I make advise/input to such >> document that does not give its copyright to IETF and while any of >> participants input has copyright of IETF. I don't understand how can I >> spend time on such document that does not give equality to any input. >> Sorry if my question is crazy but I trying to understand these things >> in IETF. >=20 > Stan talked about the copyright part of LOADng that prevents other > protocols from copying parts of it. As soon as LOADng would be a > workinggroup draft, it would have the NORMAL IETF copyright notice as > every other normal workinggroup draft. At least thats MY > understanding. Correct.=20 Regards, Stan >=20 > Henning Rogge >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From salo@saloits.com Thu Dec 20 20:08:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C3621F88E1 for ; Thu, 20 Dec 2012 20:08:31 -0800 (PST) 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 V38-aw3EGk5R for ; Thu, 20 Dec 2012 20:08:31 -0800 (PST) Received: from server.saloits.com (saloits.com [208.42.140.127]) by ietfa.amsl.com (Postfix) with ESMTP id E684B21F87D9 for ; Thu, 20 Dec 2012 20:08:30 -0800 (PST) Received: from [192.168.1.241] (mail.gdmfinancial.com [64.122.144.190] (may be forged)) by server.saloits.com (8.14.4/8.14.3) with ESMTP id qBL48RJZ000492; Thu, 20 Dec 2012 22:08:28 -0600 Message-ID: <50D3E0AF.4060607@saloits.com> Date: Thu, 20 Dec 2012 22:08:15 -0600 From: "Timothy J. Salo" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: " List" References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BCFC@xmb-aln-x03.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 04:08:31 -0000 > Stan talked about the copyright part of LOADng that prevents other > protocols from copying parts of it. My understanding of copyright law is that a copyright might prevent others from copying the LOADng _document_, but copyright cannot protect the protocol itself. (This topic pops up every few years. It would be nice if the IETF had an FAQ that covered this topic...) -tjs From hrogge@googlemail.com Sat Dec 22 00:30:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1EE21F8B13 for ; Sat, 22 Dec 2012 00:30:08 -0800 (PST) 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 iBreGHZ-K9Q6 for ; Sat, 22 Dec 2012 00:30:08 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id E514A21F8B11 for ; Sat, 22 Dec 2012 00:30:07 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id z14so6274235lag.2 for ; Sat, 22 Dec 2012 00:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vrW9TjlJYMTQpnsM6j5rUPqVKXRjRmd+SmkMRO7ygGY=; b=SBxNdESUDyMw22l84kspGiCGNo5n8zY7D0L6u122fokYuK7oFolm3KeY/LIf/Qm1X3 5ByztFAq92NaWKQg5zh+bVUSFNd0lETs+Z5YB/rwwPTYCpLgPWNvMc3I+fqJ6picgLBp 3cBn5m0KlUWCIOEyspdR/27CqRyQeH49xOadpMyGNbJxHIaDbyiyL1FNhe3YT/wRgSPw WSTWWc9VeE4k7FyTklfRiaczXjOIF8EavVoQTMwV5c8GJgZG9/YFqennLxPwNfLvQ+V0 VN+Og3cAuZSWVHJQc6O027fE5joW8wJsvFdC7h+LwbNaMJ28BKKnHon3czfofjIYzur0 8Dkg== Received: by 10.112.82.202 with SMTP id k10mr6439118lby.22.1356165006483; Sat, 22 Dec 2012 00:30:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Sat, 22 Dec 2012 00:29:46 -0800 (PST) In-Reply-To: <50D3E0AF.4060607@saloits.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BCFC@xmb-aln-x03.cisco.com> <50D3E0AF.4060607@saloits.com> From: Henning Rogge Date: Sat, 22 Dec 2012 09:29:46 +0100 Message-ID: To: "Timothy J. Salo" Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 08:30:08 -0000 On Fri, Dec 21, 2012 at 5:08 AM, Timothy J. Salo wrote: >> Stan talked about the copyright part of LOADng that prevents other >> protocols from copying parts of it. > > > My understanding of copyright law is that a copyright might prevent > others from copying the LOADng _document_, but copyright cannot protect > the protocol itself. And thats exactly what the copyright notice on LOADng is about if I remember it correctly. It prevents people from taking parts of the draft text. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Sat Dec 22 05:51:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FDD21F8B4E for ; Sat, 22 Dec 2012 05:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 KCMI8zZkfAmL for ; Sat, 22 Dec 2012 05:51:46 -0800 (PST) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) by ietfa.amsl.com (Postfix) with ESMTP id A44F221F8B48 for ; Sat, 22 Dec 2012 05:51:46 -0800 (PST) Received: by mail-vb0-f48.google.com with SMTP id fc21so6046623vbb.7 for ; Sat, 22 Dec 2012 05:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7HsYen3Y9JhoJtRjyccmOWV+++mPA8CsbT0+QYBDIhs=; b=aI+lYIJME3M6p1YsNmGid3xclyMRWZ/t5ztffcRp6iReWVtMIQlK8yDqjEksLysTPP T78VYYRHuD5ysOuamoCyfkwIZu7fbX8MIQ4oVxR3sG4rtWkNeFnHV7QPceI2UHJCctzf vzci77rMaDJD29+eqIgUIOoWbnciT+ruU5DWPbYBKBqQZ7WERXv+UE4niVzoDvgYMNfX btVa0IzlLtHWz0NcSLg7BlW/+7slF9/kk+qLHjUSAk6XR+wp9ZCQD0qGdi2b2CYElkIq BYDYZJXtdGcrrHySXPwuSjjfx4BsoNPzvfRvUtIpjf3PgAp4J7aefov6tD8CBBADaaeJ r2jQ== MIME-Version: 1.0 Received: by 10.52.175.106 with SMTP id bz10mr21216457vdc.125.1356184306005; Sat, 22 Dec 2012 05:51:46 -0800 (PST) Received: by 10.220.145.5 with HTTP; Sat, 22 Dec 2012 05:51:45 -0800 (PST) In-Reply-To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BCFC@xmb-aln-x03.cisco.com> <50D3E0AF.4060607@saloits.com> Date: Sat, 22 Dec 2012 14:51:45 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "Timothy J. Salo" , " List" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 13:51:48 -0000 On 12/22/12, Henning Rogge wrote: >> My understanding of copyright law is that a copyright might prevent >> others from copying the LOADng _document_, but copyright cannot protect >> the protocol itself. > > And thats exactly what the copyright notice on LOADng is about if I > remember it correctly. It prevents people from taking parts of the > draft text. > I understood from you that it tries to prevent ietf participants from using its text parts in another ietf draft, which is new rights introduced from my understanding, but happy to learn :) So if I have an input on the list I can prevent others to use as to write within my input: or Regards AB From drdanhe@gmail.com Sat Dec 22 06:57:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F66121F8AE3 for ; Sat, 22 Dec 2012 06:57:16 -0800 (PST) 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 qQX+KZsRc6c6 for ; Sat, 22 Dec 2012 06:57:15 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id BE15F21F8941 for ; Sat, 22 Dec 2012 06:57:15 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id c11so7390554ieb.5 for ; Sat, 22 Dec 2012 06:57:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E7P173CHZLfyHe8hp/dDUN+qLTwHRcke1EppkxV2oOI=; b=rF6OwIOaarZiL2eRd/87QoYyKDYLiR5WX/k9y9ATcCtNzSZXspWdd5g2efFp5wbJCw hwuV68UlonjklQoo14lVgV0lpxMkjIzaqRbGWE6qF2N+EDp+qD6cJGqUOVMaJeQjc5Me +FD55ZRRZNJldsXLBiccpo7IUWvh+13ahislNZMe4kwQug2pNviOetYcBQmFGfiTsin9 aGaPQgCf005OHUMFXiWnRlXM4DCq2Mtk1PL/UVG7HIx2iNBhfDcc6TfVx7cC/3gYeSFT WwWiglCEMdvkPq5vrO+YxQ3QMvklguVIvJwUf+0Mx47VE4mg2sZlWBFkkg4yBIpOVoyz 6K/A== MIME-Version: 1.0 Received: by 10.50.51.231 with SMTP id n7mr11272152igo.85.1356188235352; Sat, 22 Dec 2012 06:57:15 -0800 (PST) Received: by 10.50.7.70 with HTTP; Sat, 22 Dec 2012 06:57:15 -0800 (PST) In-Reply-To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BCFC@xmb-aln-x03.cisco.com> <50D3E0AF.4060607@saloits.com> Date: Sat, 22 Dec 2012 14:57:15 +0000 Message-ID: From: Daniel He To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=14dae9340f0f044aa204d1722e56 Cc: "Timothy J. Salo" , " List" Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 14:57:16 -0000 --14dae9340f0f044aa204d1722e56 Content-Type: text/plain; charset=ISO-8859-1 It is the meaning what copyright is to prevent the others to take any part from the text (particularly for the draft). It is not new right. But as I understood, as long as the draft becomes a standard, all materials have been surrended to IETF copyright. Cheers, Dan On 22 December 2012 13:51, Abdussalam Baryun wrote: > On 12/22/12, Henning Rogge wrote: > >> My understanding of copyright law is that a copyright might prevent > >> others from copying the LOADng _document_, but copyright cannot protect > >> the protocol itself. > > > > And thats exactly what the copyright notice on LOADng is about if I > > remember it correctly. It prevents people from taking parts of the > > draft text. > > > > I understood from you that it tries to prevent ietf participants from > using its text parts in another ietf draft, which is new rights > introduced from my understanding, but happy to learn :) > > So if I have an input on the list I can prevent others to use as to > write within my input: > > or > > > Regards > AB > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Dan He --------------------- openstack contributor GPU stream programming http://wiki.openstack.org/Contributors Tel: +44-788-686-3428 --14dae9340f0f044aa204d1722e56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It is the meaning what copyright is to prevent the others to take any part<= br>from the text (particularly for the draft). It is not new right.
But as I understood, as long as the draft becomes a standard, all material= s
have been surrended to IETF copyright.

Cheers,
Dan

On 22 December 2012 13:51, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
On 12/22/12, Henning Rogge= <hrogge@googlemail.com>= wrote:
>> My understanding of copyright law is that a copyright might preven= t
>> others from copying the LOADng _document_, but copyright cannot pr= otect
>> the protocol itself.
>
> And thats exactly what the copyright notice on LOADng is about if I > remember it correctly. It prevents people from taking parts of the
> draft text.
>

I understood from you that it tries to prevent ietf participants from=
using its text parts in another ietf draft, which is new rights
introduced from my understanding, but happy to learn :)

So if I have an input on the list I can prevent others to use as to
write within my input:
<This message removes copyrights, no participant allowed to use the text= > or
<This message removes copyrights, only draft-xxx allowed to use the text= >

Regards
AB
_____________________= __________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



--
Dan He
-= --------------------
openstack contributor
GPU stream programming
=
ht= tp://wiki.openstack.org/Contributors

Tel: +44-788-686-3428
--14dae9340f0f044aa204d1722e56-- From adrian@olddog.co.uk Sat Dec 22 08:02:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5CA21F8B43 for ; Sat, 22 Dec 2012 08:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 pwOGLefrD5Oi for ; Sat, 22 Dec 2012 08:02:33 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1F93F21F8ACA for ; Sat, 22 Dec 2012 08:02:32 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBMG2RJO010586; Sat, 22 Dec 2012 16:02:27 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBMG2PjA010574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Dec 2012 16:02:26 GMT From: "Adrian Farrel" To: "'Daniel He'" , "'Abdussalam Baryun'" Date: Sat, 22 Dec 2012 16:02:21 -0000 Message-ID: <004b01cde05d$b9e8e240$2dbaa6c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01CDE05D.B9ED9D30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3gXbcjawXPG8MdQsCSLigD1DS0gQ== Content-Language: en-gb Cc: "'Timothy J. Salo'" , manet@ietf.org Subject: [manet] Copyright and derivative works [was LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt)] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 16:02:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004C_01CDE05D.B9ED9D30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am not a lawyer. When posting an Internet-Draft, IETF policies allow various options. One is that the copyright is held jointly by the IETF Trust and the authors, and permission to produce derivative works is granted. Another is that the right to generate derivative works is withheld - meaning that another I-D cannot be created using any of the text from the first document. WGs often consider such issues when deciding whether to adopt an I-D as a working group document. Learning from other documents that are in the public domain, and using ideas is not necessarily covered depending on your view of what is copyrightable. Using someone else's ideas would still, IMHO, require crediting the original authors - there is an etiquette to be observed. You really need to read the IETF Trust's legal provisions relating to IETF documents at http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf (and then you need to take your own legal advice and not rely on me to interpret for you :-) Adrian From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Daniel He Sent: 22 December 2012 14:57 To: Abdussalam Baryun Cc: Timothy J. Salo; List Subject: Re: [manet] LOADng (was Re: I-D Action: draft-ietf-manet-dymo-24.txt) It is the meaning what copyright is to prevent the others to take any part from the text (particularly for the draft). It is not new right. But as I understood, as long as the draft becomes a standard, all materials have been surrended to IETF copyright. Cheers, Dan On 22 December 2012 13:51, Abdussalam Baryun wrote: On 12/22/12, Henning Rogge wrote: >> My understanding of copyright law is that a copyright might prevent >> others from copying the LOADng _document_, but copyright cannot protect >> the protocol itself. > > And thats exactly what the copyright notice on LOADng is about if I > remember it correctly. It prevents people from taking parts of the > draft text. > I understood from you that it tries to prevent ietf participants from using its text parts in another ietf draft, which is new rights introduced from my understanding, but happy to learn :) So if I have an input on the list I can prevent others to use as to write within my input: or Regards AB _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet -- Dan He --------------------- openstack contributor GPU stream programming http://wiki.openstack.org/Contributors Tel: +44-788-686-3428 ------=_NextPart_000_004C_01CDE05D.B9ED9D30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am not a = lawyer.

 

When posting an = Internet-Draft, IETF policies allow various options. One is that the = copyright is held jointly by the IETF Trust and the authors, and = permission to produce derivative works is granted. Another is that the = right to generate derivative works is withheld - meaning that another = I-D cannot be created using any of the text from the first document. WGs = often consider such issues when deciding whether to adopt an I-D as a = working group document.

 

Learning from other documents = that are in the public domain, and using ideas is not necessarily = covered depending on your view of what is copyrightable. Using someone = else's ideas would still, IMHO, require crediting the original authors - = there is an etiquette to be observed.

 

You really need to read the = IETF Trust's legal provisions relating to IETF documents at = http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf  (and then you need to take your = own legal advice and not rely on me to interpret for you = :-)

 

Adrian

 

From: = manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of = Daniel He
Sent: 22 December 2012 14:57
To: = Abdussalam Baryun
Cc: Timothy J. Salo; <manet@ietf.org> = List
Subject: Re: [manet] LOADng (was Re: I-D Action: = draft-ietf-manet-dymo-24.txt)

 

It is the meaning what copyright is to = prevent the others to take any part
from the text (particularly for = the draft). It is not new right.

But as I understood, as long as = the draft becomes a standard, all materials
have been surrended to = IETF copyright.

Cheers,
Dan

On 22 December 2012 13:51, Abdussalam Baryun <abdussalambaryun@gmail.com> = wrote:

On 12/22/12, Henning Rogge <hrogge@googlemail.com> = wrote:
>> My understanding of copyright law is that a copyright = might prevent
>> others from copying the LOADng _document_, but = copyright cannot protect
>> the protocol = itself.
>
> And thats exactly what the copyright notice on = LOADng is about if I
> remember it correctly. It prevents people = from taking parts of the
> draft = text.
>

I understood from = you that it tries to prevent ietf participants from
using its text = parts in another ietf draft, which is new rights
introduced from my = understanding, but happy to learn :)

So if I have an input on the = list I can prevent others to use as to
write within my = input:
<This message removes copyrights, no participant allowed to = use the text > or
<This message removes copyrights, only = draft-xxx allowed to use the text >

Regards
AB

_______________________________________________
mane= t mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet




-- =
Dan He
---------------------
openstack contributor
GPU = stream programming

http://wiki.openstack.org/Contributors

Tel: = +44-788-686-3428

------=_NextPart_000_004C_01CDE05D.B9ED9D30-- From philippe.jacquet@inria.fr Sat Dec 22 14:03:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7BD21F8941 for ; Sat, 22 Dec 2012 14:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 bdfyoBmLq91l for ; Sat, 22 Dec 2012 14:03:19 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id DA4D721F88C9 for ; Sat, 22 Dec 2012 14:03:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,338,1355094000"; d="scan'208";a="187374121" Received: from zmbs5.inria.fr ([128.93.142.18]) by mail1-relais-roc.national.inria.fr with ESMTP; 22 Dec 2012 23:03:08 +0100 Date: Sat, 22 Dec 2012 23:03:08 +0100 (CET) From: Philippe Jacquet To: adrian@olddog.co.uk Message-ID: <1426335259.16861717.1356213788658.JavaMail.root@inria.fr> In-Reply-To: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [79.94.7.193] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - SAF3 (Mac)/7.2.0_GA_2669) Cc: manet@ietf.org Subject: Re: [manet] Resolving the Reactive Protocol issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 22:03:20 -0000 Dear Adrian, My input: 1 : no 2 : no 3 : yes Philippe ----- Mail original ----- De: "Adrian Farrel" =C0: manet@ietf.org Envoy=E9: Lundi 17 D=E9cembre 2012 19:55:34 Objet: [manet] Resolving the Reactive Protocol issue Hi MANET, In the spirit of all good examination papers, please read all the way to th= e end of this email before starting to write your response. I have been watching the discussions on the MANET list with care and talkin= g with the chairs. All three of us have, I know, received plenty of private e= mails on the subject as well. In my opinion, the debate about documents has almost (but not completely) obscured the technical work. This is neither helpful nor in the spirit of a= n engineering organisation. As AD it falls to me to unblock this log jam and enable the working group t= o do useful work. I think I see people explicitly asking for AD intervention. In Atlanta, there remained interest in having a reactive protocol produced = by the working group. There is clearly still some interest on the list. But it= is not clear to me how the WG feels on this since there may be many who are watching and wishing they could get on with other work in a quieter environ= ment. Therefore:=20 =3D=3D=3D=3D=3D Question 1 to the working group: Would you prefer to have "Standards track Reactive protocol" removed from the charter? A "yes/no" answer is all that = I want to hear. =3D=3D=3D=3D=3D It is clear to me that attempts to merge or choose documents have failed. T= here is no value in discussing how or why, nor to what extent they might be part= ially successful, or how resolution could be potentially reached. Therefore: =3D=3D=3D=3D=3D Question 2 to the working group: Would you like the AD to select one of the documents (and, obviously, I will not tell you in advance which I might sel= ect!) and require that the WG works on that one document? In this case, publicati= on of the other document with AD sponsorship or through the ISE is unlikely. Agai= n, a "yes/no" answer is all I want to hear, but respondents must understand that saying "yes" implies a willingness to cooperate, to provide text, and to ha= ve the WG make any modifications to the document all in the normal IETF way. =3D=3D=3D=3D=3D Failing the selection of just one document, and absent abandoning the work = item, there remains the possibility of progressing both documents within the work= ing group. As AD I will not allow the working group to produce two standards tr= ack RFCs for reactive protocols, and I therefore see no benefit in having two working group drafts claiming to be intended for standards track publicatio= n. So this leads to: =3D=3D=3D=3D=3D Question 3 to the working group: Would you be prepared to work on two docum= ents describing reactive protocols that are intended for publication as Experime= ntal RFCs? Yet again, a "yes/no" answer is what I want to hear, but respondents = need to understand that saying "yes" implies a willingness to see both documents published as Experimental RFCs and that, owing to the lower bar on Experime= ntal work, it would not be acceptable to attempt to block the progress of either document with protracted technical discussions. We might (in the operationa= l spirit of the MANET working group) come back after some time and experience= with the RFCs to re-charter and select just one solution for the standards track= , but that is for the distant future.=09 =3D=3D=3D=3D=3D I need to explain to the working group that the default position will be to remove this item from the WG charter. That is, if the WG overwhelmingly say= s "no" to both Q2 and Q3, I will work with the IESG to remove reactive protoc= ols from the MANET charter regardless of the answer to Q1. How to answer this email: Send responses in the form of 1 [yes/no] 2 [yes/no] 3 [yes/no] This is not a vote, but I am taking the mood of the working group in order = to inform my decision. Conditional answers such as "yes, but only if foo" are within your rights, = but will not be very helpful to me,=20 I know that many people are busy with work or enjoying themselves at this t= ime of year, but this decisions needs to be made soon. I am inclined to make my decision before the end of 2012, but in deference to the festivities, I wil= l announce it in the week of January 7th. Thanks, Adrian _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From philippe.jacquet@inria.fr Sun Dec 23 02:30:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535DF21F868F for ; Sun, 23 Dec 2012 02:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.707 X-Spam-Level: X-Spam-Status: No, score=-9.707 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, URIBL_RHS_DOB=1.083] 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 8GyrLAZ8j3w8 for ; Sun, 23 Dec 2012 02:30:20 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id C5ADB21F86B3 for ; Sun, 23 Dec 2012 02:30:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,341,1355094000"; d="scan'208";a="187406139" Received: from zmbs5.inria.fr ([128.93.142.18]) by mail1-relais-roc.national.inria.fr with ESMTP; 23 Dec 2012 11:30:18 +0100 Date: Sun, 23 Dec 2012 11:30:18 +0100 (CET) From: Philippe Jacquet To: manet@ietf.org Message-ID: <125992629.16916888.1356258618199.JavaMail.root@inria.fr> In-Reply-To: <1426335259.16861717.1356213788658.JavaMail.root@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [79.94.7.193] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - SAF3 (Mac)/7.2.0_GA_2669) Subject: Re: [manet] Resolving the Reactive Protocol issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 10:30:21 -0000 Hello folks, Some bit of explanations about my vote, since I didn't participate to the d= iscussions. I would have voted "yes" to the first question, if I had the feeling that t= he reactive protocols would become a blocking issue for the whole Manet WG.= I assume no (I hope I am right). I have voted "no" to the second question because I think that none of the p= roposals are presently meeting all Manet standards. One proposal seems with= the time to have partially lost some of his quality edges, and the second = proposal seems, at least partially, not right in the scope of Manet focus.= =20 Therefore I voted "yes" to the third question, although I totally agree tha= t this may lead to further frustrations. But it is already very frustrating= that two not that far proposals with so much potentials could not benefit = from each other. Merry X-mas and happy New Year, Philippe ----- Mail original ----- De: "Philippe Jacquet" =C0: adrian@olddog.co.uk Cc: manet@ietf.org Envoy=E9: Samedi 22 D=E9cembre 2012 23:03:08 Objet: Re: [manet] Resolving the Reactive Protocol issue Dear Adrian, My input: 1 : no 2 : no 3 : yes Philippe ----- Mail original ----- De: "Adrian Farrel" =C0: manet@ietf.org Envoy=E9: Lundi 17 D=E9cembre 2012 19:55:34 Objet: [manet] Resolving the Reactive Protocol issue Hi MANET, In the spirit of all good examination papers, please read all the way to th= e end of this email before starting to write your response. I have been watching the discussions on the MANET list with care and talkin= g with the chairs. All three of us have, I know, received plenty of private e= mails on the subject as well. In my opinion, the debate about documents has almost (but not completely) obscured the technical work. This is neither helpful nor in the spirit of a= n engineering organisation. As AD it falls to me to unblock this log jam and enable the working group t= o do useful work. I think I see people explicitly asking for AD intervention. In Atlanta, there remained interest in having a reactive protocol produced = by the working group. There is clearly still some interest on the list. But it= is not clear to me how the WG feels on this since there may be many who are watching and wishing they could get on with other work in a quieter environ= ment. Therefore:=20 =3D=3D=3D=3D=3D Question 1 to the working group: Would you prefer to have "Standards track Reactive protocol" removed from the charter? A "yes/no" answer is all that = I want to hear. =3D=3D=3D=3D=3D It is clear to me that attempts to merge or choose documents have failed. T= here is no value in discussing how or why, nor to what extent they might be part= ially successful, or how resolution could be potentially reached. Therefore: =3D=3D=3D=3D=3D Question 2 to the working group: Would you like the AD to select one of the documents (and, obviously, I will not tell you in advance which I might sel= ect!) and require that the WG works on that one document? In this case, publicati= on of the other document with AD sponsorship or through the ISE is unlikely. Agai= n, a "yes/no" answer is all I want to hear, but respondents must understand that saying "yes" implies a willingness to cooperate, to provide text, and to ha= ve the WG make any modifications to the document all in the normal IETF way. =3D=3D=3D=3D=3D Failing the selection of just one document, and absent abandoning the work = item, there remains the possibility of progressing both documents within the work= ing group. As AD I will not allow the working group to produce two standards tr= ack RFCs for reactive protocols, and I therefore see no benefit in having two working group drafts claiming to be intended for standards track publicatio= n. So this leads to: =3D=3D=3D=3D=3D Question 3 to the working group: Would you be prepared to work on two docum= ents describing reactive protocols that are intended for publication as Experime= ntal RFCs? Yet again, a "yes/no" answer is what I want to hear, but respondents = need to understand that saying "yes" implies a willingness to see both documents published as Experimental RFCs and that, owing to the lower bar on Experime= ntal work, it would not be acceptable to attempt to block the progress of either document with protracted technical discussions. We might (in the operationa= l spirit of the MANET working group) come back after some time and experience= with the RFCs to re-charter and select just one solution for the standards track= , but that is for the distant future.=09 =3D=3D=3D=3D=3D I need to explain to the working group that the default position will be to remove this item from the WG charter. That is, if the WG overwhelmingly say= s "no" to both Q2 and Q3, I will work with the IESG to remove reactive protoc= ols from the MANET charter regardless of the answer to Q1. How to answer this email: Send responses in the form of 1 [yes/no] 2 [yes/no] 3 [yes/no] This is not a vote, but I am taking the mood of the working group in order = to inform my decision. Conditional answers such as "yes, but only if foo" are within your rights, = but will not be very helpful to me,=20 I know that many people are busy with work or enjoying themselves at this t= ime of year, but this decisions needs to be made soon. I am inclined to make my decision before the end of 2012, but in deference to the festivities, I wil= l announce it in the week of January 7th. Thanks, Adrian _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From yi.jiazi@gmail.com Mon Dec 24 05:55:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6C621F88F5 for ; Mon, 24 Dec 2012 05:55:45 -0800 (PST) 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 RrVF76pLivcb for ; Mon, 24 Dec 2012 05:55:44 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1D59621F88F3 for ; Mon, 24 Dec 2012 05:55:43 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id ei8so3332864wgb.32 for ; Mon, 24 Dec 2012 05:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to:x-mailer; bh=CRwuRcSQZUcLvP0FywiAjQF6+qPckWx+Qmqvht+UXTE=; b=pKGWzgAbB8ekyDdPPX5emUkoO2zVDxHLdZCRjuO0yrpd5/K1YlWAcAv4SqbJEBloTr lg8Nt4oY9FSpXSOVt9iGI+V39EUT83WxixbAz+zgyecDZh2sfpuQ10ewisRKDbJCbTvC pFaYJ+pStxjqf6P3SHhY5FjqlXGyW7Rmjg45U+8yPqg8sqTcZ588q9jzRB09fN7OaWOt 6eds525l9oDbdv5Fyw8nt046Kpo4Euh0PsS10k8J+WdFcidDknowyirdEzkdyU/3IkbL YmWwfySIxdr1LciWUKShH0oNYFt14HLGfhmhKH6srbc9g7U8O5w4UWy5npnskjpUcy36 iljg== X-Received: by 10.180.24.198 with SMTP id w6mr27188456wif.27.1356357342989; Mon, 24 Dec 2012 05:55:42 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id hg17sm43122022wib.1.2012.12.24.05.55.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Dec 2012 05:55:42 -0800 (PST) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_A82517D3-4D09-4746-91D7-A833DAD0B21A" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi YI In-Reply-To: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> Date: Mon, 24 Dec 2012 14:55:39 +0100 Message-Id: <19CB495C-1D45-4912-AA55-4EBEC00F2481@jiaziyi.com> References: <014301cddc88$189edda0$49dc98e0$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1499) Cc: manet@ietf.org Subject: Re: [manet] Resolving the Reactive Protocol issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 13:55:45 -0000 --Apple-Mail=_A82517D3-4D09-4746-91D7-A833DAD0B21A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Adrian, all: Here is my opinion on those questions: 1) Would you prefer to have "Standards track Reactive protocol" removed = from the charter? NO But it's not something I'll fight for. Therefore, I voted "yes" = to 3) also.=20 2) Would you like the AD to select one of the documents? NO I would say "YES" if I know what's the considerations when = making those selections. If it's based on IETF's "running code" and = "rough consensus", or at least either of them, I'm totally OK. But = without further information, I can only say NO.=20 3) Would you be prepared to work on two documents describing reactive = protocols that are intended for publication as Experimental RFCs? YES It's not the best choice, but it's acceptable for me if there is = no consensus in the WG.=20 best Merry Christmas.=20 Jiazi On Dec 17, 2012, at 7:55 PM, Adrian Farrel wrote: > Hi MANET, >=20 > In the spirit of all good examination papers, please read all the way = to the end > of this email before starting to write your response. >=20 > I have been watching the discussions on the MANET list with care and = talking > with the chairs. All three of us have, I know, received plenty of = private emails > on the subject as well. >=20 > In my opinion, the debate about documents has almost (but not = completely) > obscured the technical work. This is neither helpful nor in the spirit = of an > engineering organisation. >=20 > As AD it falls to me to unblock this log jam and enable the working = group to do > useful work. I think I see people explicitly asking for AD = intervention. >=20 > In Atlanta, there remained interest in having a reactive protocol = produced by > the working group. There is clearly still some interest on the list. = But it is > not clear to me how the WG feels on this since there may be many who = are > watching and wishing they could get on with other work in a quieter = environment. > Therefore:=20 >=20 > =3D=3D=3D=3D=3D > Question 1 to the working group: Would you prefer to have "Standards = track > Reactive protocol" removed from the charter? A "yes/no" answer is all = that I > want to hear. > =3D=3D=3D=3D=3D >=20 > It is clear to me that attempts to merge or choose documents have = failed. There > is no value in discussing how or why, nor to what extent they might be = partially > successful, or how resolution could be potentially reached. Therefore: >=20 > =3D=3D=3D=3D=3D > Question 2 to the working group: Would you like the AD to select one = of the > documents (and, obviously, I will not tell you in advance which I = might select!) > and require that the WG works on that one document? In this case, = publication of > the other document with AD sponsorship or through the ISE is unlikely. = Again, a > "yes/no" answer is all I want to hear, but respondents must understand = that > saying "yes" implies a willingness to cooperate, to provide text, and = to have > the WG make any modifications to the document all in the normal IETF = way. > =3D=3D=3D=3D=3D >=20 > Failing the selection of just one document, and absent abandoning the = work item, > there remains the possibility of progressing both documents within the = working > group. As AD I will not allow the working group to produce two = standards track > RFCs for reactive protocols, and I therefore see no benefit in having = two > working group drafts claiming to be intended for standards track = publication. So > this leads to: >=20 > =3D=3D=3D=3D=3D > Question 3 to the working group: Would you be prepared to work on two = documents > describing reactive protocols that are intended for publication as = Experimental > RFCs? Yet again, a "yes/no" answer is what I want to hear, but = respondents need > to understand that saying "yes" implies a willingness to see both = documents > published as Experimental RFCs and that, owing to the lower bar on = Experimental > work, it would not be acceptable to attempt to block the progress of = either > document with protracted technical discussions. We might (in the = operational > spirit of the MANET working group) come back after some time and = experience with > the RFCs to re-charter and select just one solution for the standards = track, but > that is for the distant future.=09 > =3D=3D=3D=3D=3D >=20 > I need to explain to the working group that the default position will = be to > remove this item from the WG charter. That is, if the WG = overwhelmingly says > "no" to both Q2 and Q3, I will work with the IESG to remove reactive = protocols > from the MANET charter regardless of the answer to Q1. >=20 >=20 > How to answer this email: Send responses in the form of > 1 [yes/no] > 2 [yes/no] > 3 [yes/no] > This is not a vote, but I am taking the mood of the working group in = order to > inform my decision. > Conditional answers such as "yes, but only if foo" are within your = rights, but > will not be very helpful to me,=20 >=20 > I know that many people are busy with work or enjoying themselves at = this time > of year, but this decisions needs to be made soon. I am inclined to = make my > decision before the end of 2012, but in deference to the festivities, = I will > announce it in the week of January 7th. >=20 > Thanks, > Adrian >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_A82517D3-4D09-4746-91D7-A833DAD0B21A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear Adrian, = all:
1) Would you prefer to have "Standards = track Reactive protocol" removed from the = charter?
NO
But it's = not something I'll fight for. Therefore, I voted "yes" to 3) = also. 

2) Would you like the AD to = select one of the documents?
NO
  I would = say "YES" if I know what's the considerations when making those = selections. If it's based on IETF's "running code" and "rough = consensus", or at least either of them, I'm totally OK.  But = without further information, I can only say = NO. 

3)  Would you be prepared to = work on two documents describing reactive protocols that are = intended for publication as Experimental RFCs?
= YES
It's not the best choice, but it's acceptable for me if = there is no consensus in the WG. 

best
Merry = Christmas. 

Jiazi


On Dec 17, 2012, at 7:55 PM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

Hi MANET,

In the spirit of all good examination = papers, please read all the way to the end
of this email before = starting to write your response.

I have been watching the = discussions on the MANET list with care and talking
with the chairs. = All three of us have, I know, received plenty of private emails
on = the subject as well.

In my opinion, the debate about documents = has almost (but not completely)
obscured the technical work. This is = neither helpful nor in the spirit of an
engineering = organisation.

As AD it falls to me to unblock this log jam and = enable the working group to do
useful work. I think I see people = explicitly asking for AD intervention.

In Atlanta, there remained = interest in having a reactive protocol produced by
the working group. = There is clearly still some interest on the list. But it is
not clear = to me how the WG feels on this since there may be many who = are
watching and wishing they could get on with other work in a = quieter environment.
Therefore:

=3D=3D=3D=3D=3D
Question 1 = to the working group: Would you prefer to have "Standards = track
Reactive protocol" removed from the charter? A "yes/no" answer = is all that I
want to hear.
=3D=3D=3D=3D=3D

It is clear to = me that attempts to merge or choose documents have failed. There
is = no value in discussing how or why, nor to what extent they might be = partially
successful, or how resolution could be potentially reached. = Therefore:

=3D=3D=3D=3D=3D
Question 2 to the working group: = Would you like the AD to select one of the
documents (and, obviously, = I will not tell you in advance which I might select!)
and require = that the WG works on that one document? In this case, publication = of
the other document with AD sponsorship or through the ISE is = unlikely. Again, a
"yes/no" answer is all I want to hear, but = respondents must understand that
saying "yes" implies a willingness = to cooperate, to provide text, and to have
the WG make any = modifications to the document all in the normal IETF = way.
=3D=3D=3D=3D=3D

Failing the selection of just one = document, and absent abandoning the work item,
there remains the = possibility of progressing both documents within the working
group. = As AD I will not allow the working group to produce two standards = track
RFCs for reactive protocols, and I therefore see no benefit in = having two
working group drafts claiming to be intended for standards = track publication. So
this leads to:

=3D=3D=3D=3D=3D
Question= 3 to the working group: Would you be prepared to work on two = documents
describing reactive protocols that are intended for = publication as Experimental
RFCs? Yet again, a "yes/no" answer is = what I want to hear, but respondents need
to understand that saying = "yes" implies a willingness to see both documents
published as = Experimental RFCs and that, owing to the lower bar on = Experimental
work, it would not be acceptable to attempt to block the = progress of either
document with protracted technical discussions. We = might (in the operational
spirit of the MANET working group) come = back after some time and experience with
the RFCs to re-charter and = select just one solution for the standards track, but
that is for the = distant future. =
=3D=3D=3D=3D=3D

I need to explain to the working group = that the default position will be to
remove this item from the WG = charter. That is, if the WG overwhelmingly says
"no" to both Q2 and = Q3, I will work with the IESG to remove reactive protocols
from the = MANET charter regardless of the answer to Q1.


How to answer = this email: Send responses in the form of
1 [yes/no]
2 = [yes/no]
3 [yes/no]
This is not a vote, but I am taking the mood = of the working group in order to
inform my decision.
Conditional = answers such as "yes, but only if foo" are within your rights, = but
will not be very helpful to me,

I know that many people = are busy with work or enjoying themselves at this time
of year, but = this decisions needs to be made soon. I am inclined to make = my
decision before the end of 2012, but in deference to the = festivities, I will
announce it in the week of January = 7th.

Thanks,
Adrian

_____________________________________= __________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail=_A82517D3-4D09-4746-91D7-A833DAD0B21A-- From abdussalambaryun@gmail.com Mon Dec 24 07:05:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC4F21F88D1 for ; Mon, 24 Dec 2012 07:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.592 X-Spam-Level: X-Spam-Status: No, score=-3.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, 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 49uskJHoMBEn for ; Mon, 24 Dec 2012 07:05:14 -0800 (PST) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id 25DA721F88D0 for ; Mon, 24 Dec 2012 07:05:14 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id r6so7418696vbi.8 for ; Mon, 24 Dec 2012 07:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=oSHP1E+HUCWscFgazvFejlSgNoheK7Esqa118SWLPoE=; b=hg97rz00kSvYjTHEl7zVBBxShDqc8R8XlHW3KrrmcTsh+sQfGjgKsteLauMLOlnzYB fIhxzmwq54MXLBxWdkWFgbvh3xYqq47uTKiyJpsRFp/wcgQSBsocdFZI4cq1jnoCMh1a 3pHvaSEyRhLso/AxDD0pKO0JyLsj7j5QnxkHHZI6QU1t3i97xiuwr9l8FMe1I231dg73 RutQRgt/+AxFyJc+WrtOzIKoxm8osC85oLo6c27delpYyvyWcJEQsToAbSTgQ2zqLtdp OvrIdOpOBkcL4TrwpBECOSG1jOdUf9dxISivjWpMnrAQXia3Z4xfQZFuCKyKzZyT89Q3 vWjA== MIME-Version: 1.0 Received: by 10.52.175.106 with SMTP id bz10mr28638235vdc.125.1356361513594; Mon, 24 Dec 2012 07:05:13 -0800 (PST) Received: by 10.220.145.5 with HTTP; Mon, 24 Dec 2012 07:05:13 -0800 (PST) Date: Mon, 24 Dec 2012 16:05:13 +0100 Message-ID: From: Abdussalam Baryun To: Jiazi YI Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: [manet] manet WG purpose and consideration (was Re: Resolving the Reactive Protocol issue) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 15:05:15 -0000 Hi Jiaz, > 2) Would you like the AD to select one of the documents? > NO > I would say "YES" if I know what's the considerations when making those > selections. If it's based on IETF's "running code" and "rough consensus", or > at least either of them, I'm totally OK. But without further information, I > can only say NO. > We have no doubt that the selection will be based on all IETF considerations with the AD's advise, but in addition to consider that we need to move on together for maintaining this IETF WG purposes at least. AB From shares@ndzh.com Mon Dec 24 07:34:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D0C21F8583 for ; Mon, 24 Dec 2012 07:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.09 X-Spam-Level: ** X-Spam-Status: No, score=2.09 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_20=-0.74, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 805T6KJpDTOi for ; Mon, 24 Dec 2012 07:34:01 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id F19FB21F846E for ; Mon, 24 Dec 2012 07:34:00 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: Date: Mon, 24 Dec 2012 10:33:52 -0500 Message-ID: <000901cde1ec$141d2c00$3c578400$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01CDE1C2.2B4D6590" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3h6/8M4Mq6Ja2qSnOI2LvJymhOzg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [manet] Resolving the Reactive Protocol issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 15:34:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000A_01CDE1C2.2B4D6590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Adrian: Question 1 to the working group: Would you prefer to have "Standards track Reactive protocol" removed from the charter? No Questions 2: Would you like the AD to select one of the documents (and, obviously, I will not tell you in advance which I might select!) and require that the WG works on that one document? - Yes Question 3 to the working group: Would you be prepared to work on two documents describing reactive protocols that are intended for publication as Experimental RFCs? - Yes Additional questions: 1) Will you suggest a style guide as well as a solution? In order to vote, I reviewed 2 months of email list discussion, and much of it had to do with document style issues. 2) In parallel with your query, can I still ask technical questions regarding people's comparison answer? 3) May I in parallel provide reactive trade-off from 802.11 work in mesh? This includes research and deployment experience with mesh networks (2-15 nodes). 4) Is this IP only or are we considering Reactive protocols directly over layer 2? Sue Hares ------=_NextPart_000_000A_01CDE1C2.2B4D6590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adrian: =

 

Question 1 to the = working group: Would you prefer to have "Standards = track

Reactive = protocol" removed from the charter?  No  =

 

Questions 2: Would you like the =
AD to select one of the
documents (and, obviously, =
I will not tell you in advance which I might select!) and require that =
the WG works on that one document?  - Yes
 =

Question 3 to the working group: Would you be =
prepared to work on two documents describing reactive protocols that are =
intended for publication as Experimental RFCs? -  Yes =

 

Additional = questions:

1)  Will you suggest a style guide as = well as a solution?  In order to vote, I reviewed 2 months of email = list discussion, and

much of it had to do with document style issues. =

2)  In parallel with your query, can I = still ask technical questions regarding people’s comparison = answer?

3)      = May I in parallel provide reactive trade-off from 802.11 work in = mesh? This includes research and deployment experience with mesh = networks (2-15 nodes).

4)  Is this IP only or are we = considering Reactive protocols directly over layer 2? =

Sue Hares =

------=_NextPart_000_000A_01CDE1C2.2B4D6590-- From abdussalambaryun@gmail.com Thu Dec 27 04:36:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1790421F8C77 for ; Thu, 27 Dec 2012 04:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.013, 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 20NMufdkiA7g for ; Thu, 27 Dec 2012 04:36:15 -0800 (PST) Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) by ietfa.amsl.com (Postfix) with ESMTP id 740A121F8C74 for ; Thu, 27 Dec 2012 04:36:07 -0800 (PST) Received: by mail-vb0-f53.google.com with SMTP id b23so9588459vbz.40 for ; Thu, 27 Dec 2012 04:36:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=5uWhPKF64XJONfsSYULhjmNm3L3UyAozBfypfjbVGkg=; b=pp7PaG4u4V9Z4fPYYjx1mdkLttz8iyYMYXw0/KHmhQ4D2GL+ERQ0CY9//y/LzzyJki oWkNfrk03jANmcfx0g9GXNwqQVGKkEPADEEClEUtNj2HXMjdHtfQeyqWqmABAIOq3gmL Qecp1vbniYlWcupiS7qwhonG4eyTsArWjkXAcHktNHsXJjyY3uasFYXLI6owDRw/ALNA keUehA/O5Vu0r3LfQKkeJey/eF9QafY4CIxhOA2nn6atRzxrQENjJEEQZRgm2EBwXAqh qFhGjY6EPR23taZMk0kFdy0y6oudYQ/ssVuuFhHNoB+i5xIIluS6Le5Z9S+32kPLRRxL D8mw== MIME-Version: 1.0 Received: by 10.52.175.106 with SMTP id bz10mr39796936vdc.125.1356611766904; Thu, 27 Dec 2012 04:36:06 -0800 (PST) Received: by 10.220.145.5 with HTTP; Thu, 27 Dec 2012 04:36:06 -0800 (PST) Date: Thu, 27 Dec 2012 13:36:06 +0100 Message-ID: From: Abdussalam Baryun To: Susan Hares Content-Type: multipart/alternative; boundary=bcaec5171e0176e72704d1d4caaf Cc: manet@ietf.org Subject: [manet] Addition Comparing Questions (was Re: Resolving the Reactive Protocol issue) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 12:36:16 -0000 --bcaec5171e0176e72704d1d4caaf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Sue, I will try to answer the last two as I think it is addressed to WG participants as well, see below; On Mon, Dec 24, 2012 at 4:33 PM, Susan Hares wrote: > Additional questions: > > **1) **Will you suggest a style guide as well as a solution? In order > to vote, I reviewed 2 months of email list discussion, and **** > > much of it had to do with document style issues. **** > > **2) **In parallel with your query, can I still ask technical questions > regarding people=92s comparison answer? **** > > **3) **May I in parallel provide reactive trade-off from 802.11 work > in mesh? This includes research and deployment experience with mesh > networks (2-15 nodes). > Yes, please provide with your opinion/experience as it will help in the new reactive protocol that we will be working on, > **** > > **4) **Is this IP only or are we considering Reactive protocols directly > over layer 2? **** > Yes, I am interested that it is only IP reactive protocol as the MANET-charter is focused on, but one of the proposed protocol seem to be working with or without IP which I believe out of scope. As mentioned by someone before on the list that some MANETs do use reactive protocols in L2. However, IMHO, considering reactive protocol directly over L2 can/may be interested to us after completing the reactive over IP. AB --bcaec5171e0176e72704d1d4caaf Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Sue,

I will try to answer the last two as I think it is addressed= to WG participants as well, see below;

O= n Mon, Dec 24, 2012 at 4:33 PM, Susan Hares <shares@ndzh.com> wrote:
Additional questions:

1)=A0 Will you suggest a st= yle guide as well as a solution?=A0 In order to vote, I reviewed 2 months o= f email list discussion, and

much of it had to do= with document style issues.

2)=A0 In parallel with your query, can I stil= l ask technical questions regarding people=92s comparison answer?

3)=A0=A0=A0=A0=A0 May I in parallel provide reactive trade-off from 802= .11 work in mesh? This includes research and deployment experience with mes= h networks (2-15 nodes).


Yes, please provide with your opinion/exp= erience as it will help in the new reactive protocol that we will be workin= g on,
=A0

<= /u>

4)=A0 Is t= his IP only or are we considering Reactive protocols directly over layer 2?=


Yes, I am interested that it is only IP r= eactive protocol as the MANET-charter is focused on, but one of the propose= d protocol seem to be working with or without IP which I believe out of sco= pe. As mentioned by someone before on the list that some MANETs do use reac= tive protocols in L2. However, IMHO, considering reactive protocol directly= over L2 can/may be interested to us after completing the reactive over IP.=

AB
--bcaec5171e0176e72704d1d4caaf-- From charliep@computer.org Sun Dec 30 14:40:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF6B21F8AF7 for ; Sun, 30 Dec 2012 14:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 WVLFV0Ck-1gX for ; Sun, 30 Dec 2012 14:40:24 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 14A8B21F8AA1 for ; Sun, 30 Dec 2012 14:40:23 -0800 (PST) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TpRYM-0000lg-BN; Sun, 30 Dec 2012 17:40:22 -0500 Message-ID: <50E0C2D5.6030404@computer.org> Date: Sun, 30 Dec 2012 14:40:21 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Marius Portmann References: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> <50BE4036.30507@computer.org> <50BFA190.7050908@computer.org> <55276FFE1B06A541A659C0B360E8066F181C42@UQEXMDA8.soe.uq.edu.au> In-Reply-To: <55276FFE1B06A541A659C0B360E8066F181C42@UQEXMDA8.soe.uq.edu.au> Content-Type: multipart/alternative; boundary="------------020601070406080107080403" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86f2c58e4e75d50c558f5c864c2b24483d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: "'manet@ietf.org'" Subject: [manet] Duplicate suppression for RREQ and RREP -- Problem and Proposed Solutions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 22:40:25 -0000 This is a multi-part message in MIME format. --------------020601070406080107080403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello folks, As noted by Marius Portmann et al., there are some subtleties about using sequence numbers to inhibit dissemination of possibly outdated RREQ and RREP messages. After reconsidering this matter for the last couple of weeks, I realized that the existing specification does not properly handle suppression of duplicate multicast messages. In order to accomplish that, while still not suppressing earlier multicast messages that do need to be transmitted, a list of previously retransmitted multicast AODVv2 routing messages needs to be maintained, as suggested by Marius. Here is some proposed text for that purpose: Two incoming RREQ messages should be considered the "same" if they have the same Sequence Number and were generated by the same AODVv2 router. Using that notion of equivalence, when RREQ messages are multicast in a MANET, a node may well receive the same RREQ from more than one of its neighbors. Such duplicated RREQs SHOULD NOT be retransmitted; otherwise, a great deal of unnecessary signaling traffic is likely to be generated in the network as multicast RREQs are retransmitted over and over again with practically no additional benefit. To avoid unnecessary retransmission of duplicate RREQ messages, while still enabling the proper handling of earlier RREQ messages that may have somehow been delayed in the network, it is needed for each AODVv2 router to keep a list of the RREQ messages which it has recently retransmitted. The same duplicate suppression is needed for other AODVv2 messages. For instance, when optional multicast RREP is used to enable selection from among multiple possible return routes, similar measures need to be taken. For this reason, the table is more generally called the AODVv2 Duplicate Suppression Table; it is simply a list of the AODVv2 RREQ and RREP messages which have been recently multicast, using the above notion of message equivalence. More formally, two AODVv2 RREQ messages are equivalent if: - they were generated by the same AODVv2 router (RREQ_gen) - RREQ_Gen assigned the same Sequence Number to its routing information in the RREQs - the RREQs are for the same desired destination address An analogous definition applies for a RREP message, in case that the RREP message would be multicast. Protocol handling of RERR messages eliminates the need for tracking RERR messages, since the rules for retransmitting RERR multicast messages prevent the phenomenon of message duplication (that can affect RREQ and RREP retransmission). As a historical note, AODV and early versions of DYMO contained a similar broadcast suppression mechanism. Prior to initiating the conversion to RFC 5444 compliance, Ian and I had thought that the underlying multicast optimization would do a better job of duplicate suppression, and in a manner already integrated with the underlying forwarding mechanisms. Thanks, Marius et al. for triggering a re-examination of this issue which has needed attention since the RFC 5444 compliance changes. On 12/13/2012 6:09 PM, Marius Portmann wrote: > > Hi Charlie, > > .................... > > >> (2) Route Reply Loss > > >> -------------------- > > >> AODV can lose route replies > (http://www.ietf.org/mail-archive/web/manet/current/msg05702.html). > > >> The reason is that route replies are only forwarded by an > > >> intermediate node when the node updates its routing table. > > ................ > > The relevant point is that an AODVv2 router retransmits the RREQ or > > > RREP regardless of whether the AODVv2 router used the incoming > > > routing information to update its route table. > > > > > > I thought there might be some wording to the contrary, but after > > > reading the relevant parts of the specification several times I > > > haven't found any such wording. Please let me know what I have missed. > > Our analysis was based on DYMO/AODVv2 version 23. It now appears that > in version 24, the specification has changed such that it is similar > to what we are proposing, i.e. to let the AODVv2 routers always > forward the RREQ/RREP messages. > > All the best, > > Rob, Peter, Marius and Wee Lum > > -- Regards, Charlie P. --------------020601070406080107080403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello folks,

As noted by Marius Portmann et al., there are some subtleties about
using sequence numbers to inhibit dissemination of possibly
outdated RREQ and RREP messages.  After reconsidering this
matter for the last couple of weeks, I realized that the existing
specification does not properly handle suppression of duplicate
multicast messages.  In order to accomplish that, while still
not suppressing earlier multicast messages that do need to be
transmitted, a list of previously retransmitted multicast AODVv2
routing messages needs to be maintained, as suggested by Marius.

Here is some proposed text for that purpose:

Two incoming RREQ messages should be considered the "same" if
they have the same Sequence Number and were generated by the same
AODVv2 router.  Using that notion of equivalence, when RREQ messages
are multicast in a MANET, a node may well receive the same RREQ from
more than one of its neighbors.  Such duplicated RREQs SHOULD NOT
be retransmitted; otherwise, a great deal of unnecessary signaling
traffic is likely to be generated in the network as multicast RREQs
are retransmitted over and over again with practically no additional
benefit.

To avoid unnecessary retransmission of duplicate RREQ messages,
while still enabling the proper handling of earlier RREQ messages
that may have somehow been delayed in the network, it is needed
for each AODVv2 router to keep a list of the RREQ messages which
it has recently retransmitted.

The same duplicate suppression is needed for other AODVv2 messages.
For instance, when optional multicast RREP is used to enable selection
from among multiple possible return routes, similar measures need to
be taken.

For this reason, the table is more generally called the AODVv2
Duplicate Suppression Table; it is simply a list of the AODVv2 RREQ
and RREP messages which have been recently multicast, using
the above notion of message equivalence.  More formally, two
AODVv2 RREQ messages are equivalent if:
- they were generated by the same AODVv2 router (RREQ_gen)
- RREQ_Gen assigned the same Sequence Number to its
  routing information in the RREQs
- the RREQs are for the same desired destination address
An analogous definition applies for a RREP message, in case that
the RREP message would be multicast.

Protocol handling of RERR messages eliminates the need for
tracking RERR messages, since the rules for retransmitting RERR
multicast messages prevent the phenomenon of message duplication
(that can affect RREQ and RREP retransmission).

As a historical note, AODV and early versions of DYMO contained
a similar broadcast suppression mechanism.  Prior to initiating the
conversion to RFC 5444 compliance, Ian and I had thought that the
underlying multicast optimization <via SMF> would do a better
job of duplicate suppression, and in a manner already integrated
with the underlying forwarding mechanisms.  Thanks, Marius et al.
for triggering a re-examination of this issue which has needed
attention since the RFC 5444 compliance changes.

On 12/13/2012 6:09 PM, Marius Portmann wrote:

Hi Charlie,

 

....................

>> (2) Route Reply Loss

>> --------------------

>> AODV can lose route replies (http://www.ietf.org/mail-archive/web/manet/current/msg05702.html).

>> The reason is that route replies are only forwarded by an

>> intermediate node when the node updates its routing table.

 

................

> The relevant point is that an AODVv2 router retransmits the RREQ or

> RREP regardless of whether the AODVv2 router used the incoming

> routing information to update its route table.

>

> I thought there might be some wording to the contrary, but after

> reading the relevant parts of the specification several times I

> haven't found any such wording.  Please let me know what I have missed.

 

Our analysis was based on DYMO/AODVv2 version 23. It now appears that in version 24, the specification has changed such that it is similar to what we are proposing, i.e. to let the AODVv2 routers always forward the RREQ/RREP messages.

 

All the best,

Rob, Peter, Marius and Wee Lum

 


-- 
Regards,
Charlie P.
--------------020601070406080107080403-- From charliep@computer.org Sun Dec 30 14:45:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B7421F8667 for ; Sun, 30 Dec 2012 14:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 jhnFCjUpjKWW for ; Sun, 30 Dec 2012 14:45:56 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7160521F8462 for ; Sun, 30 Dec 2012 14:45:56 -0800 (PST) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TpRdj-0005ba-CL; Sun, 30 Dec 2012 17:45:55 -0500 Message-ID: <50E0C423.7020009@computer.org> Date: Sun, 30 Dec 2012 14:45:55 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Henning Rogge References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> In-Reply-To: <50C05967.405@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad866cf01b845374f74811affa438c04d18f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 22:45:57 -0000 Hello Henning, I have been thinking a lot about the readability issues. Here are notational devices used in the current specification: | Route[DestAddr] | A route table entry towards DestAddr | | Route[Addr].{field} | A field in a route table entry | I am assuming these are O.K. | -- | -- | | | RFC 5444 Message Header | | | RFC 5444 Message Header | | AddrBlk | an RFC 5444 Address TLV Block | | AddrBlk[1] | The first address slot in AddrBlk | | AddrBlk[N] | The Nth address slot in AddrBlk | | AddrBlk[OrigNode] | AddrBlk[1] | | AddrBlk[TargNode] | AddrBlk[2] | | AddrTLV | an RFC 5444 Address Block TLV | | AddrTLV[1] | the first item in AddrTLV | | AddrTLV[N] | the Nth item in AddrTLV | | AddrTLV[OrigNode] | AddrTLV[1] | | AddrTLV[TargNode] | AddrTLV[2] | These are pretty intuitive, given the notation already in RFC 5444. | SeqNumTLV | Sequence Number AddrTLV for AddrBlk | Looks O.K. to me...? | OrigNode | Originating Node | | RREQ_Gen | AODVv2 router originating an RREQ | | RREP_Gen | AODVv2 router responding to an RREQ | | RteMsg | Either RREQ or RREP | | RteMsg.{field} | Field in RREQ or RREP | | RteMsg_Gen | Router generating a RteMsg | | HandlingRtr | Handling Router | | TargNode | Target Node | | UnreachableNode | Unreachable Node | I am guessing that, if you find any of the notation difficult to read, it would be one of these. I have been steadily reducing the number of different such notations over time, but the above seem to be very useful and seem pretty transparent to me. I have replaced "OrigRtr" by "RREQ_Gen" and "TargRtr" by "RREP_Gen" in the version I am editing now. This has the advantage of reducing the number of notational devices, but did require some rewording of certain sentences that seemed to make better sense with the earlier notation. The case for using "RteMsg" to stand for either RREQ or RREP is pretty strong, for anyone who believes in eliminating redundancy in specification. There are quite many protocol actions that are the same for RREQ as they are for RREP. To write the relevant sections twice seems wrong to me. However, I am quite open to using any other terminology if there are suggestions for improvement. For instance, one could replace all instances of "RteMsg" by "RREQ_or_RREP", but (it seems to me) that would typically *reduce* readability instead of enhancing it. If the claim is that *any* such abbreviations should be replaced with fully spelled out words, then we should have a discussion. For instance, "UnreachableNode" is equally readable as "Unreachable Node", but the former has the advantage of immediately connoting a distinguished term in the document. I tried to have a discussion about this before, using "F = ma" as an example (no one complained about the mistake in the previous example, surprisingly to me). As I said before, to someone who knows what 'F', 'm', and 'a' mean, "F = ma" is a lot more readable than "Force is the same as the product of mass and acceleration". Even more to the point, "F = ma" is pretty easy to remember. But to someone who has never before encountered the abbreviations for those fundamental quantities, "F = ma" is impenetrable. To reiterate after having said all that, I always remain quite open to suggestions for ways to improve the notation. If there are other concerns about readability, please do not hesitate to point them out. I have made major improvements in document organization and editorial style during the last two months, and so I hope that you can take a fresh look. On 12/6/2012 12:37 AM, Henning Rogge wrote: > On 12/05/2012 10:45 PM, Charles E. Perkins wrote: >> >> Hello Henning, >> >> Here is some more follow-up on your observations and suggestions. >> >> On 12/3/2012 5:25 AM, Henning Rogge wrote: >>> >>> > Handling Router (HandlingRtr) >>> > HandlingRtr denotes the AODVv2 router handling an AODVv2 message. >>> >>> Do you really need the "HandlingRtr" abbreviation? It complicates the >>> text and does not shorten it that much. >> >> Would you like to see this terminology changed to instead be "Handler"? >> I guess there's no need to constantly remind the reader that the node >> doing the AODVv2 processing is a "router"... > > I think we should have a discussion on the list if that many > abbreviations are really useful/necessary for a draft/rfc. In my > opinion they have no advantage (beyond saving a few characters) and > make the draft harder to read. > -- Regards, Charlie P. From charliep@computer.org Mon Dec 31 16:06:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C4121F85B8 for ; Mon, 31 Dec 2012 16:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 d6Jcbo6ZpDUU for ; Mon, 31 Dec 2012 16:06:16 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5D821F8484 for ; Mon, 31 Dec 2012 16:06:15 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TppN1-0000tT-17 for manet@ietf.org; Mon, 31 Dec 2012 19:06:15 -0500 Message-ID: <50E22876.8000504@computer.org> Date: Mon, 31 Dec 2012 16:06:14 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "'manet@ietf.org'" References: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> <50BE4036.30507@computer.org> <50BFA190.7050908@computer.org> <55276FFE1B06A541A659C0B360E8066F181C42@UQEXMDA8.soe.uq.edu.au> <50E0C2D5.6030404@computer.org> In-Reply-To: <50E0C2D5.6030404@computer.org> Content-Type: multipart/alternative; boundary="------------000302090205080804010702" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad869ab08c3b87f4436d51c004fa1c951e3c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Subject: Re: [manet] Duplicate suppression for RREQ and RREP -- Problem and Proposed Solutions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 00:06:18 -0000 This is a multi-part message in MIME format. --------------000302090205080804010702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello again folks, During the process of writing down the specification for duplicate suppression, various technical points became much more clear. Consequently, the proposed mechanics of duplicate suppression that I sent out yesterday requires some modification. First, while it is true that suppressing message retransmission has in the past been motivated mostly by broadcast RREQ, the actual phenomenon applies equally well to unicast RREQ and unicast RREP. For example, if a target router receives RREQ and would respond with RREP, then it must first check to see whether the routing information in the RREP is more useful than from a previous RREP sent in response to a comparable incoming RREQ. Second, I reviewed the proposed concept of RteMsg "equivalence", and it is far too fragile. There are several worthy variations of "message equivalence" that deserve consideration. It turns out that the algorithm can be expressed quite well with the much weaker notion of "comparable" messages. Two RREQ or RREP messages are "comparable" if: - they were generated by the same router, and - they have the same OrigNode and TargNode addresses. The algorithm proceeds by comparing a candidate outgoing message "comparable" to previous messages to see whether the candidate outgoing message should be "suppressed". Third, the table of previously transmitted messages (renamed to be "AODVv2 Transmitted RteMsg Table" -- or, simply "RteMsg Table) is maintained so that no two entries are comparable. This is easier than trying to compare a candidate outgoing RREQ or RREP message against all comparable messages in the RteMsg table -- if there were to be more than one such comparable RteMsg table entry. In the above, it's hard to know whether a message is a "duplicate" without relying on a notion of "equivalence". For that reason, the algorithm should no longer be called "duplicate suppression". I have renamed it to be "useless message suppression". It is, however, quite similar to the duplicate broadcast suppression used long ago, but lost during the transition to enable use of more general multicast transmission infrastructures (and RFC 5444). I am sure this is will all be clearer when I am able to exhibit the text for the above data structure and algorithm in the natural settings of the revised draft. On 12/30/2012 2:40 PM, Charles E. Perkins wrote: > Hello folks, > > As noted by Marius Portmann et al., there are some subtleties about > using sequence numbers to inhibit dissemination of possibly > outdated RREQ and RREP messages. After reconsidering this > matter for the last couple of weeks, I realized that the existing > specification does not properly handle suppression of duplicate > multicast messages. In order to accomplish that, while still > not suppressing earlier multicast messages that do need to be > transmitted, a list of previously retransmitted multicast AODVv2 > routing messages needs to be maintained, as suggested by Marius. > > Here is some proposed text for that purpose: > > Two incoming RREQ messages should be considered the "same" if > they have the same Sequence Number and were generated by the same > AODVv2 router. Using that notion of equivalence, when RREQ messages > are multicast in a MANET, a node may well receive the same RREQ from > more than one of its neighbors. Such duplicated RREQs SHOULD NOT > be retransmitted; otherwise, a great deal of unnecessary signaling > traffic is likely to be generated in the network as multicast RREQs > are retransmitted over and over again with practically no additional > benefit. > > To avoid unnecessary retransmission of duplicate RREQ messages, > while still enabling the proper handling of earlier RREQ messages > that may have somehow been delayed in the network, it is needed > for each AODVv2 router to keep a list of the RREQ messages which > it has recently retransmitted. > > The same duplicate suppression is needed for other AODVv2 messages. > For instance, when optional multicast RREP is used to enable selection > from among multiple possible return routes, similar measures need to > be taken. > > For this reason, the table is more generally called the AODVv2 > Duplicate Suppression Table; it is simply a list of the AODVv2 RREQ > and RREP messages which have been recently multicast, using > the above notion of message equivalence. More formally, two > AODVv2 RREQ messages are equivalent if: > - they were generated by the same AODVv2 router (RREQ_gen) > - RREQ_Gen assigned the same Sequence Number to its > routing information in the RREQs > - the RREQs are for the same desired destination address > An analogous definition applies for a RREP message, in case that > the RREP message would be multicast. > > Protocol handling of RERR messages eliminates the need for > tracking RERR messages, since the rules for retransmitting RERR > multicast messages prevent the phenomenon of message duplication > (that can affect RREQ and RREP retransmission). > > As a historical note, AODV and early versions of DYMO contained > a similar broadcast suppression mechanism. Prior to initiating the > conversion to RFC 5444 compliance, Ian and I had thought that the > underlying multicast optimization would do a better > job of duplicate suppression, and in a manner already integrated > with the underlying forwarding mechanisms. Thanks, Marius et al. > for triggering a re-examination of this issue which has needed > attention since the RFC 5444 compliance changes. > > On 12/13/2012 6:09 PM, Marius Portmann wrote: >> >> Hi Charlie, >> >> .................... >> >> >> (2) Route Reply Loss >> >> >> -------------------- >> >> >> AODV can lose route replies >> (http://www.ietf.org/mail-archive/web/manet/current/msg05702.html). >> >> >> The reason is that route replies are only forwarded by an >> >> >> intermediate node when the node updates its routing table. >> >> ................ > >> > The relevant point is that an AODVv2 router retransmits the RREQ or >> >> > RREP regardless of whether the AODVv2 router used the incoming >> >> > routing information to update its route table. >> >> > >> >> > I thought there might be some wording to the contrary, but after >> >> > reading the relevant parts of the specification several times I >> >> > haven't found any such wording. Please let me know what I have missed. >> >> Our analysis was based on DYMO/AODVv2 version 23. It now appears that >> in version 24, the specification has changed such that it is similar >> to what we are proposing, i.e. to let the AODVv2 routers always >> forward the RREQ/RREP messages. >> >> All the best, >> >> Rob, Peter, Marius and Wee Lum >> >> > > -- > Regards, > Charlie P. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Regards, Charlie P. --------------000302090205080804010702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello again folks,

During the process of writing down the specification for duplicate
suppression, various technical points became much more clear.
Consequently, the proposed mechanics of duplicate suppression
that I sent out yesterday requires some modification.

First, while it is true that suppressing message retransmission
has in the past been motivated mostly by broadcast RREQ, the
actual phenomenon applies equally well to unicast RREQ and
unicast RREP.  For example, if a target router receives RREQ and
would respond with RREP, then it must first check to see whether
the routing information in the RREP is more useful than from
a previous RREP sent in response to a comparable incoming RREQ.

Second, I reviewed the proposed concept of RteMsg "equivalence",
and it is far too fragile.  There are several worthy variations of
"message equivalence" that deserve consideration.  It turns out
that the algorithm can be expressed quite well with the much
weaker notion of "comparable" messages.  Two RREQ or RREP
messages are "comparable" if:
- they were generated by the same router, and
- they have the same OrigNode and TargNode addresses.
The algorithm proceeds by comparing a candidate outgoing
message "comparable" to previous messages to see whether
the candidate outgoing message should be "suppressed".

Third, the table of previously transmitted messages (renamed
to be "AODVv2 Transmitted RteMsg Table" -- or, simply "RteMsg
Table) is maintained so that no two entries are comparable.
This is easier than trying to compare a candidate outgoing
RREQ or RREP message against all comparable messages in
the RteMsg table -- if there were to be more than one such
comparable RteMsg table entry.

In the above, it's hard to know whether a message is a
"duplicate" without relying on a notion of "equivalence".
For that reason, the algorithm should no longer be called
"duplicate suppression".  I have renamed it to be "useless
message suppression".  It is, however, quite similar to the
duplicate broadcast suppression used long ago, but lost
during the transition to enable use of more general multicast
transmission infrastructures (and RFC 5444).

I am sure this is will all be clearer when I am able to exhibit
the text for the above data structure and algorithm in the
natural settings of the revised draft.


On 12/30/2012 2:40 PM, Charles E. Perkins wrote:
Hello folks,

As noted by Marius Portmann et al., there are some subtleties about
using sequence numbers to inhibit dissemination of possibly
outdated RREQ and RREP messages.  After reconsidering this
matter for the last couple of weeks, I realized that the existing
specification does not properly handle suppression of duplicate
multicast messages.  In order to accomplish that, while still
not suppressing earlier multicast messages that do need to be
transmitted, a list of previously retransmitted multicast AODVv2
routing messages needs to be maintained, as suggested by Marius.

Here is some proposed text for that purpose:

Two incoming RREQ messages should be considered the "same" if
they have the same Sequence Number and were generated by the same
AODVv2 router.  Using that notion of equivalence, when RREQ messages
are multicast in a MANET, a node may well receive the same RREQ from
more than one of its neighbors.  Such duplicated RREQs SHOULD NOT
be retransmitted; otherwise, a great deal of unnecessary signaling
traffic is likely to be generated in the network as multicast RREQs
are retransmitted over and over again with practically no additional
benefit.

To avoid unnecessary retransmission of duplicate RREQ messages,
while still enabling the proper handling of earlier RREQ messages
that may have somehow been delayed in the network, it is needed
for each AODVv2 router to keep a list of the RREQ messages which
it has recently retransmitted.

The same duplicate suppression is needed for other AODVv2 messages.
For instance, when optional multicast RREP is used to enable selection
from among multiple possible return routes, similar measures need to
be taken.

For this reason, the table is more generally called the AODVv2
Duplicate Suppression Table; it is simply a list of the AODVv2 RREQ
and RREP messages which have been recently multicast, using
the above notion of message equivalence.  More formally, two
AODVv2 RREQ messages are equivalent if:
- they were generated by the same AODVv2 router (RREQ_gen)
- RREQ_Gen assigned the same Sequence Number to its
  routing information in the RREQs
- the RREQs are for the same desired destination address
An analogous definition applies for a RREP message, in case that
the RREP message would be multicast.

Protocol handling of RERR messages eliminates the need for
tracking RERR messages, since the rules for retransmitting RERR
multicast messages prevent the phenomenon of message duplication
(that can affect RREQ and RREP retransmission).

As a historical note, AODV and early versions of DYMO contained
a similar broadcast suppression mechanism.  Prior to initiating the
conversion to RFC 5444 compliance, Ian and I had thought that the
underlying multicast optimization <via SMF> would do a better
job of duplicate suppression, and in a manner already integrated
with the underlying forwarding mechanisms.  Thanks, Marius et al.
for triggering a re-examination of this issue which has needed
attention since the RFC 5444 compliance changes.

On 12/13/2012 6:09 PM, Marius Portmann wrote:

Hi Charlie,

 

....................

>> (2) Route Reply Loss

>> --------------------

>> AODV can lose route replies (http://www.ietf.org/mail-archive/web/manet/current/msg05702.html).

>> The reason is that route replies are only forwarded by an

>> intermediate node when the node updates its routing table.

 

................

> The relevant point is that an AODVv2 router retransmits the RREQ or

> RREP regardless of whether the AODVv2 router used the incoming

> routing information to update its route table.

>

> I thought there might be some wording to the contrary, but after

> reading the relevant parts of the specification several times I

> haven't found any such wording.  Please let me know what I have missed.

 

Our analysis was based on DYMO/AODVv2 version 23. It now appears that in version 24, the specification has changed such that it is similar to what we are proposing, i.e. to let the AODVv2 routers always forward the RREQ/RREP messages.

 

All the best,

Rob, Peter, Marius and Wee Lum

 


-- 
Regards,
Charlie P.


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



-- 
Regards,
Charlie P.
--------------000302090205080804010702--

= Hi Charlie,

 

>> (1) Non-Optimal Routes

>> ----------------------

>> On-demand/reactive routing proto= cols (such as AODV, DYMO and

>> LOADng) often fails to discover = the best (shortest) routes [1,2].

 

> This is certainly true. ... However,= the nodes which establish

> non-optimal routes to the source are= also unlikely to use those

> routes.

 

Of course it is quite possible that these= 'indirectly discovered' non-optimal routes will never or rarely be used.

However, as far as we understand, DYMO/AO= DVv2 supports the option of 'path accumulation' (as it used to be called), =  where nodes can include 'AddedNode routing information' discovered indirectly, i.e. not via the source or destination= of a route discover process. Assuming the 'path accumulation' feature is b= eneficial, and nodes will use this 'indirectly discovered' routing informat= ion, we think it is likely that non-optimal routes will be used as a consequence.=

 

>> As a possible solution, we propo= se that route requests are always

>> forwarded, even by nodes generat= ing a route reply [2,3]. The

>> forwarded request should include= a flag stating that a reply has

>> already been initiated. In [3] i= t is shown that this increases the

>> quality of routes. Of course thi= s could increase the overhead of

>> control messages, but in most of= the cases the additional overhead

>> is minimal, since a request floo= ds the entire network anyway.

 

> This can be made into an optional be= havior, controllable either by a

> system-wide configuration parameter,= or a new RREQ option.  I would

> not expect that it should be the def= ault behavior.

 

This is obviously a trade off between the= cost and the benefit of this mechanism.

We believe that overhead is small enough = for it to be considered as a default option.

Unfortunately, we don’t have any qu= antitative results to back this up at the moment.<= /p>

 

>> (2) Route Reply Loss<= /span>

>> --------------------<= /span>

>> AODV can lose route replies (h= ttp://www.ietf.org/mail-archive/web/manet/current/msg05702.html).

>> The reason is that route replies= are only forwarded by an

>> intermediate node when the node = updates its routing table.

 

> I guess you mean that the two RREPs = under discussion were going

> towards two distinct Originating Nod= es.  Otherwise, it would be good

> for the older RREP to be dropped.

 

Yes, indeed.

 

> The relevant point is that an AODVv2= router retransmits the RREQ or

> RREP regardless of whether the AODVv= 2 router used the incoming

> routing information to update its ro= ute table.

>

> I thought there might be some wordin= g to the contrary, but after

> reading the relevant parts of the sp= ecification several times I

> haven't found any such wording. = ; Please let me know what I have missed.

 

Our analysis was based on DYMO/AODVv2 ver= sion 23. It now appears that in version 24, the specification has changed s= uch that it is similar to what we are proposing, i.e. to let the AODVv2 routers always forward the RREQ/RREP messages.=

 

All the best,

Rob, Peter, Marius and Wee Lum=

=  

=  

= From: Charles E. Perkins [mailto:charliep@computer.org]
Sent: Thursday, 6 December 2= 012 5:34 AM
To: Marius Portmann
Cc: 'manet@ietf.org'
Subject: Re: [manet] DYMO/AO= DVv2 and LOADng -- Problems and Proposed Solutions=

 


Hello again Marius,

I have been looking for the protocol error, and up until now have not
found it.  I probably should have looked closer before sending my
reply to you yesterday.   Here is a summary of the relevant proto= col
details that affect processing (and, retransmission) of RREQ and RREP
messages.

- Check that the RREQ or RREP is "valid"
- Test all the routing information and use when permissible
- Update certain fields of the incoming message
- Decide whether to advertise availability for forwarding
- If so, retransmit (or, consume the RREQ and transmit RREP)

The relevant point is that an AODVv2 router retransmits the
RREQ or RREP regardless of whether the AODVv2 router used
the incoming routing information to update its route table.

I thought there might be some wording to the contrary, but after
reading the relevant parts of the specification several times I haven't
found any such wording.  Please let me know what I have missed.

Otherwise, since the AODVv2 routers typically do retransmit
route discovery messages even when not using the routing
information contained by those route discovery messages, I think
the problem you identified for earlier protocols does not arise.

Regards,
Charlie P.


On 12/4/2012 10:25 AM, Charles E. Perkins wrote:


Hello Marius,

Interesting results.  I have some follow-up questions.

On 12/3/2012 9:21 PM, Marius Portmann wrote:

 

(1) Non-Optimal Routes

--------------------------------<= /span>

On-demand/reactive routing protocols (such a= s AODV, DYMO and LOADng) often fail to discover the best (shortes= t) routes [1,2].


This is certainly true.  There have been measurements = about how far from optimal
the routes can be, and if I remember correctly it's typically somewhere in = the
neighborhood of 10%, depending on congestion and node mobility.


 

The problem is that during route discovery t= he destination (target) node does not forward route requests; so, = ;nodes that lie downstream of the destination node frequently create non-optimal routes to the source. Knightly and Miskovic [1] ha= ve shown that "poorly selected paths can have significantly highe= r routing-metric costs, and their duration can extend to minute time scales= ". 

We have verified that this problem exists in= DYMO and LOADng.


Moreover, the result makes intuitive sense.  However, = the nodes which establish
non-optimal routes to the source are also unlikely to use those routes.


 

As a possible solution, we propose that rout= e requests are always forwarded, even by nodes generating a route reply [2,= 3]. The forwarded request should include a flag stating that a reply has already been initiated. In [3] it is shown t= hat this increases the quality of routes. Of course this could increas= e the overhead of control messages, but in most of the cases the addit= ional overhead is minimal, since a request floods the entire network anyway.


This can be made into an optional behavior, controllable ei= ther by a
system-wide configuration parameter, or a new RREQ option.  I would not expect that it should be the default behavior.



(2) Route Reply Loss

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

AODV can lose route replies (http://www.ie= tf.org/mail-archive/web/manet/current/msg05702.html). <= /span>

The reason is that route replies are on= ly forwarded by an intermediate node when the node updates its routing= table. 

This problem has partly been solved in DYMO = and LOADng by increasing sequence numbers when initiating a route reply.

However, a careful analysis shows that repli= es can still be lost; yielding again non-optimal routes or route discovery = failures. Namely, if one route reply overtakes another, i.e., a newer reply reaches a node earlier than an older one, the= n the older route reply is dropped [4].


I guess you mean that the two RREPs under discussion were g= oing towards
two distinct Originating Nodes.  Otherwise, it would be good for the o= lder RREP
to be dropped.

For the case of two distinct Originating Nodes, the behavior is a protocol<= br> error that needs to be fixed.  "Always forwarding" RREPs is = one alternative,
and certainly preferable to a new Route Discovery cycle in the network.
I am confident that there is a better solution, and I will work on finding<= br> and specifying it.


 

(3) Route Request Loss

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

Similar to (2), route requests might be= lost in DYMO and LOADng.

Namely, if one route request overtakes anoth= er, i.e., a newer request reaches a node earlier than an older one, then th= e older route request is dropped.

This problem does not occur in AODV, thanks = to the use of a list of previously seen RREQ IDs.<= /p>


I think that a "better" solution for (2) will als= o resolve this problem.
Here, the solution of "always forwarding" seems much less palatab= le.

Thanks much for reporting these error cases, and for providing the
references.


-- 
Regards,
Charlie P.




-- 
Regards,
Charlie P.