Subject: grow: I-D ACTION:draft-ietf-grow-rfc1519bis-02.txt

From: [email-masked]
Date: Mon, 13 Jun 2005 15:37:09 -0400

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
	
This memo discusses the strategy for address assignment of the
   existing 32-bit IPv4 address space with a view toward conserving the
   address space and limiting the growth rate of global routing state.
   This document obsoletes the original CIDR spec [RFC1519], with
   changes made both to clarify the concepts it introduced and, after
   more than twelve years, to update the Internet community on the
   results of deploying the technology described.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-grow-rfc1519bis-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-grow-rfc1519bis-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-grow-rfc1519bis-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 15 Jun 2005 08:30:22 +0300 (EEST)

> 	Filename	: draft-ietf-grow-rfc1519bis-02.txt

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/

---

From: Vince Fuller <[email-masked]>
Date: Wed, 15 Jun 2005 11:15:44 -0700

Hi Pekka-

First, let me say that I am quite reluctant to make changes to the document
now, since doing so will delay publication by several more months, thanks
to our wonderful standards process. We had hoped to get this thing out the
door in time for the next IETF (that's why we sent out the initial draft way
back in April). To that end, it would have been Really Nice to have seen
this comments during the WG last call period.

Dave, Geoff: what do you think? Do these comments warrant resetting the
Last Call/publication clock yet again? How much delay will we incur?

> substantial

This text does describe current practice. If the document is to be modified,
I would retain the text but perhaps qualify it by stating that this is the
current state of affairs as of mid-2005 but that block sizes and even the
organizations involved may well change in the future.

> the tone should possibly be watered down a bit to also address the

Again, this is current practice for routing-based multihoming in IPv4. It
is also, IMHO, a core requirement of this document to describe how CIDR
works in the presence of such multi-homing and the related issues of
topological rehoming and renumbering.

Any modification would be to add a timeframe qualification. It might also be
appropriate to add pointers to other documents that describe other multi-
homing strategies. Can you offer appropriate references?

> there is legitimate or recommended use of advertising more specifics.

This is a technical document. There was some discussion about whether to
describe some of the "other significant considerations" but the authors
and the early reviewers came to agreement that we didn't want to overly
muddy the technical description with political issues.

Tony/Geoff/Dave: do we want to consider any changes to this section? My
inclination is to say "no".

> (such as traffic class for class-based routing, protocol distance, etc.)

These are the rules that are intended to make routing "work" (i.e. avoid
loops and other undesirable behavior) in a world where address assignment
is done according to CIDR. IMHO, the other technologies you describe are
beyond the scope of this document.

> removing the last sentence completely.

This is a case where I simply disagree.

> about 3 different places in the doc)

I will defer to my co-author and to the WG co-chairs for their opinions.

> routes or even your own aggregates in your IGP, so the text could probably

IGP could be replaced here with "the provider's internal routing system",
which would be more vague but would capture a larger range of current common
practice. Not sure it is worth making the distinction.

> currently exists or put in an example of about /26, /27, or /30 reverse dns

Oh? Quoting from it's Introduction:

   This document describes a way to do IN-ADDR.ARPA delegation on non-
   octet boundaries for address spaces covering fewer than 256
   addresses.  The proposed method should thus remove one of the
   objections to subnet on non-octet boundaries but perhaps more
   significantly, make it possible to assign IP address space in smaller
   chunks than 24-bit prefixes, without losing the ability to delegate
   authority for the corresponding IN-ADDR.ARPA mappings.  The proposed
   method is fully compatible with the original DNS lookup mechanisms
   specified in [1], i.e. there is no need to modify the lookup
   algorithm used, and there should be no need to modify any software
   which does DNS lookups.

Is there a better canonical reference?

> editorial

This changes would be largely adopted should we decide to modify and re-
issue the document. Thanks.

	--Vince

---

From: Pekka Savola <[email-masked]>
Date: Thu, 16 Jun 2005 18:31:08 +0300 (EEST)

> Last Call/publication clock yet again? How much delay will we incur?

As said, I'm OK with waiting until the IETF last call (or if AD 
evaluation results in requiring changes).  There's no escaping the 
fact, however, that the draft needs to be revised before the IESG 
evaluation.

I'm also a bit doubtful about getting this finished by the next IETF, 
because when the AD is done evaluating it, at least 2-week IETF LC is 
required (plus a revision cycle), after which it takes at least 1-2 
weeks until the IESG evaluation (in the best case).  As the next IETF 
starts in about 1.5 months, things would need to progress very quickly 
to achieve that.

> organizations involved may well change in the future.

That would be OK by me.  The maint point here is that the document 
cannot be read to be normative on the subject.

> topological rehoming and renumbering.

It is _a_ current practice; maybe the most dominant one, but others 
provably exist as well.  My maint point is to ensure that this 
document does not attempt to specify which is the "right" multihoming 
method.

As I see it, the main goal of this doc is to illustrate how 
longest-prefix matching works.  If we want to use multihoming as an 
example to make the concepts in practice easier to understand, that's 
fine.  But multihoming shouldn't (IMHO) be the main topic of this doc.

> homing strategies. Can you offer appropriate references?

Unfortunately, no; I do have a (yet) unpublished (being reviewed) 
paper on BGP-based multihoming approaches which I've observed from the 
advertisements.  I can send it off-list if interested.  There are 
probably other, better sources as well.

> inclination is to say "no".

The recommendation "it makes sense to assign all end-site address 
space out of blocks allocated to service providers." is given without 
consideration for non-routing related costs.  IMHO, a standards track 
(or BCP) document cannot do that.

If you prefer not to discuss this topic properly, I suggest we remove 
most of the multihoming text from this document, as it is not required 
from the CIDR point of view.

The CIDR concept can be well understood without having to make 
arguments whether using more specific or independent blocks is a 
better idea.

> beyond the scope of this document.

Sure, I wasn't saying you need to describe them.  I was just saying 
that the statement, in particular the word _only_, is technically 
inaccurate, and must be replaced.  For example, you could say,

   Routing to all destinations must be always use the longest-match
   basis first.

> This is a case where I simply disagree.

Can you show me two vendor (or even one) who, for example, do not 
advertise the default route from iBGP to eBGP if the route map 
basically just says "advertise everything"?

AFAICS, even cisco's 'default-information originate' has narrower 
semantics.

> practice. Not sure it is worth making the distinction.

I'd make that change and further say, "(e.g., IGP or iBGP)".

> Is there a better canonical reference?

Sorry, I meant that _this_ (grow) document doesn't discuss RFC2317, 
even though it refers to it (and discusses _classful_ delegations). 
What I was saying is that this document should discuss more (i.e., 
RFC2317) or less (so that it would be more balanced).

---

From: Joe Abley <[email-masked]>
Date: Thu, 16 Jun 2005 22:01:32 -0400

[...]

>> homing strategies. Can you offer appropriate references?

It may be worth reviewing draft-multi6-v4-multihoming-03, which is has 
been approved for publication and is just waiting for the RFC editor.

Joe