[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GROW] [Editorial Errata Reported] RFC4632 (1824)



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 at 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 at ietf.org
https://www.ietf.org/mailman/listinfo/grow