Tony,
Why would any subsequent provider give a S on what the origin intended?
Without mutual charging arrangement that is. For that we have the Integrated
Services model already.
There is difference in "muting" to only locally understood value and to
globally standardized values.
All this discussion is based on an assumption that a diffserv domain egress
cannot map from a local (yes, it's own) DSCP->PHB mapping to a standard
recommended DSCP value for the same (or equivalent) PHB. If this mapping CAN
be done, that is what NEEDS to be done, and we can forget this whole
discussion. This far Brian has maintained that this cannot be forced on The
Operators.
Jarno
Tony Hain wrote:
>
> Jarno Rajahalme wrote:
>
> > 9. this form is MUTABLE:
> >
> > If the intention is to enable contractual aggregation needed
> > by e.g. the
> > diffserv model, domain must be able to remark the value
> > (change it), but
> > also the new value needs to be taken from the set of
> > standardized values, so
> > that the semantics of the value is always unambiguous. The
> > mutability allows
> > cutting off "freeloaders" (as put so eloquently by Steve
> > Blake), and enables
> > the diffserv aggregation model.
>
> I am sorry, but this is BS. The diffserv model already
> has a mutable field giving the provider ultimate control
> and doesn't need a second one. In fact allowing this
> proposed use to be mutable will ensure that subsiquent
> providers have no clue what the origin intended. If the
> provider wants to cut people off, it can set the TC to 0,
> or drop the packet. Allowing providers to modify these
> bits adds no value to the existing diffserv capabilities.
>
> Tony
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
