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

Ole Troan <otroan@employees.org> Wed, 22 January 2014 20:15 UTC

Return-Path: <otroan@employees.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 6BE6C1A01B6 for <ipv6@ietfa.amsl.com>; Wed, 22 Jan 2014 12:15:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Level:
X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] 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 Gof-Duppfwko for <ipv6@ietfa.amsl.com>; Wed, 22 Jan 2014 12:15:35 -0800 (PST)
Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFFA1A0149 for <ipv6@ietf.org>; Wed, 22 Jan 2014 12:15:33 -0800 (PST)
Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 42710608A; Wed, 22 Jan 2014 12:15:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=KxpXvbRMef9vhnN1CeZFN CBblmk=; b=TdP3UBzkAfjREV1SIonizkxro4ZpEmnW/+WZJ6SkOiPT5nScYRcGT TGE562RzJk5UtG8DXtNYCTHcKVfHQCVnvIFU6s1L6qyTAqNpKzkT7fDzx27zHvKA fYE4D10/sM2p6Fb5wAyurbYid4gphYRI6mhAAP9eJ//5Ssh/sVYWg4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=QoGVuiYzodw/z+q uD+lCAL6J7BsgpYUi8Z7SAFxDRudTlGw4ucu1wky3UbNrHTe3SBViYr6Q1i5Rt4D 2zyHYp5hNqVnakb4npx+YT1UgxbHMD4fmINnFKWOeQqWbo7bfJCLaFiFrhm7reKQ /ju/5MpZG7Xq+yG1pamyp5g5DO5M=
Received: from dhcp-10-61-101-124.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 16A086098; Wed, 22 Jan 2014 12:15:29 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_DE0E4609-A0B2-4377-B3FD-4E996397C01F"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt
From: Ole Troan <otroan@employees.org>
In-Reply-To: <6299FD64-01A9-4F19-B271-9891AFCA3269@gmail.com>
Date: Wed, 22 Jan 2014 21:15:26 +0100
Message-Id: <7AB1FAB9-6E17-4F1C-A8F0-784843FAA51B@employees.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>
To: Ralph Droms <rdroms.ietf@gmail.com>
X-Mailer: Apple Mail (2.1827)
Cc: draft-ietf-6man-resilient-rs@tools.ietf.org, 6man WG <ipv6@ietf.org>
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: Wed, 22 Jan 2014 20:15:37 -0000

>>   When an interface on a host is initialized, the host transmits Router
>>   Solicitations in order to minimize the amount of time it needs to
>>   wait until the next unsolicited multicast Router Advertisement is
>>   received.  In certain scenarios, these router solicitations
>>   transmitted by the host might be lost.  This document specifies a
>>   mechanism for hosts to cope with the loss of the initial Router
>>   Solicitations.  Furthermore, on some links, unsolicited multicast
>>   Router Advertisements are never sent and the mechanism in this
>>   document is intended to work even in such scenarios.
>> 
>> Authors,
>> 
>> One comment here.
>> 
>> If the intent is that we should be able to run networks that do not send periodic RAs at all, then this document will need to require that hosts send router solicitations when their RAs (or whatever is in the RA contents, including lifetimes of PIOs, RIOs, RDNSS options, etc.) are about to expire - otherwise the hosts will lose connectivity.
> 
> I think it's worse than that.
> 
> 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.
> 
> Furthermore, a host on a multicast-capable link won't know if multicast RAs are being sent on the link, so all hosts will have to send periodic RSs.

for periodic RAs Router Lifetime /  RtrAdvInterval >= 3 to ensure that the mechanism works even when a couple of multicast messages are lost.
if it is specified that the periodic RS is sent only after 2/3s of the router lifetime has passed, then either the host would have received the multicast advertisement, and dropped sending the periodic RS, or it lost the multicast messages, and would be best off sending the RS anyway, or it was on a link-type that didn't send periodic RAs.

cheers,
Ole