Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt

Erik Nordmark <nordmark@sonic.net> Thu, 30 January 2014 18:13 UTC

Return-Path: <nordmark@sonic.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62DF1A044D for <ipv6@ietfa.amsl.com>; Thu, 30 Jan 2014 10:13:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level:
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3mScjA_RHZM for <ipv6@ietfa.amsl.com>; Thu, 30 Jan 2014 10:13:05 -0800 (PST)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 023931A0429 for <ipv6@ietf.org>; Thu, 30 Jan 2014 10:13:04 -0800 (PST)
Received: from [10.0.0.180] (75-94-129-28.sfo.clearwire-wmx.net [75.94.129.28] (may be forged)) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s0UICuoB007360 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 30 Jan 2014 10:12:58 -0800
Message-ID: <52EA9628.4020700@sonic.net>
Date: Thu, 30 Jan 2014 10:12:56 -0800
From: Erik Nordmark <nordmark@sonic.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Erik Kline <ek@internetdraft.org>, Erik Nordmark <nordmark@acm.org>
Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt
References: <20131021233827.32495.34424.idtracker@ietfa.amsl.com> <CAKD1Yr2eBffHBA-xSepNaJQ-az56F01pgry5sdRbTRC0VMhf_w@mail.gmail.com> <CAKD1Yr2CWsysF8XD8MxiKF9rZnhxWrUO9L6-RrwETGQGEqOuzw@mail.gmail.com> <6299FD64-01A9-4F19-B271-9891AFCA3269@gmail.com> <CAAedzxrTu9L_JDktjrZh74YN6hT06dMGody6AfuQC3xewjWQ5w@mail.gmail.com> <52E9EFB9.9000402@acm.org> <A7BB76FD-FE3C-4D1B-8946-8D4A1591D933@internetdraft.org>
In-Reply-To: <A7BB76FD-FE3C-4D1B-8946-8D4A1591D933@internetdraft.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Sonic-ID: C;cBbZJNqJ4xGnhNRAJ1f4WQ== M;BOKqJdqJ4xGnhNRAJ1f4WQ==
X-Mailman-Approved-At: Mon, 03 Feb 2014 08:34:38 -0800
Cc: draft-ietf-6man-resilient-rs@tools.ietf.org, IETF IPv6 Mailing List <ipv6@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 30 Jan 2014 18:13:07 -0000

On 1/29/14 11:41 PM, Erik Kline wrote:
> In such an approach when would the router stop unicasting RAs to a 
> particular address? Forever? Until NUD fails? What is the host was 
> gone for 30 seconds without the host noticing and as a result the 
> router saw a NUD failure.
> I like your “until the router detects a NUD failure for the host” notion, I think.  In that case, I think the host will either:
Erik,

Sorry for not being clear. That wasn't a proposal of mine but a prod for 
some clarification. It doesn't actually work (sorry for having been 
terse) since the host has no way to find out when the router saw a NUD 
failure and stopped with the unicasts. I wanted to illustrate that this 
is harder than it seems. I should have made that more obvious.

>     [1]  enter into NUD detection from its perspective because communications are failing (no replies to packets sent), or
NUD doesn't work that way - each side determines unreachable separately.

   Erik

>
>     [2]  it had to packets to send so didn’t notice anything, and then the RA timers get “low” and the host enters into the proposed “retry RSes (probably requiring multicast)” behaviour that launched this thread.
>
> I do agree that if a network is going to rely on RSes before it sends a periodic RA (say, because the network is one of these split horizon things) some guidelines for the RA-sending side are probably in order, but I’m not yet convinced it’s terribly complicated.
>
> …but maybe I just haven’t thought about it enough.
>
> -Erik (the lesser)
>