In my view, we didn't restrict it to be "non-mutable", but that is in
the boundaries set by:
" (c) A flow label is assigned to a flow by the flow's source node.
It
can be changed en-route, with the condition that its original
significance be maintained, or restored, when necessary. "
at page 15, in the draft. "(c)" protects the value of the flow label, or
rather, its meaning, where it is relevant to protect it.
That is because, the value in itself, alone, is not meaningful. It is
the meaning of the value, which is important, and as long as that
meaning is preserved, the value can change.
Regards,
Alex
Brian E Carpenter wrote:
>
> Hmm... it seems to me that both the formats we are suggesting (pseudo-random
> and diffserv PHB ID) are immutable.
>
> Brian
>
> Alex Conta wrote:
> >
> > Jim,
> >
> > Please reexamine.
> >
> > As a hint, note that MPLS, which is using *mutable* labels, is using
> > RSVP-TE (extension of RSVP
> > for Traffic Engineering) as one of the label distribution mechanisms.
> >
> > Alex
> >
> > Jim Bound wrote:
> > >
> > > Yes I would as a note. I want what we orginally called for and to make
> > > sure nothing breaks RSVPv6 which uses the flowlabel too.
> > >
> > > /jim
> > >
> > > On Fri, 17 Aug 2001, Tim Chown wrote:
> > >
> > > > On Fri, 17 Aug 2001, Francis Dupont wrote:
> > > >
> > > > > In your previous mail you wrote:
> > > > >
> > > > > I think the WG needs to decide once and for all whether the flow label is
> > > > > a) a CATNIP or MPLS-like routing handle
> > > > > or b) a QOS hint for intserv only
> > > > > or c) a QOS hint for intserv and diffserv
> > > > > or d) a waste of bits
> > > > >
> > > > > => I vote for b)
> > > >
> > > > So would you vote to mandate that the field is non-mutable in transit too?
> > > >
> > > > tim
S/MIME Cryptographic Signature
