Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 21 Dec 2001 15:50:35 +0100

>    => It would be good if yu could point out 
  >    a link perhaps to help me understand the reasons. 
  > 
  > => there are tons of mails in the archive of this list about that.

=> OK thanks.

  > 
  >      >    If we want to make it 
  >      >    more sophisticated then we can add another number 
  >      >    to the hash input (e.g P1 || P2 || x).
  >      >    Where x can be something specific to this flow.
  >      > 
  >      > => so why not just x (:-)...
  >    
  >    => Well because not all applications have that
  >    luxury of knowing an 'x' beforehand. 
  >    Also you would have to define for each application
  >    what 'x' means. Or define some behaviour in the
  >    IPv6 stack based on some shared secret, which again
  >    is not always available.
  >    
  > => I still don't understand what is the difference between
  > x and hash(P1 || P2 || x) where x can be something specific
  > to this flow.

=> Well it doesn't have to be flow specific. If you're
trying to avoid exposing the encryption key, you 
can use x, where x is any number that both nodes are
aware of. If ESP is not being used, you simply use 
P1 || P2 || x (x = 0) , unless you get a duplication 
(1 in a thousand probability, that is if the two nodes 
have a thousand connections between them). 
Anyhow, if you get a duplicate flow id then you can 
increment x by 1. This is a brief explanation obviously. 

  > PS: I can read between the lines that an end-to-end usage of
  > the flow label is proposed. 

=> It wasn't meant to be between the lines :) 

IMHO this is only a waste of bits,
  > the flow label is in the header in order to be available to
  > intermediate nodes. For end-to-end options, a destination header
  > fits better.

=> But doesn't that waste even more bits ?

Cheers,
Hesham

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Dec 2001 18:41:08 +0100

> x and hash(P1 || P2 || x) where x can be something specific
   
   => Well it doesn't have to be flow specific.

=> you wrote "x can be something specific"...

   If you're trying to avoid exposing the encryption key, you 
   can use x, where x is any number that both nodes are
   aware of.

=> I don't understand why the peer has to be aware of x.
Do you want to provide QoS inside end nodes? IMHO this is
not a bad idea because the CPU is far faster than I/O subsystems,
i.e. this is the wrong place.
BTW most implementations don't provide an API to get the received
flow ID or label, just because this is not considered as useful.

Regards

[email-masked]