I-D Action:draft-azinger-scalable-addressing-00.txt

Fred Baker fred at cisco.com
Mon Sep 27 15:55:22 CEST 2010


On Sep 26, 2010, at 5:34 PM, David Conrad wrote:

> Fred,
> 
> On Sep 26, 2010, at 1:27 AM, Fred Baker wrote:
>> So the complaint is that the IETF has not found a cure for human stupidity/laziness or for the need to configure routers?
> 
> This is somewhat beside the point as the die has already been cast, but I believe you are unfairly glossing over some of the difficulties implicit in the choice to bind the locator and identifier into the same object.  For example, the fact that transport-layer connections must be terminated when changing network topologic location means that it is impossible to maintain connection over those network change events.  This has nothing to do with human stupidity/laziness.

No argument there. I suspect, though, that this is also true of ILNP (which tries to do exactly what you are asking for) as there is no signal that tells the peer which prefix to change do. 

>> Or is there another complaint?
> 
> I believe the original complaint was that some folks in the IETF have in the past ignored operators' input and the current draft appears to be repeating that pattern.

I can't fix everyone in the IETF. I am asking questions in this forum because I was asked by an operator to do so. I hope it's clear that v6ops is listening.

>> I'm serious. If the IETF has actively gotten in the way, there's something we need to fix.
> 
> In this specific case, several people including myself have argued that in the area of address allocation policy (or architecture, if you prefer), the IETF has in the past published documents that have tried to block PI allocation to end users without providing a reasonable (from the end users' perspective) alternative.  I fully understand the underlying rationale for these attempts and I even agree conceptually with the intent, but pragmatically speaking, I don't see the IETF having a whole lot of say in the matter.

Ack.


More information about the ipv6-ops mailing list