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.
Regards,
Mark.