Re: [RRG] RE: What do we have consensus on?

[Robin Whittle <rw@firstpr.com.au>]

Hi Tony,

Thanks for your reply:

>> Can you list what decisions the RRG has achieved consensus on?
> 
> There are a few things that we have consensus on and even then there are
> contingencies on that consensus.  Specifically, for the mapping function, we
> have consensus that we should support host specific identifiers, as well as
> blocks.  

OK.

> We also have consensus that mapping systems that there should be
> active mechanisms for dealing with overload situations.  

I don't understand this or recall the discussion.  Can you point me
to that discussion.


>> For instance, is there broad consensus that will the RRG have done
>> its job if we propose a solution which only works with IPv6?
> 
> No, not at all.  

Good.


>> The RRG Design Goals only mention IPv4 once and do not mention IPv6
>> in the body of the text.  There is no IPv6 scaling problem and won't
>> be one for many years - until the adoption level rises well beyond
>> the current state, which would take a decade or more at current
>> growth rates.   I assumed we were trying to solve the IPv4 routing
>> scaling problem, with an eye to doing something similar for IPv6 -
>> although perhaps not with the same urgency.
> 
> Bad assumption.  We have the same problem in v6 that we do in v4 since the
> architecture is identical.  Solving v4 without solving v6 is just a bandaid.
> Hopefully, we can do better.  IMHO, it would be sufficient to fix just the
> v6 side of things, but again, that's personal opinion.

I wasn't suggesting we only try to solve the IPv4 routing scaling
problem, or that the solution should only work for IPv4.  However, I
think the urgency of implementing the solution in IPv6 is less - so
we could probably afford to wait and learn from the IPv4 experience.

IPv6 mapping data is more voluminous, since the ETR address is 4
times as long as in IPv4, and if the micronet (EID) is specified
with 128 bit precision ("for the mapping function, we have consensus
that we should support host specific identifiers") then this is 4
times longer too.  These factors of 4 are significant, but are
unlikely to make any particular scheme completely impractical in
IPv6 if it is a good solution for IPv4.


>> Do we have consensus that it is acceptable for our solution to
>> require host changes to all hosts which participate in
>> communications which involve the new techniques?   For instance if a
>> host-based solution doesn't provide scaling benefits when
>> communicating with a non-upgraded host.
> 
> No, we don't have consensus on that.  We don't have consensus that host
> changes are prohibited either.

OK.

>> Do we have consensus that if the host-based solution by its very
>> nature makes it impossible for the network administrator to control
>> multihoming, portability etc. via central routers, that such an
>> approach provides suitable benefits to the routing system and to
>> those who must adopt it that is likely to be widely enough adopted
>> to make sufficient difference to the routing scaling problem?
> 
> Nope, we don't have consensus on that either.

That's not surprising since it was a badly written sentence.  It is
really a critique of any solution which requires host changes.


  - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg