Subject: Re: new version of draft-narten-ipv6-3177bis-48boundary-03.txt

From: Thomas Narten <[email-masked]>
Date: Fri, 07 Mar 2008 13:47:55 -0500

"Tony Hain" <[email-masked]> writes:

> There is no discussion about negating the overly conservative mindset of 
> the RIR membership, and that the reason they didn't take this up until 
> 2005 was that they were not really serious about IPv6 before that. That 
> overly conservative mindset still exists, with no consideration about 
> the long term impact of their oppressive behavior.

Not sure I agree with this or that it would be appropriate in any case
to say something along those lines in the document. Do you have
specific text in mind?

> There is no discussion of the point raised in the intro about the 
> scaling impact on the public routing system. I would suggest after the 
> last paragraph of section 2:
>
> Being overly conservative on end site assignment size also has a direct 
> impact on the potential size of the global routing system. When longer 
> prefixes are assigned to end sites, the public routing table has the 
> potential to grow 2^n times larger than with shorter prefixes. Many of 
> the same people that complain about assigning the same size prefix to 
> large enterprises and home users also complain about the scale of the 
> public routing system, without acknowledging that the longer prefixes 
> make that problem worse.

I actually don't agree with this phrasing. Indeed, I've been kind of
frustrated with parts of of the discussion about how IPv6 makes the
routing table problem worse.

The size of the end site assignment does not necessarily mean more
prefixes in the routing table.

The size of the routing table is determined more by the need for
"sites" (I'm using the term loosely here) to be independent of each
other (and in routing terms, that means part of a bigger aggregate)
and have their own prefix propagated into the core. What determines
the need for an individual prefix includes such things:

  need to traffic engineer for the "site"
  that it makes sense for all of that site's primary communication to
     the Internet be through a single point of attachment
     (geographically dispersed sites regardless of size may want to be
     individually routed for better connectivity, etc.)

Note that none of the above is directly correlated with size of the
end site allocation. 

Another factor: unwillingness to renumber into a bigger block, if the
current block fills up. But even that doesn't necessarily lead to
extra prefixes in the DFZ. An ISP has the option of just giving the
customer a second (non-aggregatable) prefix and flat routing that
internally (within the ISP), while still aggregating the prefix for
external purposes.

> The summary comment about bridging not being desirable appears to assume 
> that it is even technically possible because all the subnets will use 
> Ethernet framing. There should be some discussion about the potential 
> for new framing formats to be developed that will not be technically 
> compatible with existing link technologies. When that happens the 
> braindead single-subnet model will result in another nat fiasco.

I changed the wording about bridging.

> The summary comment about 'generally unacceptable' is probably the wrong > language. Maybe reword the comment something like:
> - assigning a longer prefix to an end site, compared with the existing > prefixes the end site already has assigned to it, is likely to increase > operational costs and complexity for the end site, with no discernable > cost savings to anyone. 

I also made this change.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 07 Mar 2008 13:44:54 -0500

"Tony Hain" <[email-masked]> writes:

> This document should clearly state that there is no -technical- reason for
> anything longer than a /48, and there are clear technical reasons for
> nothing longer than a /60. There may be -business- reasons for nibble values
> in between, but those should not be confused with technical
> requirements.

I might be close to agreeing with this, I think, but probably not for
the reasons you mention.

I think it's actually somewhat unhelpful to say "technical reasons",
because now we get into arguing what "technical" means. I believe that
most of the issues surrounding the end site allocation size are
operational, and not really technical. They have to do with ease of
renumbering (when changing providers -- i.e., don't move to fewer
subnets). Or the ease of having the site be restricted to using only N
subnets. 

So, can you restate what the arguments are against longer than a 60?

Thomas