IETF Logo Mail Archive

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

Ole Troan <otroan@employees.org> Wed, 22 January 2014 20:27 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 B36DE1A01D0 for <ipv6@ietfa.amsl.com>; Wed, 22 Jan 2014 12:27:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no
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 nsfLm218-Rqa for <ipv6@ietfa.amsl.com>; Wed, 22 Jan 2014 12:27:35 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 476781A0132 for <ipv6@ietf.org>; Wed, 22 Jan 2014 12:27:35 -0800 (PST)
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFANco4FKQ/khL/2dsb2JhbABbgwy8a4EXFnSCJQEBAQMBeRALDjhXBogQCMNrF458B4MkgRQEkDuZf4MuOw
X-IronPort-AV: E=Sophos; i="4.95,702,1384300800"; d="asc'?scan'208"; a="4031113"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 22 Jan 2014 20:27:34 +0000
Received: from dhcp-10-61-101-124.cisco.com (dhcp-10-61-101-124.cisco.com [10.61.101.124]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0MKRWpj007893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jan 2014 20:27:33 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_18575BA3-DF62-4294-AD29-1CD17AA2B6D4"; 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: <007C5C8C-5837-48B7-8641-20B85DF818FF@gmail.com>
Date: Wed, 22 Jan 2014 21:27:32 +0100
Message-Id: <94B0A155-DC47-4C42-B18B-35C94CB09BDD@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> <7AB1FAB9-6E17-4F1C-A8F0-784843FAA51B@employees.org> <007C5C8C-5837-48B7-8641-20B85DF818FF@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:27:36 -0000

Ralph,

[...]

>> 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.
> 
> OK ... but the host will not learn about new prefixes assigned to the link in a timely fashion, which is (I infer) the motivation for this text:
> 
>   On non-multicast links, the hosts following this specification MUST
>   continue retransmitting the RSs even after an RA that results in a
>   default route is received.

I'm not sure that 3600 seconds is timely fashion. ;-)
I'm not quite sure why the reference to non-multicast links is there.
(and I'm not sure we need to talk about it, if the only example is ISATAP).
ND doesn't really run over non-multicast links. I can recommend RFC2022. ;-)

cheers,
Ole

v2.14.0 | Report a Bug | By Email