Subject: [Fwd: RE: [NSIS] IPv6 Flow Label]

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Jul 2002 12:08:16 +0200

Forwarded with permission...

-------- Original Message --------
Subject: RE: [NSIS] IPv6 Flow Label
Date: Thu, 11 Jul 2002 11:34:13 +0300
From: [email-masked]
To: <[email-masked]>, <[email-masked]>, <[email-masked]>,<[email-masked]>
CC: <[email-masked]>, <[email-masked]>

Hi,

Here are some comments on the flow label draft.

John

> -----Original Message-----
> From: ext Hancock, Robert [mailto:[email-masked]]
> Sent: 11 July, 2002 02:04
> To: Loughney John (NRC/Helsinki); [email-masked]
> 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-masked] [mailto:[email-masked]]
> > Sent: 10 July 2002 13:43
> > To: [email-masked]
> > 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-masked]
--------------------------------------------------------------------