Re: Neighbor Unreachability Detection..

Erik Nordmark <nordmark@acm.org> Mon, 30 April 2012 00:31 UTC

Return-Path: <nordmark@acm.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6922921F8592 for <ipv6@ietfa.amsl.com>; Sun, 29 Apr 2012 17:31:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKZZYumvabqr for <ipv6@ietfa.amsl.com>; Sun, 29 Apr 2012 17:31:23 -0700 (PDT)
Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id BD9F721F8569 for <ipv6@ietf.org>; Sun, 29 Apr 2012 17:31:23 -0700 (PDT)
Received: from [10.21.72.123] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q3U0VJcM029016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Apr 2012 17:31:20 -0700
Message-ID: <4F9DDD57.4070207@acm.org>
Date: Sun, 29 Apr 2012 17:31:19 -0700
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120420 Thunderbird/12.0
MIME-Version: 1.0
To: Somasundaram Selvaraj <ietf.interest@gmail.com>
Subject: Re: Neighbor Unreachability Detection..
References: <CALOzrYeJeWAsiNQD1VdFqsnTFBjTWSMHiqnu23G8UmxC_gcviw@mail.gmail.com>
In-Reply-To: <CALOzrYeJeWAsiNQD1VdFqsnTFBjTWSMHiqnu23G8UmxC_gcviw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Apr 2012 00:31:24 -0000

On 4/29/12 5:54 AM, Somasundaram Selvaraj wrote:
> All
>
>   I went through RFC 4861 and found the section on "Neighbor
> Unreachablity Detection" to be of less signifance especially on the
> links between Router.

Did you read the text in section 7.3 which says
    Neighbor Unreachability Detection may
    also be used between routers, but is not required if an equivalent
    mechanism is available, for example, as part of the routing
    protocols.

Keep in mind that ND predates BFD; if the specification which written 
today it might as "as part of the routing protocols or BFD".

I don't know if anybody has looked for a detailed description of how ND 
address resolution between routers might interact with BFD, but AFAICT 
this should be straight-forward. Just disabling NUD on the interfaces 
where BFD is being used.

Does that answer your concerns?

   Erik


> Reason is that, while there are failure detection protocols already
> available to detect a liveliness of the neighbor I dont understand
> effectivenss of such a mechanism within IpV6.
> Moreover, whenever the neighborstate is not in "Reachable state", there
> is a bunch of packets that gets trapped to the CPU to invoke IPV6 to
> send NeighborSolicitaion message to detect the liveliness of the
> neighbor. And Interestingly, the implementations  continue to forward to
> the neighbor irrespective of what the "Nbr state is" and then trap the
> (copy of the packets)packets to cpu to do a Neighbor Unreachablity
> Detection check (for the sake of sticking to the standard).
> I didnt like Router Doing this especially on the Router-Router link.
> Here are my opinion on handling the above issues.
> 1: Why to go through all the NeighborStates
> (Incomplete->Reachable->Stale->Delay->Probe) when Protocols like BFD are
> already present to check the liveliness of the neighbor (On a
> Router-Router link). Cant we avoid "Neighbor unreachablity detection"
> completely?
> 2: Simplify the NeighborState Machine.Just mainitain two states in the
> Neighbor cache when the neighbor is a router. The states would be
> "Incomplete and Reachable".
> Enhancement as follows:
>       Initially the Neighbor state would be marked "Incomplete" and a
> NeighborSolicitation message would  be originated to determine the link
> layer address.Once it receives a response move the neighbor state to
> "Reachable". Just maintain an ageout timer like the one meant for ARP
> (no more complications) to flush an entry from neighbor Cache.
>
> Please share your thoughts.
>
> Regards
> Somasundaram
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------