[RAM] Re: RADIR Problem Statement: timeframe, portability, mobility, FIB etc.

Robin,

Briefly,

On 2007-08-09 04:56, Robin Whittle wrote:
...
> 
> I am sure that there is no prospect whatsoever of end-user's genuine
> needs for multihoming - or for ease of using another ISP - being met
> by some other mechanism than portability of their own address space.

"Portability" is a word I associate with cell-phone numbers. If you're
referring exclusively to IPv4, and to the class of mechanism described
in RFC 4116, then yes. But your argument does not apply a priori
to a scenario where address space and prefixes are plentiful. That is
why IPv6 was designed from the start on the assumption that sites
would have multiple simultaneous prefixes and hosts would have multiple
simultaneous addresses.
...
> It would be marvellous if mathematicians found more than 4 billion
> combinations of 32 bits . . . but since we all agree there is no
> possibility of this occurring, there is no point in an IPv4 addressing
> problem statement being written as if it was a possibility.

Yes, but that isn't the problem statement being written.

...
>> (And no, I'm not about to argue that getting automatic/painless
>> renumbering is about to happen. But let any proposed solution in
>> that direction be evaluated  on its merits please!).
> 
> I am evaluating "automatic/painless renumbering" it on its merits -
> its merits amount to zero.

That's just polemic.

> So let's not pretend that perhaps, by some new technique no-one has
> stumbled upon in all these years, there might be a technical
> approach which would make network operators happy to have their
> entire network suddenly renumbered the moment one multihoming link
> goes down,

I'm not aware that anyone has ever suggested such a thing.

> or that could provably make some automated renumbering
> system work flawlessly on a huge variety of networks in existence
> today, for which there is no clear enough definition to even start
> designing such an automated system.

There was certainly some thought about that in the early days of
IPv6 design, but it's clearly impossible, which is why RFC 4192
was written.

...
> The reason it is not being pushed very heavily is because the only
> people who want it are not the end-users, but those who want to keep
> end-users using PA space for the convenience of not having to design
> and run the Internet in a way which genuinely supports end-user needs.

This also verges on the polemic. To be clear, we've spent >10 years
with the certain knowledge that the only way to avoid a BGP4 meltdown
is to aggregate prefixes, and the only way to aggregate prefixes is to
us PA space whenever possible (and I mean that strictly, i.e. not
merely whenever convenient or preferred).

Multi6 took that as a basic assumption and Shim6 (and I suppose Six/One)
takes that as a basic assumption. This wasn't an assumption adopted for
convenience; it was an assumption adopted to avoid meltdown. People thought
that would be even less convenient.

That's also why it would be pretty short sighted to hand out more than a
few tens of thousands PI prefixes, of course, unless we have a viable
solution in the LISP/iVIP/eFIT class ready to deploy. If this current
effort leads to such a solution, net convenience will increase. But the
problem statement cannot assume that such a solution can be found.

...
>>>  - Do folk agree with the problem statement as written, or are we
>>>    missing something fairly fundamental?
>> Yes. I think it's correct to keep it down to the bare bones.

I still think that. Short problem statements get read. Long
ones don't.

...
> and I responded to your critique:
> 
>   http://www1.ietf.org/mail-archive/web/ram/current/msg01779.html
> 
> but I haven't seen your response to this.

You won't. I will be mostly silent for the next month while
moving jobs and land masses.

     Brian

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram