Brian E Carpenter wrote:
> [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 standardized 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.
>
My precise point was that *between domains* PHB-ID carries 6 bits of
information only (the standardized DSCP values). Any *local use* values
would not be used inter-domain, and any *experimental* value usage would
need bilateral agreements (perhaps as part of the SLAs), so for this info
(mapping from an *experimental* PHB-ID to the actual behavior definition) an
out-of-band signaling method (online or offline) exists already.
> > 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.
>
Hopefully the SLAs specify what treatment should be given to which packets.
It is not up to IETF to standardize redundant technologies just because a
"business decision says so".
In my opinion, you have not yet shown a convincing scenario, where the
proposed behavior aggregate usage of the IPv6 flow label field actually
provides something we don't already have. You should provide a concrete
example showing the relationships between the operators, who marks what
(end-to-end/hop-by-hop), how the traffic is policed etc.
> > 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.
Let's add to the end. "If a bilateral SLA doesn't state otherwise."
>
> 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).
The whole discussion has been for the case *between operators*, or have I
missed something. With my amendment above, the above can easily be mandated
by IETF. The main motivation for any standardization is interoperability.
IMO what I said above would just facilitate interoperability (in case the
operators don't know better).
> >
> > 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.
"encouraging" doesn't need too much power, just good will :-)
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]
--------------------------------------------------------------------
