Re: [GROW] [Editorial Errata Reported] RFC4632 (1824)
Tony Li <tony.li@tony.li> Thu, 06 August 2009 02:50 UTC
Return-Path: <tony.li@tony.li>
X-Original-To: grow@core3.amsl.com
Delivered-To: grow@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A9A13A6878 for <grow@core3.amsl.com>; Wed, 5 Aug 2009 19:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.309
X-Spam-Level: *
X-Spam-Status: No, score=1.309 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, MANGLED_PAIN=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPOLHSUAqhZN for <grow@core3.amsl.com>; Wed, 5 Aug 2009 19:50:23 -0700 (PDT)
Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 4B1163A680F for <grow@ietf.org>; Wed, 5 Aug 2009 19:50:23 -0700 (PDT)
Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id Qoyc1c0020mlR8UA2qqT21; Thu, 06 Aug 2009 02:50:27 +0000
Received: from [192.168.0.110] ([24.6.155.154]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id QqqR1c0073L8a8Q8XqqRBq; Thu, 06 Aug 2009 02:50:26 +0000
Message-ID: <4A79B684.4030600@tony.li>
Date: Wed, 05 Aug 2009 09:42:44 -0700
From: Tony Li <tony.li@tony.li>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: RFC Errata System <rfc-editor@rfc-editor.org>
References: <200908051022.n75AMo3h024409@boreas.isi.edu>
In-Reply-To: <200908051022.n75AMo3h024409@boreas.isi.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: grow@ietf.org, dromasca@avaya.com, drajasek@cisco.com
Subject: Re: [GROW] [Editorial Errata Reported] RFC4632 (1824)
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/grow>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Aug 2009 02:50:24 -0000
The fix looks good to me. Thanks. Tony RFC Errata System wrote: > The following errata report has been submitted for RFC4632, > "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4632&eid=1824 > > -------------------------------------- > Type: Editorial > Reported by: Dande Rajasekhar <drajasek@cisco.com> > > Section: 6.1 > > Original Text > ------------- > To make this example more realistic, assume that C4 and C5 are multi- > homed through some other service provider, "PB". Further assume the > existence of a site, "C7", that was originally connected to "RB" but > that has moved to "PA". For this reason, it has a block of network > numbers that are assigned out PB's block of (the next) 2048 x /24. > > o C7. Assign 10.32.0 through 10.32.15. This block is described by > the route 10.32.0.0/20 (mask 255.255.240.0). > > For the multi-homed sites, assume that C4 is advertised as primary > via "RA" and secondary via "RB"; and that C5 is primary via "RB" and > secondary via "RA". In addition, assume that "RA" and "RB" are both > connected to the same transit service provider, "BB". > > Graphically, this topology looks something like this: > > 10.24.0.0 -- 10.24.7.0__ __10.32.0.0 - 10.32.15.0 > C1: 10.24.0.0/21 \ / C7: 10.32.0.0/20 > \ / > +----+ +----+ > 10.24.16.0 - 10.24.31.0_ | | | | > C2: 10.24.16.0/20 \ | | _10.24.12.0 - 10.24.15.0__ | | > \| | / C4: 10.24.12.0/20 \ | | > | |/ \| | > 10.24.8.0 - 10.24.11.0___/| PA |\ | PB | > C3: 10.24.8.0/22 | | \__10.24.32.0 - 10.24.33.0___| | > | | C5: 10.24.32.0/23 | | > | | | | > 10.24.34.0 - 10.24.35.0__/| | | | > C6: 10.24.34.0/23 | | | | > +----+ +----+ > || || > routing advertisements: || || > || || > 10.24.12.0/22 (C4) || 10.24.12.0/22 (C4) || > 10.32.0.0/20 (C7) || 10.24.32.0/23 (C5) || > 10.24.0.0/13 (PA) || 10.32.0.0/13 (PB) || > || || > VV VV > +---------- BACKBONE NETWORK BB ----------+ > > > Corrected Text > -------------- > To make this example more realistic, assume that C4 and C5 are multi- > homed through some other service provider, "PB". Further assume the > existence of a site, "C7", that was originally connected to "PB" but > that has moved to "PA". For this reason, it has a block of network > numbers that are assigned out PB's block of (the next) 2048 x /24. > > o C7. Assign 10.32.0 through 10.32.15. This block is described by > the route 10.32.0.0/20 (mask 255.255.240.0). > > For the multi-homed sites, assume that C4 is advertised as primary > via "PA" and secondary via "PB"; and that C5 is primary via "PB" and > secondary via "PA". In addition, assume that "PA" and "PB" are both > connected to the same transit service provider, "BB". > > Graphically, this topology looks something like this: > > 10.24.0.0 -- 10.24.7.0__ __10.32.0.0 - 10.32.15.0 > C1: 10.24.0.0/21 \ / C7: 10.32.0.0/20 > \ / > +----+ +----+ > 10.24.16.0 - 10.24.31.0_ | | | | > C2: 10.24.16.0/20 \ | | _10.24.12.0 - 10.24.15.0__ | | > \| | / C4: 10.24.12.0/20 \ | | > | |/ \| | > 10.24.8.0 - 10.24.11.0___/| PA |\ | PB | > C3: 10.24.8.0/22 | | \__10.24.32.0 - 10.24.33.0___| | > | | C5: 10.24.32.0/23 | | > | | | | > 10.24.34.0 - 10.24.35.0__/| | | | > C6: 10.24.34.0/23 | | | | > +----+ +----+ > || || > routing advertisements: || || > || || > 10.24.12.0/22 (C4) || 10.24.12.0/22 (C4) || > 10.32.0.0/20 (C7) || 10.24.32.0/23 (C5) || > 10.24.0.0/13 (PA) || 10.32.0.0/13 (PB) || > || || > VV VV > +---------- BACKBONE NETWORK BB ----------+ > > > Notes > ----- > All the reference of "RA" and "RB" to be replaced with "PA" and "PB". > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4632 (draft-ietf-grow-rfc1519bis-04) > -------------------------------------- > Title : Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan > Publication Date : August 2006 > Author(s) : V. Fuller, T. Li > Category : BEST CURRENT PRACTICE > Source : Global Routing Operations > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow >
- [GROW] [Editorial Errata Reported] RFC4632 (1824) RFC Errata System
- Re: [GROW] [Editorial Errata Reported] RFC4632 (1… Tony Li