Subject: RE: [NSIS] IPv6 Flow Label

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 11 Jul 2002 15:30:45 +0100

hi marcus,

see inline:

> -----Original Message-----
> From: Marcus Brunner [mailto:[email-masked]]
> Sent: 11 July 2002 12:14
> To: Hancock, Robert; [email-masked]; [email-masked]
> Subject: RE: [NSIS] IPv6 Flow Label
> 
> 
> 
> 
> --On Donnerstag, 11. Juli 2002 00:04 +0100 "Hancock, Robert" 
> <[email-masked]> wrote:
> 
> > 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.)
> >
> 
> 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.
[reh] so are you saying that it _is_ reasonable for a router to load share packets from the same flow (i.e. same DA and flowlabel) on two links?

> 
> > 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.
[reh] maybe it should be MAY then.

> 
> > 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.
[reh] ok, for the tear message i think it is clear. the problem comes when the tear won't work. example:
1. i set up a pinhole in a firewall associated with a flowlabel
2. rerouting changes which firewall is used, pinhole is set up in new firewall
3. i remove the new pinhole with a tear message
4. the old firewall still has a pinhole in it. when do i know it is safe to reuse that flowlabel?

> 
> 
> > 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.
[reh] my concern is not with that statement, but with the paragraph at the end of section 4, which places a requirement on signalling (e.g. NSIS) to carry the flow label to the peer. if this is just a notification it's probably not a problem, but if it's a request that sounds like flow label negotiation which I think is not an NSIS problem. (Or, it may be that I have over-interpreted this section.)

[snip]
> 
> 
> --------------------------------------
> 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
> 
> 
========================================================================================
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 16:44:39 +0200

> [reh] so are you saying that it _is_ reasonable for a router to load
> share packets from the same flow (i.e. same DA and flowlabel) on two
> links?

I would assume it depends on the load shareing mechanisms implemented. But 
in the routing decision you definitly don't want to take into account a 
flowlabel.

[...]

> [reh] ok, for the tear message i think it is clear. the problem comes
> when the tear won't work. example: 1. i set up a pinhole in a firewall
> associated with a flowlabel
> 2. rerouting changes which firewall is used, pinhole is set up in new
> firewall 3. i remove the new pinhole with a tear message

You know it after some time (time a state is still operational).

> [reh] my concern is not with that statement, but with the paragraph at
> the end of section 4, which places a requirement on signalling (e.g.
> NSIS) to carry the flow label to the peer. if this is just a notification
> it's probably not a problem, but if it's a request that sounds like flow
> label negotiation which I think is not an NSIS problem. (Or, it may be
> that I have over-interpreted this section.)

Oh, I understood this such that NSIS must carry the flow label in signaling 
message, but not that NSIS is used for negotiation of the label. I think 
this is an issue of high layer lignaing such as SIP.

Marcus

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