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

[Gorry Fairhurst <[e-mail]>]

Thanks Brian, see below

On 01/08/2017, 21:28, Brian E Carpenter wrote:
> 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.
I agree! (To me a key issue is whether standardising a codepoint for the 
LE service may result in a specific failure mode that requires our 
attention.)
> 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.
Thanks, this seems correct. It's not to be taken lightly, but the Chairs 
could explore this approach, working with IANA, if there is a 
justification to go ahead.
>> 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.
To this, I'd add that if we allocate from a different pool for LE - it 
will be because the need is different for a "less than default" treatment.
> Regards
>      Brian
Best wishes,
Gorry
>> Regards,
>>   Roland
>>
>> .
>>