Re: grow: Last Call: 'Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan' to Proposed Standard

[Pekka Savola <[e-mail]>]

On Tue, 22 Nov 2005, The IESG wrote:
> The IESG has received a request from the Global Routing Operations WG to
> consider the following document:
>
> - 'Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and
>   Aggregation Plan '
>   <draft-ietf-grow-rfc1519bis-03.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [e-mail] or [e-mail] mailing lists by 2005-12-06.

I think this is a useful document to recycle up in the standards 
track.

Unfortunately, as the basic document included a lot of description of 
operational techniques as of 12 years ago, recycling these kind of 
documents require some amount of brush-up to be accurate.  Those cases 
that I spotted are below.

substantial
-----------

    o  An organization which is multi-homed.  Because a multi-homed
       organization must be advertised into the system by each of its
       service providers, it is often not feasible to aggregate its
       routing information into the address space of any one of those
       providers.  Note that the organization still may receive its
       address assignment out of a service provider's address space
       (which has other advantages),

                                    but a route to the organization's
       prefix must still be explicitly advertised by all of its service
       providers.  For this reason, the global routing cost for a multi-
       homed organization is generally the same as it was prior to the
       adoption of CIDR.

==> this document describes the multihoming approaches at quite bit of
length, and I'm not sure if such are appropriate for a standards track
document.  Certainly, the practices do change, and the text above "must ..
be advertised by all.." is not correct.  As was discussed in section 5.2, if
the site is using one ISP as the primary, and is using a more specific
prefix, there exists a valid case of multihoming where advertising the
prefix equally through both ISPs is not required.

It would be useful to consider to which degree the language of what must be
done in multihoming scenarios is needed in this doc, but if it is needed,
the tone should possibly be watered down a bit to also address the
cornercases like above.

....

4.1  Rules for route advertisement

    1.  Routing to all destinations must be done on a longest-match basis
        only. [...]

==> this is an overly simplistic statement.  Shouldn't you rather say that
longest-match basis must always be the _first_ route selection criteria? (by
the way some multicast RPF techniques allow overriding this AFAIR) --
otherwise the text is confusing about the other route selection criteria
(such as traffic class for class-based routing, protocol distance, etc.)

Note that the degenerate route to
    prefix 0.0.0.0/0 is used as a default route and MUST be accepted by
    all implementations.  Further, to protect against accidental
    advertisements of this route via the inter-domain protocol, this
    route should only be advertised when a router is explicitly
    configured to do so - never as a non-configured, "default" option.

==> I do not think the "Further, ..." statement is appropriate here -- and I
don't think the vendors actually implement this stuff.  I suggest just
removing the last sentence completely.

Multi-homed networks are always explicitly advertised
    by every service provider through which they are routed even if they
    are a specific subset of one service provider's aggregate (if they
    are not, they clearly must be explicitly advertised).  It may seem as
    if the "primary" service provider could advertise the multi-homed
    site implicitly as part of its aggregate, but the assumption that
    longest-match routing is always done causes this not to work.

==> see above; not sure if this text is appropriate or useful in this kind
of doc (in any case, the same thing seems to be said in different ways in
about 3 different places in the doc)

    These six sites should be represented as six prefixes of varying size
    within the provider IGP.  If, for some reason, the provider were to
    use an obsolete IGP that doesn't support classless routing or
    variable-length subnets, then then explicit routes all /24s will have
    to be carried.

==> what's your definition of IGP?  typically you don't carry customer
routes or even your own aggregates in your IGP, so the text could probably
use refreshing.

    See [RFC2317] for a much more detailed discussion of DNS delegation
    with classless addressing.

==> "much more detailed discussion" indeed -- this doc doesn't really
address the beef of the classless DNS delegation, i.e., assignments on
boundaries other than 8 bits.  I'd cut down the amount of DNS text that
currently exists or put in an example of about /26, /27, or /30 reverse dns
classless delegation.



editorial
---------

==> section 11 is confusing editorially as there are double the number 
of bullet points compared to the before.  A different xml2rfc 
technique (no new bullet point) should be used here.

   Rule #1 guarantees that the routing algorithm used is consistent
    across implementations and consistent with other routing protocols,
    such as OSPF.

==> "_other_ routing protocols" ? so, I guess the document is implicitly
written about BGP?  Rewording needed..

When that traffic gets to the "child", however,
    the mid-level *must not* follow the route 192.168.0.0/16 back up to
    the "parent" ...

==> the first use of the term "mid-level".  what do you mean?  clarify.
(btw, the paragraph was difficult to understand though it described
something that's blindingly obvious right now.  Maybe it could use a
rephrasing.)

  This can be a useful
    tool for reducing the amount of routing state that an AS must carry
    and propagate to its customers and neighbors, proxy aggregation can
    also create inconsistencies in global routing state.

==> insert "however" or something before "proxy aggregation" ?

  Assuming
    a best common practice for network administrators to exchange lists
    of prefixes to accept from one and other,

==> s/to/is to/ ?

5.  Example of new address assignments and routing

==> remove "new" ?

   this base "root" collection.  There is reason to believe that many of
    these additional entries are exist to solve problems of regional or
    even local scope and should not need to be globally propagated.

==> remove "are" or "exist"
==> btw, most of these actually don't solve any problem at all, but are just
useless junk :)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/