From kathir_cec@rediffmail.com  Sun Aug  2 21:10:18 2009
Return-Path: <kathir_cec@rediffmail.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8ABE3A688F for <manet@core3.amsl.com>; Sun,  2 Aug 2009 21:10:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.267
X-Spam-Level: ***
X-Spam-Status: No, score=3.267 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MSGID_FROM_MTA_HEADER=0.803, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rm-Attmod0Q1 for <manet@core3.amsl.com>; Sun,  2 Aug 2009 21:10:17 -0700 (PDT)
Received: from rediffmail.com (f4mail-234-231.rediffmail.com [202.137.234.231]) by core3.amsl.com (Postfix) with SMTP id 358023A6868 for <manet@ietf.org>; Sun,  2 Aug 2009 21:10:16 -0700 (PDT)
Received: (qmail 55359 invoked by uid 510); 3 Aug 2009 04:08:09 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=v1zoXwuNPUTEQ4QBFOqwk01SgSgQp0rFdgASFpixSQ5SJDEOA6ibHTrGxWszW8bkBqhYyEdVhnUV54wC9Cma6J/+F9G3nVwupPQIdgvvNxxn7JbTncFGWqsAPfzxGEr/Eq6Et/SN+DFTbXpJFP4drbmOFmkTsbkNco33pZVF6Wk= ; 
X-CNFS-Analysis: score=0 v=1.0 c=1 a=-CdFbzBBmnYA:10 a=KdWpPuvJASjKg9mIw8GYSA==:17 a=gGlOo44wWz5LNH9Rd7MA:9 a=35KCUZ8Qtb0JzL4W6oA4RmhGQmsA:4 a=6SwCy3u5AAAA:8 a=K57tCgj2AAAA:8 a=ZZrnJcLN9nDp6fqlXN4A:7
Date: 3 Aug 2009 04:08:09 -0000
Message-ID: <20090803040809.55355.qmail@f4mail-234-231.rediffmail.com>
MIME-Version: 1.0
To: <manet@ietf.org>
Received: from unknown 218.248.26.130 by rediffmail.com via HTTP; 03 Aug 2009 04:08:09 -0000
From: "kathirvel" <kathir_cec@rediffmail.com>
Content-Type: multipart/alternative; boundary="=_24f1722968d26cab7738f06955b461f8"
X-Mailman-Approved-At: Mon, 03 Aug 2009 10:44:26 -0700
Cc: ayyakathir@rediffmail.com
Subject: [manet] [MANET] watchdog and pathrater have lot of weakness
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2009 04:10:18 -0000

--=_24f1722968d26cab7738f06955b461f8
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="ISO-8859-1"

Dear IETF group,

     In the watchdog and pathrater have lot of weakness. The weakness are 1. ambiguous collisions
2. Receiver collisions
3. Limited tranmission power
4. false misbehaviour
5. collusion
6. partial dropping
7. re-entrance of malicious node

Whereas it was implemented on top of the DSR routing protocols. Is this problem is because of the extension of the DSR routing protocols !.

If any one known please answer the question.

kathir
--=_24f1722968d26cab7738f06955b461f8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="ISO-8859-1"

Dear IETF group,<br />
<br />
     In the watchdog and pathrater have lot of weakness. The weakness are 1=
. ambiguous collisions<br />
2. Receiver collisions<br />
3. Limited tranmission power<br />
4. false misbehaviour<br />
5. collusion<br />
6. partial dropping<br />
7. re-entrance of malicious node<br />
<br />
Whereas it was implemented on top of the DSR routing protocols. Is this pro=
blem is because of the extension of the DSR routing protocols !.<br />
<br />
If any one known please answer the question.<br />
<br />
kathir<br><Table border=3D0 Width=3D644 Height=3D57 cellspacing=3D0 cellpad=
ding=3D0 style=3D"font-family:Verdana;font-size:11px;line-height:15px;"><TR=
><td><A HREF=3D"http://sigads.rediff.com/RealMedia/ads/click_nx.ads/www.red=
iffmail.com/signatureline.htm@Middle?" target=3D"_blank"><IMG SRC=3D"http:/=
/sigads.rediff.com/RealMedia/ads/adstream_nx.ads/www.rediffmail.com/signatu=
reline.htm@Middle"></A></td></TR></Table>
--=_24f1722968d26cab7738f06955b461f8--

From ian.chakeres@gmail.com  Sat Aug  8 06:04:58 2009
Return-Path: <ian.chakeres@gmail.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26EA83A6925 for <manet@core3.amsl.com>; Sat,  8 Aug 2009 06:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xexVTSRPc9Zm for <manet@core3.amsl.com>; Sat,  8 Aug 2009 06:04:57 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 8316F3A68D7 for <manet@ietf.org>; Sat,  8 Aug 2009 06:04:57 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id f9so557263rvb.49 for <manet@ietf.org>; Sat, 08 Aug 2009 06:04:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date:cc :x-mailer; bh=UcWWFY1kMTlIyDVF5mqxWFrEmcvw0DrTVgsmZ1MrAsY=; b=FbEkAo0mYe23uzbEiDsDm2tIefHlA2CK3uWLYxTNE292MRWN7aNilGRXA5et8+DjLM heR3OpuOGyqMjQMlv7Z+Ye8HWs0qrUoMFur0CR0UyqEhD7ugVBeSwS9gJ+q1Szshj4Wj RnWLY5hh9YI0t8GI8R2iU2vAh1bcKsSV8wHBI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:cc:x-mailer; b=sfjglkkUj2cCaKusSyV4RKOFfrolRRaaDcqolSJIzLerHbWT2lYyyNwqhkv/Q6w3/E +Ge0PkDpxR4BaP8Ttbpk2oMTFv6ML4gapnMccOVolmpqYXQuHdnzYlZLpytfOymT+cEh sS1UtWKBzOxwtVmM9JN1p3kdW+NWsBi3zqGa0=
Received: by 10.140.162.3 with SMTP id k3mr961275rve.3.1249736699063; Sat, 08 Aug 2009 06:04:59 -0700 (PDT)
Received: from ?192.168.1.3? (108.sub-70-211-171.myvzw.com [70.211.171.108]) by mx.google.com with ESMTPS id k37sm9988942rvb.2.2009.08.08.06.04.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 08 Aug 2009 06:04:57 -0700 (PDT)
Message-Id: <9BE4A11A-7DA3-4093-9A7A-B11C092DBF7D@gmail.com>
From: Ian Chakeres <ian.chakeres@gmail.com>
To: MANET IETF <manet@ietf.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Sat, 8 Aug 2009 09:04:39 -0400
X-Mailer: Apple Mail (2.935.3)
Subject: [manet] draft-ietf-manet-smf-09.txt - WGLC
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Aug 2009 13:04:58 -0000

This note announces the WG Last Call for comments on draft-ietf-manet- 
smf-09.txt, "Simplified Multicast Forwarding".

The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-09.txt

The document is intended to be submitted for publication as an  
experimental standard document.

Please review the document carefully and send your comments to the  
MANET list and document authors.

This last call ends Sunday August 23.

Thanks,
Ian Chakeres

From Chris.Dearlove@baesystems.com  Mon Aug 10 09:07:35 2009
Return-Path: <Chris.Dearlove@baesystems.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE6363A6A15 for <manet@core3.amsl.com>; Mon, 10 Aug 2009 09:07:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level: 
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNZGg5CBfjMa for <manet@core3.amsl.com>; Mon, 10 Aug 2009 09:07:34 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 51A163A6D5F for <manet@ietf.org>; Mon, 10 Aug 2009 09:07:34 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.43,354,1246834800"; d="scan'208";a="16528266"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 10 Aug 2009 17:07:37 +0100
Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n7AG7bRN030830; Mon, 10 Aug 2009 17:07:38 +0100
Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 10 Aug 2009 17:07:36 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon, 10 Aug 2009 17:07:35 +0100
Message-ID: <ABE739C5ADAC9A41ACCC72DF366B719D02213679@GLKMS2100.GREENLNK.NET>
In-Reply-To: <9BE4A11A-7DA3-4093-9A7A-B11C092DBF7D@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [manet] draft-ietf-manet-smf-09.txt - WGLC
thread-index: AcoYKN/8wiLm0Y3kSUurXtPk0E6KngBqFJHQ
References: <9BE4A11A-7DA3-4093-9A7A-B11C092DBF7D@gmail.com>
From: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
To: "Ian Chakeres" <ian.chakeres@gmail.com>, "MANET IETF" <manet@ietf.org>
X-OriginalArrivalTime: 10 Aug 2009 16:07:36.0861 (UTC) FILETIME=[AD87F4D0:01CA19D4]
Cc: macker@itd.nrl.navy.mil
Subject: Re: [manet] draft-ietf-manet-smf-09.txt - WGLC
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2009 16:07:35 -0000

I haven't read every paragraph thoroughly, and I have still
to read the appendices (in this draft) but I thought I'd
send my initial comments.

The document is a (substantial) collection of mechanism, not
a single protocol, with limited interoperability of options.
I'm just going to note that and consider that as a design=
decision. I don't know whether the IESG may have comments on
this and related mattters.

References to RFC 2901 should be to RFC 2501.

Section 2.1 table would be better in alphabetical order.

Should section 3 note that e.g. IGMP can be used unchanged
(assuming that it can - if not, why not?).

Second (last) paragraph of section 3 is one place (there are
others, I think I may note another below) where there is a
reference to demonstrations etc. There are however no details,
ideally an external reference, or at least who did them (if
the authors, I guess a blanket comment to that effect might
work - or is this assumed?).

Section 4 I found the terminology of "SMF forwarder"
confusing. There are nodes (routers) participating in SMF.
At any given time a node may forward all (subject to DPD),
some or none of the packets it receives. I think this still
classifies the latter as an SMF forwarder, where my first
assumption was that they were excluded. I would suggest
"SMF participant".

Section 4, use of site-local address. As these are deprecated,
that's a hostage to IESG fortune.

TTL or hop limit (not count) in Section 4.

Section 4, six point list. Is point 4 in scope for an IETF
protocol?

Section 4 paragraph starting "Note that rule #3" doesn't
make the point that this mechanism avoids the need for a
node to keep a list of its own packets.

Section 5.1.1 "TBD". I would recomment keeping the TBDs
confined solely to the IANA section. I think that's usual
practice.

Section 5.1.3 I made a note of why MD5, and then read later.
Limiting to this section (the subject comes up again later)
my reaction was OK, but here you don't care about that MD5
is weak, but in the forwarding section you take some care
over changed TTLs.

Section 5.3 first paragraph. On my reading so far I don't
understandhow this works. Is it relying on a shared secret
(numerical or procedural) among nodes that an attacker is
assumed not to have? Maybe I need to read better, or maybe
needs some clarification.

Section 6 third paragraph is another case where whose
experiments etc. is a question. In the following 4 point
list Better probably should be better.

Section 7 I spotted an [MDA07] without a space before. Of
course this and other nits will get pciked up later, but
as I spotted it ...

Section 7.1.1 May I suggest Expert Review may suit your
purposes better than STD action, especially for an
Experimental protocol. We looked at all these issues
when finalising RFC 5444 and definitely preferred as
suggested. Expert Review needs criteris - but you can
reference or steal from RFC 5444.

Suggest in describing TLVs you explicitly note that when
a TLV (SMF_NBR_RELAY_ALG) doesn't need parameters you can
omit length/value to avoid this appearing to mandate them.

I would remove all uses of "packetbb". That was only the
working name of RFC 5444, which does not contain that name
at all, so packetbb has no referent. (In section 7 and
IANA section at least.)

Section 8.1 last sentence. My reaction is that by the time
you publish you should know if more work is needed or not.

Section 12 driect -> direct

References, you don't need "and et al" as et means and,
so et al will do.

As I noted, Appendices, not yet. And if I have time I may
go back over some points in what I've covered above. Or
may not.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

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 Ian Chakeres
Sent: 08 August 2009 14:05
To: MANET IETF
Subject: [manet] draft-ietf-manet-smf-09.txt - WGLC


                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.


This note announces the WG Last Call for comments on draft-ietf-manet- 
smf-09.txt, "Simplified Multicast Forwarding".

The document can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-09.txt

The document is intended to be submitted for publication as an  
experimental standard document.

Please review the document carefully and send your comments to the  
MANET list and document authors.

This last call ends Sunday August 23.

