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

[Pekka Savola <[e-mail]>]

On Wed, 15 Jun 2005, Vince Fuller wrote:
> 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?

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.

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

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

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

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.

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

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.

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

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.

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

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.

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

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.

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

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

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

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

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