Comments on draft-chandra-ospf-manet-ext-01.txt
Richard Ogier <ogier@EARTHLINK.NET> Mon, 02 August 2004 20:04 UTC
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00877 for <ospf-archive@LISTS.IETF.ORG>; Mon, 2 Aug 2004 16:04:19 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00E340D9@cherry.ease.lsoft.com>; Mon, 2 Aug 2004 16:04:19 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 28761262 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 2 Aug 2004 16:04:16 -0400
Received: from 207.217.120.46 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 2 Aug 2004 16:04:16 -0400
Received: from sdn-ap-004castocp0178.dialsprint.net ([63.187.32.178] helo=earthlink.net) by grebe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Brj2c-0006Zb-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 02 Aug 2004 13:04:14 -0700
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202)
X-Accept-Language: en-us
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID: <410E9E3D.7060804@earthlink.net>
Date: Mon, 02 Aug 2004 13:04:13 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Richard Ogier <ogier@EARTHLINK.NET>
Subject: Comments on draft-chandra-ospf-manet-ext-01.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit
I have some comments and questions for the draft draft-chandra-ospf-manet-ext-01.txt. (Unfortunately, I could not make it to the meeting this week.) I see that the following requirement has been added to 2.3.5: "The first Hello packet with a particular SCS number MUST contain the full state associated with that SCS number, and thus MUST NOT set the 'N' bit in the State Check Sequence TLV." Assuming that the Hello is multicast to all neighbors, does the "full state" include all neighbors? Or does it include only the neighbors that recently changed state? If the former is the case, then the Hellos are not incremental. If the latter is the case, then I am not sure exactly how "full state" is defined for an incremental Hello. From Section 2.3.6 (Receiving Hellos), I see that the initial Hello for a new SCS number (with the N bit not set) must be received correctly by all neighbors, and a neighbor must send a Hello request if it discovers that it missed the initial Hello for a given SCS number. This concerns me, because in a MANET, a node will typically miss a large percentage of Hellos, and thus will have to unicast a large number of Hello requests to each neighbor. It is possible to design the Hello protocol so that it is OK to miss 2 out of 3 Hellos (for example) without having to send a Hello request. TBRPF (RFC 3684) does by reporting each neighbor change in 3 (or k) consecutive Hellos, so that each neighbor will either learn about the state change, or will declare the neighbor lost after missing 3 consecutive Hellos from the neighbor. (To detect this, the Hello sequence number is incremented with each transmitted Hello.) Another issue is that, because different nodes can have different transmission ranges, it is possible for a node to have many 1-way neighbors that never become 2-way. Unfortunately, your incremental Hellos will have to report all of these 1-way neighbors forever in Hellos. In TBRPF, when a 1-way neighbor is discovered, it is reported in at most 3 Hellos. (The correctness proof for TBRPF shows that this works, and TBRPF has been throroughly tested.) I am not trying to promote TBRPF, but am just pointing out some potential advantages of the TBRPF Hello protocol. Perhaps simulations should be conducted to compare these two methods for using incremental Hellos. I have a few additional quick comments on the draft. There is a typo in the last bullet of 2.3.4.2: "I bit" should be "N bit". In Section 2.4.7 (Flooding and Relay Decisions), the first step upon receiving an LSA from an adjacent speaker is as follows: 1. If the node is an active overlapping relay for the adjacent speaker, then the router MUST immediately relay any information received from the adjacent speaker. This could cause inifinite looping, since two nodes could be overlapping relays (MPRs) for each other. I guess you mean either: (a) the LSA is relayed if it has not already been relayed, or (b) the LSA is relayed if it has not already been received. The inefficiency of doing (a) has already been discussed on this mailing list, as well as the possible incorrectness of doing (b). My final comment regards the use of MPRs instead of a CDS for flooding. This choice has been discussed, and I think this is still an open question, but let me know if you have concluded that MPRs is preferable. As a review, I will list some advantages of using a CDS: 1. A CDS is simpler and is a more natural generalization of a DR, since each CDS node relays all LSAs (independent of which neighbor the LSA was received from). 2. Each node can decide whether it is a CDS node based only on Hellos and LSAs originated from neighbors, without having to compute MPRs, or to add a new TLV to report MPRs. (The DR field of a Hello can be used to identify a CDS node instead.) 3. A full adjacency needs to be established only between each CDS node and its neighbors. Regards, Richard Ogier
- Comments on draft-chandra-ospf-manet-ext-01.txt Richard Ogier
- Re: Comments on draft-chandra-ospf-manet-ext-01.t… Russ White
- Re: Comments on draft-chandra-ospf-manet-ext-01.t… Richard Ogier