IETF Logo Mail Archive

RE: rs-refresh

"Hemant Singh (shemant)" <shemant@cisco.com> Thu, 05 March 2015 11:40 UTC

Return-Path: <shemant@cisco.com>
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 7CD7B1A1B2E for <ipv6@ietfa.amsl.com>; Thu, 5 Mar 2015 03:40:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 oAGi2Hafsg4Q for <ipv6@ietfa.amsl.com>; Thu, 5 Mar 2015 03:40:04 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27D41B2C0F for <6man@ietf.org>; Thu, 5 Mar 2015 03:40:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2312; q=dns/txt; s=iport; t=1425555604; x=1426765204; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=+GThjd9/36WZROS9uryzm1LGAX5525ShFtccGhnS3zA=; b=fgMbqwgEXPSDt6HbLfQNaWrJNhmk7mmLf4iWGf4fTx2zPFov5/YNibmB MzJivymbpAkUqZOXiCG/VsgwpWhSplzIVlGURa/VZ6ZRYudjEfsVNP2hD CxeZRq7IHP+Ej6D/jWzAU+FK1kJAWKOAO+ZV/9ZLc729KQXhzInj9kmqY w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D8BQBlQPhU/5xdJa1agwWBLASDB8QUAhyBGE0BAQEBAQF8hA8BAQEEIxFFEgEIEQQBAQMCBh0DAgQwFAEICQEEAQ0FCIgnvQqafAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYlzhD0xgm8vgRQBBJAFnTkjg25vgUR/AQEB
X-IronPort-AV: E=Sophos;i="5.11,346,1422921600"; d="scan'208";a="129183020"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 05 Mar 2015 11:39:46 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t25BdjMg029476 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 11:39:46 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.40]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 05:39:45 -0600
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: Lorenzo Colitti <lorenzo@google.com>, Erik Nordmark <nordmark@acm.org>
Subject: RE: rs-refresh
Thread-Topic: rs-refresh
Thread-Index: AdBXORCTDkYgMkaaSWaOLdishDJgqQ==
Date: Thu, 05 Mar 2015 11:39:45 +0000
Message-ID: <75B6FA9F576969419E42BECB86CB1B8916811E1F@xmb-rcd-x06.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.252.185]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/DN8cB2hPiOmNmOmjPrsrqjxGBPY>
Cc: "6man@ietf.org" <6man@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: Thu, 05 Mar 2015 11:40:08 -0000

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Lorenzo Colitti
Sent: Thursday, March 05, 2015 1:28 AM
To: Erik Nordmark
Cc: 6man@ietf.org
Subject: Re: rs-refresh

>I don't think this is as useful as it appears to be at first glance, for a few reasons:
>1. This is only useful if all the hosts on the link support it. If one host does not support it, then we fall back to sending multicast RAs again.

Not true.  See below where I have responded to items 3 and 4.

>2. Despite what the document says (in two different sections), it is not possible to make it so that "updated nodes can sleep better" AND "preserve the timely and scalable reconfiguration capabilities that a periodic RA >model provides" unless there are no legacy hosts on the network

Not true.  See below where I have responded to items 3 and 4.

>3. If the router misses all the RSes from a legacy node (which for a legacy node that doesn't implement resilient RS, means a total of 3 packets sent within 3 seconds of each other, which is quite possible) then that >node is blackholed.

No.  If the node never sees an RA, the node resets its network stack and tries another three RS messages and repeats until an RA is received.   If the node has received an RA and wakes up after sleep and does not receive any RA after sending three RS messages, the node sends traffic to the default router and uses old RA information.   A router can issue Redirect to the node.  The node refreshes the  default router information later.  

>If the router loses state, all legacy nodes are blackholed.

ND has always had default routers (plural).   Another router can still serve the nodes. 

Hemant

v2.23.0 | Report a Bug | By Email