RE: 3177-bis

["Tony Hain" <alh-ietf@tndh.net>]

Thomas Narten wrote:
> Tony,
> 
> I'd really welcome your feedback on how to make the document
> better. But to be blunt, I am having difficulty extracting the
> substantive content to apply to the document.
> 
> > The fundamental goal of this draft is just misguided.
> 
> As Brian says, please be clear. The goal of this draft is to make
> clear that /48 is not a technical/architecural requirement and that the
> concerns/motivations that led to the original recommendation of /48
> can be met with end site assignments other than "/48 for everyone". If
> you disagree with this, please elaborate.
> 
> > It is essentially trying to get the IETF to revisit history &
> > restate the IAB's recommendation, in order to align it with the
> > persistently short-sighted policies of the RIR's.
> 
> Revisit history? Come on. By that logic, we can't revise any document
> that has been made into an RFC, since that would revisit history.
> 
> 3177 was written some 8 years ago. Some of what it says needs
> updating. Also, the consensus for the 3177 recommendations was what I
> would call "rough", even back then. Case in point, I supported it. But
> I now view /48 for everyone to be unnecssary and inappropriate.

As I recall your primary issue back then was renumbering, and that has not
gotten any easier. Despite chatter about not making people take a longer
prefix than one they already have, there is no policy anywhere that
explicitly enforces that. Primarily that is because the RIRs don't enforce
ISP business practice, they only withhold resources if their perception of
'reasonableness' is not met.

It appears you missed the point, I was not arguing that we can't revise
documents, I was pointing out that we are being asked to revise a document
because the RIRs are not willing to do what they need to. 3177 was never a
mandate, as it has 'Recommendation' in the title, and 'should' for the
expected action. Most of the clarification aspect of this document is fine,
but there is no need to explicitly say /56, and if it is going to be there
some math justifying the new value needs to go along with it. 

> 
> > Due to their core objectives, the RIR's are incapable of supporting
> > innovation and looking to the future because they are focused on the
> > past, as their measures of 'fairness' are based on historical
> > measures of efficient deployment of technologies and networking
> > models from the last century.  The call for 'reasonable' is a prime
> > example of how quickly this will fail, because perceptions of
> > 'reason' that are based on the past will never accommodate future
> > innovation.
> 
> This seems like nonsense to me. To say that the RIR's idea of fairness
> is based on "historical measures" seems to ignore the vastly different
> RIR policies currently in place for IPv6 vs. IPv4. There is literally
> no comparison between the two, in terms of how much address space one
> gets under IPv6 per current RIR policies.

That paragraph is an indication of how easy the trap is to fall into. Number
of addresses is not the issue, it is the measure of 'reasonable' and how
much effort is required to justify more. Group-think is incapable of
imagination, so there is no way to ever move beyond past practice.

> 
> > There is no math justifying the assertion that a /56 actually solves
> the
> > collective set of goals. In particular, the scare tactic reference
> > [ROUTE-SCALING] has no substantiating documentation, and even cursory
> > thought about the problem would expose the point that moving bits
> from local
> > to global routing will only make any scaling concerns worse.
> 
> The reference to [ROUTE-SCALING] is in the intro and is associated
> with the sentence:
> 
>    There are a number of considerations that factor into address
>    assignment policies. For example, to provide for the long-term
> health
>    and scalability of the public routing infrastructure, it is
> important
>    that addresses aggregate well [ROUTE-SCALING].
> 
> Are you saying that the sentence is false? Surely you are not going to
> argue that aggregation isn't important. But more to the point, this
> sentence is general background (and a true statement) and isn't
> intended to (or actually used to) justify any other part of the
> document. So I really don't get why you bring this up.
> 
> Also, moving bits from the left to the right does NOT automatically
> make aggregation worse, as I indicated in another posting recently.
> There are a number of other factors that come into play that are also
> important. Aggregation is about the number of distinct prefixes that
> the routing system must carry. The size of an individual prefix is
> irrelevant. It's just the total number of prefixes that matter.

I agree it is the total number of prefixes that matter, and moving the bits
from the site to the DFZ side of the default allocation unit will amplify
the number of possible prefixes that the global routing system has to carry.
Since we know the RIR policy will continue to be as stingy as possible,
there will be fragmentation over time, so more bits just means a bigger
scaling problem. 


> 
> > The arguments at the mic today about fragmentation due to having to
> > get additional space are an artifact of RIR policy, and no matter
> > what size the IAB/IETF recommends, the RIR policies will insist on
> > small periodic blocks for 'efficiency' (read that as power to say
> > no), which will result in fragmentation over time.
> 
> I agree that RIR policy has a big impact on aggragation over time. But
> that is not something this document can address, so I don't think this
> has any impact on this document. (At least, not that I can tell.)
> 
> In any case, I'm optimistic that RIR policies can be made better to
> address the aggregation problem, if that turns out to be a problem in
> practice.

Their actions show otherwise, and they lose the power to say no if their
customer base never has to come back and beg for more. 

> 
> > The other argument at the mic today about needing something longer
> > than a /48 to avoid RIR policy to register assignments in whois,
> > completely misses the point that it is the RIR policy that has
> > failed, not the recommended size. For example, a policy that said
> > 'any deaggregate which results in an explicit DFZ table entry is
> > required to have a whois registration', would make much more sense
> > than one that assumes all units of the same size have the same
> > policy. There is no reason that end site assignments that are
> > aggregated into the DFZ would need their own whois entry, but rather
> > than fixing RIR policy, there is an expectation that the IETF/IAB
> > should change to accommodate their unwillingness to act.
> 
> I agree that this argument is orthogonal to the end site assignment
> size and out of scope for this document.
> 
> > The half-hearted discussion about bridging possibly not being
> desired,
> > completely glosses over the point that time after time it has been
> shown
> > that bridging between media types is prone to failure, and that there
> will
> > be new media types that emerge during the lifetime of IPv6. Given the
> uproar
> > over a past technology that only allowed a single cell to consume 10
> > microseconds of link time, and that for the 100Gbps link Comcast used
> this
> > week a full-sized Ethernet frame only consumes 120 nanoseconds of
> link time,
> > we are already past due for a new framing technology. Whatever it is,
> there
> > will be routed rather than bridged interconnection of those. (never
> mind
> > that the IETF is supposed to be focused on L3 approaches, not
> promoting
> > bridging of a 30 year old L2 one)
> 
> The key point for this document is that we shouldn't force bridging on
> anyone. The document says that. I.e., it says:
> 
> 
>      Although a /64 can (in theory) address an almost unlimited number
>         of devices, sites should be given sufficient address space to
> be
>         able to lay out subnets as appropriate, and not be forced to
> use
>         address conservation techniques such as using bridging. Whether
>         or not bridging is an appropriate choice is an end site
>         matter.
> 
> I don't think we need to spend a lot of time arguing about what will
> or will not happen with frame formats over the next ten years.
> 
> The current text was based on a list suggestion. I am willing to make
> it stronger. Going back to
> http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00357.html, I'm
> willing to add something like:
> 
>     In some cases, bridging is not an available alternative to routing
>     or subnetting, as it requires a significant level of compatibility
>     between the link layer technologies being bridged. For example, it
>     is not possible to bridge between Ethernet and Bluetooth.)
> 
> (And FWIW, I think we are going to be stuck with Ethernet frame format
> essentially forever, because the incremental improvement of other
> formats simply aren't enough to get past the ease of interoperating
> with a very well-established frame format.)

That text is better at making the point. While I agree that Ethernet will be
around for awhile, it is not the last framing technology, and eventually
something will come along when the pain of tiny 1500B frames exceeds the
cost of switching. 

> 
> > The discussion about paying fees to get additional space is probably
> > inappropriate, because it presumes that the IETF knows this is a bad
> > business practice.
> 
> I am willing to take this out, but only reluctantly. I put it in to
> counter the myth that ISPs charge for extra addresses because they
> have to (i.e, because they are just passing along the cost of getting
> addresses from RIRs.)  It is a myth that is widely
> repeated. Unfortunately, the argument comes up when people voice
> opposition to changing the end site assignment. Hence, I think it is
> important to include it.

I will try to send you some text, but I need to get on the road right now.

> 
> > The real goal here is to note that justifications on the past are
> > irrelevant and can't be assessed appropriately when talking about
> > future deployment needs. There are 281,474,976,710,656 /48's (minus
> > special use prefixes), so claims that we will run out are
> > absurd. The fact that the RIRs started out applying a host measure
> > to what is a subnet assignment reality does not mean that the IAB
> > was wrong. What it means is that people need to use real math
> > justifications to back up their claims, not just vague notions of a
> > problem that will never exist.
> 
> The RIRs are well past measuring "host utilization" for IPv6, and have
> been for 6+ years. So I don't get why you bring this up.

HD and practice came up at the mic. If this document intends to state a
value other than /48, it needs to offer a mathematical basis for the change.
That basis also needs to indicate the impact on the DFZ of adding 256x the
number of prefixes.

Tony