Jarno, this is recursing the DSCP model up to the (proposed)
flow label. I don't think it's necessary. On this point I
am in agreement with Tony.
Brian
[EMAIL PROTECTED] wrote:
>
> Steve Blake wrote:
> > 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.
>
> Has this changed? Would there be hope for non-locally-mappable DSCP
> deployment NOW? I've understood the standardized values already exist (the
> PHB definition recommended DSCP values).
>
> > 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".
>
> I can see this to be useful, IF DSCP cannot be made non-mappable, and the
> proposed flow label usage would be mutable.
>
> > The only additional
> > in-band information that would be remotely useful for Diffserv would
> > be a credit card account number.
>
> Assuming that the flow label usage would be immutable. The first operator
> that doesn't see the transitive out-of-band credit card should re-mark the
> flow label to '00000'.
>
> Jarno
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
