I agree with Erik. If I were given time to discuss the hybrid I could do
both the technical quick resultant from such a choice but define why I think
it solves the problem that the others do not.
/jim
> -----Original Message-----
> From: ext Erik Nordmark [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday,March 14,2001 6:10 AM
> To: Steve Deering
> Cc: [EMAIL PROTECTED]; Bob Hinden
> Subject: Re: Flow Label discussion
>
>
>
> > At the moment, we have one scheduled presentation on Flow
> Label issues,
> > by Winston Seah (draft-shen-ipv6-flow-trans-00.txt), and we
> would like
> > to offer the opportunity for others who were arguing for alternative
> > semantics for the Flow Label field to summarize their proposals. If
> > I recall correctly, the debate came to down to basically three
> > different choices for Flow Label semantics:
> >
> > (1) a non-mutable value that, when concatenated with the source
> > address, can be used by routers to identify flows. (This was
> > the original design, described in pre-RFC2460 versions of
> > the IPv6 spec.)
> >
> > (2) a mutable value that can be or will be modified hop-by-hop,
> > like an ATM virtual circuit identifier or an MPLS label.
> >
> > (3) a hybrid of (1) and (2) in which, say, one bit of the Flow
> > Label field indicates whether or not the rest of the field
> > is mutable.
>
> I understand that the above 3 are the currently understood
> alternatives
> for what the flow label semantics could be.
>
> I think that I could construct arguments for either one of them
> being the best; it all depends on what problem I think the 20
> bits could be
> used to solve. So while it might be useful to get arguments
> for and against the
> various semantics on the table, there is a risk that this
> isn't productive is
> folks have very different views of what problem they can
> solve using the flow
> label field.
>
> Thus before the WG can actually make any decisions about flow label
> semantics I think we need to have folks write up the different
> problem statements for which they see the flow label as a
> potential solution.
> Then the WG can decide which problem(s) are the most
> important to solve
> and whether or not using the flow label is the best solution.
> That would
> then hopefully lead to nailing down the semantics of the flow label.
>
> So having the discussion you propose is fine, but please keep
> the problem
> statements in mind.
>
> Erik
>
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
