Alex,
> Jim,
>
> Jim Bound wrote:
> >
> > I think we should do b via an experimental draft. Go write some code and
> > see if it works in the test beds (e.g. 6bone, 6init, Eurosix, DoD). Then
> > report back. This will give us some experience.
> >
> > I think doing anything to promote routing based on transport+port is a bad
> > technical idea and strategy for IPv6.
>
> I am afraid, there is a misunderstanding. Nobody advocated
> transport+port to promote routing
> or as a strategy.
So advocating port numbers in the flowlabel is not the view of the current
thinking?
Thats good then. If I missed that I will have to go back and check.
>
>
> > IPv6 should put an end to that type
> > of route lookup and forwarding now.
> >
> > Also regarding the argument of not knowing the length of headers, Itojun
> > is correct we cannot put that in the flow label it will create bugs and is
> > not prudent.
>
> I am afraid again of a misunderstanding.
>
> As I do not expect everyone to understand or care about bit shifting, I
> should mention
> just for the sake of the record, that it was shown, that the details can
> be crafted to eliminate
> the risk mentioned by Itojun, regarding length.
I saw that mail. That is not the only bug. The other bug will be
assuming the extensions and when to update the length. Adding this to the
IPv6 processing would need to be reviewed very carefully at this point.
Because it can be bit shifted does not mean it will work.
>
> > We have long known that the forwarding path will have to
> > live with extensibile headers. It is a done deal and we should move
> > forward.
>
> We have also known from day one, that the flow label is an aid to
> forwarding, and to QoS, and that
> we still have to work on it.
>
Of course.
> > Let the best engineers win who are are the smartest to create
> > algorithms that can adapt to IPv6 extensibility.
>
> No question, IPv6 extensibility which is the ability to define and stack
> options in the 'hop by hop' headers, or 'destination' headers, is a
> plus.
Also completely new prototcols.
> But we should minimize the price paid for it, that is the price for
> variable IPv6 headers of variable size. Cause variable size, during
> packet forwarding, is as bad, if not worse than variable size addresses,
> and we know where we (Steve, Bob, Jim, I, and many others) were on that
> many years ago.
I agree and that was for the address too. But if one follows the
extension chain all works correctly no matter what size or how many
extensions exist.
> Minimizing the price paid is even more necessary, when we examine the
> gain on extensibility, by counting the IPv6 options which were
> standardized. and compare, them to the IPv4 standard options.
IPv4 options don't work? I am missing the point?
But I think we should maybe define the reqs we are trying to achieve?
If we could all agree on that we may be able to move forward. But that
gets back to Brian's mail on choosing a-e.
I think waiting is not a good idea though.
We should figure this out now.
regards,
/jim
>
> Alex
>
> >
> > /jim
> >
> > On Fri, 17 Aug 2001, Bob Hinden wrote:
> >
> > > Brian,
> > >
> > > > > I don't think that we have enough experience to pick between a), b), or c)
> > > > > now, and think that something might come up in the future where 28 bits in
> > > > > the IPv6 header might be very useful. This might not have anything to do
> > > > > with QOS.
> > > >
> > > >I think you mean 20 bits. The traffic class octet is fully standardised by
> > > >diffserv and ECN.
> > >
> > > Yes, my error. I was not suggesting we change the traffic class field.
> > >
> > > >The problem with this is that the text we have today effectively selects
> > > >option b), since it endorses the pseudo-random value. If we do nothing,
> > > >we have effectively chosen the intserv-only usage. That's why I started
> > > >this thread.
> > >
> > > I agree. It was good to ask the question.
> > >
> > > The point I was trying to make is that while we have now many QOS
> > > standards, we don't have very much deployment experience. As such it is
> > > hard to tell if it is worthwhile to use these 20 bits to optimize QOS
> > > performance.
> > >
> > > Bob
> > >
> > > --------------------------------------------------------------------
> > > 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]
> > --------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
