Last Call: 'Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan' to Proposed Standard
draft-ietf-grow-rfc1519bis-03.txt as a Proposed Standard That's an interesting document - at least for me, because I didn't know most of the nine obsoleted RfCs. Does it intentionally avoid 2119 keywords ? There's a MUST in 5.1, a should NOT in 5, and somewhere I saw another must which could be a 2119 MUST. There might be a few typos in the text above the ASCII art in 6.1, s/RA/PA/ and s/RB/PB/ (?) For the difference between C4 and C5 a pointer could help: The text and RfC 1519 apparently say that C5 should also explicitly show up on the left side (PA) like C4, not only on the right side (PB). There's no erratum for 1519, probably I just miss some clue about primary vs. secondary, or aggregation. Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: grow: Last Call: 'Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan' to Proposed Standard
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 iesg@ietf.org or ietf@ietf.org 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
Re: grow: Last Call: 'Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan' to Proposed Standard
On 26-Nov-2005, at 11:30, Pekka Savola wrote: == 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. Perhaps an informative reference to RFC 4116 could save some space and avoid a certain amount of wheel-reinvention. 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. Personally, if the draft is to receive additional edits anyway, I think all the DNS info should be stripped and replaced with a sentence or two that note the additional complexity that CIDR introduces to IN-ADDR.ARPA delegation, along with a normative reference to 2317. Attempting to embed a stripped down version of 2317 into this document doesn't seem productive. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan' to Proposed Standard
On Tue, Nov 22, 2005 at 10:52:23AM -0500, 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 iesg@ietf.org or ietf@ietf.org mailing lists by 2005-12-06. Hi, I think this is an interesting update. Some minor points that may wish to be considered but feel free to pass over. One is on section 2 - I think the issue is perhaps more the efficiency of usage of IPv4 address space. I know that is tied to rate of consumption, but for many end site admins the impact of CIDR is a lot of paperwork to demonstrate efficient use of allocated (or requested) address space. The rate of growth of the routing tables is perhaps also about the PI vs PA issue. Perhaps these terms could be explained in the text. Another point is the use of private address space in the documentation for example purposes. I know this is hard to avoid, but a statement like For example, the legacy class B network 172.16.0.0, with an implied network mask of 255.255.0.0, is defined as the prefix 172.16.0.0/16 seems odd when I normally see 172.16.0.0 and think of it as a /12. A third point is on the negative impacts of CIDR. For example, in squeezing out every bit of the prefix address space, administrators often spend extra time resizing internal (globally addressed) subnets because their provider insists on them maximising the efficiency of their address plans (understandably).Or when a site grows, its ISP offers it a different larger block (requiring renumebring) or non-contiguous ones, adding some internal complexity. I would also suggest that this pressure has led to increased adoption of NAT. I don't see NAT mentioned anywhere in the text - perhaps it is avoided for 'religious' reasons :) I think in contrast to IPv6 address space allocation, in IPv6 we have aggregation from the outset, with a /48 per site (or maybe a /56 for some sites :) and in effect 'infinitely' sized subnets, so the above concerns are not really present for a typical IPv6 deployment. Perhaps again though an aside into IPv6 comparisons with aggregation would be a distraction :) -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: 'Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan' to Proposed Standard
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 iesg@ietf.org or ietf@ietf.org mailing lists by 2005-12-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-grow-rfc1519bis-03.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
