[ppml] "Recommended Practices" procedure

--On May 1, 2006 11:51:39 AM -0700 Vince Fuller <vaf at cisco.com> wrote:

>> 4. Regardless of the technical merits, 2005-1 is good for at least one
>> thing: it sends a strong message to the IETF saying in substance "In
>> case you have not noticed, it's about time to stick your head out of
>> somewhere and actually deliver something that could be accepted by both
>> the op community and the end customer".
> 
> No, it sends quite the opposite message. It says, in effect, "Hey, aside
> from your strict topological addressing plan, that ipv6 stuff is good
> enough for us. So we'll just ignore the only thing that makes ipv6
> routing scale and deploy it anyway".
> 
Well... I guess we'll have to see which message they receive.  I would
hope they are smart enough to realize that it specifies a requirement
for a scalable routing solution.  Realistically, with a scalable solution
to IDR, IPv6 is, essentially, deployable as is.

So... The intended message and yours aren't very far apart, but, that
subtle distinction does substantially change the meaning.  Hopefully
IETF will understand that it really is a demand for a scalable IDR
solution to support PI space.

> And no, I do not think that ipv6 is deployable with strict topological
> addressing (as the IETF naively specified) because the whole concept of an
> "address" is hopelessly non-scalable in ipv6 (and in IPv4, for that
> matter; but I think we have consensus that IPv4 won't scale into the next
> century).
> 
Yes.

> If you open the Pandora's box of "PI addressing" instead of demanding a
> scalable routing architecture, the game is over.
> 
I disagree.  I think that the two can continue together quite nicely.  What
is it about PI addressing that prevents subsequent deployment of an ID/LOC
split which is scalable?

> The solution space was too constrained for the multi6/shim6 effort to have
> a realistic shot at success. Once a decision was made not to modify ipv6
> protocol semantics (out of concern for the vast installed base that
> existed when multi6/shim6 started), the solution was virtually guarenteed
> to be complex, ugly, and of limited value. Again, basic design/engineering
> practice.
> 
I think there are ways we can change the protocol semantics without
affecting
end nodes and without having to do it in such a way that all routers have
to be upgraded simultaneously.

The simplest (from a protocol design perspective) would be to stick the
LOC in a type 53 extension header and then use that for IDR. If we add a
second subtype to 53, we can have a "beenthere" header which can be used
to prevent packet looping.  With these two data in the packet, AS PATH
is all that is required for IDR forwarding and prefixes never need to
leave the local AS (in terms of routing).

>> The way out of this mess is a BGP replacement that could handle
>> large-scale PI.
> 
> BGP isn't the issue and devising a replacement for BGP doesn't attack the
> fundamental problem.
> 
Correct.

> Co-mingling endpoint identification and topological location pretty much
> guarentees that the single number space that you use for "addressing"
> can't provide both the flexibility (proof against renumbering) and
> scalability (routing that can be summarized at abstraction boundaries)
> that you want.
> 
Yes.  On this, we absolutely agree.

Owen

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://lists.arin.net/pipermail/arin-ppml/attachments/20060501/8452700b/attachment.bin