[EMAIL PROTECTED] wrote:
>
> Now that I read the draft-conta-ipv6-flow-label-02.txt again in the context
> of this discussion, few remarks:
>
> - The draft discusses "diffserv MF-classifier" use for the flow label, while
> what really is proposed is a diffserv behavior aggregate (BA) classification
> based on standard, non-mappable PHB identifiers. Since DSCP is mappable to a
> local convention (for whatever political reasons), now the flow label is
> proposed to replace the DSCP field on the domain boundaries.
Exactly, since it can convey e2e semantics from the source.
>
> - RFC 3140 defines PHB-ID as 16 bits, out of which 6 bits are used in the
> "standards action" defined PHBs. These 6 bits are the recommended bits for
> the DSCP field by the PHB definition (that can be mapped locally to
> different set of bits). If there is no local mapping (but the domain routers
> are configured to understand and use the recommended DSCP values for each
> supported PHB), the 6 bits in the PHB-ID are the same as the 6 bits in the
> DSCP in the Traffic Class field. The other variant (*experimental* and
> *local use*, e.g. intra-domain) use more of the 16 bits.
Correct. The idea was that people could register PHB IDs with IANA to
go beyond the formally standardised ones.
>
> - Since the PHB-ID carries only 6 bits of information between diffserv
No, the DSCP is limited to 6 bits; the PHB-ID has a full 16 bits.
The mapping to DSCP is a decision made by the classifier in an ingress
border router.
> domains, it would seem entirely reasonable, that at diffserv domain egress,
> all DSCPs are mapped to the equivalent recommended DSCP values, that will
> then be understood by the receiving diffserv domain.
It might be reasonable, but we can't assume it. This depends entirely
on the SLA between the two ISPs concerned and is a business decision.
> The egress could base
> the mapping to whatever MF-classification or just map from locally used
> DSCPs.
>
> So, as an alternative to make the IPv6 flow label NOT identify flows, I'd
> propose the diffserv WG to specify that (for IPv6) a diffserv domain MUST
> remark the DSCP value of the Traffic Class field at egress to use the
> PHB-definition recommended ("standards action") DSCP value, including the
> case that *local use* or *experimental* PHBs are mapped to the default PHB
> ('000000') at domain egress.
Impossible. This is not something the IETF can mandate, and in particular ISPs
are free to implement non-standard PHBs (e.g. multiple independent implementations
of EF, or more than four AF classes, or some proprietary PHB).
>
> In addition to more efficient classification and policing on the domain
> ingress, this could have a side effect of encouraging the operators to
> actually use the recommended DSCP values intra-domain as well :-)
This is not in our power.
>
> The only argument against this I have seen to date is that "operators
> wanted" the DSCP bits to be locally mappable (and perhaps so that reverse
> mapping back to the standard values may be hard?). Has there been any
> discussion with these operators on the possibility that instead of agreeing
> with their peers about the DSCP values to be used *at the domain boundaries*
> (could still use locally mapped values intra-domain), they would base their
> mutual SLAs on an end-to-end field set by the IP host originating the
> traffic? IHO this is way different from the MF-classification discussed in
> the diffserv specs (since the proposal in the draft is actually about a
> behavior aggregate classification).
This is not a discussion one can have with ISPs. What they do in their
bilateral agreements is a private, confidential matter.
Brian
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
