grow: Re: I-D ACTION:draft-ietf-grow-rfc1519bis-02.txt
Pekka Savola <pekkas@netcore.fi> Wed, 15 June 2005 05:33 UTC
Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08406 for <grow-archive@lists.ietf.org>; Wed, 15 Jun 2005 01:33:41 -0400 (EDT)
Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j5F5UVwk006107; Tue, 14 Jun 2005 22:30:31 -0700 (PDT)
Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j5F5UVZq006104; Tue, 14 Jun 2005 22:30:31 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j5F5UT39006022 for <grow@lists.uoregon.edu>; Tue, 14 Jun 2005 22:30:29 -0700 (PDT)
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j5F5UM519059 for <grow@lists.uoregon.edu>; Wed, 15 Jun 2005 08:30:23 +0300
Date: Wed, 15 Jun 2005 08:30:22 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: grow@lists.uoregon.edu
Subject: grow: Re: I-D ACTION:draft-ietf-grow-rfc1519bis-02.txt
In-Reply-To: <200506131937.PAA14655@ietf.org>
Message-ID: <Pine.LNX.4.61.0506150826460.18786@netcore.fi>
References: <200506131937.PAA14655@ietf.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Sender: owner-grow@lists.uoregon.edu
Precedence: bulk
On Mon, 13 Jun 2005 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Global Routing Operations Working Group of the IETF. > > Title : Classless Inter-Domain Routing (CIDR): The Internet > Address Assignment and Aggregation Plan > Author(s) : T. Li, V. Fuller > Filename : draft-ietf-grow-rfc1519bis-02.txt > Pages : 28 > Date : 2005-6-13 Sorry I couldn't find the time to look at this during WGLC, so maybe you should consider these as IETF LC comments. In general I think the doc is good, but there are a couple of places which weren't updated since 1519 which needed a slight polish, and a couple of pieces of text (like on multihoming) which left me wondering whether they even belong to this document (at least in that extent). The problem could be that someone thinks the text here is normative on how you should or should not multihome, how IANA should allocate addresses, etc., and we don't want to create that perception. Below.. substantial ----------- The IANA makes allocations from this pool to Regional Internet Registries, as required. These allocations are made in contiguous bit-aligned blocks of 2^24 addresses (a.k.a. /8 prefixes). ==> I do not think the latter sentence is appropriate in a standards track document. We should not be micro-managing the IANA allocation procedures in this document; if the IANA wanted to change to allocate e.g., /9 or /7, someone could come along and point to this doc, stating that the IETF doesn't support such allocations. The text like this should be reworded so that the /8 prefixes can not be read as normative text but rather just the status as of writing this document. 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. Also, since the routing cost associated with assigning a multi-homed site out of a service provider's address space is no greater than the old method of sequential number assignment by a central authority, it makes sense to assign all end-site address space out of blocks allocated to service providers. ==> the routing cost might be the same either way (more specific vs an independent address block), but there are other significant considerations (which is one reason, above, why this kind of text might be controversial in a standards track document on CIDR; a BCP on multihoming mechanisms might be a better place). Specifically, when ISPs employ BGP or IP prefix filtering, to block outside advertisements (or packets) from their own address space, multihomed more specifics from your own block are exceptions you must handle. More specifics are also less elegant because they create a perception of routing swamp -- it is more difficult to pursue "bad advertisements" when there is legitimate or recommended use of advertising more specifics. .... 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 --------- o RFC 2036: Observations on the use of Components of the Class A Address Space within the Internet [...] o RFC 1518: An Architecture for IP Address Allocation with CIDR ==> 1518 should probably be put in the right numerical place? 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" ? 2. Acceleration of the exponential trend in late 1993 and early 1994 as CIDR supernet" blocks were first assigned by the NIC and ==> missing " 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/
- grow: I-D ACTION:draft-ietf-grow-rfc1519bis-02.txt Internet-Drafts
- grow: Re: I-D ACTION:draft-ietf-grow-rfc1519bis-0… Pekka Savola
- Re: grow: Re: I-D ACTION:draft-ietf-grow-rfc1519b… Vince Fuller
- Re: grow: Re: I-D ACTION:draft-ietf-grow-rfc1519b… Pekka Savola
- Re: grow: Re: I-D ACTION:draft-ietf-grow-rfc1519b… Joe Abley