On Wed, Feb 22, 2017 at 06:43:56AM +1100, Mark Smith wrote: > On 22 February 2017 at 04:27, Job Snijders <job@xxxxxxx> wrote: > > On Tue, Feb 21, 2017 at 09:49:32AM +0900, Lorenzo Colitti wrote: > >> On Tue, Feb 21, 2017 at 8:57 AM, Job Snijders <job@xxxxxxx> wrote: > >> > ps. The "Write a draft" argument is weak at best, since we are > >> > already are discussing a draft (called > >> > 'draft-ietf-6man-rfc4291bis-07.txt'), which is in IETF Last call, > >> > which means it is in a place to discuss the contents of that draft. > >> > No reason to kick the can down the road. > >> > >> I'm sorry, but that's really how it is. The text you dislike has been > >> the standard for almost 20 years, and is it inappropriate to change it > >> in the context of reclassifying this document from draft standard to > >> Internet standard. > > > > Or, perhaps it is inappropiate for the -bis document to target "Internet > > Standard" classification at this moment? ¯\_(ツ)_/¯ > > > > Especially when solidifying recommendations in an architecture Internet > > Standard-to-be, the utmost care should be taken to verify whether the > > paper reality (RFCs) and operational reality (what people do, for > > $reasons) are aligned. > > > > Flexibility isn't cheaper, it is more operationally expensive, because > it creates opportunity for complexity and errors. > > A very simple example to demonstrate the additional cost of flexibility. > > You showed the the distribution of prefix lengths in an AS. That may > have taken say 5 minutes to assemble and calculate? If all your prefix > lengths were /64s, you could have saved 5 minutes because you would > know the single value. > > Multiply that sort of example 5 minutes over the many times you deal > with the complexity and errors that will occur when having a range of > prefix lengths, and that will add up to a significant amount of time. > It was an unavoidable cost in IPv4 because it was necessary to stretch > the usable life of IPv4's 32 bits of address space. It is an avoidable > cost in IPv6. > > IPv4 too started out with a fixed or well known boundary between the > network portion and the host portion. > > RFC760: > > " Addresses are fixed length of four octets (32 bits). An address > begins with a one octet network number, followed by a three octet > local address. This three octet field is called the "rest" field." > > I advocate for /48s for all customers over a mix of /56s and /48s for > the same reason. The cost of managing the different prefix lengths and > resolving errors when the incorrect size prefix is assigned to a > customer are significant compared to the savings in RIR fees, and > perhaps may eliminate all those savings. When there is a single value > or size, there is no ambiguity and no opportunity for error. > > I think many network engineers (and many technical people in general) > consider flexibility to be a a desirable property because they think > it means they'll be able to adapt to any future requirement without > any significant constraints. It's an understandable view (which I used > to have), however, I don't think they often consider the cost that > flexibility creates. I've also haven't seen that flexibility pay off > as much as it is supposed to. > > > In those years sufficient data has been collected to conclude that > > /64 is not the "be all and end all". > > Alternatively, it could show that people are applying IPv4 practices > they're familiar with to IPv6, even when it isn't necessary. They're > missing out on operational savings from simplicity. Have you read rfc1925 section 2.4? You are grossly overstating these 'operational savings'. Also, for the sake of this dialogue I'll apply Hanlon's razor and operate under the assumption that you are not familiar with my work environment. I am amazed your reaction to my sharing of real-world data is the equivalent of "well, i think you are doing it wrong". A lack of empathy is exhibited in that you do not wonder _why_ things are what they are. Kind regards, Job