Tony Hain wrote:
> At this point what we can't afford is redefining a field simply
> because the diffserv WG refused to create a set of end-to-end
> consistent bits. It is no surprise that people are finding it
> difficult to build hardware that will make consistent decisions
> when all the bits in the header are random. Since the diffserv
> mechanism is the one that needs a consistent set of bits for
> hardware acceleration, that WG should have provided them. Instead
> the DSCP is effectively a random set of bits with no global
> context, and we are being asked to redefine another set of bits
> to provide the necessary end-to-end consistency since the
> diffserv WG refuses to.
I agree with your conclusion, but I disagree with the assumptions you are
making about diffserv (for the sake of argument, say).
RFC2475 was built on the assumption of bilateral agreements between
peering providers, because that was the only model that had a hope
of being deployed. The Diffserv flow-label proposal is trying to
invent an end-to-end, in-band QoS "signaling" mechanism to operate in
parallel with the hop-by-hop DSCP "signaling". The only additional
in-band information that would be remotely useful for Diffserv would
be a credit card account number.
Regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake <[EMAIL PROTECTED]>
Ericsson IP Infrastructure 919-472-9913
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
