Re: [Manet-dt] [Fwd: Re: DYMO SeqNum Decisions]

"Ian Chakeres" <ian.chakeres@gmail.com> Sat, 26 August 2006 00:17 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGlrA-0004pr-16; Fri, 25 Aug 2006 20:17:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGlr8-0004pj-VE for manet-dt@ietf.org; Fri, 25 Aug 2006 20:16:58 -0400
Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGlr6-00053f-KN for manet-dt@ietf.org; Fri, 25 Aug 2006 20:16:58 -0400
Received: by ug-out-1314.google.com with SMTP id m2so1084439uge for <manet-dt@ietf.org>; Fri, 25 Aug 2006 17:16:55 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=k7LnWS5cJz3ub9RpUDoTEomsKRNU3oqM5136MR0LP5lvmVk2yHb7dF2jKIKRo15pPfnRmJcSFtG4CNLjnLsHQMeC24sjgo4S9OEKTHKAd0cjvppIdCztFILiMQyR4z6/89s+/Bs4qXyKK0WERBkvvBmpAY+5x2hmiDvVVBoCUAg=
Received: by 10.67.101.10 with SMTP id d10mr2235961ugm; Fri, 25 Aug 2006 17:16:55 -0700 (PDT)
Received: by 10.67.23.16 with HTTP; Fri, 25 Aug 2006 17:16:55 -0700 (PDT)
Message-ID: <374005f30608251716t30cb17d1mc37c4f278fdc6eb2@mail.gmail.com>
Date: Fri, 25 Aug 2006 17:16:55 -0700
From: "Ian Chakeres" <ian.chakeres@gmail.com>
To: "Charles E. Perkins" <charles.perkins@nokia.com>
Subject: Re: [Manet-dt] [Fwd: Re: DYMO SeqNum Decisions]
In-Reply-To: <44EF8F78.1010004@nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <44EF897E.8060700@nokia.com> <374005f30608251647u1ed23d0fxeec7e33f455740f0@mail.gmail.com> <44EF8F78.1010004@nokia.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: "Elizabeth M. Belding \(work\)" <ebelding@cs.ucsb.edu>, karim.seada@nokia.com, manet-dt@ietf.org
X-BeenThere: manet-dt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: MANET Design Team <manet-dt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/manet-dt>, <mailto:manet-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/manet-dt>
List-Post: <mailto:manet-dt@ietf.org>
List-Help: <mailto:manet-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/manet-dt>, <mailto:manet-dt-request@ietf.org?subject=subscribe>
Errors-To: manet-dt-bounces@ietf.org

Comments inline.

On 8/25/06, Charles E. Perkins <charles.perkins@nokia.com> wrote:
>
> Hello again Ian,
>
> A few follow-on comments...
>
> ext Ian Chakeres wrote:
> >> > Pedro & Fran ran into seq num problems last year. During IETF 65 Ramon
> >> > identified another sequence number issue related to this discussion.
> >> > Both had problems with RREP being blackholed.
> >> Were those problems caused by the scenario outlined in recent e-mails?
> >
> > Both these problems were because the RREP originator was not
> > incrementing its sequence number.
> That formulation prejudices the outcome.  I will interpret it to mean that,
> both problems would be solved if the RREP originator would
> increment its sequence number.  But the problem is _caused_ by
> some other occurence.  It is this true cause of the problem that
> I want to know more about.

"The problem"  is that RREP were not being considered as fresh or
superior, and therefore dropped.

I would like to find a solution that does not require the RREQ target
(RREP originator) to increment its sequence number, but I have not
found one yet.

Finding such a solution appears difficult, since the target does not
know the state of routing tables in nodes along the path from the RREP
originator to the RREP target (RREQ originator).

I am querying you and others to propose a solution that would solve
"The problem". Hopefully, one that does not require the RREP
originator to increment its seqnum.

One other note lower.

> >> > If we force intermediate nodes to examine information about the target
> >> > (last known seqnum and hopcnt) we might be able to know something at
> >> > the target node about the route traversed. But we still need to ensure
> >> > that a RREQ will reach the target, and I think any such logic could
> >> > result in RREQ blackholing.
> >> I think I am missing something here, unfortunately.  Can you say
> >> just a little more about when the blackholing would occur?
> >
> > This condition would occur whenever an intermediate node discarded a
> > RREQ (due to new rules) and it was the only route to the target.
> Do you mean the new DYMO rules?  Or, which ones specifically?

A possible set of new processing rules associated with dropping RREQ
based on the target's last know sequence number and hop count that
would allow the RREQ target to know something about the route
traversed.

I do think blackholing could occur if this (new processing rules) were
implemented.

Ian

> --
> Please address return e-mail to charles.perkins@nokia.com
>
>

_______________________________________________
Manet-dt mailing list
Manet-dt@ietf.org
https://www1.ietf.org/mailman/listinfo/manet-dt