>   | I don't think that should be allowed.
  > 
  > Huh?   What shouldn't be allowed?   Not having multiple default
  > routers?   That is, you're saying everyone must have more than one?
  > That would be rather ambitious.

=> Indeed, but that's not what I was saying :)
or at least not what I meant. I was arguing
against letting the default routers set the 
flow label and I was saying that 'it' (setting 
the flow label by default routers) should not 
be allowed, or at least not unless somehow
it's restored before the packet is delivered to
the receiver, as per draft-rajahame....

  > I agree as well.
  > 
  > But, if I have only one default router, and I have a lot of 
  > applications
  > that know nothing about setting flow labels (which pretty 
  > much describes all
  > the IPv6 code that exists at the minute that Im aware of), 
  > are you telling
  > me that I am to be prohibited from having the router do 
  > classification and
  > set the flow label to some intelligent choice ?

=> Well the assumption here of course is that 
applications know nothing about the flow label, 
which is fair, considering that it has not been
defined yet. However, once it is defined, I can't 
see why we can't add it to the API and allow it
to be set by the applications. 
Alternatively another part of the stack may
also choose to set it. 


  > 
  > Note: no-one is proposing (that I am aware of) mandating 
  > that it work
  > this way - the issue is more of whether we should be prohibiting it.
  > Personally, I like to prohibit as little as possible, unless there's
  > a very good reason - and that someone (or some group) can't 
  > figure out
  > how they'd sanely use it, isn't good enough.

=> So I guess you're arguing for allowing the 
case where routers can modify the flow label
from zero to X. But should we then force them
to set it back to Zero again ? 
I'm just wondering if there will be any confusion
if the receiver gets a flow label set to X when
the sending node didn't intend to set/use the 
flow label at all.

Hesham
  > 
  > kre
  > 
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------

Reply via email to