[EMAIL PROTECTED] wrote: > > >This is especially important if the implementation should keep track of > >flow labels across reboots. I see no good way of doing this except > >writing the labels in some kind persistent storage. And consider > >operating system crashes etc. where this may not be possible. The only > >sane way seems to be to use random flow labels (or at least randomize the > >point where to begin using flow labels after a reboot); there are no > >problems if one does not have too high expectations of the lifetime of the > >uniqueness. > > i completely agree with this statement. can't always reliably keep > flow label value into persistent store, so something like "start from > random number on reboot, and monotonically increase value" makes > more sense.
I don't see that. Transaction processing systems and databases have this requirement too, and in "normal" crashes they have no problem, because a transaction ID is always saved in stable storage before it's used. (I agree that if you do have to restart the allocation process for some reason, a pseudo-random seed is good.) But in any case, IMHO we have no business specifying any of this in a basic protocol spec. As John said, it depends on the application scenario. I can well imagine a case where an application might want to use the same flow label for a consecutive flow; there's nothing in the spec to forbid that, I hope. Brian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
