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. 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. 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. Let the best engineers win who are are the smartest to create
algorithms that can adapt to IPv6 extensibility.
/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]
--------------------------------------------------------------------
