Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB?

["Bless, Roland (TM)" <[e-mail]>]

Hi,

comments inline.

Am 01.08.2017 um 22:28 schrieb Brian E Carpenter:
> On 01/08/2017 20:52, Bless, Roland (TM) wrote:
>> Hi,
>>
>> Am 01.08.2017 um 10:22 schrieb [e-mail]:> GF> There
>> seems evidence that there are still even now deployed routers
>>> that have not adjusted their remarking behaviour after the IETF 
>>> deprecated ToS Precedence bleaching. 
>>>
>>> [RG2] True. I prefer a core-router to be able to re-mark DSCPs by bit-mask at  
>>> interconnection interfaces rather than DSCP by DSCP. The config effort to customize 
>>> re-marking on a DSCP by DSCP basis is high. An easy to configure alternative is to classify 
>>> by bit-mask and re-mark to a single DSCP. Gorry, do you have any preference here?
>>
>> Hmm, RFC2474 states that the DSCP is unstructured:
>>   "The DSCP field is defined as an
>>    unstructured field to facilitate the definition of future per-hop
>>    behaviors.
>>
>>    With some exceptions noted below, the mapping of codepoints to PHBs
>>    MUST be configurable.  A DS-compliant node MUST support the logical
>>    equivalent of a configurable mapping table from codepoints to PHBs"
> 
> This is the fundamental point (and it is entirely the result of ISP
> people who were active in the diffserv WG that we have this rule, by the
> way). If an operator doesn't support this, anything can happen.
> 
> DSCPs are not end-to-end. DSCP to behaviour mappings are not end-to-end.
> If you ignore this, things *will* go wrong. Trying to arrange things so
> that some arbitrary bit-masking of DCSP values will produce predictable
> results *will* fail in some cases. I think it's futile.
> 
> Fundamentally I don't care which arbitrary bit pattern is recommended
> for LE, as long as it doesn't clash with a CS code point. But if
> you encroach on pool 3 I think that requires a formal update to RFC2474
> or at least some very careful wording of the IANA considerations.

I'm not sure that the experienced behavior is actually better if we use
a DSCP from pool 3, since it may already be used in some domain
internally for local use.

>> IMHO it shouldn't be difficult to have a mapping table
>> from each DSCP to a PHB. The mapping table should
>> initially only contain mappings to the default PHB
>> (no need to remark anything then).
>> Configuring DSCP remarking by using bitmasks is IMHO
>> not RFC2474 compliant and a broken concept causing
>> the trouble we just ran into.
> 
> And you shouldn't fix broken products by fiddling with a standard;
> that rewards the makers of broken products.

+1

Regards,
 Roland