Re: Distribution of RFC 3484 address selection policies
Fred Baker <fred@cisco.com> Tue, 09 August 2005 16:32 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2X29-0005Kg-CW; Tue, 09 Aug 2005 12:32:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2X27-0005Jp-5S for ipv6@megatron.ietf.org; Tue, 09 Aug 2005 12:32:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21297 for <ipv6@ietf.org>; Tue, 9 Aug 2005 12:32:52 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Xa2-0005mn-7I for ipv6@ietf.org; Tue, 09 Aug 2005 13:07:59 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 09 Aug 2005 09:32:44 -0700
X-IronPort-AV: i="3.96,92,1122879600"; d="scan'208"; a="330495703:sNHT33241164"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j79GWcoo011184; Tue, 9 Aug 2005 09:32:41 -0700 (PDT)
Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j79GTcUH023954; Tue, 9 Aug 2005 09:29:38 -0700
In-Reply-To: <42F813F3.7050005@eng.monash.edu.au>
References: <20050808194427.GB21924@storhaugen.uninett.no> <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> <E73B54E1-66F7-4E59-AEE0-D497323431E6@ecs.soton.ac.uk> <42F7F18E.2000102@eng.monash.edu.au> <AB1F5381-5D2C-431C-8DC7-719FA14BF0D9@cisco.com> <42F813F3.7050005@eng.monash.edu.au>
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <ABD76F03-A396-4057-B3A8-3492A90A2920@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Date: Tue, 09 Aug 2005 09:32:35 -0700
To: greg.daley@eng.monash.edu.au
X-Mailer: Apple Mail (2.733)
DKIM-Signature: a=rsa-sha1; q=dns; l=1290; t=1123604979; x=1124037179; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Distribution=20of=20RFC=203484=20address=20selection=20policies| From:Fred=20Baker=20<fred@cisco.com>| Date:Tue,=209=20Aug=202005=2009=3A32=3A35=20-0700| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=HazDFhhLdeSlC2uCjc0MfJrP+WeHwb4JF616ZcARAaijUu1AZQVHplNN06HwcQUZ0TINW4a3 w24h/5WPjcyac+//uHGGkOUdY/bfEYT3NiTId7MLwW04R4lg/55hE0wYrvWze/59MLmw0NEc8ju dMF1+I3mztYuhvqvTm7jIdoo=
Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>
Subject: Re: Distribution of RFC 3484 address selection policies
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
On Aug 8, 2005, at 7:24 PM, Greg Daley wrote: > I'm not sure anyone is doing it, but renumbering is applicable > there as a means of providing information about which prefixes are > valid. One of the outcomes of the v6ops WG last week was the observation that the Router Renumbering Protocol is not widely implemented, and when renumbering-in-anger persuant to http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering- procedure-05.txt "Procedures for Renumbering an IPv6 Network without a Flag Day", Fred Baker, 18-Mar-05, <draft-ietf-v6ops-renumbering-procedure-05.txt> was tested by the 6net folks, it was found wanting in a variety of ways. Basically, it made the special case where you want to distribute a new aggregated prefix and maintain the same subnet number distribution (such as "I have changed upstream provider") pretty simple, but didn't cover any of the other cases in which one might want to renumber, and didn't handle any of the nuances like making sure this also happened in route maps, aggregation filters, qos classification filters, etc. As the discussion proceeded, we basically decided that renumbering (and more generally number distribution and number use policy) was the province of the network management folks, perhaps netconf. They need to decide how to manage a network, and if a protocol like RRP is part of that, specify a set of requirements for it. RRP at minimum needs work, and I would suggest it be declared "historic" and replaced with a new protocol if such a definition happens. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- Distribution of RFC 3484 address selection polici… Stig Venaas
- Re: Distribution of RFC 3484 address selection po… Fred Baker
- Re: Distribution of RFC 3484 address selection po… Mark K. Thompson
- Re: Distribution of RFC 3484 address selection po… Greg Daley
- Re: Distribution of RFC 3484 address selection po… Fred Baker
- Re: Distribution of RFC 3484 address selection po… Greg Daley
- RE: Distribution of RFC 3484 address selection po… john.loughney
- Re: Distribution of RFC 3484 address selection po… Arifumi Matsumoto
- Re: Distribution of RFC 3484 address selection po… Fred Baker
- Re: Distribution of RFC 3484 address selection po… Greg Daley
- Re: Distribution of RFC 3484 address selection po… Greg Daley
- Re: Distribution of RFC 3484 address selection po… Stig Venaas
- Re: Distribution of RFC 3484 address selection po… a
- Re: Distribution of RFC 3484 address selection po… Mark K. Thompson
- Re: Distribution of RFC 3484 address selection po… Greg Daley
- RE: Distribution of RFC 3484 address selection po… timothy enos
- Re: Distribution of RFC 3484 address selection po… Greg Daley
- RE: Distribution of RFC 3484 address selection po… timothy enos
- Re: Distribution of RFC 3484 address selection po… Tim Chown
- Re: Distribution of RFC 3484 address selection po… Ralph Droms
- Re: Distribution of RFC 3484 address selection po… Tim Chown
- Re: Distribution of RFC 3484 address selection po… Stig Venaas
- Re: Distribution of RFC 3484 address selection po… Ralph Droms
- Re: Distribution of RFC 3484 address selection po… Tim Chown
- Re: Distribution of RFC 3484 address selection po… Stig Venaas
- RE: Distribution of RFC 3484 address selection po… timothy enos