Re: [tsvwg] I-D Action: draft-polk-tsvwg-new-dscp-assignments-02.txt

[Brian E Carpenter <[e-mail]>]

Hi,

I don't really understand why this draft, and draft-polk-tsvwg-rfc4594-update,
are so profligate with DSCP values.

DSCP values are only bound to specific PHBs locally, with
some recommended bindings as shown in the IANA registry.
But if we have two similar-but-different PHBs, such that a given
diffserv domain will only use one of them, it is perfectly fine
to re-use a DSCP value.

For example, is CS5-Admit (as defined in draft-polk-tsvwg-rfc4594-update)
ever going to be used in the same domain as CS5 (RFC2474)?

If not, there is no need to allocate a new recommended code-point.

There might be a need to allocate a PHB ID for signaling or SLAs, but
that is not a precious resource (RFC3140).

>    The key part of the above quote is 
> 
>       "... which should be preferentially utilized for standardized 
>        assignments if Pool 1 is ever exhausted..."
> 
>    which we here take to mean 'SHOULD NOT use unless you have a really 
>    good reason to use'. 

I don't see what's hard to interpret about "if Pool 1 is ever exhausted".
As far as I can tell, it isn't, so Pool 3 isn't yet available.

>    One reason for assigning out of Pool 3 is to get similar 
>    marking from layer 2 technologies that only have 3 bits to use for 
>    their value, not 6 bits.

That doesn't convince me. Clearly you have to map at the boundary of
one of those techologies, but a 6 bit to 3 bit map is not a big deal,
and you can't reasonably expect to get away with just masking off
3 bits in the general case.

Incidentally, I don't think that -rfc4594-update yet does all that is
called for by Section 5 of RFC3086 in defining the new PHBs.

   Brian