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

Erik Kline <ek@internetdraft.org> Thu, 30 January 2014 07:41 UTC

Return-Path: <ek@internetdraft.org>
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 A92B51A04F8 for <ipv6@ietfa.amsl.com>; Wed, 29 Jan 2014 23:41:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 O56f_rSZaER7 for <ipv6@ietfa.amsl.com>; Wed, 29 Jan 2014 23:41:44 -0800 (PST)
Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2D11D1A0476 for <ipv6@ietf.org>; Wed, 29 Jan 2014 23:41:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zoho; d=internetdraft.org; h=content-type:mime-version:subject:from:in-reply-to:date:cc:message-id:references:to; b=c0HbtAV3AtZLcMth6nAu0gGbLxCvnH+Iw7RmP7bOD8Std2atP50GIShlymG3j2Sfm6gQC0ogzT0g eEziluchd0BFrf5jEO0zLMroZfxPBBH8g3xC5SwcCBeEYUqG30bbF8wnqV/sNtAhrRJoMsyko8PN PMwStROZeVwYbSFO5w4=
Received: from [192.168.0.112] (c-69-181-65-10.hsd1.ca.comcast.net [69.181.65.10]) by mx.zohomail.com with SMTPS id 1391067686784897.7134095304955; Wed, 29 Jan 2014 23:41:26 -0800 (PST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt
From: Erik Kline <ek@internetdraft.org>
In-Reply-To: <52E9EFB9.9000402@acm.org>
Date: Wed, 29 Jan 2014 23:41:25 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <A7BB76FD-FE3C-4D1B-8946-8D4A1591D933@internetdraft.org>
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>
To: Erik Nordmark <nordmark@acm.org>
X-Mailer: Apple Mail (2.1827)
X-ZohoMailClient: External
X-Zoho-Virus-Status: 2
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 07:41:45 -0000

On Jan 29, 2014, at 10:22 PM, Erik Nordmark <nordmark@acm.org> wrote:

> On 1/29/14 11:34 AM, Erik Kline wrote:
>>> A host on a multicast-capable link on which "unsolicited multicast Router Advertisements are never sent" will have to use the same transmission behavior as a host on a non-multicast-capable link, so that the host can learn of changes in the link prefixes in a timely fashion.
>> Not necessarily.
>> 
>> Consider the situation in a which a router responds to multicast RSs
>> with unicast RAs.  The host may in fact continue to receive unicast
>> RAs periodically.
> Erik,
> 
> 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:

   [1]  enter into NUD detection from its perspective because communications are failing (no replies to packets sent), or

   [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)