Forwarded with permission... -------- Original Message -------- Subject: RE: [NSIS] IPv6 Flow Label Date: Thu, 11 Jul 2002 11:34:13 +0300 From: [EMAIL PROTECTED] To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> CC: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Hi, Here are some comments on the flow label draft. John > -----Original Message----- > From: ext Hancock, Robert [mailto:[EMAIL PROTECTED]] > Sent: 11 July, 2002 02:04 > To: Loughney John (NRC/Helsinki); [EMAIL PROTECTED] > Subject: RE: [NSIS] IPv6 Flow Label > > > John, > > Interesting draft. I have tried to think it through from a > purely NSIS perspective. > > 1) Nowhere does it say if routers (or even sources) should > send packets from the same flow along the same path. Is that > because it's (a) the wrong place to say so or (b) obvious or > (c) impossible to mandate? In particular, it does say that a > node not carrying out flow specific treatment MUST ignore the > field on forwarding - maybe 'keeping packets together' could > be regarded as flow specific treatment (and made mandatory). > (If we could rely on this it would be a powerful weapon in > the signalling/data path divergence issue, but see next point.) > > 2) The draft seems to encourage (SHOULD) a highly granular > assignment of flow labels (e.g. section 4 rules 3 & 4). On > the other hand, there may be good reasons to use the same > label for a sequence of 'microflows' (e.g. successive files > in a bulk ftp transfer; the same point has been made on the > v6 list). Encouraging this granularity directly increases the > signalling burden. How strong is SHOULD? > > 3) Fortunately, I think most of the agonies about flow label > re-use don't have to worry us, they're end-system internal. > However, there are two points: > a) Do we need to strengthen our requirement for a TEAR > message to flush flow label state? > b) If a TEAR isn't possible (e.g. a route flap means some > routers wouldn't see it), do we need to allow the end system > to control the soft state timeout so they can be assured of > when flow label state has been purged? I don't think our > current requirements give this level of control to end hosts, > and I'm not sure they should. > > 4) I don't see why the flow state establishment method (i.e. > NSIS for example) needs to be able to manage flow label > agreement between end systems (end of section 4). After all, > it doesn't handle port number agreement. Such information > would need to be end-to-end secured, which (IMHO) is a poor > match to the security capabilities we are currently assuming for NSIS. > > 5) I'm seriously concerned about rule (6) of section 5. I > don't see it has anything to do with a standard on flow label > definition. If it does, then the rest of the draft has to be > clarified so whenever it refers to address it is clear if it > means home or care of address (e.g. on reception at the end > system, does a node check the combination of flow label with > HA or CoA to work out which flow something belongs to), and > the security considerations section might need something on > validating ownership of the home address as well. Better I > think would be to point out that something like the second > sentence of rule (6) applies in mobile environments, and that > flow state establishment methods should handle this how best > they can. (We have this requirement in NSIS anyway.) > > So, there might be some options for making the draft leaner > and meaner. > > Cheers, > > Robert > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: 10 July 2002 13:43 > > To: [EMAIL PROTECTED] > > Subject: [NSIS] IPv6 Flow Label > > > > > > Hi all, > > > > One tool we may want to use is the IPv6 flow label. There is some > > standardization of this on-going in the IPv6 WG. I wonder if folks > > could comment on the spec, with regards to how NSIS could use it. > > > > It can be found from: > > > > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-02.txt > > John > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
