Subject: [NSIS] IPv6 Flow Label

From: [email-masked]
Date: Wed, 10 Jul 2002 15:43:18 +0300

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

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 11 Jul 2002 16:29:34 +0100

hi marcus:

inline (just 2 left). 

> -----Original Message-----
> From: Marcus Brunner [mailto:[email-masked]]
> Sent: 11 July 2002 15:45
> To: Hancock, Robert; [email-masked]; [email-masked]
> Subject: RE: [NSIS] IPv6 Flow Label
> 
> 
> 
> >> > 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?
> 
> 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] not routing but forwarding. see for example rfc3272 section 4.2.4. in the language of that rfc, should flowlabelled packets be allowed to be round-robin distributed, or distributed on any fields other than the flowlabel (and addresses)?

> 
> [...]
> 
> >>
> >> > 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?
> 
> You know it after some time (time a state is still operational).
> 

[reh] and does the end system need to be able to (a) know (or know an upper bound), or even (b) control this time? that's my concern. it could be hard.

> 
> Marcus
>  --------------------------------------
> 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: "Hancock, Robert" <[email-masked]>
Date: Tue, 23 Jul 2002 16:29:29 +0100

Hi Sarantis,

one brief point, else I think we have converged:

> > [reh] i think doing this at the triplet level where there 
> is diverse routing (remember, they may all have different 
> destination addresses) will be a huge source of complexity. 
> is it really worth it? otherwise we are just talking about 
> flow grouping as already in NSIS.
> 
> How can flow labels denoting the same flow have different destination
> addresses?  I thought we were talking about same source and 
> destination
> addresses, but different flow labels for the same flow.  In 
> case of different
> destination address, we have different flows by definition.
> 
[reh] well, maybe again I am over-reading the draft, but I was going from the phrase "SCTP flows with multiple addresses at either end-points" (in the same rule (1) from section 5). this refers to SCTP's ability to have one logical flow between two multihomed (therefore multi-addressed) endpoints - at the transport layer, SCTP thinks it's one flow, the question is whether we are supposed to know this at the network layer. My view is not.

Cheers,

Robert