Re: [renum] IPv4 deployment scenarios to minimise renumbering costs

Fred,

This isn't a WG and we don't have a formal charter. But personally
I don't see much point in rehashing the last 15 years of discussion
of PI versus PA and what might happen if we deployed a completely
new architecture.  That doesn't preclude making the observation
that certain causes of renumbering won't apply if certain types
of address independence are in place. But the operational problem
isn't there. It's in what do we do when we must renumber anyway.

Please everybody, as I said at the start, re-read RFC 5887.

If you don't accept its conclusion that renumbering is sometimes
unavoidable, I think that point should be discussed elsewhere.

IMHO it's quite legitimate in that context to observe, without
extensive analysis, that address-independence techniques reduce
the cases in which renumbering is needed. That's why I
misinterpreted Ran's message and annoyed Fred. But it ends there;
the problem on the table is what to do when renumbering *is*
necessary.

Regards
   Brian

On 2010-12-04 13:05, Templin, Fred L wrote:
>> ...and therefore think of 
>> itself as PI, while allowing all of its upstreams to treat it 
>> as PA and aggregate routing accordingly.
> 
> What's that? Someone said "PI", and Teco didn't even jump
> in with a disparaging remark?
> 
> You all are talking about various solution ways forward
> all the while telling me to pipe down. You really ought
> to go have a look at IRON, RANGER, VET and SEAL.
> 
> Here is the lastest in the series, called "Provider-
> Managed IRON", which I think you will see strikes a
> happy balance between PI and PA:
> 
> http://www.ietf.org/id/draft-templin-iron-pm-00.txt
> 
> Fred
> fred.l.templin@boeing.com
> 
>> _______________________________________________
>> renum mailing list
>> renum@ietf.org
>> https://www.ietf.org/mailman/listinfo/renum
>>