Looks like we're actually in full agreement.

Of course some people are going to strongly push for IPv6 anyway (there has been an epic thread arguing this for about 4 days now on Nanog with no sign of consensus. See the "quietly..." thread in the nanog archive if you have a few hours to spare...)

I can see some of their arguments, but they don't are going to cause friction in the long term because they don't align with the vision of the IAB for Internet development. Essentially nodes behind the NAT are not truly part of the Internet... Maybe for these cases sticking with IPv4 with NAPTv4 and NAT64 is the best way for them to continue to connect in future. If IPv6 doesn't give you what you want then don't use it. But at the same time respect the people it does work for.

I agree 100% with the fact that we need to expect and plan for growth.
I don't agree that attempts to route more intelligently are simply
bit shaving exercises though.

As things stand at the moment the size of the Internet RIB is an order
of magnitude greater than the number of AS numbers originating those
routes and this disparity is increasing. There are a number of
drivers here, certainly mobility is one, scarcity of IPv4 addresses
leading to fragmentation of allocations is another and there are also
concerns such as traffic engineering and multihoming.

The work that the IRTF Routing Research Group (RRG) is doing is taking
these fundamental drivers causing growth of the global table and
trying to find a long term architecture that allows us to address
these drivers while keeping the amount of information that has to be
distributed to a minimum.

By keeping the information in the global table down to a minimum both
stability and scalability are improved and everyone wins. Certainly
one of the outputs of the RRG is of the bit shaving type: Aggregation
with Increasing Scopes (AIS) but this is seen as a short term
solution. In the longer term something more fundamental is required.

Something else that it is also worth bearing in mind is that while
Moore's Law holds, CPU speed and memory capacity are growing
exponentially (as are the number of entries in the routing table);
however memory access speed does not show this same behaviour (see
http://www.dba-oracle.com/oracle_tips_hardware_oracle_performance.htm)

Locator / Identifier separation techniques allow the causes of routing
table growth to be addressed while removing the need for every router
needing to maintain a full set of endpoint routes but they also
introduce new functionality (e.g. enabling multihoming without the
edge network needing to run BGP). LISP allows routers to only carry
the identifier mappings for destinations that they are communicating
with. ILNP takes this even further and allows for locator mobility at
the host level enabling hosts to get everything they would gain from
PI space while using PA space. These approaches (as well as several
others being proposed) are a fundamental change in the way we think
about IP routing that allow for much higher bounds on long term
growth. They allow us to keep simplicity in BGP, current issues are
leading to proposals that make BGP significantly more complex under
the hood and complexity is the enemy of scale.

Putting these into the same camp as PPP header compression isn't
comparing like with like. Header compression is a useful technique to
improve efficiency of transport on expensive links but it doesn't
increase functionality so as higher capacity links come down in price
the need for it goes away. I do not believe this is the case with the
Locator / Identifier techniques

All three of these technologies will certainly help to reduce the power required for transmission, which is a good thing. The ability to detect the direction of the base station and to send directionally is also a good way to reduce interference and increase the density of information you can get in the air too. These are certainly good steps forward but will they be enough when we are looking at an exponential growth in demand?

We are still talking about non-coherent radiation sources too so dispersion will be a significant limiting factor in transmission distances even if power is lowered.

And of course I didn't really mention the NIMBY effect that tends to stand in the way of new RF deployments. Once the road surface is back down on a fibre dig people tend to forget about it. While if you put up an RF mast you will be plagued with people campaigning to have it taken down over unverified health claims (Oh, won't someone think of the children!)

Maybe I am just too pessimistic. We can certainly squeeze a lot more out of these technologies. Maybe demand will slacken off before we have exhausted that potential...

It is ideas like this that make me favour making the flow label mutable...

I really don't see how encoding port numbers in the flow label is supposed to give a greater level of stateless QoS than simply using the DSCP...

Hi Sam,

That's an interesting perspective.

Are you suggesting that your application register would specify the full 20-bit flow label? To be honest from my reading of RFC3697 I don't think this is an invalid use of the label. The RFC states that IPv6 Nodes should make no assumptions about the properties of the flow; however it appears to be talking about forwarding nodes. In your example it is not the forwarding node that is making an assumption, it is a remote management station that is using it for statistical purposes (presumably using something like IPFIX of Netflow v9 templates).

I can see how some form of structured flow-id assignment could be useful within an administrative domain but it is only going to be useful if the standards allow re-writing of the flow label at the edge. As you say, if you let stuff in from an untrusted zone then you risk overlapping (either randomly or maliciously) flow labels.

And is trust of flow values really only limited to public networks? Unless you are 100% responsible for writing all application code used in the network (including OS level network communications) can you really afford to trust flow values? Any registered value that you set aside could easily coincide with a pseudo-random value generated by an app that doesn't follow your coding guidelines.

The statement that the validity would be zero on a public-accessible network kind of gets to the crux of it. The default area of applicability of IETF standards is the "Big I" Internet. Private internets are certainly allowed, but they tend to be treated as special cases and are unlikely to wield a lot of weight during protocol definition. Any attempt to map flow labels to application is likely to remain outside of the standards and therefore it is also less likely to turn up in off the shelf products. Getting your network management platform to map from flow values to applications using your register is likely to involve you rolling you own code.

Another thing I would throw into the mix is the fact that by definition we are using IPv6. This means that the address space is not constrained. Using the flow-label for load balancing may seem like a waste of 20 bits to you, but isn't assigning addresses on the basis of a node also a bit of a waste of a 64-bit link address space? Would having a seperate end-point identifier per-application not also be a way of encoding this information? This would also have the benefit of being carried in a checksum protected part of the header.

I'm kind of thinking aloud here and there may well be mile wide holes in what I'm saying. I would be interested in further thoughts on this :)

The way I read the draft (and I have only read one of the set so far)
host changes would be required to gain full benefit of mobility, but
they are not mandated for initial deployments (although I am not clear
how ILNPv4 could be done without host changes).

Some of the problems that solutions like ILNP and LISP are trying to
solve are coming from the higher levels of the stack (most notably the
fact that an IP address identifies an interface, not a host) and
because of this solutions that only address the network (i.e. LISP)
are not guaranteed to scratch everyone's itch. In many ways I think
host changes are inevitable; however they make things much more
difficult to implement :(

One thing that I plan on expanding on in a later post is that neither
LISP nor ILNP seem to be particularly friendly to existing middle box
gear. Firewalling of either of these Map+Encap technologies will be a
nightmare...

What browsers are you guys using? I have been unable to reproduce here in Chrome, Firefox or IE.

I have even grabbed the URL from a the command line on a couple of boxes using wget.

I really don't understand what is going on here...

Thanks for reporting this. The diagrams are set to public and they
work for me when I am logged out of my accounts so I'm not sure what
the problem is :(

I'll get my investigating hat on and try and track down the problem...

Just a quick thought about how this could work in the future... When carrying L2TP over IPv6 it would be useful if the BRAS could expose the session ID (or a hash of it) in the Flow header. This would keep a per-user distinction in standard IP headers within the SP network and reduce the desire to make L3 decisions based on L4+ headers...

Hmmm... this response seems to have gotten lost when I posted by email earlier... Apologies if it shows up twice...

My past experience in the broadband area is that providers try to cram as many customers as possible on to a BRAS, so some level of congestion on the output interface is basically a given ;)

On the queuing front, I have run hierarchical queues using exactly this model on the Juniper E series. I was assuming that Cisco could do something equivalent.

As a disclaimer, I am not currently working with DSL on a large scale and it is over a decade since I last worked in the consumer space so a lot of my knowledge is second hand.