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

[Vince Fuller <[e-mail]>]

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?

To respond to the specific comments:

> 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.

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.

>    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.

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?

>               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.

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".

> 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.)

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.

> 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.

This is a case where I simply disagree.

> 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)

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

>    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.

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.

>    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.

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
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/