Thanks,
Ian Chakeres
_______________________________________________
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 joseph.macker@nrl.navy.mil  Mon Aug 10 10:02:14 2009
Return-Path: <joseph.macker@nrl.navy.mil>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8524728C19C for <manet@core3.amsl.com>; Mon, 10 Aug 2009 10:02:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZNt0TNMl0LD for <manet@core3.amsl.com>; Mon, 10 Aug 2009 10:02:13 -0700 (PDT)
Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 4D0CD28C18E for <manet@ietf.org>; Mon, 10 Aug 2009 10:02:13 -0700 (PDT)
Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id n7AH1eEj025807; Mon, 10 Aug 2009 13:01:40 -0400
Received: from [132.250.217.206] ([132.250.217.206]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009081013013831773 ; Mon, 10 Aug 2009 13:01:39 -0400
References: <9BE4A11A-7DA3-4093-9A7A-B11C092DBF7D@gmail.com> <ABE739C5ADAC9A41ACCC72DF366B719D02213679@GLKMS2100.GREENLNK.NET>
Message-Id: <4206B60F-26D7-4A6C-BE4E-149A7FB944C8@nrl.navy.mil>
From: "joseph.macker" <joseph.macker@nrl.navy.mil>
To: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
In-Reply-To: <ABE739C5ADAC9A41ACCC72DF366B719D02213679@GLKMS2100.GREENLNK.NET>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
X-Mailer: iPod Mail (7A341)
Mime-Version: 1.0 (iPod Mail 7A341)
Date: Mon, 10 Aug 2009 13:01:42 -0400
Cc: MANET IETF <manet@ietf.org>, "<macker@itd.nrl.navy.mil>" <macker@itd.nrl.navy.mil>
Subject: Re: [manet] draft-ietf-manet-smf-09.txt - WGLC
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2009 17:02:14 -0000

Chris good comments most to incorporate in revision some I will  
respond to in a day or so .. Traveling right Now

Sent from my iPod

On Aug 10, 2009, at 12:07 PM, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com 
 > wrote:

> I haven't read every paragraph thoroughly, and I have still
> to read the appendices (in this draft) but I thought I'd
> send my initial comments.
>
> The document is a (substantial) collection of mechanism, not
> a single protocol, with limited interoperability of options.
> I'm just going to note that and consider that as a design=
> decision. I don't know whether the IESG may have comments on
> this and related mattters.
>
> References to RFC 2901 should be to RFC 2501.
>
> Section 2.1 table would be better in alphabetical order.
>
> Should section 3 note that e.g. IGMP can be used unchanged
> (assuming that it can - if not, why not?).
>
> Second (last) paragraph of section 3 is one place (there are
> others, I think I may note another below) where there is a
> reference to demonstrations etc. There are however no details,
> ideally an external reference, or at least who did them (if
> the authors, I guess a blanket comment to that effect might
> work - or is this assumed?).
>
> Section 4 I found the terminology of "SMF forwarder"
> confusing. There are nodes (routers) participating in SMF.
> At any given time a node may forward all (subject to DPD),
> some or none of the packets it receives. I think this still
> classifies the latter as an SMF forwarder, where my first
> assumption was that they were excluded. I would suggest
> "SMF participant".
>
> Section 4, use of site-local address. As these are deprecated,
> that's a hostage to IESG fortune.
>
> TTL or hop limit (not count) in Section 4.
>
> Section 4, six point list. Is point 4 in scope for an IETF
> protocol?
>
> Section 4 paragraph starting "Note that rule #3" doesn't
> make the point that this mechanism avoids the need for a
> node to keep a list of its own packets.
>
> Section 5.1.1 "TBD". I would recomment keeping the TBDs
> confined solely to the IANA section. I think that's usual
> practice.
>
> Section 5.1.3 I made a note of why MD5, and then read later.
> Limiting to this section (the subject comes up again later)
> my reaction was OK, but here you don't care about that MD5
> is weak, but in the forwarding section you take some care
> over changed TTLs.
>
> Section 5.3 first paragraph. On my reading so far I don't
> understandhow this works. Is it relying on a shared secret
> (numerical or procedural) among nodes that an attacker is
> assumed not to have? Maybe I need to read better, or maybe
> needs some clarification.
>
> Section 6 third paragraph is another case where whose
> experiments etc. is a question. In the following 4 point
> list Better probably should be better.
>
> Section 7 I spotted an [MDA07] without a space before. Of
> course this and other nits will get pciked up later, but
> as I spotted it ...
>
> Section 7.1.1 May I suggest Expert Review may suit your
> purposes better than STD action, especially for an
> Experimental protocol. We looked at all these issues
> when finalising RFC 5444 and definitely preferred as
> suggested. Expert Review needs criteris - but you can
> reference or steal from RFC 5444.
>
> Suggest in describing TLVs you explicitly note that when
> a TLV (SMF_NBR_RELAY_ALG) doesn't need parameters you can
> omit length/value to avoid this appearing to mandate them.
>
> I would remove all uses of "packetbb". That was only the
> working name of RFC 5444, which does not contain that name
> at all, so packetbb has no referent. (In section 7 and
> IANA section at least.)
>
> Section 8.1 last sentence. My reaction is that by the time
> you publish you should know if more work is needed or not.
>
> Section 12 driect -> direct
>
> References, you don't need "and et al" as et means and,
> so et al will do.
>
> As I noted, Appendices, not yet. And if I have time I may
> go back over some points in what I've covered above. Or
> may not.
>
> -- 
> Christopher Dearlove
> Technology Leader, Communications Group
> Networks, Security and Information Systems Department
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194  Fax: +44 1245 242124
>
> 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 Ian Chakeres
> Sent: 08 August 2009 14:05
> To: MANET IETF
> Subject: [manet] draft-ietf-manet-smf-09.txt - WGLC
>
>
>                    *** WARNING ***
>
>  This message has originated outside your organisation,
>  either from an external partner or the Global Internet.
>      Keep this in mind if you answer this message.
>
>
> This note announces the WG Last Call for comments on draft-ietf-manet-
> smf-09.txt, "Simplified Multicast Forwarding".
>
> The document can be found at:
> http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-09.txt
>
> The document is intended to be submitted for publication as an
> experimental standard document.
>
> Please review the document carefully and send your comments to the
> MANET list and document authors.
>
> This last call ends Sunday August 23.
>
> Thanks,
> Ian Chakeres
> _______________________________________________
> 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 Aug 11 02:38:27 2009
Return-Path: <Chris.Dearlove@baesystems.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB63C3A6D68 for <manet@core3.amsl.com>; Tue, 11 Aug 2009 02:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level: 
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymXGDFxSKstv for <manet@core3.amsl.com>; Tue, 11 Aug 2009 02:38:26 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 979AB3A6FD0 for <manet@ietf.org>; Tue, 11 Aug 2009 02:38:26 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.43,359,1246834800"; d="scan'208";a="16628354"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 11 Aug 2009 10:38:30 +0100
Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n7B9cUdg016453 for <manet@ietf.org>; Tue, 11 Aug 2009 10:38:30 +0100
Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 11 Aug 2009 10:38:29 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue, 11 Aug 2009 10:38:28 +0100
Message-ID: <ABE739C5ADAC9A41ACCC72DF366B719D0224F35F@GLKMS2100.GREENLNK.NET>
In-Reply-To: <9BE4A11A-7DA3-4093-9A7A-B11C092DBF7D@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [manet] draft-ietf-manet-smf-09.txt - WGLC
thread-index: AcoYKN/8wiLm0Y3kSUurXtPk0E6KngCPfHVg
References: <9BE4A11A-7DA3-4093-9A7A-B11C092DBF7D@gmail.com>
From: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
To: "MANET IETF" <manet@ietf.org>
X-OriginalArrivalTime: 11 Aug 2009 09:38:29.0330 (UTC) FILETIME=[7BBB3320:01CA1A67]
Subject: Re: [manet] draft-ietf-manet-smf-09.txt - WGLC
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2009 09:38:27 -0000

One quick comment on Appendix B (which I have still only
skimmed). Most references are to [OLSRv2], which is correct
(but of course still a moving target). There are some
references to [RFC3626] that aren't clear why the change,
and at least one incorrect reference to [REFC3626] referring
to TLVs (that aren't in it, only in OLSRv2).

I suggest an initial reference to [OLSRv2], with a comment
that the MPR mechanism in it derives from [REFC3626] and
then using [OLSRv2] references thereafter.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

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 Ian Chakeres
Sent: 08 August 2009 14:05
To: MANET IETF
Subject: [manet] draft-ietf-manet-smf-09.txt - WGLC


                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.


This note announces the WG Last Call for comments on draft-ietf-manet- 
smf-09.txt, "Simplified Multicast Forwarding".

The document can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-09.txt

The document is intended to be submitted for publication as an  
experimental standard document.

Please review the document carefully and send your comments to the  
MANET list and document authors.

This last call ends Sunday August 23.

Thanks,
Ian Chakeres
_______________________________________________
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 tom5760@gmail.com  Fri Aug 14 14:01:23 2009
Return-Path: <tom5760@gmail.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0E33A68C5 for <manet@core3.amsl.com>; Fri, 14 Aug 2009 14:01:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.229
X-Spam-Level: 
X-Spam-Status: No, score=-0.229 tagged_above=-999 required=5 tests=[AWL=0.881,  BAYES_05=-1.11]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmBwNSnKzunU for <manet@core3.amsl.com>; Fri, 14 Aug 2009 14:01:22 -0700 (PDT)
Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by core3.amsl.com (Postfix) with ESMTP id 919383A63CB for <manet@ietf.org>; Fri, 14 Aug 2009 14:01:22 -0700 (PDT)
Received: by bwz2 with SMTP id 2so1311905bwz.43 for <manet@ietf.org>; Fri, 14 Aug 2009 14:00:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=LoEG4KaZrP62Q9wm4x/tTc3kIFMPVc6Sn576XSL09hw=; b=CRXglGlm95uDd/8dYfql0/VZq5CshR6gWKnrD7liYxVGDQXYc68yPNC18DZlIqWDfV yYVoQiIkX7I33mA2MgQJUTpwwWOeEm+eUnEa9eUZ2m0IAnoK9G3WCrRREP2hnHk33gIc RlIZ3tM/xoUq5sv3tEtVZdcDg6qR+uIEG9bkQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=nn+f5fQbsLMcn5EEsdyKZvk1or+XsrWjf7QIveraY4qiCbt9QkoU+1LW+VvdNqlVmc NE1jAkWL2XshGX+fdf18oj1HO+wVE2WVhp5EC0byXH0JX3nWVclY6LCarsmFYJYwdtYt JG3/UPINskd/u7IwJ+D07e+PONqvJcL39KSaU=
MIME-Version: 1.0
Received: by 10.204.34.205 with SMTP id m13mr1387924bkd.80.1250283651896; Fri,  14 Aug 2009 14:00:51 -0700 (PDT)
Date: Fri, 14 Aug 2009 17:00:51 -0400
Message-ID: <e246419f0908141400s78d6d2c0t78bc8fca656c338c@mail.gmail.com>
From: Tom Wambold <tom5760@gmail.com>
To: ns-develpers@isi.edu, manet@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sat, 15 Aug 2009 13:18:23 -0700
Subject: [manet] NS-3 RFC5444 (PacketBB) Implementation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Aug 2009 21:01:23 -0000

All:

I have just recently published a new PacketBB implementation for the
NS-3 Network Simulator as part of work at Drexel University and
University of Pennsylvania.

The implementation can be found in the Mercurial repository at [1].  The
source files are in src/contrib/packetbb.{cc,h}.  A thorough test can be
found at src/contrib/test-packetbb.cc

This library fully conforms to RFC5444 [2], and passes all
interoperability tests performed at the 2008 OLSR Interop [3].  Since
these example packets were based on an earlier PacketBB draft, a minor
change was needed to match the latest RFC.  Otherwise, this
implementation passes all of the tests found at [4].

We will be actively using this library to support our implementation of
NHDP and SMF.  These should be ready for release in a few weeks.
Hopefully, these could be merged into the main NS-3 distribution.

Since NS-3 has a full IP stack, with packets being fully serialized,
this implementation could potentially interoperate with other PacketBB
implementations when using NS-3 in emulation.  Also, this implementation
is fairly generic, so it could be ported to live systems without much
effort.

Please feel free to send me any questions/comments/etc. that you may
have as we are actively using and maintaining this library.

Thanks!
-Tom Wambold

[1] - http://code.nsnam.org/twambold/ns-3-dev-packetbb
[2] - http://tools.ietf.org/html/rfc5444
[3] - http://interop08.thomasclausen.org/packets-and-dumps.txt
[4] - http://code.nsnam.org/twambold/ns-3-dev-packetbb/file/tip/src/contrib/test-packetbb.cc

From joseph.macker@nrl.navy.mil  Fri Aug 21 10:25:41 2009
Return-Path: <joseph.macker@nrl.navy.mil>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A32B3A6B63 for <manet@core3.amsl.com>; Fri, 21 Aug 2009 10:25:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.575
X-Spam-Level: 
X-Spam-Status: No, score=-4.575 tagged_above=-999 required=5 tests=[AWL=-2.025, BAYES_50=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmN1Dt5-bt43 for <manet@core3.amsl.com>; Fri, 21 Aug 2009 10:25:40 -0700 (PDT)
Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id A9DD23A6B28 for <manet@ietf.org>; Fri, 21 Aug 2009 10:25:40 -0700 (PDT)
Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id n7LHPLUH010912 for <manet@ietf.org>; Fri, 21 Aug 2009 13:25:35 -0400
Received: (from sextant [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009082113252016196 for <manet@ietf.org>; Fri, 21 Aug 2009 13:25:20 -0400
From: "Joe Macker" <joseph.macker@nrl.navy.mil>
To: <manet@ietf.org>
Date: Fri, 21 Aug 2009 13:25:18 -0400
Message-ID: <007e01ca2284$5a5f8f80$0f1eae80$@macker@nrl.navy.mil>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
thread-index: AcoihFovYQ2hVAFtQXqFaKqvCc/CTw==
Content-Language: en-us
Subject: [manet] SMF WGLC alignment with NHDP
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Aug 2009 17:25:41 -0000

As editor of SMF, I realize we need to synchronize the submission and review of SMF with NHDP due to some normative dependencies
with NHDP in certain SMF modes of operation. 

We will need reconsider the SMF WGLC schedule once NHDP WGLC has been issued.

-joe




From ian.chakeres@gmail.com  Fri Aug 21 10:54:26 2009
Return-Path: <ian.chakeres@gmail.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6A63A6BA4 for <manet@core3.amsl.com>; Fri, 21 Aug 2009 10:54:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDdfXbeReRMI for <manet@core3.amsl.com>; Fri, 21 Aug 2009 10:54:25 -0700 (PDT)
Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 07B383A6B5A for <manet@ietf.org>; Fri, 21 Aug 2009 10:54:06 -0700 (PDT)
Received: by qw-out-2122.google.com with SMTP id 5so588236qwi.31 for <manet@ietf.org>; Fri, 21 Aug 2009 10:54:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=LyD2RYHEleRn1TMMrRgTzBGqo27iQy4U2U+vPzb3Bkc=; b=Ac8Ice3dn65moza95k4CXe5mhayxEfjqHlQlqi26Bx0Vs06L9U8IqduWnSvt+j6/0I HXzdW67qp/C+nOKAg47JE9rzeR95y4ACeY+T3bwougODggqURdzO08rkt7NXD0Jl8BAG IvlNos50G+geenrhi8E2YnKzJVxQk8JgcffXM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; b=YsktnYmaK4wnU/ZQAnv4KYGc7OYdCE/qM6Djl94cdiMeMogbisRHsFMjEOJYTE3VhM +Jf3K9E9zyXouJkKl/8bk+KJ6upPpSdJeXhv7cAOFuIHU1M20rl26ZpyHk8+h20ygbtT 3rCgrijqXzlEcWDw3+Rt0nwm/Zz2YRNecLt2o=
MIME-Version: 1.0
Received: by 10.229.15.203 with SMTP id l11mr344480qca.43.1250877249159; Fri,  21 Aug 2009 10:54:09 -0700 (PDT)
From: Ian Chakeres <ian.chakeres@gmail.com>
Date: Fri, 21 Aug 2009 13:53:49 -0400
Message-ID: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com>
To: MANET IETF <manet@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Aug 2009 17:54:26 -0000

During my recent review of NHDP I uncovered several concerns to the
current specification. That said, the most recent version is an
improvement on the prior version, and I really like the new
explanatory text with examples in the appendix.

I feel the existing NHDP spec is pretty well defined when running by
itself; I am more concerned when it is run more widely - with multiple
interfaces, multiple instances, multiple extensions, and multiple.

I've gone ahead and elaborated a little more on these items, and a few
more, below.

#1) I am concerned about running multiple protocols on-top of NHDP,
e.g. OLSRv2 SMF. My understanding is that each extension protocol
(that requires other nodes participate) must define its own TLVs and
tag each address that is participating. If this is our method for
doing extensions, let's make it explicit. Also, if OLSRv2 or SMF isn't
doing it right at the moment we should adjust them.

#2) I don't see how to run multiple NHDP instances on the same
interface or same router. PacketBB says that only one protocol
instance can accept a particular message. Currently there is no way to
identify which NHDP instance a NHDP message should be delivered.

#3) In the current spec there is no single identifier for a NHDP node;
instead a NHDP node is identified by the set of its IP addresses. I
really liked the new explanatory text and examples, but I still find
this complex - especially when there are multiple interfaces and
multiple hops. Can someone please explain to me why we don't use a
nhdp-node-id? Is this is related to relay set calculations.

#4) I don't see a way to identify a neighboring NHDP node's interface.
This is most important when multiple interfaces use the same IP
address (un-numbered interfaces).

#5) I would like text explaining why NHDP is such a complex HELLO
protocol, specifically that NHDP was build to assist in calculating
reduced relay sets (e.g. MPR, CDS). I think this stated purpose will
be helpful in explaining why certain information is included and the
overall design of the protocol.

#6) The spec explicitly identifies using multicast & broadcast, but it
does not mention using unicast for distribution of NHDP
messages/packets. I think we should be able to execute NHDP over
unicast transport too, although it might require more configuration.

I suspect some of my concerns may simply require further explanation
for me to ascertain the existing correctly specified behavior. If you
can shed light on any of the items above, please reply.

Thanks.
Ian Chakeres

From jdean@itd.nrl.navy.mil  Fri Aug 21 12:21:42 2009
Return-Path: <jdean@itd.nrl.navy.mil>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4776028C1F8 for <manet@core3.amsl.com>; Fri, 21 Aug 2009 12:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.669
X-Spam-Level: 
X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=0.930,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEKQQc7ft-CV for <manet@core3.amsl.com>; Fri, 21 Aug 2009 12:21:41 -0700 (PDT)
Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 7A9D228C27A for <manet@ietf.org>; Fri, 21 Aug 2009 12:19:11 -0700 (PDT)
Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id n7LJINsk018021; Fri, 21 Aug 2009 15:18:30 -0400
Received: (from bebe [132.250.93.61]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009082115183016790 ; Fri, 21 Aug 2009 15:18:30 -0400
From: "Justin Dean" <jdean@itd.nrl.navy.mil>
To: "'MANET IETF'" <manet@ietf.org>
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com>
In-Reply-To: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com>
Date: Fri, 21 Aug 2009 15:16:20 -0400
Message-ID: <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcoiiGWpXhlitUh1RBaJQGBqgAdxKQABYSAw
Content-Language: en-us
Cc: 'Christopher Dearlove' <chris.dearlove@baesystems.com>, 'Thomas Heide Clausen' <thomas@thomasclausen.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Aug 2009 19:21:42 -0000

While I would prefer to be addressing these issues within the scope of a
last call, my comments to the items in question are inline.

> -----Original Message-----
> From: Ian Chakeres [mailto:ian.chakeres@gmail.com]
> Sent: Friday, August 21, 2009 1:54 PM
> To: MANET IETF
> Cc: Joe P Macker; Thomas Heide Clausen; Christopher Dearlove; Justin
> Wendell Dean
> Subject: Some NHDP Concerns
> 
> During my recent review of NHDP I uncovered several concerns to the
> current specification. That said, the most recent version is an
> improvement on the prior version, and I really like the new
> explanatory text with examples in the appendix.
> 
> I feel the existing NHDP spec is pretty well defined when running by
> itself; I am more concerned when it is run more widely - with multiple
> interfaces, multiple instances, multiple extensions, and multiple.
> 
> I've gone ahead and elaborated a little more on these items, and a few
> more, below.
> 
> #1) I am concerned about running multiple protocols on-top of NHDP,
> e.g. OLSRv2 SMF. My understanding is that each extension protocol
> (that requires other nodes participate) must define its own TLVs and
> tag each address that is participating. If this is our method for
> doing extensions, let's make it explicit. Also, if OLSRv2 or SMF isn't
> doing it right at the moment we should adjust them.
> 
I would not be opposed to expanding and elaborating on some common issues
which protocols using NHDP would need to address.  On the other hand I would
not be for mandating specific protocol behaviors as this is clearly outside
of the scope of NHDP. 

> #2) I don't see how to run multiple NHDP instances on the same
> interface or same router. PacketBB says that only one protocol
> instance can accept a particular message. Currently there is no way to
> identify which NHDP instance a NHDP message should be delivered.
> 
Packetbb, RFC 5444, disallows this behavior.  Having more than one NHDP
instance on an interface will result in ambiguous behaviors.

> #3) In the current spec there is no single identifier for a NHDP node;
> instead a NHDP node is identified by the set of its IP addresses. I
> really liked the new explanatory text and examples, but I still find
> this complex - especially when there are multiple interfaces and
> multiple hops. Can someone please explain to me why we don't use a
> nhdp-node-id? Is this is related to relay set calculations.
>
A single identifier would seem to provide some functionality by logically
grouping addresses of nodes together.  I say seem because at the NHDP level
it doesn't really tell you anything as the addresses and interfaces they
represent might have differing functionality and although be co-located on
the same machine knowing this provides no extra benefit other than perhaps
network displays (they could not be used for CDS calculations as it isn't
know if all addresses provide the same functionality).  If the addresses all
have the same functionality then another TLV would have to be attached
indicating this thus providing redundant TLV messaging, SMF defines TLVs
which provide this behavior.  Having a single id would also increase
overhead (in the form of TLVS) in that all addresses would have to be
provided anyhow rather than just using a single id.  Furthermore things get
even more complicated when these identifier addresses change or disappear
but the underlying addressing does not.  Any protocol which would want this
type of functionality could easily provide it with a new TLV type which
would provide (in NHDP case) duel functionality indicating
co-location/protocol functionality.  IMO this is where the grouping of
addresses into one ID belongs using TLVs belongs in derived protocols.
 
> #4) I don't see a way to identify a neighboring NHDP node's interface.
> This is most important when multiple interfaces use the same IP
> address (un-numbered interfaces).
> 
I don't know anyone who deploys MANETs in this way but...if they were my
first question to them would be for what purpose are they the same?  Do they
need to be that way?  To me this seems like a very poorly configured MANET.
That being said here is a proposal for a solution to that "problem",
provided for discussion.

Introduction of an NHDP_AREA message level TLV which could de-conflict these
interfaces.
An optional TLV  which includes a value field which is administratively
configured.
Lack of this TLV would indicate a value of ONE or ZERO or whatever number is
decided upon.
Upon reception of an NHDP message the NHDP instance would ignore any NHDP
message which has a differing NHDP_AREA value other than itself.
The default mode of operation would be no TLV.

I am not currently convinced this is a good/bad idea just one which may
provide some extra functionality which some are looking for.

I also considered various schemes for using TLVs to "renumber" the
interfaces to de-conflict them.  I did not think of any satisfactory
solutions within routing layer scope which would not require extensive
changes to NHDP.  Using different physical or mac level distinguishers all
could work, although using the same address for multiple interfaces just
seems like a scenario ripe for being broken in one way or another.

> #5) I would like text explaining why NHDP is such a complex HELLO
> protocol, specifically that NHDP was build to assist in calculating
> reduced relay sets (e.g. MPR, CDS). I think this stated purpose will
> be helpful in explaining why certain information is included and the
> overall design of the protocol.
> 
While CDS calculation is one of the goals it is not the only usage/goal of
NHDP.  I am not against expanding rational but am wary of language which
would limit the potential usefulness of NHDP to other possible protocol
uses.

> #6) The spec explicitly identifies using multicast & broadcast, but it
> does not mention using unicast for distribution of NHDP
> messages/packets. I think we should be able to execute NHDP over
> unicast transport too, although it might require more configuration.
> 
While my co-authors may disagree I am not against allowing unicast (although
I don't see the use of it).  I prefer leaving it out but not specifically
disallowing the behavior either.

> I suspect some of my concerns may simply require further explanation
> for me to ascertain the existing correctly specified behavior. If you
> can shed light on any of the items above, please reply.
> 
> Thanks.
> Ian Chakeres

Justin



From philippe.jacquet@inria.fr  Sun Aug 23 13:06:39 2009
Return-Path: <philippe.jacquet@inria.fr>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1403A6AB0 for <manet@core3.amsl.com>; Sun, 23 Aug 2009 13:06:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWiYuCLWx71i for <manet@core3.amsl.com>; Sun, 23 Aug 2009 13:06:38 -0700 (PDT)
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 426863A69FD for <manet@ietf.org>; Sun, 23 Aug 2009 13:06:37 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,260,1249250400"; d="scan'208";a="34778327"
Received: from 240.64.204-77.rev.gaoland.net (HELO [192.168.1.21]) ([77.204.64.240]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 23 Aug 2009 22:06:41 +0200
Message-Id: <DF5C1E8C-8965-4EA1-B7EB-3DA4775CF357@inria.fr>
From: jacquet <philippe.jacquet@inria.fr>
To: Ian Chakeres <ian.chakeres@gmail.com>
In-Reply-To: <9BE4A11A-7DA3-4093-9A7A-B11C092DBF7D@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Sun, 23 Aug 2009 22:09:10 +0200
References: <9BE4A11A-7DA3-4093-9A7A-B11C092DBF7D@gmail.com>
X-Mailer: Apple Mail (2.935.3)
Cc: MANET IETF <manet@ietf.org>
Subject: Re: [manet] draft-ietf-manet-smf-09.txt - WGLC
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Aug 2009 20:06:39 -0000

Below are our comment from Pascale Minet and myself about  draft-ietf-=20=

manet-smf-09.txt

First, general comment: we second the suggestion that has already done =20=

by many that t NHDP draft should go to WGLC first, since it is an =20
important normative reference of draft-ietf-manet-smf-09.txt.

Second, detailed comments:

1. It is not clear how the I-DPD and the H-DPD methods can coexist in =20=

the same MANET deployment (section 5.2)

2. Could you please specify which type of multicast is supported, =20
depending on the two following criteria:
- The multicast source belongs to the MANET or not,
- Some destination nodes are within the MANET and other are outside,....

3. Concerning the group membership protocol, IGMP, it seems that there =20=

are some problems with this protocol when applied in a MANET. More =20
precisely, the elimination procedure between routers that hear each =20
other could prevent a host to receive multicast data as illustrated by =20=

the following example. Two routers R1 and R2 hear each other; =20
according to the elimination procedure, only router R1 will send =20
queries. There is a host H in the coverage area of R2, but not in the =20=

coverage area of R1. This host H will never send its report because it =20=

will never receive a query.

About the appendices.

4. E-CDS does not have a regular reference. Maybe you could use RFC =20
5614, or the paper of Wu Dai on rule k CDS.

5. CF SMF forwarder not defined.

6. Although the need is not necessarily obvious, maybe there should be =20=

some provision about the use of link metrics on relay set selection.

7. In E-CDS: the use of degree node as priority makes the highest =20
degree node very busy since it has to forward from many neighbors.

8. Step 8 in E-CDS selection: 1-hop neighbors of node x are not all =20
known by node n0. Maybe change it in "1-hop neighbors of node x that =20
are in N1 when x is in N2, and all 1-hop neighbors excluding n0 when x =20=

is in N1". It may be preferable to use the exact terminology of NHDP =20
database in order to remove possible confusion.

9. E-CDS selection: router ID and node priority of nodes in N2 should =20=

be known. This is not clear with NHDP databases, this would need that =20=

each node advertize the router ID and priority of all its neighbors  =20
on all its interface, this may be expensive. Maybe it would be less =20
burden to remove the possibility of populating Q with node in N2 (I =20
think it does not change the performance drastically) and restrict Q =20
to N1 nodes only.

10. E-CDS Extension to k-hop as claimed by the document is unclear.

11. Appendix B: S-MPR forwarding rule: notice that S-MPR will still =20
work if one allows forwarding from non symmetric neighbors. In this =20
case S-MPR nodes can be mixed with non SMF nodes that are not =20
performing NHDP, by considering those node as default relay selectors.

12. More general comment: S-MPR operations are described in a per =20
interface basis. Why it is not the case with E-CDS? If one interface =20
is slow, not reliable but long range, then  E-CDS may be limited to =20
the low performance of this interface. Same problem may apply to MPR-=20
CDS.

Best regards,
Pascale and Philippe


Le 8 ao=FBt 09 =E0 15:04, Ian Chakeres a =E9crit :

> This note announces the WG Last Call for comments on draft-ietf-=20
> manet-smf-09.txt, "Simplified Multicast Forwarding".
>
> The document can be found at: =
http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-09.txt
>
> The document is intended to be submitted for publication as an =20
> experimental standard document.
>
> Please review the document carefully and send your comments to the =20
> MANET list and document authors.
>
> This last call ends Sunday August 23.
>
> Thanks,
> Ian Chakeres
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>


From Chris.Dearlove@baesystems.com  Mon Aug 24 01:36:33 2009
Return-Path: <Chris.Dearlove@baesystems.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E943A69FA for <manet@core3.amsl.com>; Mon, 24 Aug 2009 01:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level: 
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOF+0DPpgImm for <manet@core3.amsl.com>; Mon, 24 Aug 2009 01:36:32 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 861D23A67F6 for <manet@ietf.org>; Mon, 24 Aug 2009 01:36:31 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,264,1249254000"; d="scan'208";a="18626094"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 24 Aug 2009 09:36:35 +0100
Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n7O8aatv027106; Mon, 24 Aug 2009 09:36:36 +0100
Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 24 Aug 2009 09:36:34 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 24 Aug 2009 09:36:31 +0100
Message-ID: <ABE739C5ADAC9A41ACCC72DF366B719D022C0B09@GLKMS2100.GREENLNK.NET>
In-Reply-To: <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Some NHDP Concerns
thread-index: AcoiiGWpXhlitUh1RBaJQGBqgAdxKQABYSAwAIHRWAA=
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com> <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil>
From: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
To: "Justin Dean" <jdean@itd.nrl.navy.mil>, "MANET IETF" <manet@ietf.org>
X-OriginalArrivalTime: 24 Aug 2009 08:36:34.0780 (UTC) FILETIME=[FD0E99C0:01CA2495]
Cc: Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Aug 2009 08:36:33 -0000

I will make some more specific comments later, but (unless I've
missed a subtlety below) I agree with Jstin's comments, that the 
resolution of all of these points (which are comments appropriate
to in WGLC, not to delay WGLC) is a mixture of a few odd sentences
to add, delegation to derived protocols (which is a reason for a
couple of the odd sentences) and don't do that. I have some specific
comments on what a delegated protocol might do, which varies (and
is a key reason for delegation).

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

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: Justin Dean [mailto:jdean@itd.nrl.navy.mil] 
Sent: 21 August 2009 20:16
To: 'MANET IETF'
Cc: 'Joe P Macker'; 'Thomas Heide Clausen'; Dearlove, Christopher (UK)
Subject: RE: Some NHDP Concerns


                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.


While I would prefer to be addressing these issues within the scope of a
last call, my comments to the items in question are inline.

> -----Original Message-----
> From: Ian Chakeres [mailto:ian.chakeres@gmail.com]
> Sent: Friday, August 21, 2009 1:54 PM
> To: MANET IETF
> Cc: Joe P Macker; Thomas Heide Clausen; Christopher Dearlove; Justin
> Wendell Dean
> Subject: Some NHDP Concerns
> 
> During my recent review of NHDP I uncovered several concerns to the
> current specification. That said, the most recent version is an
> improvement on the prior version, and I really like the new
> explanatory text with examples in the appendix.
> 
> I feel the existing NHDP spec is pretty well defined when running by
> itself; I am more concerned when it is run more widely - with multiple
> interfaces, multiple instances, multiple extensions, and multiple.
> 
> I've gone ahead and elaborated a little more on these items, and a few
> more, below.
> 
> #1) I am concerned about running multiple protocols on-top of NHDP,
> e.g. OLSRv2 SMF. My understanding is that each extension protocol
> (that requires other nodes participate) must define its own TLVs and
> tag each address that is participating. If this is our method for
> doing extensions, let's make it explicit. Also, if OLSRv2 or SMF isn't
> doing it right at the moment we should adjust them.
> 
I would not be opposed to expanding and elaborating on some common
issues
which protocols using NHDP would need to address.  On the other hand I
would
not be for mandating specific protocol behaviors as this is clearly
outside
of the scope of NHDP. 

> #2) I don't see how to run multiple NHDP instances on the same
> interface or same router. PacketBB says that only one protocol
> instance can accept a particular message. Currently there is no way to
> identify which NHDP instance a NHDP message should be delivered.
> 
Packetbb, RFC 5444, disallows this behavior.  Having more than one NHDP
instance on an interface will result in ambiguous behaviors.

> #3) In the current spec there is no single identifier for a NHDP node;
> instead a NHDP node is identified by the set of its IP addresses. I
> really liked the new explanatory text and examples, but I still find
> this complex - especially when there are multiple interfaces and
> multiple hops. Can someone please explain to me why we don't use a
> nhdp-node-id? Is this is related to relay set calculations.
>
A single identifier would seem to provide some functionality by
logically
grouping addresses of nodes together.  I say seem because at the NHDP
level
it doesn't really tell you anything as the addresses and interfaces they
represent might have differing functionality and although be co-located
on
the same machine knowing this provides no extra benefit other than
perhaps
network displays (they could not be used for CDS calculations as it
isn't
know if all addresses provide the same functionality).  If the addresses
all
have the same functionality then another TLV would have to be attached
indicating this thus providing redundant TLV messaging, SMF defines TLVs
which provide this behavior.  Having a single id would also increase
overhead (in the form of TLVS) in that all addresses would have to be
provided anyhow rather than just using a single id.  Furthermore things
get
even more complicated when these identifier addresses change or
disappear
but the underlying addressing does not.  Any protocol which would want
this
type of functionality could easily provide it with a new TLV type which
would provide (in NHDP case) duel functionality indicating
co-location/protocol functionality.  IMO this is where the grouping of
addresses into one ID belongs using TLVs belongs in derived protocols.
 
> #4) I don't see a way to identify a neighboring NHDP node's interface.
> This is most important when multiple interfaces use the same IP
> address (un-numbered interfaces).
> 
I don't know anyone who deploys MANETs in this way but...if they were my
first question to them would be for what purpose are they the same?  Do
they
need to be that way?  To me this seems like a very poorly configured
MANET.
That being said here is a proposal for a solution to that "problem",
provided for discussion.

Introduction of an NHDP_AREA message level TLV which could de-conflict
these
interfaces.
An optional TLV  which includes a value field which is administratively
configured.
Lack of this TLV would indicate a value of ONE or ZERO or whatever
number is
decided upon.
Upon reception of an NHDP message the NHDP instance would ignore any
NHDP
message which has a differing NHDP_AREA value other than itself.
The default mode of operation would be no TLV.

I am not currently convinced this is a good/bad idea just one which may
provide some extra functionality which some are looking for.

I also considered various schemes for using TLVs to "renumber" the
interfaces to de-conflict them.  I did not think of any satisfactory
solutions within routing layer scope which would not require extensive
changes to NHDP.  Using different physical or mac level distinguishers
all
could work, although using the same address for multiple interfaces just
seems like a scenario ripe for being broken in one way or another.

> #5) I would like text explaining why NHDP is such a complex HELLO
> protocol, specifically that NHDP was build to assist in calculating
> reduced relay sets (e.g. MPR, CDS). I think this stated purpose will
> be helpful in explaining why certain information is included and the
> overall design of the protocol.
> 
While CDS calculation is one of the goals it is not the only usage/goal
of
NHDP.  I am not against expanding rational but am wary of language which
would limit the potential usefulness of NHDP to other possible protocol
uses.

> #6) The spec explicitly identifies using multicast & broadcast, but it
> does not mention using unicast for distribution of NHDP
> messages/packets. I think we should be able to execute NHDP over
> unicast transport too, although it might require more configuration.
> 
While my co-authors may disagree I am not against allowing unicast
(although
I don't see the use of it).  I prefer leaving it out but not
specifically
disallowing the behavior either.

> I suspect some of my concerns may simply require further explanation
> for me to ascertain the existing correctly specified behavior. If you
> can shed light on any of the items above, please reply.
> 
> Thanks.
> Ian Chakeres

Justin




********************************************************************
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 Aug 24 07:43:39 2009
Return-Path: <Chris.Dearlove@baesystems.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD863A6DB5 for <manet@core3.amsl.com>; Mon, 24 Aug 2009 07:43:39 -0700 (PDT)
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.043,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHDi0XZrkeIQ for <manet@core3.amsl.com>; Mon, 24 Aug 2009 07:43:37 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id D9ED428C237 for <manet@ietf.org>; Mon, 24 Aug 2009 07:43:36 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,265,1249254000"; d="scan'208";a="18734829"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 24 Aug 2009 15:43:42 +0100
Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n7OEhiIS005698; Mon, 24 Aug 2009 15:43:44 +0100
Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 24 Aug 2009 15:43:42 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 24 Aug 2009 15:43:41 +0100
Message-ID: <ABE739C5ADAC9A41ACCC72DF366B719D02302901@GLKMS2100.GREENLNK.NET>
In-Reply-To: <ABE739C5ADAC9A41ACCC72DF366B719D022C0B09@GLKMS2100.GREENLNK.NET>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [manet] Some NHDP Concerns
thread-index: AcoiiGWpXhlitUh1RBaJQGBqgAdxKQABYSAwAIHRWAAAC6YAIA==
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com><000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil> <ABE739C5ADAC9A41ACCC72DF366B719D022C0B09@GLKMS2100.GREENLNK.NET>
From: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
To: "Justin Dean" <jdean@itd.nrl.navy.mil>, "MANET IETF" <manet@ietf.org>
X-OriginalArrivalTime: 24 Aug 2009 14:43:42.0328 (UTC) FILETIME=[467FAF80:01CA24C9]
Cc: Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Aug 2009 14:43:39 -0000

Sorry, top-posting is evil, but I'm doing it here. Please
disentangle to read properly. But of course the earlier
postings can be read as made in sequence.

I'll make one specific comment. SMF (and variations that it
could use) shows an example of why delegation to the derived
protocol (n various alternative use cases) is to be preferred.

One might think that all you need in SMF is a simple "I am an
SMF router" added to HELLO messages (message TLV). That both
doesn't work and almost works.

- It doesn't work because SMF is not a single protocol, but a
  familiy of protocols in flooding algorithm. (Also in DPD issues,
  but that's not important right now.) So the SMF message TLV
  needs a parameter for flooding algorithm.

- It almost works in that that message TLV is sufficient to
  ensure that flooding doesn't attempt to use an unsuitable
  router as an intermediate. (At least, I think that's the
  case. All such things need rigorously proving before we
  base a protocol on them.) But it doesn't work efficiently.
  If I have a neighbour A, and A has neighbours B, C, D, ...
  but none of the latter are (compatible) SMF routers, then
  with just a message TLV I may pick A as an MPR (for example)
  but actually I don't need to, and it would be more efficient
  not to do so. So SMF has a second TLV to mark addresses.

However with regard to the latter point, SMF for MPRs wants
that second TLV. SMF for blind flooding doesn't. That's all
information that NHDP doesn't know. In fact had a simple TLV
for NHDP been designed we might have missed the address block
TLV requirement. And if we defined both TLVs (as SMF does)
we might miss another case that some NHDP derivative needs.
Only the derived protocols know this stuff. And each derived
protocol is also where to make tradeoffs. For example here
is a simple modification to the SMF strategy that typically
saves octets - make the message TLV specify a default for
the address block TLV, thus saving the address block TLV
when all routers are using the same SMF variant. Is that
appropriate for SMF? We could debate this. Should some other
extension protocol make a different tradeoff? Quite possibly.

And there are more cases. One such is that if administratively
I know which other routers are sharing routing protocol with
me, as we should form a subnet, then I can filter on HELLO
sending addresses to separate uses. (I could filter either by
dropping HELLO messages I don't want, or I could filter by
putting everything into various protocol sets, but ignoring
Tuples with the "wrong" addresses. This is, in effect,
allowing different protocols to have different "views" of
NHDP's Information Bases.) Or I could filter at L2 - if you
don't have the right IDs and encryption keys you are out.
This may leave me able to simply ignore the whole issue of
alternative uses of NHDP, because in my closed world defined
by that ID/key there are no alternative uses of NHDP, so why
waste octets on excluding them?

(I would expect to cover the latter case to end up with the
derived protocol using SHOULD level mechanisms, possibly
backed up by a MUST do this or something administrative.
But we can debate that in due course.)

Incidentally I've done some work on something which basically
is unicast NHDP. And there are some significant issues,
including:

- Efficiency: If you have N neighbours, local broadcast NHDP's
  workload is fixed, unicast NHDP's workload scales as N does.

- Bootstrapping: Local broadcast is assumed to find other routers
  that could be neighbours (within range in a typical wireless
  system). But unicast won't do that for you. You need an alternative
  approach to deal with this.

- Theoretical timing issues, you can produce a race condition if you
  extend this to flooding by hop by hop unicast.

This all leads to that unicast NHDP is not a simple base protocol
variant, but rather needs someone who knows what they are doing
- which may involve an extension. Specifying the base protocol
using local broadcast/multicast and leaving open the avenue to a
unicast extension by not actually banning it is again the best
approach I strongly suggest.

Finally if you want a unique identifier, RFC 5444 provides the
message originator address to do that task. And the next version
of OLSRv2 will require message originator addresses in all cases
(but with a feature to avoid adding any overhead in the single
address router case). But some NHDP uses (e.g. SMF) don't require
it, and hence bandwidth efficiency suggests omitting from this
base specification.
=09

--=20
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

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 Dearlove, Christopher (UK)
Sent: 24 August 2009 09:37
To: Justin Dean; MANET IETF
Cc: Thomas Heide Clausen
Subject: Re: [manet] Some NHDP Concerns


                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet.=20
      Keep this in mind if you answer this message.


I will make some more specific comments later, but (unless I've
missed a subtlety below) I agree with Jstin's comments, that the=20
resolution of all of these points (which are comments appropriate
to in WGLC, not to delay WGLC) is a mixture of a few odd sentences
to add, delegation to derived protocols (which is a reason for a
couple of the odd sentences) and don't do that. I have some specific
comments on what a delegated protocol might do, which varies (and
is a key reason for delegation).

--=20
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

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: Justin Dean [mailto:jdean@itd.nrl.navy.mil]=20
Sent: 21 August 2009 20:16
To: 'MANET IETF'
Cc: 'Joe P Macker'; 'Thomas Heide Clausen'; Dearlove, Christopher (UK)
Subject: RE: Some NHDP Concerns


                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet.=20
      Keep this in mind if you answer this message.


While I would prefer to be addressing these issues within the scope of a
last call, my comments to the items in question are inline.

> -----Original Message-----
> From: Ian Chakeres [mailto:ian.chakeres@gmail.com]
> Sent: Friday, August 21, 2009 1:54 PM
> To: MANET IETF
> Cc: Joe P Macker; Thomas Heide Clausen; Christopher Dearlove; Justin
> Wendell Dean
> Subject: Some NHDP Concerns
>=20
> During my recent review of NHDP I uncovered several concerns to the
> current specification. That said, the most recent version is an
> improvement on the prior version, and I really like the new
> explanatory text with examples in the appendix.
>=20
> I feel the existing NHDP spec is pretty well defined when running by
> itself; I am more concerned when it is run more widely - with multiple
> interfaces, multiple instances, multiple extensions, and multiple.
>=20
> I've gone ahead and elaborated a little more on these items, and a few
> more, below.
>=20
> #1) I am concerned about running multiple protocols on-top of NHDP,
> e.g. OLSRv2 SMF. My understanding is that each extension protocol
> (that requires other nodes participate) must define its own TLVs and
> tag each address that is participating. If this is our method for
> doing extensions, let's make it explicit. Also, if OLSRv2 or SMF isn't
> doing it right at the moment we should adjust them.
>=20
I would not be opposed to expanding and elaborating on some common
issues
which protocols using NHDP would need to address.  On the other hand I
would
not be for mandating specific protocol behaviors as this is clearly
outside
of the scope of NHDP.=20

> #2) I don't see how to run multiple NHDP instances on the same
> interface or same router. PacketBB says that only one protocol
> instance can accept a particular message. Currently there is no way to
> identify which NHDP instance a NHDP message should be delivered.
>=20
Packetbb, RFC 5444, disallows this behavior.  Having more than one NHDP
instance on an interface will result in ambiguous behaviors.

> #3) In the current spec there is no single identifier for a NHDP node;
> instead a NHDP node is identified by the set of its IP addresses. I
> really liked the new explanatory text and examples, but I still find
> this complex - especially when there are multiple interfaces and
> multiple hops. Can someone please explain to me why we don't use a
> nhdp-node-id? Is this is related to relay set calculations.
>
A single identifier would seem to provide some functionality by
logically
grouping addresses of nodes together.  I say seem because at the NHDP
level
it doesn't really tell you anything as the addresses and interfaces they
represent might have differing functionality and although be co-located
on
the same machine knowing this provides no extra benefit other than
perhaps
network displays (they could not be used for CDS calculations as it
isn't
know if all addresses provide the same functionality).  If the addresses
all
have the same functionality then another TLV would have to be attached
indicating this thus providing redundant TLV messaging, SMF defines TLVs
which provide this behavior.  Having a single id would also increase
overhead (in the form of TLVS) in that all addresses would have to be
provided anyhow rather than just using a single id.  Furthermore things
get
even more complicated when these identifier addresses change or
disappear
but the underlying addressing does not.  Any protocol which would want
this
type of functionality could easily provide it with a new TLV type which
would provide (in NHDP case) duel functionality indicating
co-location/protocol functionality.  IMO this is where the grouping of
addresses into one ID belongs using TLVs belongs in derived protocols.
=20
> #4) I don't see a way to identify a neighboring NHDP node's interface.
> This is most important when multiple interfaces use the same IP
> address (un-numbered interfaces).
>=20
I don't know anyone who deploys MANETs in this way but...if they were my
first question to them would be for what purpose are they the same?  Do
they
need to be that way?  To me this seems like a very poorly configured
MANET.
That being said here is a proposal for a solution to that "problem",
provided for discussion.

Introduction of an NHDP_AREA message level TLV which could de-conflict
these
interfaces.
An optional TLV  which includes a value field which is administratively
configured.
Lack of this TLV would indicate a value of ONE or ZERO or whatever
number is
decided upon.
Upon reception of an NHDP message the NHDP instance would ignore any
NHDP
message which has a differing NHDP_AREA value other than itself.
The default mode of operation would be no TLV.

I am not currently convinced this is a good/bad idea just one which may
provide some extra functionality which some are looking for.

I also considered various schemes for using TLVs to "renumber" the
interfaces to de-conflict them.  I did not think of any satisfactory
solutions within routing layer scope which would not require extensive
changes to NHDP.  Using different physical or mac level distinguishers
all
could work, although using the same address for multiple interfaces just
seems like a scenario ripe for being broken in one way or another.

> #5) I would like text explaining why NHDP is such a complex HELLO
> protocol, specifically that NHDP was build to assist in calculating
> reduced relay sets (e.g. MPR, CDS). I think this stated purpose will
> be helpful in explaining why certain information is included and the
> overall design of the protocol.
>=20
While CDS calculation is one of the goals it is not the only usage/goal
of
NHDP.  I am not against expanding rational but am wary of language which
would limit the potential usefulness of NHDP to other possible protocol
uses.

> #6) The spec explicitly identifies using multicast & broadcast, but it
> does not mention using unicast for distribution of NHDP
> messages/packets. I think we should be able to execute NHDP over
> unicast transport too, although it might require more configuration.
>=20
While my co-authors may disagree I am not against allowing unicast
(although
I don't see the use of it).  I prefer leaving it out but not
specifically
disallowing the behavior either.

> I suspect some of my concerns may simply require further explanation
> for me to ascertain the existing correctly specified behavior. If you
> can shed light on any of the items above, please reply.
>=20
> Thanks.
> Ian Chakeres

Justin




********************************************************************
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 weianni@huawei.com  Thu Aug 27 04:05:08 2009
Return-Path: <weianni@huawei.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF6C53A6DD1 for <manet@core3.amsl.com>; Thu, 27 Aug 2009 04:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.357
X-Spam-Level: ****
X-Spam-Status: No, score=4.357 tagged_above=-999 required=5 tests=[AWL=1.859,  BAYES_20=-0.74, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, MIME_BASE64_TEXT=1.753]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4kZe4bjg5vW for <manet@core3.amsl.com>; Thu, 27 Aug 2009 04:05:08 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C51B33A6D42 for <manet@ietf.org>; Thu, 27 Aug 2009 04:05:07 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP100FE1842WA@szxga04-in.huawei.com> for manet@ietf.org; Thu, 27 Aug 2009 19:04:50 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP100C2N842E4@szxga04-in.huawei.com> for manet@ietf.org; Thu, 27 Aug 2009 19:04:50 +0800 (CST)
Received: from w00151475 ([10.111.16.57]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KP100ID1842V1@szxml04-in.huawei.com> for manet@ietf.org; Thu, 27 Aug 2009 19:04:50 +0800 (CST)
Date: Thu, 27 Aug 2009 19:04:49 +0800
From: Anni Wei <weianni@huawei.com>
To: manet@ietf.org
Message-id: <006001ca2706$3272ecc0$39106f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: multipart/alternative; boundary="Boundary_(ID_hiHVjaef9FVUTrIja3/j8w)"
X-Priority: 3
X-MSMail-priority: Normal
Subject: [manet] new draft:routing algorithm based on the flow sensing parameter
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2009 11:05:08 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_hiHVjaef9FVUTrIja3/j8w)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Dear MANET WG members,
I have submitted a new draft about routing algorithm based on the flow sensing parameter.

A URL for this Internet-Draft is:http://tools.ietf.org/html/draft-wei-manet-rafsp-00Comments and feedback are appreciated. With Best Regards Anni Wei   Huawei Technologies   Huawei Building, Xinxi Road No.3   Haidian District, Beijing  100085   P. R. China

--Boundary_(ID_hiHVjaef9FVUTrIja3/j8w)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w
MC4yOTAwLjM1NjIiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8
Qk9EWSBiZ0NvbG9yPSNjN2VkY2M+DQo8RElWPjxGT05UIHNpemU9Mj4NCjxESVY+DQo8RElWPjxG
T05UIHNpemU9Mj48Rk9OVCBzaXplPTQ+RGVhciBNQU5FVCBXRyBtZW1iZXJzLDwvRk9OVD48L0ZP
TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTPjxTUEFOIGxhbmc9
RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBGT05ULUZBTUlMWTogVmVyZGFuYTsgbXNv
LWZhcmVhc3QtZm9udC1mYW1pbHk6IMvOzOU7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28t
YmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1hbnNpLWxhbmd1YWdlOiBF
Ti1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVIt
U0EiPjxGT05UIA0KZmFjZT3LzszlIHNpemU9ND5JIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0
IGFib3V0IHJvdXRpbmcgYWxnb3JpdGhtIGJhc2VkIG9uIHRoZSANCmZsb3cgc2Vuc2luZyBwYXJh
bWV0ZXIuPC9GT05UPjwvU1BBTj48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl
PcvOzOUgc2l6ZT00PjxTUEFOIGxhbmc9RU4tVVM+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJG
T05ULVNJWkU6IDExcHQ7IEZPTlQtRkFNSUxZOiBWZXJkYW5hOyBtc28tZmFyZWFzdC1mb250LWZh
bWlseTogy87M5TsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5
OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFz
dC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PC9TUEFOPjwvU1BB
Tj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PEZPTlQgDQpzaXplPTI+PFBSRT48U1BBTiBsYW5nPUVOLVVT
PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6IFZl
cmRhbmE7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDLzszlOyBtc28tZm9udC1rZXJuaW5nOiAx
LjBwdDsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYW5zaS1s
YW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFu
Z3VhZ2U6IEFSLVNBIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IEZP
TlQtRkFNSUxZOiBWZXJkYW5hOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogy87M5TsgbXNvLWZv
bnQta2VybmluZzogMS4wcHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu
JzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047
IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgZmFjZT3LzszlIHNpemU9ND5BIFVSTCBm
b3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczo8QlI+PC9GT05UPjxBIGhyZWY9IiI+PEZPTlQgZmFj
ZT3LzszlIHNpemU9ND5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13ZWktbWFuZXQt
cmFmc3AtMDA8L0ZPTlQ+PC9BPjwvU1BBTj48L1NQQU4+PC9TUEFOPjwvUFJFPjxQUkU+PFNQQU4g
bGFuZz1FTi1VUz48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IEZPTlQt
RkFNSUxZOiBWZXJkYW5hOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogy87M5TsgbXNvLWZvbnQt
a2VybmluZzogMS4wcHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsg
bXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1z
by1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF
OiAxMXB0OyBGT05ULUZBTUlMWTogVmVyZGFuYTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IMvO
zOU7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVz
IE5ldyBSb21hbic7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3Vh
Z2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxQIGNsYXNzPU1zb05vcm1hbCBz
dHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1BTElHTjogbGVmdDsgbXNvLXBhZ2luYXRp
b246IHdpZG93LW9ycGhhbjsgdGFiLXN0b3BzOiA0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJw
dCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0
IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCIgYWxpZ249bGVmdD48L1NQ
QU4+PC9TUEFOPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9
IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IG1zby1mYXJlYXN0LWZvbnQt
ZmFtaWx5OiDLzszlOyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWJpZGktZm9udC1mYW1p
bHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJl
YXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48U1BBTiBsYW5n
PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IEZPTlQtRkFNSUxZOiBWZXJkYW5hOyBtc28t
ZmFyZWFzdC1mb250LWZhbWlseTogy87M5TsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1i
aWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVO
LVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1T
QSI+PEZPTlQgZmFjZT3LzszlIHNpemU9ND5Db21tZW50cyBhbmQgZmVlZGJhY2sgYXJlIGFwcHJl
Y2lhdGVkLjwvRk9OVD48L1NQQU4+PC9TUEFOPjwvU1BBTj48L1A+PC9QUkU+PFBSRT48U1BBTiBs
YW5nPUVOLVVTPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1G
QU1JTFk6IFZlcmRhbmE7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDLzszlOyBtc28tZm9udC1r
ZXJuaW5nOiAxLjBwdDsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBt
c28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNv
LWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6
IDExcHQ7IEZPTlQtRkFNSUxZOiBWZXJkYW5hOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogy87M
5TsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMg
TmV3IFJvbWFuJzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFn
ZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgZmFjZT3LzszlIHNpemU9
ND48L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L1NQQU4+Jm5ic3A7PC9QUkU+PFBSRT48U1BBTiBsYW5n
PUVOLVVTPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1J
TFk6IFZlcmRhbmE7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDLzszlOyBtc28tZm9udC1rZXJu
aW5nOiAxLjBwdDsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28t
YW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJp
ZGktbGFuZ3VhZ2U6IEFSLVNBIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEx
cHQ7IEZPTlQtRkFNSUxZOiBWZXJkYW5hOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogy87M5Tsg
bXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3
IFJvbWFuJzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog
WkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgZmFjZT3LzszlIHNpemU9ND5X
aXRoIEJlc3QgUmVnYXJkcyA8L0ZPTlQ+PC9QUkU+PFBSRT48Rk9OVCBmYWNlPcvOzOUgc2l6ZT00
PkFubmkgV2VpPEJSPiZuYnNwOyZuYnNwOyBIdWF3ZWkgVGVjaG5vbG9naWVzPEJSPiZuYnNwOyZu
YnNwOyBIdWF3ZWkgQnVpbGRpbmcsIFhpbnhpIFJvYWQgTm8uMzxCUj4mbmJzcDsmbmJzcDsgSGFp
ZGlhbiBEaXN0cmljdCwgQmVpamluZyZuYnNwOyAxMDAwODU8QlI+Jm5ic3A7Jm5ic3A7IFAuIFIu
IENoaW5hPC9GT05UPjwvUFJFPjwvU1BBTj48L1NQQU4+PC9TUEFOPjwvRk9OVD48L0RJVj48L0ZP
TlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg==

--Boundary_(ID_hiHVjaef9FVUTrIja3/j8w)--

From rogge@fgan.de  Thu Aug 27 06:36:37 2009
Return-Path: <rogge@fgan.de>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B5128C53C for <manet@core3.amsl.com>; Thu, 27 Aug 2009 06:36:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level: 
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2c8aAFpazfZe for <manet@core3.amsl.com>; Thu, 27 Aug 2009 06:36:36 -0700 (PDT)
Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 50E7B28C1EC for <manet@ietf.org>; Thu, 27 Aug 2009 06:36:36 -0700 (PDT)
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <rogge@fgan.de>) id 1Mgf9a-0006OE-5s; Thu, 27 Aug 2009 15:36:38 +0200
Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <rogge@fgan.de>) id 1Mgf9Z-0005TX-Sz; Thu, 27 Aug 2009 15:36:37 +0200
From: Henning Rogge <rogge@fgan.de>
To: manet@ietf.org
Date: Thu, 27 Aug 2009 15:36:35 +0200
User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; )
References: <006001ca2706$3272ecc0$39106f0a@china.huawei.com>
In-Reply-To: <006001ca2706$3272ecc0$39106f0a@china.huawei.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3739171.0utZrJhXIl"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200908271536.35369.rogge@fgan.de>
X-Virus-Scanned: yes (ClamAV 0.95.2/9746/Thu Aug 27 12:58:39 2009) by mailguard.fgan.de
X-Scan-Signature: ff96b43a3b0bdca915144ec1b58e50d3
Subject: Re: [manet] new draft:routing algorithm based on the flow sensing parameter
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2009 13:36:37 -0000

--nextPart3739171.0utZrJhXIl
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Thu August 27 2009 13:04:49 schrieb Anni Wei:
> Dear MANET WG members,
> I have submitted a new draft about routing algorithm based on the flow
> sensing parameter.
>
> A URL for this Internet-Draft
> is:http://tools.ietf.org/html/draft-wei-manet-rafsp-00Comments and feedba=
ck
> are appreciated. With Best Regards Anni Wei   Huawei Technologies   Huawei
> Building, Xinxi Road No.3   Haidian District, Beijing  100085   P. R. Chi=
na

I think the link should be
http://tools.ietf.org/id/draft-wei-manet-rafsp-00.txt

Henning Rogge

*************************************************
Diplom-Informatiker Henning Rogge
=46orschungsgesellschaft f=C3=BCr
Angewandte Naturwissenschaften e. V. (FGAN)=20
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
=46ax: 0049 (0)228 9435-685
E-Mail: rogge@fgan.de
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender=20
(Stellv.)


--nextPart3739171.0utZrJhXIl
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkqWi+MACgkQRIfGfFXsz+DYdQCdHAwOhwhFrswBGN+YSXSWD0Uo
MgYAn2aEJSXWriVJz4FR9p0hhcRuapWq
=/HyM
-----END PGP SIGNATURE-----

--nextPart3739171.0utZrJhXIl--

From ian.chakeres@gmail.com  Thu Aug 27 06:46:10 2009
Return-Path: <ian.chakeres@gmail.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BF9D3A6B46 for <manet@core3.amsl.com>; Thu, 27 Aug 2009 06:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEkdkhoWgk2Z for <manet@core3.amsl.com>; Thu, 27 Aug 2009 06:46:09 -0700 (PDT)
Received: from mail-qy0-f186.google.com (mail-qy0-f186.google.com [209.85.221.186]) by core3.amsl.com (Postfix) with ESMTP id 14D713A6880 for <manet@ietf.org>; Thu, 27 Aug 2009 06:46:08 -0700 (PDT)
Received: by qyk16 with SMTP id 16so593955qyk.20 for <manet@ietf.org>; Thu, 27 Aug 2009 06:46:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=481BOddwE1H5p+5P5A5w2PVylzPue45gfjjnEpjxjqg=; b=IqQj0Ta1MpnhCc0vtl577VjI/gjr7wumPrHcmh2Wg7l6MFfQwIFWY0zs/XjbPQxGhD wF0vL1obsoTXnjyS62eD5dmHQ+t3ifb0oaUKyOVwcWTXfpLHNDE+YnH2De4daAFQ9FpZ QBgHySF8MRkMuCmsoPpnErrsNQtCWeNtZLDc0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mmeQsNU6NsrZvC0izYwfG7aycjmO42ImV2DrpLyCHvXVVXZO94a9vEfNCC1Lbc7h+D N6LCHoqj4h19e0o7lHEkHMLxwMaLp8Sm84OrzSg7kXYJEjLcmdJ+hWZyEk2d4Cn/OAZR 4tGboms55igX52qnjEd103mSxJ2jDezEMYkXU=
MIME-Version: 1.0
Received: by 10.229.27.195 with SMTP id j3mr2814557qcc.57.1251380772124; Thu,  27 Aug 2009 06:46:12 -0700 (PDT)
In-Reply-To: <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil>
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com> <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil>
Date: Thu, 27 Aug 2009 09:46:12 -0400
Message-ID: <374005f30908270646xc962c8bhd0460759612c66f1@mail.gmail.com>
From: Ian Chakeres <ian.chakeres@gmail.com>
To: Justin Dean <jdean@itd.nrl.navy.mil>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, MANET IETF <manet@ietf.org>, Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2009 13:46:10 -0000

Comments inline

On Fri, Aug 21, 2009 at 3:16 PM, Justin Dean<jdean@itd.nrl.navy.mil> wrote:
> While I would prefer to be addressing these issues within the scope of a
> last call, my comments to the items in question are inline.
>
>> -----Original Message-----
>> From: Ian Chakeres [mailto:ian.chakeres@gmail.com]
>> Sent: Friday, August 21, 2009 1:54 PM
>> To: MANET IETF
>> Cc: Joe P Macker; Thomas Heide Clausen; Christopher Dearlove; Justin
>> Wendell Dean
>> Subject: Some NHDP Concerns
>>
>> During my recent review of NHDP I uncovered several concerns to the
>> current specification. That said, the most recent version is an
>> improvement on the prior version, and I really like the new
>> explanatory text with examples in the appendix.
>>
>> I feel the existing NHDP spec is pretty well defined when running by
>> itself; I am more concerned when it is run more widely - with multiple
>> interfaces, multiple instances, multiple extensions, and multiple.
>>
>> I've gone ahead and elaborated a little more on these items, and a few
>> more, below.
>>
>> #1) I am concerned about running multiple protocols on-top of NHDP,
>> e.g. OLSRv2 SMF. My understanding is that each extension protocol
>> (that requires other nodes participate) must define its own TLVs and
>> tag each address that is participating. If this is our method for
>> doing extensions, let's make it explicit. Also, if OLSRv2 or SMF isn't
>> doing it right at the moment we should adjust them.
>>
> I would not be opposed to expanding and elaborating on some common issues
> which protocols using NHDP would need to address. =A0On the other hand I =
would
> not be for mandating specific protocol behaviors as this is clearly outsi=
de
> of the scope of NHDP.

I think it is appropriate for NHDP to provide clear instructions for
extensions to NDHP. My example above which is true for both SMF &
OLSRv2 seems appropriate for inclusion. I suspect I may be unaware of
other important pieces of wisdom for NHDP extensions. If you are aware
let's please discuss them.


>> #2) I don't see how to run multiple NHDP instances on the same
>> interface or same router. PacketBB says that only one protocol
>> instance can accept a particular message. Currently there is no way to
>> identify which NHDP instance a NHDP message should be delivered.
>>
> Packetbb, RFC 5444, disallows this behavior. =A0Having more than one NHDP
> instance on an interface will result in ambiguous behaviors.

RFC 5444 does not disallow the behavior I described. It does disallow
having multiple NHDP instances receive the same message. Therefore,
there must be a way to determine the instance of NHDP to which a
message should be delivered.

>> #3) In the current spec there is no single identifier for a NHDP node;
>> instead a NHDP node is identified by the set of its IP addresses. I
>> really liked the new explanatory text and examples, but I still find
>> this complex - especially when there are multiple interfaces and
>> multiple hops. Can someone please explain to me why we don't use a
>> nhdp-node-id? Is this is related to relay set calculations.
>>
> A single identifier would seem to provide some functionality by logically
> grouping addresses of nodes together. =A0I say seem because at the NHDP l=
evel
> it doesn't really tell you anything as the addresses and interfaces they
> represent might have differing functionality and although be co-located o=
n
> the same machine knowing this provides no extra benefit other than perhap=
s
> network displays (they could not be used for CDS calculations as it isn't
> know if all addresses provide the same functionality). =A0If the addresse=
s all
> have the same functionality then another TLV would have to be attached
> indicating this thus providing redundant TLV messaging, SMF defines TLVs
> which provide this behavior. =A0Having a single id would also increase
> overhead (in the form of TLVS) in that all addresses would have to be
> provided anyhow rather than just using a single id. =A0Furthermore things=
 get
> even more complicated when these identifier addresses change or disappear
> but the underlying addressing does not. =A0Any protocol which would want =
this
> type of functionality could easily provide it with a new TLV type which
> would provide (in NHDP case) duel functionality indicating
> co-location/protocol functionality. =A0IMO this is where the grouping of
> addresses into one ID belongs using TLVs belongs in derived protocols.

I understand what you are saying, but I'm not sure I agree.

Here is one situation in which I think it would help to have single
identifier. Let's imagine that a NHDP node is going to sign its
messages - which identifier or set of identifiers would it use to
identify itself? Knowing that the other device may or may not have the
complete set of IP addresses associated with this particular NHDP
node.

I would actually feel more comfortable depending on a fixed NHDP
identifier, instead of an IP address which might be changed as you
pointed out.

>> #4) I don't see a way to identify a neighboring NHDP node's interface.
>> This is most important when multiple interfaces use the same IP
>> address (un-numbered interfaces).
>>
> I don't know anyone who deploys MANETs in this way but...if they were my
> first question to them would be for what purpose are they the same? =A0Do=
 they
> need to be that way? =A0To me this seems like a very poorly configured MA=
NET.
> That being said here is a proposal for a solution to that "problem",
> provided for discussion.

There are many cases when existing routers use unnumbered interfaces
presenting the same IP address/identifier on multiple interfaces. I
think this can make it easier to address and manage the router.

> Introduction of an NHDP_AREA message level TLV which could de-conflict th=
ese
> interfaces.
> An optional TLV =A0which includes a value field which is administratively
> configured.
> Lack of this TLV would indicate a value of ONE or ZERO or whatever number=
 is
> decided upon.
> Upon reception of an NHDP message the NHDP instance would ignore any NHDP
> message which has a differing NHDP_AREA value other than itself.
> The default mode of operation would be no TLV.
>
> I am not currently convinced this is a good/bad idea just one which may
> provide some extra functionality which some are looking for.
>
> I also considered various schemes for using TLVs to "renumber" the
> interfaces to de-conflict them. =A0I did not think of any satisfactory
> solutions within routing layer scope which would not require extensive
> changes to NHDP. =A0Using different physical or mac level distinguishers =
all
> could work, although using the same address for multiple interfaces just
> seems like a scenario ripe for being broken in one way or another.

I agree there are several different ways to solve this problem. I am
open to discussing several and deciding upon the most appropriate.


>> #5) I would like text explaining why NHDP is such a complex HELLO
>> protocol, specifically that NHDP was build to assist in calculating
>> reduced relay sets (e.g. MPR, CDS). I think this stated purpose will
>> be helpful in explaining why certain information is included and the
>> overall design of the protocol.
>>
> While CDS calculation is one of the goals it is not the only usage/goal o=
f
> NHDP. =A0I am not against expanding rational but am wary of language whic=
h
> would limit the potential usefulness of NHDP to other possible protocol
> uses.

I also would not like to limit the potential usefulness of NHDP.
Although, I do feel that the document appears overtly complex for the
basic functionality provided in the NHDP spec, and I think it is
important to explicitly call out and explain why certain complexity
was included to simplify NHDP extensions, e.g. OLSRv2 & SMF.

>> #6) The spec explicitly identifies using multicast & broadcast, but it
>> does not mention using unicast for distribution of NHDP
>> messages/packets. I think we should be able to execute NHDP over
>> unicast transport too, although it might require more configuration.
>>
> While my co-authors may disagree I am not against allowing unicast (altho=
ugh
> I don't see the use of it). =A0I prefer leaving it out but not specifical=
ly
> disallowing the behavior either.
>
>> I suspect some of my concerns may simply require further explanation
>> for me to ascertain the existing correctly specified behavior. If you
>> can shed light on any of the items above, please reply.
>>
>> Thanks.
>> Ian Chakeres
>
> Justin
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>

From ian.chakeres@gmail.com  Thu Aug 27 06:52:18 2009
Return-Path: <ian.chakeres@gmail.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B72D28C5B6 for <manet@core3.amsl.com>; Thu, 27 Aug 2009 06:52:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUiFnwrDCxqI for <manet@core3.amsl.com>; Thu, 27 Aug 2009 06:52:17 -0700 (PDT)
Received: from mail-qy0-f184.google.com (mail-qy0-f184.google.com [209.85.221.184]) by core3.amsl.com (Postfix) with ESMTP id 56C7A28C5A3 for <manet@ietf.org>; Thu, 27 Aug 2009 06:52:17 -0700 (PDT)
Received: by qyk14 with SMTP id 14so623984qyk.17 for <manet@ietf.org>; Thu, 27 Aug 2009 06:52:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ZczefhCrhQv7p4MODFXYwmQlbJutqQRqW7QTgpPbQ70=; b=h7pfAOh0uV9mWLg6B0GKR9BgRyPisSBL8IsphfTJLkQxnJCka3e5zBZnf0vraPlOSK gZMsjJJKGxxd7ASHD0k809KAjYesiIUWKWqHUcKJwwBp1PaNRvHk8o9q3GKJXaSst7lt xoM1DtZZwh4BJvBDXu/+XJXBKrDtnslMYOuPE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=NP1vsXvT7EaNvqdJpFtMYKSoKLb+SB30IMvIBVpAne3sbIOZmkgk4VB/Js8MY6l3m5 0FZz4IMQsaNBZsIG4XifbdUf0vuPvzGhijdDh23Xe7jMXPFnx3OcHfMJ1E1eu3SZp5K5 WCEj7SR8vr71pLf92gMOInubtRypkUMradfXI=
MIME-Version: 1.0
Received: by 10.229.37.130 with SMTP id x2mr2845367qcd.15.1251381141086; Thu,  27 Aug 2009 06:52:21 -0700 (PDT)
In-Reply-To: <ABE739C5ADAC9A41ACCC72DF366B719D02302901@GLKMS2100.GREENLNK.NET>
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com>  <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil> <ABE739C5ADAC9A41ACCC72DF366B719D022C0B09@GLKMS2100.GREENLNK.NET> <ABE739C5ADAC9A41ACCC72DF366B719D02302901@GLKMS2100.GREENLNK.NET>
From: Ian Chakeres <ian.chakeres@gmail.com>
Date: Thu, 27 Aug 2009 09:52:01 -0400
Message-ID: <374005f30908270652p7197f84frf698e412a26b03fb@mail.gmail.com>
To: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: MANET IETF <manet@ietf.org>, Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2009 13:52:18 -0000

Comments about unicast NHDP.

I agree that finding out about unicast neighbors dynamically is
challenging, but in the case where you know who your unicast neighbor
is (e.g. point-to-point) - I think it is very valuable to be able to
run NHDP between these neighbors.

Therefore, I would say that unicast NHDP should be included if
properly administratively configured.

Ian

On Mon, Aug 24, 2009 at 10:43 AM, Dearlove, Christopher
(UK)<Chris.Dearlove@baesystems.com> wrote:
<snip>
>
> Incidentally I've done some work on something which basically
> is unicast NHDP. And there are some significant issues,
> including:
>
> - Efficiency: If you have N neighbours, local broadcast NHDP's
> =A0workload is fixed, unicast NHDP's workload scales as N does.
>
> - Bootstrapping: Local broadcast is assumed to find other routers
> =A0that could be neighbours (within range in a typical wireless
> =A0system). But unicast won't do that for you. You need an alternative
> =A0approach to deal with this.
>
> - Theoretical timing issues, you can produce a race condition if you
> =A0extend this to flooding by hop by hop unicast.
>
> This all leads to that unicast NHDP is not a simple base protocol
> variant, but rather needs someone who knows what they are doing
> - which may involve an extension. Specifying the base protocol
> using local broadcast/multicast and leaving open the avenue to a
> unicast extension by not actually banning it is again the best
> approach I strongly suggest.
>
<snip>

From thomas@thomasclausen.org  Thu Aug 27 06:59:03 2009
Return-Path: <thomas@thomasclausen.org>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157683A6E1D for <manet@core3.amsl.com>; Thu, 27 Aug 2009 06:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvuaNXJqeiDa for <manet@core3.amsl.com>; Thu, 27 Aug 2009 06:59:02 -0700 (PDT)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 1FF663A696D for <manet@ietf.org>; Thu, 27 Aug 2009 06:58:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 34F144300E4; Thu, 27 Aug 2009 06:58:16 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from new-host-19.SME (ASte-Genev-Bois-153-1-82-253.w81-48.abo.wanadoo.fr [81.48.32.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id CB6D54300D8; Thu, 27 Aug 2009 06:58:13 -0700 (PDT)
Message-Id: <B58F3053-D6E9-4B2B-A757-8110EE628AC8@thomasclausen.org>
From: Thomas Heide Clausen <thomas@thomasclausen.org>
To: Ian Chakeres <ian.chakeres@gmail.com>
In-Reply-To: <374005f30908270646xc962c8bhd0460759612c66f1@mail.gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-2-343867936
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 27 Aug 2009 15:58:11 +0200
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com> <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil> <374005f30908270646xc962c8bhd0460759612c66f1@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, MANET IETF <manet@ietf.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2009 13:59:03 -0000

--Apple-Mail-2-343867936
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

I would, like Justin, much prefer addressing these issues within the  
scope of a last call, corresponding to the consensus at the Stockholm  
WG meeting.

Comment below.

On Aug 27, 2009, at 3:46 PM, Ian Chakeres wrote:

> Comments inline
>
> On Fri, Aug 21, 2009 at 3:16 PM, Justin Dean<jdean@itd.nrl.navy.mil>  
> wrote:
>> While I would prefer to be addressing these issues within the scope  
>> of a
>> last call, my comments to the items in question are inline.

<SNIP>

>>> #2) I don't see how to run multiple NHDP instances on the same
>>> interface or same router. PacketBB says that only one protocol
>>> instance can accept a particular message. Currently there is no  
>>> way to
>>> identify which NHDP instance a NHDP message should be delivered.
>>>
>> Packetbb, RFC 5444, disallows this behavior.  Having more than one  
>> NHDP
>> instance on an interface will result in ambiguous behaviors.
>
> RFC 5444 does not disallow the behavior I described. It does disallow
> having multiple NHDP instances receive the same message. Therefore,
> there must be a way to determine the instance of NHDP to which a
> message should be delivered.
>

RFC5444 reads:

    o  For each Message Type, a protocol -- unless specified otherwise,
       the one making the IANA reservation for that Message Type -- MUST
       be designated as the "owner" of that Message Type.
<SNIP>
    o  Incoming messages MUST be either silently discarded or MUST be
       delivered to the instance of the protocol that owns the  
associated
       Message Type.  Incoming messages SHOULD NOT be delivered to any
       other protocol instances and SHOULD NOT be delivered to more than
       one protocol instance.
The detail you're to be looking carefully at is in the first sentence  
of the second bullet.

I believe that this addresses the issue fully.

Thomas



--Apple-Mail-2-343867936
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">I would, like Justin, much =
prefer addressing these issues within the scope of a last call, =
corresponding to the consensus at the Stockholm WG =
meeting.<div><br></div><div>Comment =
below.</div><div><br></div><div><div><div>On Aug 27, 2009, at 3:46 PM, =
Ian Chakeres wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>Comments inline<br><br>On Fri, Aug 21, 2009 at 3:16 =
PM, Justin Dean&lt;<a =
href=3D"mailto:jdean@itd.nrl.navy.mil">jdean@itd.nrl.navy.mil</a>&gt; =
wrote:<br><blockquote type=3D"cite">While I would prefer to be =
addressing these issues within the scope of =
a<br></blockquote><blockquote type=3D"cite">last call, my comments to =
the items in question are =
inline.</blockquote></div></blockquote><div><br></div>&lt;SNIP&gt;</div><d=
iv><br><blockquote type=3D"cite"><div><blockquote =
type=3D"cite"><blockquote type=3D"cite">#2) I don't see how to run =
multiple NHDP instances on the =
same<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">interface or same router. PacketBB says that only one =
protocol<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">instance can accept a particular =
message. Currently there is no way =
to<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">identify which NHDP instance a NHDP message should be =
delivered.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite">Packetbb, RFC 5444, disallows this behavior. &nbsp;Having =
more than one NHDP<br></blockquote><blockquote type=3D"cite">instance on =
an interface will result in ambiguous behaviors.<br></blockquote><br>RFC =
5444 does not disallow the behavior I described. It does =
disallow<br>having multiple NHDP instances receive the same message. =
Therefore,<br>there must be a way to determine the instance of NHDP to =
which a<br>message should be =
delivered.<br><br></div></blockquote><div><br></div><div>RFC5444 =
reads:</div><div><br></div><div><span class=3D"Apple-style-span" =
style=3D"font-family: monospace; white-space: pre-wrap; ">   o  For each =
Message Type, a protocol -- unless specified =
otherwise,</span></div><div><span class=3D"Apple-style-span" =
style=3D"font-family: monospace; white-space: pre-wrap; ">      the one =
making the IANA reservation for that Message Type -- =
MUST</span></div><div><span class=3D"Apple-style-span" =
style=3D"font-family: monospace; white-space: pre-wrap; ">      be =
designated as the "owner" of that Message Type.</span></div><div><span =
class=3D"Apple-style-span" style=3D"font-family: Times; "><pre =
style=3D"word-wrap: break-word; white-space: pre-wrap; =
">&lt;SNIP&gt;</pre><pre style=3D"word-wrap: break-word; white-space: =
pre-wrap; ">   o  Incoming messages MUST be either silently discarded or =
MUST be
      delivered to the instance of the protocol that owns the associated
      Message Type.  Incoming messages SHOULD NOT be delivered to any
      other protocol instances and SHOULD NOT be delivered to more than
      one protocol instance.</pre></span></div><div>The detail you're to =
be looking carefully at is in the first sentence of the second =
bullet.</div><div><br></div><div>I believe that this addresses the issue =
fully.</div><div><br></div><div>Thomas</div><div><br></div><div><br></div>=
</div></div></body></html>=

--Apple-Mail-2-343867936--

From ian.chakeres@gmail.com  Thu Aug 27 07:12:28 2009
Return-Path: <ian.chakeres@gmail.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87CAD28C5CA for <manet@core3.amsl.com>; Thu, 27 Aug 2009 07:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfZ+fhymug2W for <manet@core3.amsl.com>; Thu, 27 Aug 2009 07:12:27 -0700 (PDT)
Received: from mail-qy0-f184.google.com (mail-qy0-f184.google.com [209.85.221.184]) by core3.amsl.com (Postfix) with ESMTP id 88CD228C1E2 for <manet@ietf.org>; Thu, 27 Aug 2009 07:12:26 -0700 (PDT)
Received: by qyk14 with SMTP id 14so637497qyk.17 for <manet@ietf.org>; Thu, 27 Aug 2009 07:12:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=qZnwk6v/Hbgh7c/fMlH8VdPw2v23pkGtBQbedYiXbkw=; b=f/AmD2ywWViAUk8ip9EEgHLwHX/6RA/Prj+4fcwxCLteK75HvH+bqV7kxSXVmlkAUB mVTt3j/QkuoebYZgmqnejgcya7sbyEgE+MroUCDwOllJAoPnOT1EKnhpoNeZvMwryiFS VDS3HUZhfERM720pelTjVeyR86DaVcs9GUiaM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=WRc9nGz9MfSeKNCQqHFI6h82d8ahlMQh8abuA2kv0UL2ZG33ViYAtM1LtvRdP6yDKJ TfYE9s/jH/UDTclVyUki91BFh/JcyEdOn41msgcyKfwbh0S/K+HQ0KncF0miLyPWoi7Y o6tkt3oWvgqJwVyNNe6QjOGigCgHrIoTYiE58=
MIME-Version: 1.0
Received: by 10.229.77.229 with SMTP id h37mr2743859qck.58.1251382350131; Thu,  27 Aug 2009 07:12:30 -0700 (PDT)
In-Reply-To: <ABE739C5ADAC9A41ACCC72DF366B719D02302901@GLKMS2100.GREENLNK.NET>
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com>  <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil> <ABE739C5ADAC9A41ACCC72DF366B719D022C0B09@GLKMS2100.GREENLNK.NET> <ABE739C5ADAC9A41ACCC72DF366B719D02302901@GLKMS2100.GREENLNK.NET>
From: Ian Chakeres <ian.chakeres@gmail.com>
Date: Thu, 27 Aug 2009 10:12:10 -0400
Message-ID: <374005f30908270712u56b1de8bufefea809145ade90@mail.gmail.com>
To: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: MANET IETF <manet@ietf.org>, Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2009 14:12:28 -0000

Comments about NHDP extensions.

I think your example below calls out the complexity involved in
building a NHDP extension, and I agree that in certain cases the
extension may be best suited to define the implementation.

As you mentioned, if a particular NHDP extension expects/requires
other NHDP instances running the same extension, or a compatible
extension, its messages need to be properly tagged.

I think we should call this particular case out & any other important
lessons that we've already learned from OLSRv2 and SMF.

Ian

On Mon, Aug 24, 2009 at 10:43 AM, Dearlove, Christopher
(UK)<Chris.Dearlove@baesystems.com> wrote:
> Sorry, top-posting is evil, but I'm doing it here. Please
> disentangle to read properly. But of course the earlier
> postings can be read as made in sequence.
>
> I'll make one specific comment. SMF (and variations that it
> could use) shows an example of why delegation to the derived
> protocol (n various alternative use cases) is to be preferred.
>
> One might think that all you need in SMF is a simple "I am an
> SMF router" added to HELLO messages (message TLV). That both
> doesn't work and almost works.
>
> - It doesn't work because SMF is not a single protocol, but a
> =A0familiy of protocols in flooding algorithm. (Also in DPD issues,
> =A0but that's not important right now.) So the SMF message TLV
> =A0needs a parameter for flooding algorithm.
>
> - It almost works in that that message TLV is sufficient to
> =A0ensure that flooding doesn't attempt to use an unsuitable
> =A0router as an intermediate. (At least, I think that's the
> =A0case. All such things need rigorously proving before we
> =A0base a protocol on them.) But it doesn't work efficiently.
> =A0If I have a neighbour A, and A has neighbours B, C, D, ...
> =A0but none of the latter are (compatible) SMF routers, then
> =A0with just a message TLV I may pick A as an MPR (for example)
> =A0but actually I don't need to, and it would be more efficient
> =A0not to do so. So SMF has a second TLV to mark addresses.
>
> However with regard to the latter point, SMF for MPRs wants
> that second TLV. SMF for blind flooding doesn't. That's all
> information that NHDP doesn't know. In fact had a simple TLV
> for NHDP been designed we might have missed the address block
> TLV requirement. And if we defined both TLVs (as SMF does)
> we might miss another case that some NHDP derivative needs.
> Only the derived protocols know this stuff. And each derived
> protocol is also where to make tradeoffs. For example here
> is a simple modification to the SMF strategy that typically
> saves octets - make the message TLV specify a default for
> the address block TLV, thus saving the address block TLV
> when all routers are using the same SMF variant. Is that
> appropriate for SMF? We could debate this. Should some other
> extension protocol make a different tradeoff? Quite possibly.
> And there are more cases. One such is that if administratively
> I know which other routers are sharing routing protocol with
> me, as we should form a subnet, then I can filter on HELLO
> sending addresses to separate uses. (I could filter either by
> dropping HELLO messages I don't want, or I could filter by
> putting everything into various protocol sets, but ignoring
> Tuples with the "wrong" addresses. This is, in effect,
> allowing different protocols to have different "views" of
> NHDP's Information Bases.) Or I could filter at L2 - if you
> don't have the right IDs and encryption keys you are out.
> This may leave me able to simply ignore the whole issue of
> alternative uses of NHDP, because in my closed world defined
> by that ID/key there are no alternative uses of NHDP, so why
> waste octets on excluding them?

<snip>

From Chris.Dearlove@baesystems.com  Thu Aug 27 07:16:41 2009
Return-Path: <Chris.Dearlove@baesystems.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51DF28C1BD for <manet@core3.amsl.com>; Thu, 27 Aug 2009 07:16:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.559
X-Spam-Level: 
X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfEKaDOwKjVu for <manet@core3.amsl.com>; Thu, 27 Aug 2009 07:16:41 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 799BA28C5EC for <manet@ietf.org>; Thu, 27 Aug 2009 07:14:52 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,286,1249254000"; d="scan'208";a="19377707"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 27 Aug 2009 15:14:58 +0100
Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n7REF0Cw032762; Thu, 27 Aug 2009 15:15:00 +0100
Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 27 Aug 2009 15:14:58 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Thu, 27 Aug 2009 15:14:57 +0100
Message-ID: <ABE739C5ADAC9A41ACCC72DF366B719D02332410@GLKMS2100.GREENLNK.NET>
In-Reply-To: <374005f30908270646xc962c8bhd0460759612c66f1@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [manet] Some NHDP Concerns
thread-index: AconHL8UTEbzGmPWSdOArPrq+DWyVQAA5XZg
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com> <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil> <374005f30908270646xc962c8bhd0460759612c66f1@mail.gmail.com>
From: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
To: "Ian Chakeres" <ian.chakeres@gmail.com>, "Justin Dean" <jdean@itd.nrl.navy.mil>
X-OriginalArrivalTime: 27 Aug 2009 14:14:58.0177 (UTC) FILETIME=[C2105F10:01CA2720]
Cc: MANET IETF <manet@ietf.org>, Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2009 14:16:41 -0000

> I think it is appropriate for NHDP to provide clear instructions for
> extensions to NDHP.

NHDP should say "you need to ensure that ..." but not "you need to
ensure that by doing this".

> My example above which is true for both SMF &
> OLSRv2 seems appropriate for inclusion.

We will not have a dependency, normative or non-normative of NHDP
on SMF or OLSRv2. So the specific example in those terms is not
appropriate. And as previously noted, different extensions will
have different things to manage, and a "one size fits all"
mechanism in NHDP is not appropriate.

********************************************************************
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 ian.chakeres@gmail.com  Thu Aug 27 07:21:02 2009
Return-Path: <ian.chakeres@gmail.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA03E3A6E43 for <manet@core3.amsl.com>; Thu, 27 Aug 2009 07:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pgKBiFqN8l0 for <manet@core3.amsl.com>; Thu, 27 Aug 2009 07:21:02 -0700 (PDT)
Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id DA1633A6E1D for <manet@ietf.org>; Thu, 27 Aug 2009 07:21:01 -0700 (PDT)
Received: by qw-out-2122.google.com with SMTP id 5so278037qwi.31 for <manet@ietf.org>; Thu, 27 Aug 2009 07:21:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=vzau2HubcPBnBXGJWphtVBttTVVU6SxjLMlq/Eh96cQ=; b=FTAWd+bwgeR1xCtb5UhnJZT2iY1NohhGWbkNI8FpQpQnOU6iuGxzuprptk93D8hehy yTTtZgjcFm+1a7RcwGH0y7K4aIC6F+R7RNqKhrbup+M0uJPwU91HrP6+CGfE40nBnoMw aG1+CN7dSP2rS9YrLuRu676bRbXGyYb0le/9o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=LUeyBiVd3tGSwiF7qtzIwVv4Tle6CW19oVTTDl2eDZxc56klCRlYaP6s6yu8dpx8bD EVSNDfaDPVPI0N5oUDNRWcFI58LUFSa2qPzkTrjbuVkjt9Fxg94CVnh5ZDNCQz8I2f2c 4qLILnd9oRYf/cCnZLCI49rZqwX94EkXCB+uU=
MIME-Version: 1.0
Received: by 10.229.27.195 with SMTP id j3mr2859996qcc.57.1251382864702; Thu,  27 Aug 2009 07:21:04 -0700 (PDT)
In-Reply-To: <ABE739C5ADAC9A41ACCC72DF366B719D02302901@GLKMS2100.GREENLNK.NET>
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com>  <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil> <ABE739C5ADAC9A41ACCC72DF366B719D022C0B09@GLKMS2100.GREENLNK.NET> <ABE739C5ADAC9A41ACCC72DF366B719D02302901@GLKMS2100.GREENLNK.NET>
From: Ian Chakeres <ian.chakeres@gmail.com>
Date: Thu, 27 Aug 2009 10:20:44 -0400
Message-ID: <374005f30908270720t663b0548nad138dbcb8a9c771@mail.gmail.com>
To: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: MANET IETF <manet@ietf.org>, Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2009 14:21:02 -0000

Comments about administrative exclusion.

I agree completely that users likely need methods to explicitly
identify information, possibly identified as not appropriate for
processing or disseminating. I think that the exclusion criteria must
be inside NHDP and not exclusively based upon information from other
layers (e.g. mac address, src/dst ip address).

I feel that requiring NHDP, or any protocol, mix information from
other protocols with NHDP may muddy the meaning of the other
information and limit the flexibility of each layer.

Ian

On Mon, Aug 24, 2009 at 10:43 AM, Dearlove, Christopher
(UK)<Chris.Dearlove@baesystems.com> wrote:
<snip>
> And there are more cases. One such is that if administratively
> I know which other routers are sharing routing protocol with
> me, as we should form a subnet, then I can filter on HELLO
> sending addresses to separate uses. (I could filter either by
> dropping HELLO messages I don't want, or I could filter by
> putting everything into various protocol sets, but ignoring
> Tuples with the "wrong" addresses. This is, in effect,
> allowing different protocols to have different "views" of
> NHDP's Information Bases.) Or I could filter at L2 - if you
> don't have the right IDs and encryption keys you are out.
> This may leave me able to simply ignore the whole issue of
> alternative uses of NHDP, because in my closed world defined
> by that ID/key there are no alternative uses of NHDP, so why
> waste octets on excluding them?
<snip>

From Chris.Dearlove@baesystems.com  Thu Aug 27 07:25:42 2009
Return-Path: <Chris.Dearlove@baesystems.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF7EF28C1DD for <manet@core3.amsl.com>; Thu, 27 Aug 2009 07:25:42 -0700 (PDT)
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.038,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mxak2BJ02SAo for <manet@core3.amsl.com>; Thu, 27 Aug 2009 07:25:41 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 498523A6A40 for <manet@ietf.org>; Thu, 27 Aug 2009 07:25:41 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,286,1249254000"; d="scan'208";a="19381090"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 27 Aug 2009 15:25:47 +0100
Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n7REPnxW007468; Thu, 27 Aug 2009 15:25:49 +0100
Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 27 Aug 2009 15:25:47 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Thu, 27 Aug 2009 15:25:46 +0100
Message-ID: <ABE739C5ADAC9A41ACCC72DF366B719D02332420@GLKMS2100.GREENLNK.NET>
In-Reply-To: <374005f30908270712u56b1de8bufefea809145ade90@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [manet] Some NHDP Concerns
thread-index: AconIGuOCb2dc3w0SIOGslezUtCTnQAAPGwg
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com> <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil> <ABE739C5ADAC9A41ACCC72DF366B719D022C0B09@GLKMS2100.GREENLNK.NET> <ABE739C5ADAC9A41ACCC72DF366B719D02302901@GLKMS2100.GREENLNK.NET> <374005f30908270712u56b1de8bufefea809145ade90@mail.gmail.com>
From: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
To: "Ian Chakeres" <ian.chakeres@gmail.com>
X-OriginalArrivalTime: 27 Aug 2009 14:25:47.0538 (UTC) FILETIME=[451CFF20:01CA2722]
Cc: MANET IETF <manet@ietf.org>, Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2009 14:25:43 -0000

I would expect - in WGLC, which is seriously overdue and
should have been called a month ago - to add something like
the following comments to WGLC. These are rough notes, not
proper wording. They go along with the notes about a protocol
extension being able to add to a HELLO message.
- In some cases, a protocol using NHDP may need to recognise
  which HELLO messages, or which parts of a HELLO message
  (specifically which neighbour addresses) it should process.
  In these cases, the protocol must ensure that required
  information is appropriately labelled (e.g. with message
  and/or address block TLVs).
- In other cases, due to protocol design, or administrative
  configuration (e.g. considering address ranges) such
  additions to a HELLO message may not be necessary.

--=20
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

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: Ian Chakeres [mailto:ian.chakeres@gmail.com]=20
Sent: 27 August 2009 15:12
To: Dearlove, Christopher (UK)
Cc: Justin Dean; MANET IETF; Thomas Heide Clausen
Subject: Re: [manet] Some NHDP Concerns


                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet.=20
      Keep this in mind if you answer this message.


Comments about NHDP extensions.

I think your example below calls out the complexity involved in
building a NHDP extension, and I agree that in certain cases the
extension may be best suited to define the implementation.

As you mentioned, if a particular NHDP extension expects/requires
other NHDP instances running the same extension, or a compatible
extension, its messages need to be properly tagged.

I think we should call this particular case out & any other important
lessons that we've already learned from OLSRv2 and SMF.

Ian

On Mon, Aug 24, 2009 at 10:43 AM, Dearlove, Christopher
(UK)<Chris.Dearlove@baesystems.com> wrote:
> Sorry, top-posting is evil, but I'm doing it here. Please
> disentangle to read properly. But of course the earlier
> postings can be read as made in sequence.
>
> I'll make one specific comment. SMF (and variations that it
> could use) shows an example of why delegation to the derived
> protocol (n various alternative use cases) is to be preferred.
>
> One might think that all you need in SMF is a simple "I am an
> SMF router" added to HELLO messages (message TLV). That both
> doesn't work and almost works.
>
> - It doesn't work because SMF is not a single protocol, but a
> =A0familiy of protocols in flooding algorithm. (Also in DPD issues,
> =A0but that's not important right now.) So the SMF message TLV
> =A0needs a parameter for flooding algorithm.
>
> - It almost works in that that message TLV is sufficient to
> =A0ensure that flooding doesn't attempt to use an unsuitable
> =A0router as an intermediate. (At least, I think that's the
> =A0case. All such things need rigorously proving before we
> =A0base a protocol on them.) But it doesn't work efficiently.
> =A0If I have a neighbour A, and A has neighbours B, C, D, ...
> =A0but none of the latter are (compatible) SMF routers, then
> =A0with just a message TLV I may pick A as an MPR (for example)
> =A0but actually I don't need to, and it would be more efficient
> =A0not to do so. So SMF has a second TLV to mark addresses.
>
> However with regard to the latter point, SMF for MPRs wants
> that second TLV. SMF for blind flooding doesn't. That's all
> information that NHDP doesn't know. In fact had a simple TLV
> for NHDP been designed we might have missed the address block
> TLV requirement. And if we defined both TLVs (as SMF does)
> we might miss another case that some NHDP derivative needs.
> Only the derived protocols know this stuff. And each derived
> protocol is also where to make tradeoffs. For example here
> is a simple modification to the SMF strategy that typically
> saves octets - make the message TLV specify a default for
> the address block TLV, thus saving the address block TLV
> when all routers are using the same SMF variant. Is that
> appropriate for SMF? We could debate this. Should some other
> extension protocol make a different tradeoff? Quite possibly.
> And there are more cases. One such is that if administratively
> I know which other routers are sharing routing protocol with
> me, as we should form a subnet, then I can filter on HELLO
> sending addresses to separate uses. (I could filter either by
> dropping HELLO messages I don't want, or I could filter by
> putting everything into various protocol sets, but ignoring
> Tuples with the "wrong" addresses. This is, in effect,
> allowing different protocols to have different "views" of
> NHDP's Information Bases.) Or I could filter at L2 - if you
> don't have the right IDs and encryption keys you are out.
> This may leave me able to simply ignore the whole issue of
> alternative uses of NHDP, because in my closed world defined
> by that ID/key there are no alternative uses of NHDP, so why
> waste octets on excluding them?

<snip>


********************************************************************
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  Thu Aug 27 07:29:38 2009
Return-Path: <Chris.Dearlove@baesystems.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519B628C5E2 for <manet@core3.amsl.com>; Thu, 27 Aug 2009 07:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.564
X-Spam-Level: 
X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KF7YBzx9V+Z for <manet@core3.amsl.com>; Thu, 27 Aug 2009 07:29:37 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 384F928C5DB for <manet@ietf.org>; Thu, 27 Aug 2009 07:29:37 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,286,1249254000"; d="scan'208";a="19382147"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 27 Aug 2009 15:29:43 +0100
Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n7RETiR0009779; Thu, 27 Aug 2009 15:29:45 +0100
Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 27 Aug 2009 15:29:43 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Thu, 27 Aug 2009 15:29:42 +0100
Message-ID: <ABE739C5ADAC9A41ACCC72DF366B719D02332431@GLKMS2100.GREENLNK.NET>
In-Reply-To: <374005f30908270720t663b0548nad138dbcb8a9c771@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [manet] Some NHDP Concerns
thread-index: AconIZ7CTWd8Af40Q9iVPgEz2pdf0QAALAnA
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com> <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil> <ABE739C5ADAC9A41ACCC72DF366B719D022C0B09@GLKMS2100.GREENLNK.NET> <ABE739C5ADAC9A41ACCC72DF366B719D02302901@GLKMS2100.GREENLNK.NET> <374005f30908270720t663b0548nad138dbcb8a9c771@mail.gmail.com>
From: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
To: "Ian Chakeres" <ian.chakeres@gmail.com>
X-OriginalArrivalTime: 27 Aug 2009 14:29:43.0015 (UTC) FILETIME=[D177EF70:01CA2722]
Cc: MANET IETF <manet@ietf.org>, Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2009 14:29:38 -0000

The most obvious information that may be used is IP
addresses. That is not mixing layer information.

In other cases, the other layers may provide the
exclusion needed without NHDP having to be aware of
this happening. If I am running OLSRv2 over 802.11
and I set my 802.11 IDs and security so that in my
specific deployment I know that OLSRv2 is all I'm
going to see, because no device that knows that stuff
has anything else deployed, why should I waste
octets in HELLO messages to exclude the possibility
of something that can't happen?

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

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: Ian Chakeres [mailto:ian.chakeres@gmail.com] 
Sent: 27 August 2009 15:21
To: Dearlove, Christopher (UK)
Cc: Justin Dean; MANET IETF; Thomas Heide Clausen
Subject: Re: [manet] Some NHDP Concerns


                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.


Comments about administrative exclusion.

I agree completely that users likely need methods to explicitly
identify information, possibly identified as not appropriate for
processing or disseminating. I think that the exclusion criteria must
be inside NHDP and not exclusively based upon information from other
layers (e.g. mac address, src/dst ip address).

I feel that requiring NHDP, or any protocol, mix information from
other protocols with NHDP may muddy the meaning of the other
information and limit the flexibility of each layer.

Ian

On Mon, Aug 24, 2009 at 10:43 AM, Dearlove, Christopher
(UK)<Chris.Dearlove@baesystems.com> wrote:
<snip>
> And there are more cases. One such is that if administratively
> I know which other routers are sharing routing protocol with
> me, as we should form a subnet, then I can filter on HELLO
> sending addresses to separate uses. (I could filter either by
> dropping HELLO messages I don't want, or I could filter by
> putting everything into various protocol sets, but ignoring
> Tuples with the "wrong" addresses. This is, in effect,
> allowing different protocols to have different "views" of
> NHDP's Information Bases.) Or I could filter at L2 - if you
> don't have the right IDs and encryption keys you are out.
> This may leave me able to simply ignore the whole issue of
> alternative uses of NHDP, because in my closed world defined
> by that ID/key there are no alternative uses of NHDP, so why
> waste octets on excluding them?
<snip>


********************************************************************
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 philippe.jacquet@inria.fr  Thu Aug 27 07:39:39 2009
Return-Path: <philippe.jacquet@inria.fr>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1440728C100 for <manet@core3.amsl.com>; Thu, 27 Aug 2009 07:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IPJcwfK8x5L for <manet@core3.amsl.com>; Thu, 27 Aug 2009 07:39:38 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id B24CC3A695A for <manet@ietf.org>; Thu, 27 Aug 2009 07:39:36 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,286,1249250400"; d="scan'208";a="33330989"
Received: from sphinx.lix.polytechnique.fr (HELO [192.168.112.230]) ([129.104.11.1]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 27 Aug 2009 16:39:41 +0200
Message-Id: <0ECB03CA-BBA3-4C87-B5A0-C405B0E78D11@inria.fr>
From: jacquet <philippe.jacquet@inria.fr>
To: Ian Chakeres <ian.chakeres@gmail.com>
In-Reply-To: <374005f30908270646xc962c8bhd0460759612c66f1@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Thu, 27 Aug 2009 16:42:24 +0200
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com> <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil> <374005f30908270646xc962c8bhd0460759612c66f1@mail.gmail.com>
X-Mailer: Apple Mail (2.935.3)
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, MANET IETF <manet@ietf.org>, Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2009 14:39:39 -0000

As far as I know signatures require a lot more informations than an =20
unique identifier of few bytes. An efficient signature would be close =20=

to 1000 bits and the basic keys would be echanged via an external =20
intermediation protocol. But maybe we are not talking of the same thing.

Philippe
Le 27 ao=FBt 09 =E0 15:46, Ian Chakeres a =E9crit :

>
>
>>> #3) In the current spec there is no single identifier for a NHDP =20
>>> node;
>>> instead a NHDP node is identified by the set of its IP addresses. I
>>> really liked the new explanatory text and examples, but I still find
>>> this complex - especially when there are multiple interfaces and
>>> multiple hops. Can someone please explain to me why we don't use a
>>> nhdp-node-id? Is this is related to relay set calculations.
>>>
>> A single identifier would seem to provide some functionality by =20
>> logically
>> grouping addresses of nodes together.  I say seem because at the =20
>> NHDP level
>> it doesn't really tell you anything as the addresses and interfaces =20=

>> they
>> represent might have differing functionality and although be co-=20
>> located on
>> the same machine knowing this provides no extra benefit other than =20=

>> perhaps
>> network displays (they could not be used for CDS calculations as it =20=

>> isn't
>> know if all addresses provide the same functionality).  If the =20
>> addresses all
>> have the same functionality then another TLV would have to be =20
>> attached
>> indicating this thus providing redundant TLV messaging, SMF defines =20=

>> TLVs
>> which provide this behavior.  Having a single id would also increase
>> overhead (in the form of TLVS) in that all addresses would have to be
>> provided anyhow rather than just using a single id.  Furthermore =20
>> things get
>> even more complicated when these identifier addresses change or =20
>> disappear
>> but the underlying addressing does not.  Any protocol which would =20
>> want this
>> type of functionality could easily provide it with a new TLV type =20
>> which
>> would provide (in NHDP case) duel functionality indicating
>> co-location/protocol functionality.  IMO this is where the grouping =20=

>> of
>> addresses into one ID belongs using TLVs belongs in derived =20
>> protocols.
>
> I understand what you are saying, but I'm not sure I agree.
>
> Here is one situation in which I think it would help to have single
> identifier. Let's imagine that a NHDP node is going to sign its
> messages - which identifier or set of identifiers would it use to
> identify itself? Knowing that the other device may or may not have the
> complete set of IP addresses associated with this particular NHDP
> node.
>
> I would actually feel more comfortable depending on a fixed NHDP
> identifier, instead of an IP address which might be changed as you
> pointed out.
>
>>>

From teco@inf-net.nl  Thu Aug 27 16:05:46 2009
Return-Path: <teco@inf-net.nl>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF2A3A6E6B for <manet@core3.amsl.com>; Thu, 27 Aug 2009 16:05:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.973
X-Spam-Level: 
X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60Zx8DE7y6pw for <manet@core3.amsl.com>; Thu, 27 Aug 2009 16:05:45 -0700 (PDT)
Received: from smtp.bit.nl (smtp.ipv6.bit.nl [IPv6:2001:7b8:3:5::25:1]) by core3.amsl.com (Postfix) with ESMTP id 17F8628C0EA for <manet@ietf.org>; Thu, 27 Aug 2009 16:05:44 -0700 (PDT)
Received: from [87.251.46.4] (port=53305 helo=M90Teco) by smtp1.smtp.dmz.bit.nl with esmtp (Exim 4.69) (envelope-from <teco@inf-net.nl>) id 1Mgo2P-0007Ha-GS for manet@ietf.org; Fri, 28 Aug 2009 01:05:49 +0200
From: "Teco Boot" <teco@inf-net.nl>
To: "'MANET IETF'" <manet@ietf.org>
References: <9BE4A11A-7DA3-4093-9A7A-B11C092DBF7D@gmail.com>
In-Reply-To: <9BE4A11A-7DA3-4093-9A7A-B11C092DBF7D@gmail.com>
Date: Fri, 28 Aug 2009 01:05:21 +0200
Message-ID: <008c01ca276a$da5fd290$8f1f77b0$@nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcoYKO7wIihkcYWXTzujkq3BqBcwHwPQLkZw
Content-Language: nl
Subject: Re: [manet] draft-ietf-manet-smf-09.txt - WGLC
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2009 23:05:46 -0000

I know I am late.
But here some remarks, up to page 14.
I may do the rest next week.


Page 7:
>  SMF relies on the MANET NHDP
>  specification to assist in IP layer 2-hop neighborhood state
>  discovery and maintenance for relay set election.
I think NHDP is just one of the options. It is "may rely" instead of
"relies".
Or is sending SMF_TYPE via NHDP mandatory ?? This would require rewording.


General:
What is the expected behavior when SMF nodes with different SMF_RELAY_ALG 
appears in the same network?


page 8:
>  It is important that SMF deployments in
>  localized edge network settings are able to connect and interoperate
>  with existing standard multicast protocols operating within more
>  conventional Internet infrastructures. 
Is SMF limited to edge networks? If so (I think so), this should be 
emphasized in the applicability statement section.
Questions would be: can the SMF enabled MANET act as transit between
other multicast routing domains? If so, are there limitations?


Page 9:
>  SMF
>  implementations MUST be capable of forwarding "global scope"
>  multicast packets to support generic multicast application needs or
>  to distribute designated multicast traffic ingressing the MANET
>  routing region via border routers.
I think there is a broader range of scopes than "global scope" 
(e.g. admin/site/org).


Page 9:
>  There
>  will also be a well-known multicast group for flooding to all SMF
>  forwarders.  This multicast group is specified to contain all MANET
>  SMF routers of a connected MANET routing region, so that packets
>  transmitted to the multicast address associated with the group will
>  be delivered to all connected SMF routers.  For IPv6, the multicast
>  address is specified to be "site-local".  The name of the multicast
>  group is "SL-MANET-ROUTERS".
Do we request for a well known group address?
If yes, do we need to request this in the IANA section?



Page 9:
>  2.  Link local multicast packets MUST NOT be forwarded.
This also applies to Interface-Local. Well known, of course.


Page 10:
>  For example, one class of forwarding is based upon relay
>  set election status and the packet's previous hop forwarder,
On the IP layer, there is no previous hop forwarder. One way of 
getting the required information is using sub-IP layer addresses. 
If so, add some words on this?


Page 11:
>  Similarly, for H-DPD, it is expected that
>  packet hash values will be kept with respect to at least the source
>  address to help ensure hash collision avoidance.
Not sure on if this really helps.


Page 12:
>  "H-bit"
I prefer the H bit depicted in figure 2. Now, it is depicted as "0".
In figure 3, it is also "0", but the H-bit was set.


Page 13:
>  When the "TaggerId" field is not present, then it is
>  assumed the source host applied the SMF-DPD option and the
>  <Identifier> can be considered unique in the context of the IPv6
>  packet header <srcAddr:dstAddr> tuple.
So it is not allowed to not adding a TaggerId on a border router? 
Maybe this is for reasons, what are those? Allow not adding TaggerId 
when not applicable?
When TaggerId is part of Identifier, the TidTyp and TidLen are not 
needed and the 7 bits are freed. And the H-bit is not needed anymore.
If reje


Page 14:
>  | Present     | *        | Present   | Invalid, do not Forward     |
>  | Not Present | Present  | Present   | Invalid, do not Forward     |
These lines are below a wildcard. A sequential lookup in the table 
will not touch the actions for these.



Teco.


|-----Oorspronkelijk bericht-----
|Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens Ian
|Chakeres
|Verzonden: zaterdag 8 augustus 2009 15:05
|Aan: MANET IETF
|Onderwerp: [manet] draft-ietf-manet-smf-09.txt - WGLC
|
|This note announces the WG Last Call for comments on draft-ietf-manet-
|smf-09.txt, "Simplified Multicast Forwarding".
|
|The document can be found at: http://www.ietf.org/internet-drafts/draft-
|ietf-manet-smf-09.txt
|
|The document is intended to be submitted for publication as an
|experimental standard document.
|
|Please review the document carefully and send your comments to the
|MANET list and document authors.
|
|This last call ends Sunday August 23.
|
|Thanks,
|Ian Chakeres
|_______________________________________________
|manet mailing list
|manet@ietf.org
|https://www.ietf.org/mailman/listinfo/manet


From weianni@huawei.com  Thu Aug 27 20:10:34 2009
Return-Path: <weianni@huawei.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C484A3A6DDC for <manet@core3.amsl.com>; Thu, 27 Aug 2009 20:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.069
X-Spam-Level: ****
X-Spam-Status: No, score=4.069 tagged_above=-999 required=5 tests=[AWL=1.550,  BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  J_CHICKENPOX_57=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jVh7e8zY+2c for <manet@core3.amsl.com>; Thu, 27 Aug 2009 20:10:32 -0700 (PDT)
Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 846F73A6822 for <manet@ietf.org>; Thu, 27 Aug 2009 20:10:32 -0700 (PDT)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP200HW9GTE64@szxga02-in.huawei.com> for manet@ietf.org; Fri, 28 Aug 2009 11:10:26 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP2009TYGTEOR@szxga02-in.huawei.com> for manet@ietf.org; Fri, 28 Aug 2009 11:10:26 +0800 (CST)
Received: from w00151475 ([10.111.16.57]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KP200IX6GTETH@szxml06-in.huawei.com> for manet@ietf.org; Fri, 28 Aug 2009 11:10:26 +0800 (CST)
Date: Fri, 28 Aug 2009 11:10:25 +0800
From: Anni Wei <weianni@huawei.com>
To: Henning Rogge <rogge@fgan.de>, manet@ietf.org
Message-id: <002601ca278d$16e440d0$39106f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <006001ca2706$3272ecc0$39106f0a@china.huawei.com> <200908271536.35369.rogge@fgan.de>
Subject: Re: [manet] new draft:routing algorithm based on the flow sensing parameter
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Aug 2009 03:10:34 -0000

Thanks :)
----- Original Message ----- 
From: "Henning Rogge" <rogge@fgan.de>
To: <manet@ietf.org>
Cc: "Anni Wei" <weianni@huawei.com>
Sent: Thursday, August 27, 2009 9:36 PM
Subject: Re: [manet] new draft:routing algorithm based on the flow sensing parameter


From thomas@thomasclausen.org  Fri Aug 28 05:09:06 2009
Return-Path: <thomas@thomasclausen.org>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C10D03A70FE for <manet@core3.amsl.com>; Fri, 28 Aug 2009 05:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level: 
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tZjx7Jo+S94 for <manet@core3.amsl.com>; Fri, 28 Aug 2009 05:09:05 -0700 (PDT)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8BB843A6B4F for <manet@ietf.org>; Fri, 28 Aug 2009 05:08:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A5E5243014A; Fri, 28 Aug 2009 05:08:47 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from new-host-19.SME (ASte-Genev-Bois-153-1-82-253.w81-48.abo.wanadoo.fr [81.48.32.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id B8288430057; Fri, 28 Aug 2009 05:08:46 -0700 (PDT)
Message-Id: <E25514C2-65D5-4D35-9EB5-D7DFABDE5050@thomasclausen.org>
From: Thomas Heide Clausen <thomas@thomasclausen.org>
To: MANET IETF <manet@ietf.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 28 Aug 2009 14:08:44 +0200
X-Mailer: Apple Mail (2.936)
Cc: Joseph Macker <macker@itd.nrl.navy.mil>
Subject: [manet] Annual OLSR Interop 2009 details
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Aug 2009 12:09:06 -0000

(It seems that the email I sent to the list during the Stockholm IETF  
never hit the archives, so I am trying again - wonder if I'm hitting  
some sort of "spam filter", wg chairs, will you check that?)

===

Folks,

As announced in both San Francisco and earlier this week in Stockholm,  
the next OLSR Interop/Workshop is being held in Vienna, hosted by  
Funkfeuer.at in early October (2-4).

The usual format: one day of "workshop", where emphasis will be on  
practical experiences with either of OLSR, OLSRv2 or its constituent  
parts (and extensions hereto), followed by two days of interop testing  
and hacking.

Here's an URL with further information, and a link to where you can  
register for attending:

	http://interop.thomasclausen.org/Interop09/

If you have an implementation of OLSR, OLSRv2 or any of its  
constituent parts, please do join us! It's usually great fun, and  
usually very constructive.

Questions or comments: don't hesitate to contact me.

Cheers,

Thomas



From thomas@thomasclausen.org  Fri Aug 28 06:47:18 2009
Return-Path: <thomas@thomasclausen.org>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A78C93A6F6E for <manet@core3.amsl.com>; Fri, 28 Aug 2009 06:47:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level: 
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiAGoCHQPL5q for <manet@core3.amsl.com>; Fri, 28 Aug 2009 06:47:17 -0700 (PDT)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D98E33A6F67 for <manet@ietf.org>; Fri, 28 Aug 2009 06:47:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1D4FA430202; Fri, 28 Aug 2009 06:47:25 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from new-host-19.SME (ASte-Genev-Bois-153-1-82-253.w81-48.abo.wanadoo.fr [81.48.32.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id ECFE74301FD; Fri, 28 Aug 2009 06:47:23 -0700 (PDT)
Message-Id: <70BB202D-5BAF-4D0D-8294-DF032B974D91@thomasclausen.org>
From: Thomas Heide Clausen <thomas@thomasclausen.org>
To: Ian Chakeres <ian.chakeres@gmail.com>
In-Reply-To: <374005f30908270652p7197f84frf698e412a26b03fb@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 28 Aug 2009 15:47:21 +0200
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com> <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil> <ABE739C5ADAC9A41ACCC72DF366B719D022C0B09@GLKMS2100.GREENLNK.NET> <ABE739C5ADAC9A41ACCC72DF366B719D02302901@GLKMS2100.GREENLNK.NET> <374005f30908270652p7197f84frf698e412a26b03fb@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, MANET IETF <manet@ietf.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Aug 2009 13:47:18 -0000

I would, like Justin, much prefer addressing these issues within the  
scope of a last call, corresponding to the consensus at the Stockholm  
WG meeting.

Comment below.

On Aug 27, 2009, at 3:52 PM, Ian Chakeres wrote:

> Comments about unicast NHDP.
>
> I agree that finding out about unicast neighbors dynamically is
> challenging, but in the case where you know who your unicast neighbor
> is (e.g. point-to-point) - I think it is very valuable to be able to
> run NHDP between these neighbors.
>
> Therefore, I would say that unicast NHDP should be included if
> properly administratively configured.
>

The scenario you summon is, that you have a point-to-point connection  
to (one of) your neighbors.

If you *know* this to be true, then either (likely) you have a  
physical point-to-point link between yourself and that neighbor -- or  
you don't have a physical link but you know that the connectivity is  
so stable that you can set one up (with a virtual interface in each  
end, if need be) easily.

In that case, if you run NHDP as-is, over your point-to-point link,  
the NHDP multi/broadcasts essentially becomes the "unicast" that you  
suggest. Managing your suggested point-to-point connectivity as such  
allows NHDP to be run identically across also these interfaces.

Therefore, I would say that this is a matter of properly  
administratively configuring of your point-to-point connectivity, and  
not NHDP.

I believe that this addresses the issue fully.

Thomas


From thomas@thomasclausen.org  Fri Aug 28 08:50:44 2009
Return-Path: <thomas@thomasclausen.org>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A153A28C410 for <manet@core3.amsl.com>; Fri, 28 Aug 2009 08:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.498
X-Spam-Level: 
X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05CATGpYApFg for <manet@core3.amsl.com>; Fri, 28 Aug 2009 08:50:43 -0700 (PDT)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id BC3B628C40E for <manet@ietf.org>; Fri, 28 Aug 2009 08:50:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0A90B43023C; Fri, 28 Aug 2009 08:50:51 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from new-host-19.SME (ASte-Genev-Bois-153-1-82-253.w81-48.abo.wanadoo.fr [81.48.32.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 9E13C430239; Fri, 28 Aug 2009 08:50:49 -0700 (PDT)
Message-Id: <F6D30C7F-9DF4-4AF4-BD1B-B17C69A6B58D@thomasclausen.org>
From: Thomas Heide Clausen <thomas@thomasclausen.org>
To: Ian Chakeres <ian.chakeres@gmail.com>
In-Reply-To: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-1-437023378
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 28 Aug 2009 17:50:46 +0200
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, MANET IETF <manet@ietf.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Aug 2009 15:50:44 -0000

--Apple-Mail-1-437023378
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

I would, like Justin, much prefer addressing these issues within the  
scope of a last call, corresponding to the consensus at the Stockholm  
WG meeting.

Comment below.

On Aug 21, 2009, at 7:53 PM, Ian Chakeres wrote:
>
> #5) I would like text explaining why NHDP is such a complex HELLO
> protocol, specifically that NHDP was build to assist in calculating
> reduced relay sets (e.g. MPR, CDS). I think this stated purpose will
> be helpful in explaining why certain information is included and the
> overall design of the protocol.
>

The current draft-ietf-manet-nhdp-10 (as well as all revisions back  
until draft-ietf-manet-nhdp-07, dated July 10 2008) explicitly states  
in section 1.1 that:

    MANET routing protocols, for example [RFC3626] and [RFC5449], often
    employ relay set reductions in order to conserve network capacity
    when maintaining network-wide topological information, with
    calculation of these reduced relay sets employing up to two hop
    information.
I believe that this addresses the issue fully.

Thomas


--Apple-Mail-1-437023378
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">I would, like Justin, much =
prefer addressing these issues within the scope of a last call, =
corresponding to the consensus at the Stockholm WG =
meeting.<br><br>Comment below.<br><div><div><br></div><div>On Aug 21, =
2009, at 7:53 PM, Ian Chakeres wrote:</div><blockquote =
type=3D"cite"><div><font class=3D"Apple-style-span" =
color=3D"#000000"><br></font>#5) I would like text explaining why NHDP =
is such a complex HELLO<br>protocol, specifically that NHDP was build to =
assist in calculating<br>reduced relay sets (e.g. MPR, CDS). I think =
this stated purpose will<br>be helpful in explaining why certain =
information is included and the<br>overall design of the =
protocol.<br><br></div></blockquote><div><br></div><div><div>The current =
draft-ietf-manet-nhdp-10 (as well as all revisions back until =
draft-ietf-manet-nhdp-07, dated July 10 2008) explicitly states in =
section 1.1 that:</div><div><br></div></div><span =
class=3D"Apple-style-span" style=3D"font-family: Times; "><pre =
style=3D"word-wrap: break-word; white-space: pre-wrap; ">   MANET =
routing protocols, for example [RFC3626] and [RFC5449], often
   employ relay set reductions in order to conserve network capacity
   when maintaining network-wide topological information, with
   calculation of these reduced relay sets employing up to two hop
   information.</pre></span>I believe that this addresses the issue =
fully.</div><br>Thomas<div><br></div></body></html>=

--Apple-Mail-1-437023378--

From ulrich@herberg.name  Fri Aug 28 05:04:50 2009
Return-Path: <ulrich@herberg.name>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D9228C346 for <manet@core3.amsl.com>; Fri, 28 Aug 2009 05:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.876
X-Spam-Level: 
X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yabj1nG7GQ24 for <manet@core3.amsl.com>; Fri, 28 Aug 2009 05:04:49 -0700 (PDT)
Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id CD24828C320 for <manet@ietf.org>; Fri, 28 Aug 2009 05:04:48 -0700 (PDT)
Received: by bwz19 with SMTP id 19so1562831bwz.37 for <manet@ietf.org>; Fri, 28 Aug 2009 05:04:52 -0700 (PDT)
MIME-Version: 1.0
Sender: ulrich@herberg.name
Received: by 10.204.157.16 with SMTP id z16mr866878bkw.103.1251461091074; Fri,  28 Aug 2009 05:04:51 -0700 (PDT)
In-Reply-To: <e246419f0908141400s78d6d2c0t78bc8fca656c338c@mail.gmail.com>
References: <e246419f0908141400s78d6d2c0t78bc8fca656c338c@mail.gmail.com>
Date: Fri, 28 Aug 2009 14:04:50 +0200
X-Google-Sender-Auth: 1b02bab2a8937ab5
Message-ID: <25c114b90908280504n7b2a7dcnbb9c3f7a73fb8da1@mail.gmail.com>
From: Ulrich Herberg <ulrich.herberg@polytechnique.edu>
To: Tom Wambold <tom5760@gmail.com>
Content-Type: multipart/alternative; boundary=0015175ccf5cc8a3870472327d52
X-Mailman-Approved-At: Fri, 28 Aug 2009 09:19:06 -0700
Cc: manet@ietf.org, ns-develpers@isi.edu
Subject: Re: [manet] NS-3 RFC5444 (PacketBB) Implementation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Aug 2009 12:04:50 -0000

--0015175ccf5cc8a3870472327d52
Content-Type: text/plain; charset=ISO-8859-1

Hi Tom,

that's good news! We are organizing an OLSR interop in Vienna and invite
everyone with a packetbb/NHDP/OLSRv2 implementation to join. More
information on:
http://interop.thomasclausen.org/Interop09

Thomas Clausen will send an email with the announcement today (it apparently
got lost on the mailing list before).

Best regards,
Ulrich

On Fri, Aug 14, 2009 at 11:00 PM, Tom Wambold <tom5760@gmail.com> wrote:

> All:
>
> I have just recently published a new PacketBB implementation for the
> NS-3 Network Simulator as part of work at Drexel University and
> University of Pennsylvania.
>
> The implementation can be found in the Mercurial repository at [1].  The
> source files are in src/contrib/packetbb.{cc,h}.  A thorough test can be
> found at src/contrib/test-packetbb.cc
>
> This library fully conforms to RFC5444 [2], and passes all
> interoperability tests performed at the 2008 OLSR Interop [3].  Since
> these example packets were based on an earlier PacketBB draft, a minor
> change was needed to match the latest RFC.  Otherwise, this
> implementation passes all of the tests found at [4].
>
> We will be actively using this library to support our implementation of
> NHDP and SMF.  These should be ready for release in a few weeks.
> Hopefully, these could be merged into the main NS-3 distribution.
>
> Since NS-3 has a full IP stack, with packets being fully serialized,
> this implementation could potentially interoperate with other PacketBB
> implementations when using NS-3 in emulation.  Also, this implementation
> is fairly generic, so it could be ported to live systems without much
> effort.
>
> Please feel free to send me any questions/comments/etc. that you may
> have as we are actively using and maintaining this library.
>
> Thanks!
> -Tom Wambold
>
> [1] - http://code.nsnam.org/twambold/ns-3-dev-packetbb
> [2] - http://tools.ietf.org/html/rfc5444
> [3] - http://interop08.thomasclausen.org/packets-and-dumps.txt
> [4] -
> http://code.nsnam.org/twambold/ns-3-dev-packetbb/file/tip/src/contrib/test-packetbb.cc
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>

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

Hi Tom,<br><br>that&#39;s good news! We are organizing an OLSR interop in V=
ienna and invite everyone with a packetbb/NHDP/OLSRv2 implementation to joi=
n. More information on:<br><a href=3D"http://interop.thomasclausen.org/Inte=
rop09">http://interop.thomasclausen.org/Interop09</a><br>
<br>Thomas Clausen will send an email with the announcement today (it appar=
ently got lost on the mailing list before).<br><br>Best regards,<br>Ulrich<=
br><br><div class=3D"gmail_quote">On Fri, Aug 14, 2009 at 11:00 PM, Tom Wam=
bold <span dir=3D"ltr">&lt;<a href=3D"mailto:tom5760@gmail.com">tom5760@gma=
il.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">All:<br>
<br>
I have just recently published a new PacketBB implementation for the<br>
NS-3 Network Simulator as part of work at Drexel University and<br>
University of Pennsylvania.<br>
<br>
The implementation can be found in the Mercurial repository at [1]. =A0The<=
br>
source files are in src/contrib/packetbb.{cc,h}. =A0A thorough test can be<=
br>
found at src/contrib/test-packetbb.cc<br>
<br>
This library fully conforms to RFC5444 [2], and passes all<br>
interoperability tests performed at the 2008 OLSR Interop [3]. =A0Since<br>
these example packets were based on an earlier PacketBB draft, a minor<br>
change was needed to match the latest RFC. =A0Otherwise, this<br>
implementation passes all of the tests found at [4].<br>
<br>
We will be actively using this library to support our implementation of<br>
NHDP and SMF. =A0These should be ready for release in a few weeks.<br>
Hopefully, these could be merged into the main NS-3 distribution.<br>
<br>
Since NS-3 has a full IP stack, with packets being fully serialized,<br>
this implementation could potentially interoperate with other PacketBB<br>
implementations when using NS-3 in emulation. =A0Also, this implementation<=
br>
is fairly generic, so it could be ported to live systems without much<br>
effort.<br>
<br>
Please feel free to send me any questions/comments/etc. that you may<br>
have as we are actively using and maintaining this library.<br>
<br>
Thanks!<br>
-Tom Wambold<br>
<br>
[1] - <a href=3D"http://code.nsnam.org/twambold/ns-3-dev-packetbb" target=
=3D"_blank">http://code.nsnam.org/twambold/ns-3-dev-packetbb</a><br>
[2] - <a href=3D"http://tools.ietf.org/html/rfc5444" target=3D"_blank">http=
://tools.ietf.org/html/rfc5444</a><br>
[3] - <a href=3D"http://interop08.thomasclausen.org/packets-and-dumps.txt" =
target=3D"_blank">http://interop08.thomasclausen.org/packets-and-dumps.txt<=
/a><br>
[4] - <a href=3D"http://code.nsnam.org/twambold/ns-3-dev-packetbb/file/tip/=
src/contrib/test-packetbb.cc" target=3D"_blank">http://code.nsnam.org/twamb=
old/ns-3-dev-packetbb/file/tip/src/contrib/test-packetbb.cc</a><br>
_______________________________________________<br>
manet mailing list<br>
<a href=3D"mailto:manet@ietf.org">manet@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/manet" target=3D"_blank">h=
ttps://www.ietf.org/mailman/listinfo/manet</a><br>
</blockquote></div><br>

--0015175ccf5cc8a3870472327d52--

From ian.chakeres@gmail.com  Sun Aug 30 05:45:58 2009
Return-Path: <ian.chakeres@gmail.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702013A6C50 for <manet@core3.amsl.com>; Sun, 30 Aug 2009 05:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5+JyTysbu8A for <manet@core3.amsl.com>; Sun, 30 Aug 2009 05:45:57 -0700 (PDT)
Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 9FF473A672F for <manet@ietf.org>; Sun, 30 Aug 2009 05:45:57 -0700 (PDT)
Received: by qw-out-2122.google.com with SMTP id 5so951210qwi.31 for <manet@ietf.org>; Sun, 30 Aug 2009 05:46:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:cc:content-type; bh=AfX6s119t+WiOiiR1bhGmSRzgES+POwcgDDvkt9TlZQ=; b=nurTTYRidWMrybI/vCobSDxus3LmPJfRgUUQZdtYuo8Q77BCP+UxJlSYdOPpYrrQmb P/+0UwszcNOQSd17dKXMB4AA3WXn50dSLyY632fhUtcGP5G5n8Ix9ZUsY8z6opVOQe2/ 6dGc2CpcT9ee+Y+n+qPcc0hFRiWMxPgaP/cGI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; b=UyeLOLFoUZwyTK6BIATO5HBg63ElzROHoIcXegq6iUu5iIdGeDhWBIEd5s1Hq1KzpB e3j6LEyufE/hAjuBnbjn2nOLuSe7dbm9ZVgAPCNV7QOsNmBA3LDSWLaiuUMvhuDjwgMn O4j+dyXaed6Bo/FSZM0Zh7ip/QnWDPNSwI4ck=
MIME-Version: 1.0
Received: by 10.229.119.154 with SMTP id z26mr1290585qcq.38.1251636361060;  Sun, 30 Aug 2009 05:46:01 -0700 (PDT)
From: Ian Chakeres <ian.chakeres@gmail.com>
Date: Sun, 30 Aug 2009 08:45:41 -0400
Message-ID: <374005f30908300545n55daabd8geb1450a4507fe10c@mail.gmail.com>
To: MANET IETF <manet@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: [manet] draft-ietf-manet-nhdp-10.txt - WGLC - Oct 5th 2009
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Aug 2009 12:45:58 -0000

This note announces the WG Last Call for comments on
draft-ietf-manet-nhdp-10.txt, "MANET Neighborhood Discovery Protocol".

The document can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-10.txt

The document is intended to be submitted for publication as an
proposed standard document.

Please review the document carefully and send your comments to the
MANET list and document authors.

This last call ends Sunday Oct 5th.

Thanks,
Ian Chakeres

From ian.chakeres@gmail.com  Mon Aug 31 05:55:31 2009
Return-Path: <ian.chakeres@gmail.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2415E3A6DF6 for <manet@core3.amsl.com>; Mon, 31 Aug 2009 05:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDoc7fWABUQF for <manet@core3.amsl.com>; Mon, 31 Aug 2009 05:55:30 -0700 (PDT)
Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 230B03A6C03 for <manet@ietf.org>; Mon, 31 Aug 2009 05:55:29 -0700 (PDT)
Received: by qw-out-2122.google.com with SMTP id 5so1125510qwi.31 for <manet@ietf.org>; Mon, 31 Aug 2009 05:55:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=R+GhtpKbSaWssQpK7Ky47GHc54R/gWAHxIG/DXK6SZ8=; b=RiCBsDs7lIPWudXpKOgpJeolRmPyTH/xwYbhOnQ9k1imKxYkTvEdzdoeyik49QzNLJ NhZW+MLJgYz7FZkaZXYlMF6o6fFRzA679L2atNAPOo5eZ4CO0/pSgwmypDFiaITTDqwB adtJvHpFlMPM5TmpxzT+4UuqrvK0nzZzXAUDk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=o/lrTpSVJvg+RB/oRkoBSaisAqpA3MFFC54IyoPsAA/4jLCJ8iVy9699M22t+PMZvl //Azuy34KO7lF2lP+aKCrNoLQIMQJTS035GG/rbywJ/OAwghCN0W7QohoY0YM43H4ni6 Nq8+ySqWK4LXP3ZASEpcbWb89UNtH4PduXkM8=
MIME-Version: 1.0
Received: by 10.229.23.212 with SMTP id s20mr1438602qcb.71.1251723338296; Mon,  31 Aug 2009 05:55:38 -0700 (PDT)
In-Reply-To: <B58F3053-D6E9-4B2B-A757-8110EE628AC8@thomasclausen.org>
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com>  <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil> <374005f30908270646xc962c8bhd0460759612c66f1@mail.gmail.com>  <B58F3053-D6E9-4B2B-A757-8110EE628AC8@thomasclausen.org>
From: Ian Chakeres <ian.chakeres@gmail.com>
Date: Mon, 31 Aug 2009 08:55:18 -0400
Message-ID: <374005f30908310555x239dd199x4fdcfef7bdf48e91@mail.gmail.com>
To: Thomas Heide Clausen <thomas@thomasclausen.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, MANET IETF <manet@ietf.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 12:55:31 -0000

If the term "instance" is excluded by a SHOULD, let's instead use the
term "area" or another term to logically separate NHDP information. Is
there a term you prefer?

I think the ability to identify/separate information and allow
multiple people to use the same physical medium is especially
important in wireless networks.

Ian

On Thu, Aug 27, 2009 at 9:58 AM, Thomas Heide
Clausen<thomas@thomasclausen.org> wrote:
> I would, like Justin, much prefer addressing these issues within the scop=
e
> of a last call, corresponding to the consensus at the Stockholm WG meetin=
g.
> Comment below.
> On Aug 27, 2009, at 3:46 PM, Ian Chakeres wrote:
>
> Comments inline
>
> On Fri, Aug 21, 2009 at 3:16 PM, Justin Dean<jdean@itd.nrl.navy.mil> wrot=
e:
>
> While I would prefer to be addressing these issues within the scope of a
>
> last call, my comments to the items in question are inline.
>
> <SNIP>
>
> #2) I don't see how to run multiple NHDP instances on the same
>
> interface or same router. PacketBB says that only one protocol
>
> instance can accept a particular message. Currently there is no way to
>
> identify which NHDP instance a NHDP message should be delivered.
>
> Packetbb, RFC 5444, disallows this behavior. =A0Having more than one NHDP
>
> instance on an interface will result in ambiguous behaviors.
>
> RFC 5444 does not disallow the behavior I described. It does disallow
> having multiple NHDP instances receive the same message. Therefore,
> there must be a way to determine the instance of NHDP to which a
> message should be delivered.
>
>
> RFC5444 reads:
> o For each Message Type, a protocol -- unless specified otherwise,
> the one making the IANA reservation for that Message Type -- MUST
> be designated as the "owner" of that Message Type.
>
> <SNIP>
>
>    o  Incoming messages MUST be either silently discarded or MUST be
>       delivered to the instance of the protocol that owns the associated
>       Message Type.  Incoming messages SHOULD NOT be delivered to any
>       other protocol instances and SHOULD NOT be delivered to more than
>       one protocol instance.
>
> The detail you're to be looking carefully at is in the first sentence of =
the
> second bullet.
> I believe that this addresses the issue fully.
> Thomas
>
>

From ian.chakeres@gmail.com  Mon Aug 31 06:06:09 2009
Return-Path: <ian.chakeres@gmail.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 630853A6E0D for <manet@core3.amsl.com>; Mon, 31 Aug 2009 06:06:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4w0jTriP2vV for <manet@core3.amsl.com>; Mon, 31 Aug 2009 06:06:08 -0700 (PDT)
Received: from mail-qy0-f194.google.com (mail-qy0-f194.google.com [209.85.221.194]) by core3.amsl.com (Postfix) with ESMTP id 80B8028C134 for <manet@ietf.org>; Mon, 31 Aug 2009 06:06:08 -0700 (PDT)
Received: by qyk32 with SMTP id 32so698276qyk.19 for <manet@ietf.org>; Mon, 31 Aug 2009 06:06:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=Cs5UE3JDstZ9QejzwgszNeLfNv2mEDR886aSew/Y+aw=; b=qv+0ggKr/jbL6lJeuzhrWVLAXaHjxaNvcF4u47P2fGNfyC/vCWviXR9qZ/1rd+yYrJ BqbAOpMvA0M/mUs6Oc1r/ivtwTtqMajbyABsOQIvsfr3V4jEyQU4LHzp788R0G7/2nUo KoHcZysFhUwWuQmoDsFxBUboK0pNFKbgpC0M0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=h9uiRTovI/IzBxqgsgp9R/lNthglJYr9vJQzhemDilLl4XgPFrZDGLltoVyCkc14d4 i83DaMDs1XEPE9JX2CE7Kg7JqJ8dMJ8hUoDc+VREQ51KBFbsR5z1Wxg4Etwy1FbSwe4W J/QjjVJD/hSFGooPp1oMVtMi9IwjXKtOPScdo=
MIME-Version: 1.0
Received: by 10.229.129.133 with SMTP id o5mr1479522qcs.45.1251723974485; Mon,  31 Aug 2009 06:06:14 -0700 (PDT)
In-Reply-To: <F6D30C7F-9DF4-4AF4-BD1B-B17C69A6B58D@thomasclausen.org>
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com>  <F6D30C7F-9DF4-4AF4-BD1B-B17C69A6B58D@thomasclausen.org>
From: Ian Chakeres <ian.chakeres@gmail.com>
Date: Mon, 31 Aug 2009 09:05:54 -0400
Message-ID: <374005f30908310605m68c5c77bg69ea32c5b43c15dc@mail.gmail.com>
To: Thomas Heide Clausen <thomas@thomasclausen.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, MANET IETF <manet@ietf.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 13:06:09 -0000

I believe there are several design decisions involving higher
complexity. beyond that of simply a 2-hop neighbor hello protocol,
that have been introduced into NHDP to enable and facilitation reduced
relay sets. I feel that a person outside MANET would be perplexed why
things are written the way they are written.

I know that this complexity issue was one of the major things that
Elwyn Davies had identified in NHDP-05. I will ask if he can review
the document again to see if the current specification satisfies him.

Ian Chakeres

On Fri, Aug 28, 2009 at 11:50 AM, Thomas Heide
Clausen<thomas@thomasclausen.org> wrote:
> I would, like Justin, much prefer addressing these issues within the scope
> of a last call, corresponding to the consensus at the Stockholm WG meeting.
>
> Comment below.
>
> On Aug 21, 2009, at 7:53 PM, Ian Chakeres wrote:
>
> #5) I would like text explaining why NHDP is such a complex HELLO
> protocol, specifically that NHDP was build to assist in calculating
> reduced relay sets (e.g. MPR, CDS). I think this stated purpose will
> be helpful in explaining why certain information is included and the
> overall design of the protocol.
>
>
> The current draft-ietf-manet-nhdp-10 (as well as all revisions back until
> draft-ietf-manet-nhdp-07, dated July 10 2008) explicitly states in section
> 1.1 that:
>
>    MANET routing protocols, for example [RFC3626] and [RFC5449], often
>    employ relay set reductions in order to conserve network capacity
>    when maintaining network-wide topological information, with
>    calculation of these reduced relay sets employing up to two hop
>    information.
>
> I believe that this addresses the issue fully.
> Thomas
>

From thomas@thomasclausen.org  Mon Aug 31 06:07:39 2009
Return-Path: <thomas@thomasclausen.org>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F23228C231 for <manet@core3.amsl.com>; Mon, 31 Aug 2009 06:07:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level: 
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsAcuF+vGdNi for <manet@core3.amsl.com>; Mon, 31 Aug 2009 06:07:38 -0700 (PDT)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 28F7D28C270 for <manet@ietf.org>; Mon, 31 Aug 2009 06:07:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 52B20430365; Mon, 31 Aug 2009 06:07:39 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from new-host-19.SME (ASte-Genev-Bois-153-1-82-253.w81-48.abo.wanadoo.fr [81.48.32.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 129F8430360; Mon, 31 Aug 2009 06:07:37 -0700 (PDT)
Message-Id: <6C06D2E5-E45B-4D59-9476-D4F35532350E@thomasclausen.org>
From: Thomas Heide Clausen <thomas@thomasclausen.org>
To: Ian Chakeres <ian.chakeres@gmail.com>
In-Reply-To: <374005f30908310555x239dd199x4fdcfef7bdf48e91@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 31 Aug 2009 15:07:35 +0200
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com> <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil> <374005f30908270646xc962c8bhd0460759612c66f1@mail.gmail.com> <B58F3053-D6E9-4B2B-A757-8110EE628AC8@thomasclausen.org> <374005f30908310555x239dd199x4fdcfef7bdf48e91@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, MANET IETF <manet@ietf.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 13:07:39 -0000

On Aug 31, 2009, at 2:55 PM, Ian Chakeres wrote:

> If the term "instance" is excluded by a SHOULD, let's instead use the
> term "area" or another term to logically separate NHDP information. Is
> there a term you prefer?
>

It is not a matter of preferring a term over the other, it's a  
conceptual matter.

> I think the ability to identify/separate information and allow
> multiple people to use the same physical medium is especially
> important in wireless networks.

NHDP simply detects connectivity. If a protocol (such as SMF) wants to  
be further discriminative as to which connectivity it wants to use,  
then this is a task for that protocol (e.g. by decorating with TLVs) -  
and most certainly not for NHDP.

You can even construct an efficiency argument as for why this would be  
a bad thing to do.

Thomas

> Ian
>
> On Thu, Aug 27, 2009 at 9:58 AM, Thomas Heide
> Clausen<thomas@thomasclausen.org> wrote:
>> I would, like Justin, much prefer addressing these issues within  
>> the scope
>> of a last call, corresponding to the consensus at the Stockholm WG  
>> meeting.
>> Comment below.
>> On Aug 27, 2009, at 3:46 PM, Ian Chakeres wrote:
>>
>> Comments inline
>>
>> On Fri, Aug 21, 2009 at 3:16 PM, Justin  
>> Dean<jdean@itd.nrl.navy.mil> wrote:
>>
>> While I would prefer to be addressing these issues within the scope  
>> of a
>>
>> last call, my comments to the items in question are inline.
>>
>> <SNIP>
>>
>> #2) I don't see how to run multiple NHDP instances on the same
>>
>> interface or same router. PacketBB says that only one protocol
>>
>> instance can accept a particular message. Currently there is no way  
>> to
>>
>> identify which NHDP instance a NHDP message should be delivered.
>>
>> Packetbb, RFC 5444, disallows this behavior.  Having more than one  
>> NHDP
>>
>> instance on an interface will result in ambiguous behaviors.
>>
>> RFC 5444 does not disallow the behavior I described. It does disallow
>> having multiple NHDP instances receive the same message. Therefore,
>> there must be a way to determine the instance of NHDP to which a
>> message should be delivered.
>>
>>
>> RFC5444 reads:
>> o For each Message Type, a protocol -- unless specified otherwise,
>> the one making the IANA reservation for that Message Type -- MUST
>> be designated as the "owner" of that Message Type.
>>
>> <SNIP>
>>
>>   o  Incoming messages MUST be either silently discarded or MUST be
>>      delivered to the instance of the protocol that owns the  
>> associated
>>      Message Type.  Incoming messages SHOULD NOT be delivered to any
>>      other protocol instances and SHOULD NOT be delivered to more  
>> than
>>      one protocol instance.
>>
>> The detail you're to be looking carefully at is in the first  
>> sentence of the
>> second bullet.
>> I believe that this addresses the issue fully.
>> Thomas
>>
>>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From thomas@thomasclausen.org  Mon Aug 31 06:09:44 2009
Return-Path: <thomas@thomasclausen.org>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 225D628C134 for <manet@core3.amsl.com>; Mon, 31 Aug 2009 06:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.539
X-Spam-Level: 
X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvI9rezNzo8O for <manet@core3.amsl.com>; Mon, 31 Aug 2009 06:09:43 -0700 (PDT)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 6A99C3A67DF for <manet@ietf.org>; Mon, 31 Aug 2009 06:09:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AF538430363; Mon, 31 Aug 2009 06:09:54 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from new-host-19.SME (ASte-Genev-Bois-153-1-82-253.w81-48.abo.wanadoo.fr [81.48.32.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 54AE8430362; Mon, 31 Aug 2009 06:09:53 -0700 (PDT)
Message-Id: <5D3C73FB-F590-4AFE-BCF1-8FE3A1428686@thomasclausen.org>
From: Thomas Heide Clausen <thomas@thomasclausen.org>
To: Ian Chakeres <ian.chakeres@gmail.com>
In-Reply-To: <374005f30908310605m68c5c77bg69ea32c5b43c15dc@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 31 Aug 2009 15:09:50 +0200
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com> <F6D30C7F-9DF4-4AF4-BD1B-B17C69A6B58D@thomasclausen.org> <374005f30908310605m68c5c77bg69ea32c5b43c15dc@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, MANET IETF <manet@ietf.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 13:09:44 -0000

On Aug 31, 2009, at 3:05 PM, Ian Chakeres wrote:

> I believe there are several design decisions involving higher
> complexity. beyond that of simply a 2-hop neighbor hello protocol,
> that have been introduced into NHDP to enable and facilitation reduced
> relay sets. I feel that a person outside MANET would be perplexed why
> things are written the way they are written.
>

The main complexity in NHDP is due to the fact that *correctly*  
detecting bidirectionality between pairs of wireless interfaces,  
especially when faced with routers with multiple interfaces  
potentially operating in the same spectrum, is a complex task.

Thomas

> I know that this complexity issue was one of the major things that
> Elwyn Davies had identified in NHDP-05. I will ask if he can review
> the document again to see if the current specification satisfies him.
>
> Ian Chakeres
>
> On Fri, Aug 28, 2009 at 11:50 AM, Thomas Heide
> Clausen<thomas@thomasclausen.org> wrote:
>> I would, like Justin, much prefer addressing these issues within  
>> the scope
>> of a last call, corresponding to the consensus at the Stockholm WG  
>> meeting.
>>
>> Comment below.
>>
>> On Aug 21, 2009, at 7:53 PM, Ian Chakeres wrote:
>>
>> #5) I would like text explaining why NHDP is such a complex HELLO
>> protocol, specifically that NHDP was build to assist in calculating
>> reduced relay sets (e.g. MPR, CDS). I think this stated purpose will
>> be helpful in explaining why certain information is included and the
>> overall design of the protocol.
>>
>>
>> The current draft-ietf-manet-nhdp-10 (as well as all revisions back  
>> until
>> draft-ietf-manet-nhdp-07, dated July 10 2008) explicitly states in  
>> section
>> 1.1 that:
>>
>>   MANET routing protocols, for example [RFC3626] and [RFC5449], often
>>   employ relay set reductions in order to conserve network capacity
>>   when maintaining network-wide topological information, with
>>   calculation of these reduced relay sets employing up to two hop
>>   information.
>>
>> I believe that this addresses the issue fully.
>> Thomas
>>


From ian.chakeres@gmail.com  Mon Aug 31 06:13:33 2009
Return-Path: <ian.chakeres@gmail.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5223A6A4C for <manet@core3.amsl.com>; Mon, 31 Aug 2009 06:13:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRXhZGQGAIwz for <manet@core3.amsl.com>; Mon, 31 Aug 2009 06:13:32 -0700 (PDT)
Received: from mail-qy0-f194.google.com (mail-qy0-f194.google.com [209.85.221.194]) by core3.amsl.com (Postfix) with ESMTP id 4CFED3A6D8A for <manet@ietf.org>; Mon, 31 Aug 2009 06:13:32 -0700 (PDT)
Received: by qyk32 with SMTP id 32so702838qyk.19 for <manet@ietf.org>; Mon, 31 Aug 2009 06:13:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=gJG9kAzVjG3yLctHd2ejOInH8vp1WNwST0959sE0J1s=; b=s1+UrmFf4hHXrv95rs/PhOOnt5xt6gGX6gIfLYByxDWCt+HM9kkvl9kVlJPbQkLpQh IZ+nJfNUNNOubsvv5gjvpYlNmZM1NqGo7I7qP0UqdhZvbOGythB25toPMSxbI2RtvweA uwmPT+W5QdmdHHgTK8B6NMWPfGcpDt9JN47OA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=FAqc3+M1gI8vHmiDQnYTKEYyYn4jnG5s/i0myKR0cR8QFtxCLJxPMtDDQ/UgCWDwtZ RyOd3xJB45EYX9rJa9d9MbmyZ2/jFB1urCZ62546WrxaNDyXtsW6YKh5xCKXA83ZAn4I HK347jHcxLi5UJd1xKvRzzJKCAfbtd8hdR+vA=
MIME-Version: 1.0
Received: by 10.229.41.74 with SMTP id n10mr1527552qce.13.1251724418297; Mon,  31 Aug 2009 06:13:38 -0700 (PDT)
In-Reply-To: <6C06D2E5-E45B-4D59-9476-D4F35532350E@thomasclausen.org>
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com>  <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil> <374005f30908270646xc962c8bhd0460759612c66f1@mail.gmail.com>  <B58F3053-D6E9-4B2B-A757-8110EE628AC8@thomasclausen.org> <374005f30908310555x239dd199x4fdcfef7bdf48e91@mail.gmail.com>  <6C06D2E5-E45B-4D59-9476-D4F35532350E@thomasclausen.org>
From: Ian Chakeres <ian.chakeres@gmail.com>
Date: Mon, 31 Aug 2009 09:13:18 -0400
Message-ID: <374005f30908310613t22c8c481re51a25029ccda4fb@mail.gmail.com>
To: Thomas Heide Clausen <thomas@thomasclausen.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, MANET IETF <manet@ietf.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 13:13:33 -0000

I believe that conceptually, NHDP and the other WG protocols should
allow multiple areas of information to be administratively separated,
especially since wireless will not provide any strict physical
separation.

Ian Chakeres

On Mon, Aug 31, 2009 at 9:07 AM, Thomas Heide
Clausen<thomas@thomasclausen.org> wrote:
>
> On Aug 31, 2009, at 2:55 PM, Ian Chakeres wrote:
>
>> If the term "instance" is excluded by a SHOULD, let's instead use the
>> term "area" or another term to logically separate NHDP information. Is
>> there a term you prefer?
>>
>
> It is not a matter of preferring a term over the other, it's a conceptual
> matter.
>
>> I think the ability to identify/separate information and allow
>> multiple people to use the same physical medium is especially
>> important in wireless networks.
>
> NHDP simply detects connectivity. If a protocol (such as SMF) wants to be
> further discriminative as to which connectivity it wants to use, then thi=
s
> is a task for that protocol (e.g. by decorating with TLVs) - and most
> certainly not for NHDP.
>
> You can even construct an efficiency argument as for why this would be a =
bad
> thing to do.
>
> Thomas
>
>> Ian
>>
>> On Thu, Aug 27, 2009 at 9:58 AM, Thomas Heide
>> Clausen<thomas@thomasclausen.org> wrote:
>>>
>>> I would, like Justin, much prefer addressing these issues within the
>>> scope
>>> of a last call, corresponding to the consensus at the Stockholm WG
>>> meeting.
>>> Comment below.
>>> On Aug 27, 2009, at 3:46 PM, Ian Chakeres wrote:
>>>
>>> Comments inline
>>>
>>> On Fri, Aug 21, 2009 at 3:16 PM, Justin Dean<jdean@itd.nrl.navy.mil>
>>> wrote:
>>>
>>> While I would prefer to be addressing these issues within the scope of =
a
>>>
>>> last call, my comments to the items in question are inline.
>>>
>>> <SNIP>
>>>
>>> #2) I don't see how to run multiple NHDP instances on the same
>>>
>>> interface or same router. PacketBB says that only one protocol
>>>
>>> instance can accept a particular message. Currently there is no way to
>>>
>>> identify which NHDP instance a NHDP message should be delivered.
>>>
>>> Packetbb, RFC 5444, disallows this behavior. =A0Having more than one NH=
DP
>>>
>>> instance on an interface will result in ambiguous behaviors.
>>>
>>> RFC 5444 does not disallow the behavior I described. It does disallow
>>> having multiple NHDP instances receive the same message. Therefore,
>>> there must be a way to determine the instance of NHDP to which a
>>> message should be delivered.
>>>
>>>
>>> RFC5444 reads:
>>> o For each Message Type, a protocol -- unless specified otherwise,
>>> the one making the IANA reservation for that Message Type -- MUST
>>> be designated as the "owner" of that Message Type.
>>>
>>> <SNIP>
>>>
>>> =A0o =A0Incoming messages MUST be either silently discarded or MUST be
>>> =A0 =A0 delivered to the instance of the protocol that owns the associa=
ted
>>> =A0 =A0 Message Type. =A0Incoming messages SHOULD NOT be delivered to a=
ny
>>> =A0 =A0 other protocol instances and SHOULD NOT be delivered to more th=
an
>>> =A0 =A0 one protocol instance.
>>>
>>> The detail you're to be looking carefully at is in the first sentence o=
f
>>> the
>>> second bullet.
>>> I believe that this addresses the issue fully.
>>> Thomas
>>>
>>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>
>

From thomas@thomasclausen.org  Mon Aug 31 06:29:27 2009
Return-Path: <thomas@thomasclausen.org>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CE7F3A6BC3 for <manet@core3.amsl.com>; Mon, 31 Aug 2009 06:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.549
X-Spam-Level: 
X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVgBE5585WZG for <manet@core3.amsl.com>; Mon, 31 Aug 2009 06:29:26 -0700 (PDT)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7FE373A69EF for <manet@ietf.org>; Mon, 31 Aug 2009 06:29:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7A592430622; Mon, 31 Aug 2009 06:29:37 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from new-host-19.SME (ASte-Genev-Bois-153-1-82-253.w81-48.abo.wanadoo.fr [81.48.32.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 15EB6430360; Mon, 31 Aug 2009 06:29:35 -0700 (PDT)
Message-Id: <7319BA2A-5B80-4D11-84EE-5A55799DFBC9@thomasclausen.org>
From: Thomas Heide Clausen <thomas@thomasclausen.org>
To: Ian Chakeres <ian.chakeres@gmail.com>
In-Reply-To: <374005f30908310613t22c8c481re51a25029ccda4fb@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 31 Aug 2009 15:29:33 +0200
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com> <000501ca2293$ddbda290$9938e7b0$@nrl.navy.mil> <374005f30908270646xc962c8bhd0460759612c66f1@mail.gmail.com> <B58F3053-D6E9-4B2B-A757-8110EE628AC8@thomasclausen.org> <374005f30908310555x239dd199x4fdcfef7bdf48e91@mail.gmail.com> <6C06D2E5-E45B-4D59-9476-D4F35532350E@thomasclausen.org> <374005f30908310613t22c8c481re51a25029ccda4fb@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, MANET IETF <manet@ietf.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 13:29:27 -0000

NHDP detects connectivity over the wireless medium. Nothing more,  
nothing less.

If another protocol wishes to do something additional, require  
something additional for admitting a communicating pair into its  
operation, then that protocol should be responsible for determining  
such. An example: An SMF router may wish to discriminate among other  
SMF routers based on their relay algorithm capabilities. Therefore,  
SMF includes a way of doing such. And NHDP includes a way for SMF to  
embed necessary signaling in NHDP HELLO messages by way of TLVs.

Alternatively, for each perceived "administrative separation" (such as  
"for each relay selection algorithm in SMF"), you would have to send  
distinct HELLO messages over the same interface and so consume network  
capacity for no good reason whatsoever, and for no benefit whatsoever.

This is not an NHDP issue, this is an issue for protocols using NHDP  
-- and (as we have seen in SMF), "administratively separated areas" is  
*not* sufficient to be a solution.

I therefore maintain my position on this matter -- that NHDP  
definitely should not do anything more than detect connectivity over  
the wireless medium.

Thomas

On Aug 31, 2009, at 3:13 PM, Ian Chakeres wrote:

> I believe that conceptually, NHDP and the other WG protocols should
> allow multiple areas of information to be administratively separated,
> especially since wireless will not provide any strict physical
> separation.
>
> Ian Chakeres
>
> On Mon, Aug 31, 2009 at 9:07 AM, Thomas Heide
> Clausen<thomas@thomasclausen.org> wrote:
>>
>> On Aug 31, 2009, at 2:55 PM, Ian Chakeres wrote:
>>
>>> If the term "instance" is excluded by a SHOULD, let's instead use  
>>> the
>>> term "area" or another term to logically separate NHDP  
>>> information. Is
>>> there a term you prefer?
>>>
>>
>> It is not a matter of preferring a term over the other, it's a  
>> conceptual
>> matter.
>>
>>> I think the ability to identify/separate information and allow
>>> multiple people to use the same physical medium is especially
>>> important in wireless networks.
>>
>> NHDP simply detects connectivity. If a protocol (such as SMF) wants  
>> to be
>> further discriminative as to which connectivity it wants to use,  
>> then this
>> is a task for that protocol (e.g. by decorating with TLVs) - and most
>> certainly not for NHDP.
>>
>> You can even construct an efficiency argument as for why this would  
>> be a bad
>> thing to do.
>>
>> Thomas
>>
>>> Ian
>>>
>>> On Thu, Aug 27, 2009 at 9:58 AM, Thomas Heide
>>> Clausen<thomas@thomasclausen.org> wrote:
>>>>
>>>> I would, like Justin, much prefer addressing these issues within  
>>>> the
>>>> scope
>>>> of a last call, corresponding to the consensus at the Stockholm WG
>>>> meeting.
>>>> Comment below.
>>>> On Aug 27, 2009, at 3:46 PM, Ian Chakeres wrote:
>>>>
>>>> Comments inline
>>>>
>>>> On Fri, Aug 21, 2009 at 3:16 PM, Justin  
>>>> Dean<jdean@itd.nrl.navy.mil>
>>>> wrote:
>>>>
>>>> While I would prefer to be addressing these issues within the  
>>>> scope of a
>>>>
>>>> last call, my comments to the items in question are inline.
>>>>
>>>> <SNIP>
>>>>
>>>> #2) I don't see how to run multiple NHDP instances on the same
>>>>
>>>> interface or same router. PacketBB says that only one protocol
>>>>
>>>> instance can accept a particular message. Currently there is no  
>>>> way to
>>>>
>>>> identify which NHDP instance a NHDP message should be delivered.
>>>>
>>>> Packetbb, RFC 5444, disallows this behavior.  Having more than  
>>>> one NHDP
>>>>
>>>> instance on an interface will result in ambiguous behaviors.
>>>>
>>>> RFC 5444 does not disallow the behavior I described. It does  
>>>> disallow
>>>> having multiple NHDP instances receive the same message. Therefore,
>>>> there must be a way to determine the instance of NHDP to which a
>>>> message should be delivered.
>>>>
>>>>
>>>> RFC5444 reads:
>>>> o For each Message Type, a protocol -- unless specified otherwise,
>>>> the one making the IANA reservation for that Message Type -- MUST
>>>> be designated as the "owner" of that Message Type.
>>>>
>>>> <SNIP>
>>>>
>>>>  o  Incoming messages MUST be either silently discarded or MUST be
>>>>     delivered to the instance of the protocol that owns the  
>>>> associated
>>>>     Message Type.  Incoming messages SHOULD NOT be delivered to any
>>>>     other protocol instances and SHOULD NOT be delivered to more  
>>>> than
>>>>     one protocol instance.
>>>>
>>>> The detail you're to be looking carefully at is in the first  
>>>> sentence of
>>>> the
>>>> second bullet.
>>>> I believe that this addresses the issue fully.
>>>> Thomas
>>>>
>>>>
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>
>>


From rogge@fgan.de  Mon Aug 31 06:38:16 2009
Return-Path: <rogge@fgan.de>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E094A28C278 for <manet@core3.amsl.com>; Mon, 31 Aug 2009 06:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Level: 
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTM8MXmh5KOZ for <manet@core3.amsl.com>; Mon, 31 Aug 2009 06:38:15 -0700 (PDT)
Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id C597D3A6E30 for <manet@ietf.org>; Mon, 31 Aug 2009 06:38:15 -0700 (PDT)
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <rogge@fgan.de>) id 1Mi75T-0004XN-8C; Mon, 31 Aug 2009 15:38:23 +0200
Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <rogge@fgan.de>) id 1Mi75S-0000AH-Vq; Mon, 31 Aug 2009 15:38:23 +0200
From: Henning Rogge <rogge@fgan.de>
To: manet@ietf.org
Date: Mon, 31 Aug 2009 15:38:15 +0200
User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; )
References: <374005f30908211053h6c18fa78s310cdc9f5246b496@mail.gmail.com> <374005f30908310613t22c8c481re51a25029ccda4fb@mail.gmail.com> <7319BA2A-5B80-4D11-84EE-5A55799DFBC9@thomasclausen.org>
In-Reply-To: <7319BA2A-5B80-4D11-84EE-5A55799DFBC9@thomasclausen.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2998255.otViZqOpJG"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200908311538.21014.rogge@fgan.de>
X-Virus-Scanned: yes (ClamAV 0.95.2/9760/Mon Aug 31 04:58:26 2009) by mailguard.fgan.de
X-Scan-Signature: 09b0da2657adb768aee0f359cc63be9c
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [manet] Some NHDP Concerns
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 13:38:17 -0000

--nextPart2998255.otViZqOpJG
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Mon August 31 2009 15:29:33 schrieb Thomas Heide Clausen:
> NHDP detects connectivity over the wireless medium. Nothing more,
> nothing less.
>
> If another protocol wishes to do something additional, require
> something additional for admitting a communicating pair into its
> operation, then that protocol should be responsible for determining
> such. An example: An SMF router may wish to discriminate among other
> SMF routers based on their relay algorithm capabilities. Therefore,
> SMF includes a way of doing such. And NHDP includes a way for SMF to
> embed necessary signaling in NHDP HELLO messages by way of TLVs.
>
> Alternatively, for each perceived "administrative separation" (such as
> "for each relay selection algorithm in SMF"), you would have to send
> distinct HELLO messages over the same interface and so consume network
> capacity for no good reason whatsoever, and for no benefit whatsoever.
>
> This is not an NHDP issue, this is an issue for protocols using NHDP
> -- and (as we have seen in SMF), "administratively separated areas" is
> *not* sufficient to be a solution.
>
> I therefore maintain my position on this matter -- that NHDP
> definitely should not do anything more than detect connectivity over
> the wireless medium.
I agree to this.

NHDP as a protocol does not need to know anything except a very basic=20
"presence service". It records what connections it has to it's one hop=20
neighbors and their connection to other neighbors. Nothing more, nothing le=
ss.

NHDP implementations might do more stuff, because other protocols like SMF =
or=20
OLSRv2 add additional TLVs to the hello messages to be more efficient. What=
=20
these TLVs do is out of scope for the NHDP protocol, but the implementation=
=20
needs some kind of multiplexer if you want to allow multiple other protocol=
s=20
enhancing NHDP. Normally NHDP will be integrated with another protocol (or=
=20
multiple protocols) into a single implementation, but thats beyond the scop=
e=20
of the protocol.

Henning Rogge

*************************************************
Diplom Informatiker Henning Rogge
=46orschungsgesellschaft f=FCr
Angewandte Naturwissenschaften e. V. (FGAN)=20
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
=46ax: 0049 (0)228 9435-685
E-Mail: rogge@fgan.de
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender=20
(Stellv.)


--nextPart2998255.otViZqOpJG
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkqb0kcACgkQRIfGfFXsz+A+2wCfW9UiTjF+Q4J2OPuCqQqXjHLb
NMMAnRwQ6fhjwrKjHGnme+0tXM6l/Oh9
=d+M7
-----END PGP SIGNATURE-----

--nextPart2998255.otViZqOpJG--

From ian.chakeres@gmail.com  Mon Aug 31 06:45:17 2009
Return-Path: <ian.chakeres@gmail.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 995B23A6E05 for <manet@core3.amsl.com>; Mon, 31 Aug 2009 06:45:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncOkTHo8Qpa0 for <manet@core3.amsl.com>; Mon, 31 Aug 2009 06:45:16 -0700 (PDT)
Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id B86493A6CAB for <manet@ietf.org>; Mon, 31 Aug 2009 06:45:16 -0700 (PDT)
Received: by qw-out-2122.google.com with SMTP id 5so1137146qwi.31 for <manet@ietf.org>; Mon, 31 Aug 2009 06:45:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=Di5QVQ3uDZNT7wdJaL3btQ6dgQlwc1R6sy3YZ2F/LdE=; b=K1x49EWCYv8EjClPVoDKyTlwavewxOvt0rkiEV066GG+IrZIUtnIoF18hZ9e8NGzzG Pm0N9pPLLgzIwut7V+F4LfpNbtLP0YueUxHYoukGGMrrqmc1zZut4d/DWYnkNaK+W4Do yE5qYXin+dcyiT3K6ULNaQhypJz8i15krUTv4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=jmACWF2Tw+fu5M+tL5NdDmf4s5DZVr6l6HBNFIhG297b3TWoBpXg0NgRWhH6k55BiD cumDQ0A6B1h+4d0T5Jh4so7MM/FTVTslQXD+IWd5WziNJ3BlDumgDjRUNd0JsOpZB8cb JNP9EHb4fa7kR19zFoyP+yjluxs9Lu5MQ9yp4=
MIME-Version: 1.0
Received: by 10.229.19.82 with SMTP id z18mr1514422qca.9.1251726324104; Mon,  31 Aug 2009 06:45:24 -0700 (PDT)
In-Reply-To: <374005f30908300545n55daabd8geb1450a4507fe10c@mail.gmail.com>
References: <374005f30908300545n55daabd8geb1450a4507fe10c@mail.gmail.com>
From: Ian Chakeres <ian.chakeres@gmail.com>
Date: Mon, 31 Aug 2009 09:45:00 -0400
Message-ID: <374005f30908310645n3850a570x74ec65043359c67@mail.gmail.com>
To: MANET IETF <manet@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [manet] draft-ietf-manet-nhdp-10.txt - WGLC - Oct 5th 2009
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 13:45:17 -0000

I am glad that several of the concerns I voiced last week are being
discussed. Based on the discussion, I believe that some of these
issues will be addressed in the next revision of NHDP (e.g. allow
unicast).

I feel the following are important and have not yet been resolved.

1) Words of wisdom for creating NHDP extensions, especially those
learned from OLSRv2 & SMF.

2) Administrative separation of information over wireless
communication, previously described as "instances" or "areas".

3) NHDP node identifiers.

4) Identifying interfaces, when they use the same address.

5) Some more tutorial information on why certain design decisions were
made that are not obvious to people outside MANET, especially as the
complexity relates to 2-way neighboring interfaces and 2-hop
neighboring information.

I encourage people to read the NHDP I-D and provide comments to the
authors on list.

Thanks.
Ian Chakeres

On Sun, Aug 30, 2009 at 8:45 AM, Ian Chakeres<ian.chakeres@gmail.com> wrote:
> This note announces the WG Last Call for comments on
> draft-ietf-manet-nhdp-10.txt, "MANET Neighborhood Discovery Protocol".
>
> The document can be found at:
> http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-10.txt
>
> The document is intended to be submitted for publication as an
> proposed standard document.
>
> Please review the document carefully and send your comments to the
> MANET list and document authors.
>
> This last call ends Sunday Oct 5th.
>
> Thanks,
> Ian Chakeres
>

From thomas@thomasclausen.org  Mon Aug 31 07:03:52 2009
Return-Path: <thomas@thomasclausen.org>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1D2D3A6AA3 for <manet@core3.amsl.com>; Mon, 31 Aug 2009 07:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.556
X-Spam-Level: 
X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPEIU237YwPk for <manet@core3.amsl.com>; Mon, 31 Aug 2009 07:03:51 -0700 (PDT)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2938D3A6A6E for <manet@ietf.org>; Mon, 31 Aug 2009 07:03:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2BDBC43036A; Mon, 31 Aug 2009 07:03:55 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from new-host-19.SME (ASte-Genev-Bois-153-1-82-253.w81-48.abo.wanadoo.fr [81.48.32.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 5DE114305BA; Mon, 31 Aug 2009 07:03:53 -0700 (PDT)
Message-Id: <300058BE-1E3E-4939-8360-34313F131405@thomasclausen.org>
From: Thomas Heide Clausen <thomas@thomasclausen.org>
To: Ian Chakeres <ian.chakeres@gmail.com>
In-Reply-To: <374005f30908310645n3850a570x74ec65043359c67@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 31 Aug 2009 16:03:51 +0200
References: <374005f30908300545n55daabd8geb1450a4507fe10c@mail.gmail.com> <374005f30908310645n3850a570x74ec65043359c67@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, MANET IETF <manet@ietf.org>
Subject: Re: [manet] draft-ietf-manet-nhdp-10.txt - WGLC - Oct 5th 2009
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 14:03:52 -0000

On Aug 31, 2009, at 3:45 PM, Ian Chakeres wrote:

> I am glad that several of the concerns I voiced last week are being
> discussed. Based on the discussion, I believe that some of these
> issues will be addressed in the next revision of NHDP (e.g. allow
> unicast).

Huh? I don't believe that there's been any support for unicast, but  
rather that we've all said that it's something that specifically does  
*not* warrant any explicit addressing in NHDP.

> I feel the following are important and have not yet been resolved.
>
> 1) Words of wisdom for creating NHDP extensions, especially those
> learned from OLSRv2 & SMF.

The way of designing extensions is not proper to NHDP, but to the  
whole grouping of RFC5444/RFC5498/NHDP/current-WG-protocols. In a  
sense, you suggest recording the "collective wisdom of the WG" -- not  
sure that we can do that ;) and certainly not in NHDP.

I therefore oppose adding such to the NHDP specification.

We can discuss (outside of this WGLC) if this is something that'd  
warrant being documented in an informational or BCP submission, though?

> 2) Administrative separation of information over wireless
> communication, previously described as "instances" or "areas".

Strongly disagree, the arguments have been presented previously.

> 3) NHDP node identifiers.

Strongly disagree, Justin has argued this well.

> 4) Identifying interfaces, when they use the same address.

Strongly disagree, Justin has argued this well.

> 5) Some more tutorial information on why certain design decisions were
> made that are not obvious to people outside MANET, especially as the
> complexity relates to 2-way neighboring interfaces and 2-hop
> neighboring information.

Strongly disagree, the arguments have been presented previously.

> I encourage people to read the NHDP I-D and provide comments to the
> authors on list.

On that, I agree 100% - reviews and constructive comments on manet@ietf.org 
  very welcome.

Thomas

>
> Thanks.
> Ian Chakeres
>
> On Sun, Aug 30, 2009 at 8:45 AM, Ian  
> Chakeres<ian.chakeres@gmail.com> wrote:
>> This note announces the WG Last Call for comments on
>> draft-ietf-manet-nhdp-10.txt, "MANET Neighborhood Discovery  
>> Protocol".
>>
>> The document can be found at:
>> http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-10.txt
>>
>> The document is intended to be submitted for publication as an
>> proposed standard document.
>>
>> Please review the document carefully and send your comments to the
>> MANET list and document authors.
>>
>> This last call ends Sunday Oct 5th.
>>
>> Thanks,
>> Ian Chakeres
>>


From rogge@fgan.de  Mon Aug 31 07:04:17 2009
Return-Path: <rogge@fgan.de>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458E93A6A29 for <manet@core3.amsl.com>; Mon, 31 Aug 2009 07:04:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.174
X-Spam-Level: 
X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtswGuUX+4yJ for <manet@core3.amsl.com>; Mon, 31 Aug 2009 07:04:16 -0700 (PDT)
Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 8A65F3A67D2 for <manet@ietf.org>; Mon, 31 Aug 2009 07:04:13 -0700 (PDT)
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <rogge@fgan.de>) id 1Mi7UZ-0005Du-RA; Mon, 31 Aug 2009 16:04:19 +0200
Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <rogge@fgan.de>) id 1Mi7UZ-0000Jd-E7; Mon, 31 Aug 2009 16:04:19 +0200
From: Henning Rogge <rogge@fgan.de>
To: manet@ietf.org
Date: Mon, 31 Aug 2009 16:04:12 +0200
User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; )
References: <374005f30908300545n55daabd8geb1450a4507fe10c@mail.gmail.com> <374005f30908310645n3850a570x74ec65043359c67@mail.gmail.com>
In-Reply-To: <374005f30908310645n3850a570x74ec65043359c67@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1269345.x8aZxeEGGg"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200908311604.17449.rogge@fgan.de>
X-Virus-Scanned: yes (ClamAV 0.95.2/9760/Mon Aug 31 04:58:26 2009) by mailguard.fgan.de
X-Scan-Signature: c5b001ed8a32557dab9f13d2bf4e6284
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [manet] draft-ietf-manet-nhdp-10.txt - WGLC - Oct 5th 2009
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 14:04:17 -0000

--nextPart1269345.x8aZxeEGGg
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Mon August 31 2009 15:45:00 schrieb Ian Chakeres:
> I am glad that several of the concerns I voiced last week are being
> discussed. Based on the discussion, I believe that some of these
> issues will be addressed in the next revision of NHDP (e.g. allow
> unicast).
>
> I feel the following are important and have not yet been resolved.
>
> 1) Words of wisdom for creating NHDP extensions, especially those
> learned from OLSRv2 & SMF.
SMF & OLSRv2 use NHDP as a "TLV transport service" to transport their own=20
neighbor-specific data. I don't think they really change/extend the behavio=
r=20
of NHDP (maybe I'm wrong)...

> 3) NHDP node identifiers.
(I assume that you are talking about something like the originator-address =
in=20
OLSR)

I talked with Thomas about this at the IETF meeting and he proposed that=20
originator-IPs/router-IDs can be required by the OLSRv2 specification. They=
=20
are not absolutely necessary for NHDP, but might help in some scenarios wit=
h=20
multiple interfaces using the same IP.

> 4) Identifying interfaces, when they use the same address.
I see two different scenarios here:

4a) one node with multiple interfaces, some of them using the same IP.

This is a bad idea, but I personally know there are users of OLSRv1 out the=
re=20
doing this, because it helps with certain routing problems. There is lots o=
f=20
trouble hidden with this configuration for NHDP, because cannot keep=20
differentiate between incoming messages from interfaces with sharing IPs=20
without additional information in the NHDP message.

4b) two different nodes with an interface configured to the same IP.

Shoot your admins... do it now !
I don't think there is much we can do in this case.

Henning Rogge




--nextPart1269345.x8aZxeEGGg
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkqb2FwACgkQRIfGfFXsz+BRvACePzTUTVVm11tKpoO4uI1Kz/Pm
tS8AnjJwH13URJourrv+e8i6juNWMHr2
=Tiuv
-----END PGP SIGNATURE-----

--nextPart1269345.x8aZxeEGGg--

From thomas@thomasclausen.org  Mon Aug 31 07:12:57 2009
Return-Path: <thomas@thomasclausen.org>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E6D3A6E44 for <manet@core3.amsl.com>; Mon, 31 Aug 2009 07:12:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.561
X-Spam-Level: 
X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eeu1AZaiDROT for <manet@core3.amsl.com>; Mon, 31 Aug 2009 07:12:56 -0700 (PDT)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 779633A6E41 for <manet@ietf.org>; Mon, 31 Aug 2009 07:12:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D3166430624; Mon, 31 Aug 2009 07:13:07 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from new-host-19.SME (ASte-Genev-Bois-153-1-82-253.w81-48.abo.wanadoo.fr [81.48.32.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id A980C430622; Mon, 31 Aug 2009 07:13:06 -0700 (PDT)
Message-Id: <18CC8F93-A0E6-465F-B88E-F90017A39032@thomasclausen.org>
From: Thomas Heide Clausen <thomas@thomasclausen.org>
To: Henning Rogge <rogge@fgan.de>
In-Reply-To: <200908311604.17449.rogge@fgan.de>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 31 Aug 2009 16:13:04 +0200
References: <374005f30908300545n55daabd8geb1450a4507fe10c@mail.gmail.com> <374005f30908310645n3850a570x74ec65043359c67@mail.gmail.com> <200908311604.17449.rogge@fgan.de>
X-Mailer: Apple Mail (2.936)
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, manet@ietf.org
Subject: Re: [manet] draft-ietf-manet-nhdp-10.txt - WGLC - Oct 5th 2009
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 14:12:57 -0000

Henning,

On Aug 31, 2009, at 4:04 PM, Henning Rogge wrote:

> Am Mon August 31 2009 15:45:00 schrieb Ian Chakeres:
>> I am glad that several of the concerns I voiced last week are being
>> discussed. Based on the discussion, I believe that some of these
>> issues will be addressed in the next revision of NHDP (e.g. allow
>> unicast).
>>
>> I feel the following are important and have not yet been resolved.
>>
>> 1) Words of wisdom for creating NHDP extensions, especially those
>> learned from OLSRv2 & SMF.
> SMF & OLSRv2 use NHDP as a "TLV transport service" to transport  
> their own
> neighbor-specific data. I don't think they really change/extend the  
> behavior
> of NHDP (maybe I'm wrong)...

That's pretty accurate, yeah. OLSRv2 and SMF do not modify the  
behavior of NHDP -- but stick information into NHDP to associate with  
information already carried by NHDP.

>
>> 3) NHDP node identifiers.
> (I assume that you are talking about something like the originator- 
> address in
> OLSR)
>
> I talked with Thomas about this at the IETF meeting and he proposed  
> that
> originator-IPs/router-IDs can be required by the OLSRv2  
> specification. They
> are not absolutely necessary for NHDP, but might help in some  
> scenarios with
> multiple interfaces using the same IP.

Actually (and Henning, I owe you an apology for not following up --  
actually took a couple of weeks off-line post-IETF this year),  
Christopher and I discussed this and a couple of auxiliary issues with  
Henning and Teco at the last IETF, and we've spent a bunch of time  
working it over. It's an OLSRv2 issue only, and the coming version of  
OLSRv2 will take this on-board as you guys suggested.

However, we'll discuss that OLSRv2 update outside of this NHDP WGLC  
when the updated I-D is out (the "weeks off-line post-IETF" are the  
reason that I-D has not emerged fully yet).

So that is an OLSRv2 issue, specifically NOT an NHDP issue.

>> 4) Identifying interfaces, when they use the same address.
> I see two different scenarios here:
>
> 4a) one node with multiple interfaces, some of them using the same IP.
>
> This is a bad idea, but I personally know there are users of OLSRv1  
> out there
> doing this, because it helps with certain routing problems. There is  
> lots of
> trouble hidden with this configuration for NHDP, because cannot keep
> differentiate between incoming messages from interfaces with sharing  
> IPs
> without additional information in the NHDP message.
>

>
> 4b) two different nodes with an interface configured to the same IP.
>
> Shoot your admins... do it now !

Well, I'd suggest something just a notch less drastic -- but the net  
result should be unique IP addresses ;)

> I don't think there is much we can do in this case.

Agree.

Thomas

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


From sratliff@cisco.com  Mon Aug 31 07:18:36 2009
Return-Path: <sratliff@cisco.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F127D3A6954 for <manet@core3.amsl.com>; Mon, 31 Aug 2009 07:18:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.293
X-Spam-Level: 
X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=0.306,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hR2ihnz0IDa for <manet@core3.amsl.com>; Mon, 31 Aug 2009 07:18:34 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A5F9B3A67C0 for <manet@ietf.org>; Mon, 31 Aug 2009 07:18:34 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAO54m0pAZnme/2dsb2JhbADAYIhBAY5iBYQagVo
X-IronPort-AV: E=Sophos;i="4.44,305,1249257600"; d="scan'208";a="56145301"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 Aug 2009 14:18:45 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7VEIjJ0004557;  Mon, 31 Aug 2009 10:18:45 -0400
Received: from rtp-sratliff-8714.cisco.com (rtp-sratliff-8714.cisco.com [10.116.179.213]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7VEIiSw017588; Mon, 31 Aug 2009 14:18:44 GMT
Message-Id: <3399E08B-5955-4D8F-8FB8-1DA8BFBA7AC3@cisco.com>
From: Stan Ratliff <sratliff@cisco.com>
To: Thomas Heide Clausen <Thomas@ThomasClausen.org>
In-Reply-To: <300058BE-1E3E-4939-8360-34313F131405@thomasclausen.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 31 Aug 2009 10:18:44 -0400
References: <374005f30908300545n55daabd8geb1450a4507fe10c@mail.gmail.com> <374005f30908310645n3850a570x74ec65043359c67@mail.gmail.com> <300058BE-1E3E-4939-8360-34313F131405@thomasclausen.org>
X-Mailer: Apple Mail (2.936)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3265; t=1251728325; x=1252592325; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20Stan=20Ratliff=20<sratliff@cisco.com> |Subject:=20Re=3A=20[manet]=20draft-ietf-manet-nhdp-10.txt= 20-=20WGLC=20-=20Oct=205th=202009 |Sender:=20 |To:=20Thomas=20Heide=20Clausen=20<Thomas@ThomasClausen.org >; bh=+EMjE1oHwyU6Xgs7RhyKRrS0PLLh4a+1Xrqh8mZcZPQ=; b=OaPtr+Y5NtdmZTBwtHQT/ua5HmYZNBKBzDg9eDrazYWOp56We/ALoY4/d+ 4Nt7IxLwdahQnzcUPjw/fhtWKnWOofMEE/mEOw0KErFry1OgVOrRNP51KBjq GAJZOP+vUW;
Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); 
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, MANET IETF <manet@ietf.org>
Subject: Re: [manet] draft-ietf-manet-nhdp-10.txt - WGLC - Oct 5th 2009
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 14:18:36 -0000

One comment inline.

On Aug 31, 2009, at 10:03 AM, Thomas Heide Clausen wrote:

>
> On Aug 31, 2009, at 3:45 PM, Ian Chakeres wrote:
>
>> I am glad that several of the concerns I voiced last week are being
>> discussed. Based on the discussion, I believe that some of these
>> issues will be addressed in the next revision of NHDP (e.g. allow
>> unicast).
>
> Huh? I don't believe that there's been any support for unicast, but  
> rather that we've all said that it's something that specifically  
> does *not* warrant any explicit addressing in NHDP.
>
>> I feel the following are important and have not yet been resolved.
>>
>> 1) Words of wisdom for creating NHDP extensions, especially those
>> learned from OLSRv2 & SMF.
>
> The way of designing extensions is not proper to NHDP, but to the  
> whole grouping of RFC5444/RFC5498/NHDP/current-WG-protocols. In a  
> sense, you suggest recording the "collective wisdom of the WG" --  
> not sure that we can do that ;) and certainly not in NHDP.
>
> I therefore oppose adding such to the NHDP specification.
>
> We can discuss (outside of this WGLC) if this is something that'd  
> warrant being documented in an informational or BCP submission,  
> though?
>
>> 2) Administrative separation of information over wireless
>> communication, previously described as "instances" or "areas".
>
> Strongly disagree, the arguments have been presented previously.
>
>> 3) NHDP node identifiers.
>
> Strongly disagree, Justin has argued this well.
>
>> 4) Identifying interfaces, when they use the same address.
>
> Strongly disagree, Justin has argued this well.
>

Some of our deployments use ip unnumbered interfaces. It has to do  
with the type of radio deployed (radios implementing RFC4938), and use  
of PPPoE in the router. I'd hate to preclude use of NHDP in these  
deployments.

Regards,
Stan



>> 5) Some more tutorial information on why certain design decisions  
>> were
>> made that are not obvious to people outside MANET, especially as the
>> complexity relates to 2-way neighboring interfaces and 2-hop
>> neighboring information.
>
> Strongly disagree, the arguments have been presented previously.
>
>> I encourage people to read the NHDP I-D and provide comments to the
>> authors on list.
>
> On that, I agree 100% - reviews and constructive comments on manet@ietf.org 
>  very welcome.
>
> Thomas
>
>>
>> Thanks.
>> Ian Chakeres
>>
>> On Sun, Aug 30, 2009 at 8:45 AM, Ian  
>> Chakeres<ian.chakeres@gmail.com> wrote:
>>> This note announces the WG Last Call for comments on
>>> draft-ietf-manet-nhdp-10.txt, "MANET Neighborhood Discovery  
>>> Protocol".
>>>
>>> The document can be found at:
>>> http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-10.txt
>>>
>>> The document is intended to be submitted for publication as an
>>> proposed standard document.
>>>
>>> Please review the document carefully and send your comments to the
>>> MANET list and document authors.
>>>
>>> This last call ends Sunday Oct 5th.
>>>
>>> Thanks,
>>> Ian Chakeres
>>>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From thomas@thomasclausen.org  Mon Aug 31 07:23:40 2009
Return-Path: <thomas@thomasclausen.org>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398AA28C285 for <manet@core3.amsl.com>; Mon, 31 Aug 2009 07:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.265
X-Spam-Level: 
X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbH4iHOUVxfw for <manet@core3.amsl.com>; Mon, 31 Aug 2009 07:23:38 -0700 (PDT)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id C48D13A68D5 for <manet@ietf.org>; Mon, 31 Aug 2009 07:23:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2BF50430624 for <manet@ietf.org>; Mon, 31 Aug 2009 07:23:50 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from new-host-19.SME (ASte-Genev-Bois-153-1-82-253.w81-48.abo.wanadoo.fr [81.48.32.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id DEFE943062A for <manet@ietf.org>; Mon, 31 Aug 2009 07:23:48 -0700 (PDT)
Message-Id: <D12071A0-A6A7-4E20-8228-C5C3F027B32C@thomasclausen.org>
From: Thomas Heide Clausen <thomas@thomasclausen.org>
To: MANET IETF <manet@ietf.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-11-691003165
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 31 Aug 2009 16:23:46 +0200
References: <E25514C2-65D5-4D35-9EB5-D7DFABDE5050@thomasclausen.org>
X-Mailer: Apple Mail (2.936)
Subject: [manet] Fwd: Annual OLSR Interop 2009 details
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 14:23:40 -0000

--Apple-Mail-11-691003165
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

And, Ian told me that this email didn't get through correctly either,  
that he did something to the list-filters and asked me to resend. So  
here goes again....

Third time is a charm, right?

Well, see y'all in Vienna!

Thomas


Begin forwarded message:

> From: Thomas Heide Clausen <thomas@thomasclausen.org>
> Date: August 28, 2009 2:08:44 PM CEDT
> To: MANET IETF <manet@ietf.org>
> Cc: Joseph Macker <macker@itd.nrl.navy.mil>, Ian Chakeres <ian.chakeres@gmail.com 
> >
> Subject: Annual OLSR Interop 2009 details
>
> (It seems that the email I sent to the list during the Stockholm  
> IETF never hit the archives, so I am trying again - wonder if I'm  
> hitting some sort of "spam filter", wg chairs, will you check that?)
>
> ===
>
> Folks,
>
> As announced in both San Francisco and earlier this week in  
> Stockholm, the next OLSR Interop/Workshop is being held in Vienna,  
> hosted by Funkfeuer.at in early October (2-4).
>
> The usual format: one day of "workshop", where emphasis will be on  
> practical experiences with either of OLSR, OLSRv2 or its constituent  
> parts (and extensions hereto), followed by two days of interop  
> testing and hacking.
>
> Here's an URL with further information, and a link to where you can  
> register for attending:
>
> 	http://interop.thomasclausen.org/Interop09/
>
> If you have an implementation of OLSR, OLSRv2 or any of its  
> constituent parts, please do join us! It's usually great fun, and  
> usually very constructive.
>
> Questions or comments: don't hesitate to contact me.
>
> Cheers,
>
> Thomas
>
>


--Apple-Mail-11-691003165
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">And, Ian told me that this =
email didn't get through correctly either, that he did something to the =
list-filters and asked me to resend. So here goes =
again....<div><br></div><div>Third time is a charm, =
right?</div><div><br></div><div>Well, see y'all in =
Vienna!</div><div><br></div><div>Thomas</div><div><br><div><br><div>Begin =
forwarded message:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><b>From: =
</b></font><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Thomas Heide Clausen &lt;<a =
href=3D"mailto:thomas@thomasclausen.org">thomas@thomasclausen.org</a>&gt;<=
/font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><b>Date: </b></font><font face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">August 28, 2009 2:08:44 PM =
CEDT</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><b>To: </b></font><font face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">MANET IETF &lt;<a =
href=3D"mailto:manet@ietf.org">manet@ietf.org</a>&gt;</font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><b>Cc: </b></font><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">Joseph =
Macker &lt;<a =
href=3D"mailto:macker@itd.nrl.navy.mil">macker@itd.nrl.navy.mil</a>&gt;, =
Ian Chakeres &lt;<a =
href=3D"mailto:ian.chakeres@gmail.com">ian.chakeres@gmail.com</a>&gt;</fon=
t></div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; "><font face=3D"Helvetica" size=3D"3" =
color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><b>Subject: </b></font><font face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica"><b>Annual OLSR Interop 2009 =
details</b></font></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><br></div> </div><div>(It seems that the email I sent to the list =
during the Stockholm IETF never hit the archives, so I am trying again - =
wonder if I'm hitting some sort of "spam filter", wg chairs, will you =
check that?)<br><br>=3D=3D=3D<br><br>Folks,<br><br>As announced in both =
San Francisco and earlier this week in Stockholm, the next OLSR =
Interop/Workshop is being held in Vienna, hosted by Funkfeuer.at in =
early October (2-4).<br><br>The usual format: one day of "workshop", =
where emphasis will be on practical experiences with either of OLSR, =
OLSRv2 or its constituent parts (and extensions hereto), followed by two =
days of interop testing and hacking.<br><br>Here's an URL with further =
information, and a link to where you can register for =
attending:<br><br><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span><a =
href=3D"http://interop.thomasclausen.org/Interop09/">http://interop.thomas=
clausen.org/Interop09/</a><br><br>If you have an implementation of OLSR, =
OLSRv2 or any of its constituent parts, please do join us! It's usually =
great fun, and usually very constructive.<br><br>Questions or comments: =
don't hesitate to contact =
me.<br><br>Cheers,<br><br>Thomas<br><br><br></div></blockquote></div><br><=
/div></body></html>=

--Apple-Mail-11-691003165--

From Thomas@ThomasClausen.org  Mon Aug 31 07:27:21 2009
Return-Path: <Thomas@ThomasClausen.org>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7285F28C28D for <manet@core3.amsl.com>; Mon, 31 Aug 2009 07:27:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.538
X-Spam-Level: 
X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn5ybY6KBfGE for <manet@core3.amsl.com>; Mon, 31 Aug 2009 07:27:20 -0700 (PDT)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id AF26D3A6E1D for <manet@ietf.org>; Mon, 31 Aug 2009 07:27:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1C98343062A; Mon, 31 Aug 2009 07:27:32 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from new-host-19.SME (ASte-Genev-Bois-153-1-82-253.w81-48.abo.wanadoo.fr [81.48.32.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 794E0430622; Mon, 31 Aug 2009 07:27:30 -0700 (PDT)
Message-Id: <E736189F-7C38-4CBD-9EBE-480A12185475@ThomasClausen.org>
From: Thomas Heide Clausen <Thomas@ThomasClausen.org>
To: Stan Ratliff <sratliff@cisco.com>
In-Reply-To: <3399E08B-5955-4D8F-8FB8-1DA8BFBA7AC3@cisco.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-12-691224986
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 31 Aug 2009 16:27:28 +0200
References: <374005f30908300545n55daabd8geb1450a4507fe10c@mail.gmail.com> <374005f30908310645n3850a570x74ec65043359c67@mail.gmail.com> <300058BE-1E3E-4939-8360-34313F131405@thomasclausen.org> <3399E08B-5955-4D8F-8FB8-1DA8BFBA7AC3@cisco.com>
X-Mailer: Apple Mail (2.936)
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, MANET IETF <manet@ietf.org>
Subject: Re: [manet] draft-ietf-manet-nhdp-10.txt - WGLC - Oct 5th 2009
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 14:27:21 -0000

--Apple-Mail-12-691224986
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit


On Aug 31, 2009, at 4:18 PM, Stan Ratliff wrote:

> One comment inline.
>>
>>> 4) Identifying interfaces, when they use the same address.
>>
>> Strongly disagree, Justin has argued this well.
>>
>
> Some of our deployments use ip unnumbered interfaces. It has to do  
> with the type of radio deployed (radios implementing RFC4938), and  
> use of PPPoE in the router. I'd hate to preclude use of NHDP in  
> these deployments.
>
> Regards,
> Stan
>

Stan,

Your thoughts are usually worth listening to -- can you be a little  
more explicit, does NHDP as-is somehow contradict the deployments that  
you target?

IOW, would NHDP as currently described work or not-work for you?

I suspect that NHDP would work, and that making it do so would be a  
deployment issue -- but as I do not know details of your deployments,  
I'd like to make sure that they're actually covered?

Thanks,

Thomas
--Apple-Mail-12-691224986
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><br><div><div>On Aug 31, 2009, =
at 4:18 PM, Stan Ratliff wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>One =
comment inline.<br><blockquote type=3D"cite"><font =
class=3D"Apple-style-span" =
color=3D"#144FAE"><br></font></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">4) Identifying interfaces, when =
they use the same address.<br></blockquote></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Strongly =
disagree, Justin has argued this well.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><br>Some of our deployments use ip =
unnumbered interfaces. It has to do with the type of radio deployed =
(radios implementing RFC4938), and use of PPPoE in the router. I'd hate =
to preclude use of NHDP in these =
deployments.<br><br>Regards,<br>Stan<br><br></div></blockquote><div><br></=
div>Stan,</div><div><br></div><div>Your thoughts are usually worth =
listening to -- can you be a little more explicit, does NHDP as-is =
somehow contradict the deployments that you =
target?</div><div><br></div><div>IOW, would NHDP as currently described =
work or not-work for you?</div><div><br></div><div>I suspect that NHDP =
would work, and that making it do so would be a deployment issue -- but =
as I do not know details of your deployments, I'd like to make sure that =
they're actually =
covered?</div><div><br></div><div>Thanks,</div><div><br></div><div>Thomas<=
/div></body></html>=

--Apple-Mail-12-691224986--

From sratliff@cisco.com  Mon Aug 31 08:09:55 2009
Return-Path: <sratliff@cisco.com>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B62623A696B for <manet@core3.amsl.com>; Mon, 31 Aug 2009 08:09:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.327
X-Spam-Level: 
X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=0.271,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FAXCLDhkLpi for <manet@core3.amsl.com>; Mon, 31 Aug 2009 08:09:54 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 7E46F3A6966 for <manet@ietf.org>; Mon, 31 Aug 2009 08:09:54 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuIEAKuEm0pAZnme/2dsb2JhbACCJjC+LohBAY5gBYQa
X-IronPort-AV: E=Sophos;i="4.44,305,1249257600"; d="scan'208,217";a="56152293"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 Aug 2009 15:09:59 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7VF9xOH002077;  Mon, 31 Aug 2009 11:09:59 -0400
Received: from rtp-sratliff-8714.cisco.com (rtp-sratliff-8714.cisco.com [10.116.179.213]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7VF9wK5007687; Mon, 31 Aug 2009 15:09:58 GMT
Message-Id: <D9DFCCD2-16E3-46E1-9787-E670E679CCC9@cisco.com>
From: Stan Ratliff <sratliff@cisco.com>
To: Thomas Heide Clausen <Thomas@ThomasClausen.org>
In-Reply-To: <E736189F-7C38-4CBD-9EBE-480A12185475@ThomasClausen.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-4-693775155
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 31 Aug 2009 11:09:58 -0400
References: <374005f30908300545n55daabd8geb1450a4507fe10c@mail.gmail.com> <374005f30908310645n3850a570x74ec65043359c67@mail.gmail.com> <300058BE-1E3E-4939-8360-34313F131405@thomasclausen.org> <3399E08B-5955-4D8F-8FB8-1DA8BFBA7AC3@cisco.com> <E736189F-7C38-4CBD-9EBE-480A12185475@ThomasClausen.org>
X-Mailer: Apple Mail (2.936)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5112; t=1251731399; x=1252595399; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20Stan=20Ratliff=20<sratliff@cisco.com> |Subject:=20Re=3A=20[manet]=20draft-ietf-manet-nhdp-10.txt= 20-=20WGLC=20-=20Oct=205th=202009 |Sender:=20 |To:=20Thomas=20Heide=20Clausen=20<Thomas@ThomasClausen.org >; bh=Z6p8Y8eAH1NE8pa7Vqc7JcBzFDGDdF3uzVx8oSmGYS8=; b=gnZWNPjvmx3LXGfuBJt8eoR2OOPEwehMwYooGkwQ+LCljfpCH0i//qmKnk MbEYA1yTr5FCwzHCjjuEsE1nTAWcMdAU/nJw6JhI/BQLeZ8+w4bJmYEBaIDO YaQyKE21oE;
Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); 
Cc: Christopher Dearlove <chris.dearlove@baesystems.com>, MANET IETF <manet@ietf.org>
Subject: Re: [manet] draft-ietf-manet-nhdp-10.txt - WGLC - Oct 5th 2009
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 15:09:55 -0000

--Apple-Mail-4-693775155
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Thomas,

As I understood the earlier thread (and my apologies for not speaking  
up sooner), there are some NHDP issues that Ian expressed when using  
the same ip address on multiple interfaces, via "ip unnumbered". This  
is what we do in some deployments, when using RFC4938-compliant  
radios. In these deployments, the radio establishes a point-to-point  
session (by some mechanism unknown to me) for each radio partner. That  
session is represented in the router by a PPPoE session, with its own  
logical interface. All of these PPPoE interfaces have the same local  
IP address.

So if two router/radio units decide to establish multiple sessions  
with each other (not currently the case, but could happen in the  
future), I think there would be a problem with NHDP (again, as I  
understood Ian's email).

Or, does NHDP handle this?

Regards,
Stan

On Aug 31, 2009, at 10:27 AM, Thomas Heide Clausen wrote:

>
> On Aug 31, 2009, at 4:18 PM, Stan Ratliff wrote:
>
>> One comment inline.
>>>
>>>> 4) Identifying interfaces, when they use the same address.
>>>
>>> Strongly disagree, Justin has argued this well.
>>>
>>
>> Some of our deployments use ip unnumbered interfaces. It has to do  
>> with the type of radio deployed (radios implementing RFC4938), and  
>> use of PPPoE in the router. I'd hate to preclude use of NHDP in  
>> these deployments.
>>
>> Regards,
>> Stan
>>
>
> Stan,
>
> Your thoughts are usually worth listening to -- can you be a little  
> more explicit, does NHDP as-is somehow contradict the deployments  
> that you target?
>
> IOW, would NHDP as currently described work or not-work for you?
>
> I suspect that NHDP would work, and that making it do so would be a  
> deployment issue -- but as I do not know details of your  
> deployments, I'd like to make sure that they're actually covered?
>
> Thanks,
>
> Thomas


--Apple-Mail-4-693775155
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; =
">Thomas,&nbsp;<div><br></div><div>As I understood the earlier thread =
(and my apologies for not speaking up sooner), there are some NHDP =
issues that Ian expressed when using the same ip address on multiple =
interfaces, via "ip unnumbered". This is what we do in some deployments, =
when using RFC4938-compliant radios. In these deployments, the radio =
establishes a point-to-point session (by some mechanism unknown to me) =
for each radio partner. That session is represented in the router by a =
PPPoE session, with its own logical interface. All of these PPPoE =
interfaces have the same local IP address.</div><div><br></div><div>So =
if two router/radio units decide to establish multiple sessions with =
each other (not currently the case, but could happen in the future), I =
think there would be a problem with NHDP (again, as I understood Ian's =
email).&nbsp;</div><div><br></div><div>Or, does NHDP handle =
this?</div><div><br></div><div>Regards,</div><div>Stan</div><div><br></div=
><div><div><div>On Aug 31, 2009, at 10:27 AM, Thomas Heide Clausen =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: =
space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 31, =
2009, at 4:18 PM, Stan Ratliff wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>One =
comment inline.<br><blockquote type=3D"cite"><font =
class=3D"Apple-style-span" =
color=3D"#144FAE"><br></font></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">4) Identifying interfaces, when =
they use the same address.<br></blockquote></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Strongly =
disagree, Justin has argued this well.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><br>Some of our deployments use ip =
unnumbered interfaces. It has to do with the type of radio deployed =
(radios implementing RFC4938), and use of PPPoE in the router. I'd hate =
to preclude use of NHDP in these =
deployments.<br><br>Regards,<br>Stan<br><br></div></blockquote><div><br></=
div>Stan,</div><div><br></div><div>Your thoughts are usually worth =
listening to -- can you be a little more explicit, does NHDP as-is =
somehow contradict the deployments that you =
target?</div><div><br></div><div>IOW, would NHDP as currently described =
work or not-work for you?</div><div><br></div><div>I suspect that NHDP =
would work, and that making it do so would be a deployment issue -- but =
as I do not know details of your deployments, I'd like to make sure that =
they're actually =
covered?</div><div><br></div><div>Thanks,</div><div><br></div><div>Thomas<=
/div></div></blockquote></div><br></div></body></html>=

--Apple-Mail-4-693775155--

From teco@inf-net.nl  Mon Aug 31 23:19:18 2009
Return-Path: <teco@inf-net.nl>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F30628C2DD for <manet@core3.amsl.com>; Mon, 31 Aug 2009 23:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.159
X-Spam-Level: 
X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5 tests=[AWL=0.345,  BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45+yUNMf9VIY for <manet@core3.amsl.com>; Mon, 31 Aug 2009 23:19:17 -0700 (PDT)
Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 7244F28C309 for <manet@ietf.org>; Mon, 31 Aug 2009 23:16:41 -0700 (PDT)
Received: (qmail 20474 invoked from network); 1 Sep 2009 08:16:51 +0200
Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 1 Sep 2009 08:16:51 +0200
From: "Teco Boot" <teco@inf-net.nl>
To: "'Stan Ratliff'" <sratliff@cisco.com>, "'Thomas Heide Clausen'" <Thomas@ThomasClausen.org>
References: <374005f30908300545n55daabd8geb1450a4507fe10c@mail.gmail.com>	<374005f30908310645n3850a570x74ec65043359c67@mail.gmail.com>	<300058BE-1E3E-4939-8360-34313F131405@thomasclausen.org>	<3399E08B-5955-4D8F-8FB8-1DA8BFBA7AC3@cisco.com>	<E736189F-7C38-4CBD-9EBE-480A12185475@ThomasClausen.org> <D9DFCCD2-16E3-46E1-9787-E670E679CCC9@cisco.com>
In-Reply-To: <D9DFCCD2-16E3-46E1-9787-E670E679CCC9@cisco.com>
Date: Tue, 1 Sep 2009 08:15:42 +0200
Message-ID: <000d01ca2acb$baa602d0$2ff20870$@nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcoqTTE2xhQt/hsiQ/aYcCtrnhhfiQAK1SpQ
Content-Language: nl
Cc: 'Christopher Dearlove' <chris.dearlove@baesystems.com>, 'MANET IETF' <manet@ietf.org>
Subject: Re: [manet] draft-ietf-manet-nhdp-10.txt - WGLC - Oct 5th 2009
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2009 06:19:18 -0000

I agree with Ian and Stan on topics #3 and #4 (identifying routers,
interfaces).
I think we should support multiple interfaces with same addresses.
P2P links in general use such, PPPoE is not the exception.
And there is the link-local addresses with VLANs scenario.

I think introducing a Router-ID in NHDP highly reduces complexity.
Then, it is no longer needed to advertize __all addresses__ so=20
overhead may be reduced.
Also, management is simplified. There is already the NeighborNodeId=20
in draft manet-nhdp-mib. And interfaces are identified with nhdpIfIndex
(which is ifIndex).

The IP header source address would be used as Router-ID if msg-orig-addr
is missing. In case another Router-ID is to be used, msg-orig-addr is
added. This would be in line with OLSRv2.

On Henning his 4b (same address on different routers):
OSPF has no problem with this.
Many admins that configured anycast want to stay alive.
I am one of them!

On Justin's argument:
> Furthermore things get even more complicated when these=20
> identifier addresses change or disappear but the underlying
> addressing does not.
My major concern is ever changing addresses. Identifiers would be
stable (or MUST be, as specified in the MIB drafts).

Teco.

=3D=3D=3D=3D=3D=3D=3D=3D=3D

Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens Stan
Ratliff
Verzonden: maandag 31 augustus 2009 17:10
Aan: Thomas Heide Clausen
CC: Christopher Dearlove; MANET IETF
Onderwerp: Re: [manet] draft-ietf-manet-nhdp-10.txt - WGLC - Oct 5th =
2009

Thomas,=A0

As I understood the earlier thread (and my apologies for not speaking up
sooner), there are some NHDP issues that Ian expressed when using the =
same
ip address on multiple interfaces, via "ip unnumbered". This is what we =
do
in some deployments, when using RFC4938-compliant radios. In these
deployments, the radio establishes a point-to-point session (by some
mechanism unknown to me) for each radio partner. That session is =
represented
in the router by a PPPoE session, with its own logical interface. All of
these PPPoE interfaces have the same local IP address.

So if two router/radio units decide to establish multiple sessions with =
each
other (not currently the case, but could happen in the future), I think
there would be a problem with NHDP (again, as I understood Ian's =
email).=A0

Or, does NHDP handle this?

Regards,
Stan

On Aug 31, 2009, at 10:27 AM, Thomas Heide Clausen wrote:



On Aug 31, 2009, at 4:18 PM, Stan Ratliff wrote:


One comment inline.


4) Identifying interfaces, when they use the same address.

Strongly disagree, Justin has argued this well.


Some of our deployments use ip unnumbered interfaces. It has to do with =
the
type of radio deployed (radios implementing RFC4938), and use of PPPoE =
in
the router. I'd hate to preclude use of NHDP in these deployments.

Regards,
Stan

Stan,

Your thoughts are usually worth listening to -- can you be a little more
explicit, does NHDP as-is somehow contradict the deployments that you
target?

IOW, would NHDP as currently described work or not-work for you?

I suspect that NHDP would work, and that making it do so would be a
deployment issue -- but as I do not know details of your deployments, =
I'd
like to make sure that they're actually covered?

Thanks,

Thomas