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

[Gorry Fairhurst <[e-mail]>]

Hi,

So, as I see it this advice applies when devices are configured in a 
consistent fashion - and could be useful to note for the draft. We'd 
like the MPLS core to behave "well", and I'd hope that people 
configuring MPLS will understand how AF is to be treated.

My thread was about what happens when you have to work over a path where 
the entire path has not been correctly configured. I'd much prefer to 
avoide surprises if DSCP-marked (or re-marked) traffic reaches an AP (or 
some other device) that has been updated to map the LE codepoint to a LE 
PHB. I'd hate to think we specify a scheme that can often result in 
impacting just a part of an AF Class, inverting the ordering of the 
treatments --, I don't feel good about introducing new opportnities for 
such priority inversion across the sets of AF codepoints, even if this 
may be a result of misconfiguration or legacy behaviours.

Gorry

On 01/08/2017, 10:49, [e-mail] wrote:
> Hi Roland,
>
> AF classes are structured sets of DSCP. Their definition starts with a bit-mask based on DSCP bits 0-2, resulting in AFnx notation. This notation also corresponds to CSn definitions, resulting in up to 4 standard DSCPs sharing the same bits 0-2.
>
> To configure re-marking of an AF class or of eight DSCPs I need _per DSCP_ :
>
> - a class definition
> - an assignment of a received DSCP to a class
> - a re-mark order of the class to my internal DSCP
>
> If a provider operates MPLS, the number of Treatment Aggregates/PHBs offered at interconnection is often 3 or 4. The options that I am aware of are:
> - a bit-mask based re-mark allows to transport and maintain up to 8 DSCP by a "3 line configuration"
> - a DSCP based re-mark combined with a bit-mask based classification allows to transport up to n
>     DSCP by a "3 line configuration" and they are all re-marked to a single DSCP.
> - a DSCP based re-mark aiming on maintaining different requires "n*3 lines of configuration" for n DSCP.
> - There's no binding standard on Diffserv class/codepoint assignment at interconnection. Setting up
>    a per carrier per DSCP to DSCP and class mapping scheme is requiring some effort (negotiation,
>    configuration, operation). I'm trying to avoid that.
>
> To me, two choices to make operational sense:
> - either bit-mask based DSCP re-mark with up to 8 DSCP per MPLS Treatment Aggregate
> - or DSCP based re-mark with a single DSCP per MPLS Treatment Aggregate.
>
> Regards,
>
> Ruediger
>
>
> -----Ursprüngliche Nachricht-----
> Von: Bless, Roland (TM) [mailto:[e-mail]]
> Gesendet: Dienstag, 1. August 2017 10:53
> An: Geib, Rüdiger<[e-mail]>; [e-mail]
> Cc: [e-mail]
> Betreff: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB?
>
> 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"
>
> 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.
>
> Regards,
>   Roland
>