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

[<[e-mail]>]

Gorry,

What are the options? 

In general, I dislike a policy of sending DSCP marked packets across an interconnection without an SLA and expecting the receiver to ensure reasonable Diffserv treatment.  

Let's assume that the receiving network tries to be friendly. I further assume bit-mask based re-marking at the receiver side:

a) without touching the DSCP pools

 - RFC2597 recommends to use AFn1 and AFn2, if only two drop 
   levels are applied. LE could then use 000110. If any joker sends 
   EF 101110 across an interconnection without an SLA and without 
    caring about re-marking the packets at the sending router, it 
    is re-marked to LE. My personal take: fair enough in that 
    case. However any AFn3 traffic will be treated like that. The 
    packets my see higher drops than AFn1 and AFn2 and a real 
   AFn flow may be re-ordered. So far I'm not aware of deployments 
    making real use of AFn1-3 as designed.

- LE could use 000010. Then it might hit AFn1 and then AFn1 may 
   see higher drops and the AFn flow may be re-ordered.

- We stick with CS1. This will be re-marked to Default in the above 
  case. To me: worst choice of all.

b) using a pool 3 DSCP

If DSCP 000001 is used for LE, there's no issue with re-marked AF or EF. We however have an issue within IETF.

Regards, 

Ruediger


-----Ursprüngliche Nachricht-----
Von: Gorry Fairhurst [mailto:[e-mail]] 
Gesendet: Dienstag, 1. August 2017 12:46
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]; [e-mail]
Betreff: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB?

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
>