[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Moving forward...

There are at least two dimensions in which the differences between v4 and v6 may make a difference to what sorts of solutions are effective / deployable / definable / ... 1) The fact that the IPv6 header has lots of bits means that there are solutions that do not involve encapsulation or information loss which can be considered with v6 that do not apply to v4. 2) The fact that v6 is still, in practice, in very early stages means that there is more willingness to change the system to make it worth having. And that folks are more willing to look at changes.
This does not mean that I want to ignore IPv4. But it does mean that I think the differences may have an impact on the architectural approach we recommend. And I would hate to see us declare that we will not consider any approach which can not leverage those differences. 

Yours,
Joel

Lixia Zhang wrote:


On Jun 18, 2008, at 4:08 PM, Vince Fuller wrote:

Date: Wed, 18 Jun 2008 16:05:03 -0700
From: Vince Fuller <vaf@cisco.com>
To: Tony Li <tony.li@tony.li>
Cc: 'rrg' <rrg@psgcom>
Subject: Re: [RRG] Moving forward...


Last week we did a consensus check on the following:

|Our recommendation should be applicable to IPv6.  It may or
|may not also apply to IPv4, but at the very least must provide
|a path forward for IPv6.
It's my judgement that we have rough consensus on this. There is dissent, 
notably from Robin and Bill, but overall, it seems that we have rough
consensus.
FWIW, put me into the more-rough, non-consensus camp that thinks providing a 
solution for IPv4 is a requirement.

Speaking for myself only.

    --Vince


You are not in the non-consensus camp :-)
I had some private exchange with Tony on this issue, but let me put it in public to help the consensus gathering: I agree that the solution must work for IPv6, but at the same time, 
- IPv4/v6 share the same architecture; the only major fundamental
  difference is their address space size.
- my notion of the RRG task is to develop an architectural
  solution to routing scalability.
- We should step up a level from looking specific versions of
  IP at this stage of solution development.  Our solution has to be
  an architectural change, and should work for either version.

Lixia

--
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



--
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