Re: Flow label versus Extension header

[Erik Nordmark <erik.nordmark@sun.com>]

Pekka Savola wrote:
> On Mon, 25 Apr 2005, Erik Nordmark wrote:
>
> > This isn't the only option. With receiver-based tag allocation, then 
> > the receiver can choose which locators it advertises for which 
> > contexts. For instance, a receiver can have multiple locators in each 
> > prefix and keep them separate. So {P1:X, P2:Y} can use tag=1 and be 
> > associated with one context, and {P1:Z, P2:W} can use tag=1 and be 
> > associated with a different context. Of course, if the host doesn't do 
> > this, then it can assign the tags to that it never needs to look at 
> > the locators in order to lookup the context.
>
>
> I'm a bit confused -- we're still talking about flow label and extension 
> header/destination option both, right?

I was (apparently not clearly) restricting my comments about 
receiver-based allocation to the case when we don't overload the flow 
label as a context tag, but instead carry a tag explicitly somewhere 
else in the packet (e.g., in a new extension header or destination option)

> How would one perform receiver-based tag allocation with flow labels, 
> because the flow label is allocated when the sender sends out a first 
> packet and cannot be changed since?

One wouldn't.
Unless we are told that it is ok to have the transmitting shim start 
using a different flow label once the shim state has been set up with 
the peer.  But my assumption is that this would cause too much pain for 
other usage of the flow label.

   Erik