Re: Flow label versus Extension header - protocol itself

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Erik,

Erik Nordmark wrote:
> Greg Daley wrote:
>
> > > I don't think it makes sense switching from F1 to a different locator 
> > > for the "main" path as you parenthetically suggest, though.
> >
> >
> >
> > Fair enough.  The main value of retaining the flow label F1 though,
> > is for applications which are interested in flow identification.
>
>
> By "applications" do you mean something running on the host?
>
> My assumption is that the shim on the receiver would not only restore 
> the IPv6 address fields to be the ULIDs, but also restore the flow label 
> to F1. Thus ULPs on the host would see a constant flow label.

Yes, I was thinking that some APIs may allow explicit access to flow
labels (perhaps as RFC3542bis), or a separate extension of to the
advanced sockets API (new socket options?)

The constant flow label would be required in this case, as it could
have particular semantics with the ULP or application.

> > The main thing I guess is that it doesn't break any existing flows while
> > the flow remains on the original path.
>
>
> Yep.
> And when switching to a different locator pair, and some flow signaling 
> is used, one would need to do the flow signaling for that locator pair 
> in any case. So using a different flow label for the different locator 
> pair shouldn't be much of an issue.

I guess you'd only want to do the signalling when you had to:

You wouldn't want to require signalling (or a new label)
for every locator pair change, if the label was receiver unique.

Greg