Subject: RE: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt]

From: "Tony Li" <[email-masked]>
Date: Thu, 18 Dec 2003 10:52:43 -0800

Brian,

I thought that the point of this document was things to think about,
not a set of decision criteria.  If it is a set of criteria, then aren't
we duplicating the requirements draft?  No, I don't want to reopen that,
but what I *AM* suggesting is that Eliot's list is literally a list
of discussion questions.  As such, I think that this is a fine question
to ask.

If you're elevating this draft as anything other than a set of 
discussion questions, then we need to have a different discussion.

Which is it?

Tony

|  -----Original Message-----
|  From: Brian E Carpenter [mailto:[email-masked]] 
|  Sent: Thursday, December 18, 2003 12:54 AM
|  To: Multi6
|  Subject: Re: [Fwd: I-D 
|  ACTION:draft-lear-multi6-things-to-think-about-00.txt]
|  
|  
|  Pekka Savola wrote:
|  > 
|  > On Tue, 16 Dec 2003, Tony Li wrote:
|  > > I'd submit that if it cannot be easily ported back to 
|  IPv4, that it
|  > > bears closer examination.  v4 and v6 are architecturally very
|  > > similar.  Any solution that does not apply to both is either a
|  > > kludge or is exploiting an odd property of one of the two.  In
|  > > either case, it would bear close examination.  You know, the kind
|  > > that you give things when the fire alarm in the building 
|  goes off...
|  > > ?  ;-)
|  > 
|  > I have to heartily disagree here.  IPv6 address *does* 
|  have more bits.
|  > Different problem spaces have leveraged that property 
|  before as well,
|  > leading to solutions which are not easily backportable to IPv4.
|  > 
|  > Maybe one could reword this differently: the solution beas some
|  > thinking about if it doesn't rely on the 128bit address length of
|  > IPv6, and is not easily IPv4-capable.
|  
|  Yes. But this is the IPv6 multihoming WG, so while applicability to
|  IPv4 is an interesting question to ask, it cannot be a decision
|  criterion.
|  
|  I would counter-argue against Tony in another way. If we had variable
|  length addresses (as some people strongly suggested for IPng) a whole
|  new class of multihoming solutions might be available. But we don't,
|  so they aren't. Thus, you cannot argue that solutions *must* 
|  be independent 
|  of address length considerations.
|  
|  (Please don't kick off a thread on variable length addresses... at
|  least not here.)
|  
|    Brian
|  
|

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Dec 2003 12:12:27 -0800

Let's leave the legaleze out of this, but (hopefully) the document 
contains some questions that can be used to evaluate such minor issues 
as deployability, security, performance, and generality.  The methods 
used might cause some conflict between these objectives.  That's okay. 
We can decide which ones are important when we understand which 
tradeoffs are being made.

Eliot
ps: I'm leaving the "for instances..." out for brevity's sake.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 18 Dec 2003 22:35:13 +0100

On 18-dec-03, at 21:12, Eliot Lear wrote:

> (hopefully) the document contains some questions that can be used to 
> evaluate such minor issues as deployability, security, performance, 
> and generality.

:-)

I found another one: TCP and UDP checksum calculation offloading. It 
seems this is pretty common these days: I have a box with a turn of the 
century NIC and FreeBSD tells me it is offloading both rx and tx 
checksums. (It works too: dire tcpdump warnings when running verbose 
enough as outgoing packets have invalid checksums as seen by BPF.)

With any multihoming solution that allows rewriting of addresses 
between the moment the checksum calculation is done and the moment the 
packet is transmitted/received, checksum offloading will pretty much 
have to be a thing of the past, unless we want to start doing some 
complex incremental updating in different places.

So which is preferable? Keep it simple but lose hardware support for 
checksumming, or keep hardware support but add more complexity?

Note that the processing for the TCP/UDP checksum is simple enough that 
it's probably free when doing a memcopy anyway.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Dec 2003 11:38:28 +0100

Yep. I don't think Kurtis and I have any problem with listing IPv4 applicability
as something to think about. We just don't want it to accidentally become
a firm decision criterion.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Dec 2003 11:36:48 +0100

Iljitsch,

From the product people I talk to, if we break offload (including the
more sophisticated forms of offload such as RDDP) the solution won't be
going anywhere. I think that is related to the point we discussed a
couple of weeks ago about virtualized end points - a model that only
works with a traditional software stack in a traditional single host
simply doesn't work in today's world of virtualized server farms
with load balancers and offload devices.

   Brian