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.
> 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.
> 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.
> 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.
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.
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.
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]
> --------------------------------------------------------------------
S/MIME Cryptographic Signature
