Subject: RE: [NSIS] IPv6 Flow Label

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 11 Jul 2002 00:04:21 +0100

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.

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 11 Jul 2002 13:14:03 +0200

--On Donnerstag, 11. Juli 2002 00:04 +0100 "Hancock, Robert" 
<[email-masked]> wrote:

> 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.)
>

I would assume it on purpose, because it does not make sense to include a 
second dimension into the forwarding decision. The primary adress is still 
the destination address.

> 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?
>

I think this is heavily application dependent. And I would not give too 
much weight on the 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.

What do you mean by flow label state. The spec says that flow state 
adressing must be via flow label AND source and dest address. I think a 
tear message must include flow labels into account.

> 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.

I don't think we need to care about this. It says
   "Therefore the source SHOULD honor the destination's request to
   mark the packets with the Flow Label value specified."
So the source should honor this, not the signaling.

> 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.)

Yes, this one puzzled me as well.

Marcus

> =========================================================================
> =============== Permission is hereby granted to pass the contents of this
> communication to third parties and any restrictions regarding
> confidentiality do not apply.

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Sarantis Paskalis <[email-masked]>
Date: Thu, 11 Jul 2002 14:58:44 +0300

Hi,

> 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 t…

The only thing relevant mentioned in the draft is a sentence in Section 2

                                                The flow state defines
   what kind of treatment should be provided, and how to classify the
   packets to the flow.

According to that definition, NSIS could define the state of the flows to
always follow the same path.  The second part of the sentence also applies
to point 2.

> 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…

I think, this is partially covered in Section 5, rule 1.  
   
       Depending on the method semantics, multiple such triplets MAY
       identify the same flow state (e.g. SCTP flows with multiple
       addresses at either end-points, or a diffserv classifier with an
       address range.

This can be extended to cover the case for a "flowmask" in which the first
say 15 bits identify the flow state, while the last 5 identify the
"microflow".

In that case the draft states that:

                          The flow state establishment method MUST
        convey this classifying information to the IPv6 nodes that need
        to perform the classification.

i.e. this should be a NSIS requirement.

Cheers,

Sarantis