> On Sun, 21 Oct 2007 13:22:08 +0200 > Jeroen Massar <[EMAIL PROTECTED]> wrote: > >> Hi, >> >> I just noticed >> http://www.nanog.org/mtg-0710/presentations/Dickson-lightning.pdf >> and found some serious flaws and most likely misunderstandings in the >> way that some things are presented in there. It was already publicly >> presented at the NANOG meeting, so lets discuss ;) >> >> <insert humble mode disclaimer etc /> >> > > Slide 2: > > "We canât fault the IETF - > they arenât operators" > > Some of us are. We've also run Novell IPX, Appletalk or DECNet networks > in the past, with fixed length node addressing, and would love to have > it back. No more too small subnets because you didn't guess right in > the first place, no more incorrect subnet masks, no more double hops > via a router on the same link because you've had to add a secondary > subnet to a link to avoid renumbering, no more remembering to larger > (or smaller) subnets, no more early mornings or late nights outside of > business or critical use hours fixing all of those things ...
Indeed. In fact, that slide was a little disingenuous. Please let me explain. There are many within the operator community who for various reasons, does not particularly respect, trust, or value, the work of the IETF, or its processes, or its members. My intention was not to play to those prejudices, but to move past them into discussions on the particulars of specific IETF RFCs. And, in particular, to completely avoid the finger-pointing game. I would have apologized in advance, to you folks, but didn't want to telegraph too much about my talk, which I decided to do at the last minute. (If I had planned for longer, or done more advance work, it might have gone over better at NANOG, let alone here.) So, let me know apologize if I have offended any. I too, have tons of experience as an operator. Most of it good, due to success in using approaches that scaled very well. I learned from the mistakes of others. (And some of it was Appletalk, Ethertalk, and bridged Appletalk/IP networking.) My intent currently, is to return that wisdom to the community at large, to help them collectively from suffering from problems that scaling up IPv6 deployment *may* introduce. I don't know for sure that not doing what I suggest will result in doom. However, I am confident in saying, that doing what I suggest will have much lower likelyhood of bad effects, for a much longer time frame. And, other than the (intended) side effect of a window of overlap between changes to RIR policy and IETF and vendor changes, of incompatibility between allocations and autoconfiguration, adopting both policy and RFC changes don't, as far as I can see, have a down side, other than the need to deploy newer versions of code to end nodes. Which is to say, the only down side is, that there is any change at all. And, to boot, the window of overlap, still has backward compatibility. At no time will autoconfiguration fail to work when used with a /64. So, giving a /64 to an end site will allow a flat autoconfiguration deployment initially, and will later result in the ability to use 2^16 autoconfiguration subnets. Thanks for your understanding, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
