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

From: Tim Chown <[email-masked]>
Date: Tue, 1 Aug 2017 07:33:38 +0000

> On 31 Jul 2017, at 21:25, Brian E Carpenter <[email-masked]> wrote:
> 
> On 01/08/2017 05:00, Fred Baker wrote:
>> 
>>> On Jul 31, 2017, at 6:34 AM, [email-masked] wrote:
>>> 
>>> DSCP 000001 might be an option. No other IETF recommended DSCP is re-marked to this one. It is to some extent RFC4594 compatible and RFC8100 could cope with it if default transport is applied. 
>> 
>> https://tools.ietf.org/html/rfc2474#section-6 indicates that 000001 is experimental/local use, available for standards allocation only as necessary. 
> 
> "We RECOMMEND that the DSCP value(s) of the
> unsupported service class be changed to 000xx1 on ingress and
> changed back to original value(s) on egress..."
> 
> That is a local use within a domain, completely compatible with both
> pools 2 and 3 which are both defined as for local use. So 000001
> is really not suitable for standards track recommendation, until
> pool 1 is full.
> 
>> Pool 1 is 32 code points, of which I believe 20 are in use (figure 3 of RFC 4594). I'd rather not dip into pool 3 unnecessarily. Is there another option?
> 
> 000010 is just fine. Why are we still discussing this?

The concern expressed in Prague was that a number of assigned code points may get bleached to 2. And that such bleaching is common enough that it would never be eradicated.

See slide 4 of https://datatracker.ietf.org/meeting/99/materials/slides-99-tsvwg-sessb-31measurements-concerning-the-dscp-for-a-le-phb

Not saying I agree with that, but that’s why we are still discussing it.

Tim

---

From: <[email-masked]>
Date: Tue, 1 Aug 2017 08:22:17 +0000

Gorry, 

Some new comments at the end.

Ruediger
RG>  DSCP 000001 might be an option. No other IETF recommended DSCP 
is re-marked to this one. It is to some extent RFC4594 compatible and 
RFC8100 could cope with it if default transport is applied.

Fred
FB> https://tools.ietf.org/html/rfc2474#section-6 indicates that 000001 
is experimental/local use, available for standards allocation only as necessary.
4597> "We RECOMMEND that the DSCP value(s) of the unsupported service class 
4597> be changed to 000xx1 on ingress and changed back to original value(s) 
4597> on egress..."

Brian
BC > That is a local use within a domain, completely compatible with both 
BC > pools 2 and 3 which are both defined as for local use. So 000001 is 
BC > really not suitable for standards track recommendation, until pool 1 
BC > is full.
....
BC> 000010 is just fine. Why are we still discussing this?

Gorry
GF>....there is reasonable doubt that a LE service can be safely deployed
across the Internet using a codepoint of 000010.

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?

GF>....A packet that uses AF marking and encounters ToS Precedence bleaching 
would expereince AF11, AF21, AF31, AF41 emerging remarked to a codepoint 
of 000010, and AF12, AF22, AF32, AF42, VA would emerge as 000100, etc.

GF> Because the LE PHB is a lower effort PHB, implementing a PHB with a codepoint 
of 000010 would result in some traffic originally marked as AFx1 being assigned a 
lower effort than AFx1 or AFx2. 

[RG2] That's a reasonable analysis. A network sending various DSCP into my domain 
without informing my NOC or setting up an SLA is not conservative with what it sends 
in my eyes. If receiving networks are expected to be supportive rather than liberal only 
in that case and are expected to maintain the original Diffserv coding sense of a 
non-cooperative sender, as described by Gorry, I think DSCP 000001 for LE is a good 
choice. That allows to maintain bit-mask based re-marking while maintaining the original 
Diffserv intent of non-cooperative networks, so I ignored the pools. 

Regards, Ruediger

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 1 Aug 2017 10:52:36 +0200

Hi,

Am 01.08.2017 um 10:22 schrieb [email-masked]:> GF> There
seems evidence that there are still even now deployed routers
> 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

---

From: <[email-masked]>
Date: Tue, 1 Aug 2017 09:49:11 +0000

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:[email-masked]] 
Gesendet: Dienstag, 1. August 2017 10:53
An: Geib, Rüdiger <[email-masked]>; [email-masked]
Cc: [email-masked]
Betreff: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB?

Hi,

Am 01.08.2017 um 10:22 schrieb [email-masked]:> GF> There seems evidence that there are still even now deployed routers
> [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?

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 01 Aug 2017 11:46:19 +0100

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, [email-masked] wrote:
> An: Geib, Rüdiger<[email-masked]>; [email-masked]
> Cc: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Aug 2017 08:28:07 +1200

>    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.

> 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.

Regards
    Brian

> .

---

From: <[email-masked]>
Date: Wed, 2 Aug 2017 06:56:58 +0000

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:[email-masked]] 
Gesendet: Dienstag, 1. August 2017 12:46
An: Geib, Rüdiger <[email-masked]>
Cc: [email-masked]; [email-masked]
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

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 2 Aug 2017 09:40:39 +0200

Hi,

comments inline.

> 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.

> that rewards the makers of broken products.

+1

Regards,
 Roland

---

From: <[email-masked]>
Date: Wed, 2 Aug 2017 08:48:14 +0000

Hi Roland,

in an MPLS domain, one generally may assign a bunch of DSCP to a 
single Treatment Aggregate / PHB. That I think is quite useful. 
Unfortunately the top label is removed before the last MPLS 
domain router is reached. Then an unknown and not re-marked 
DSCP is not acceptable. Hence your guidance below isn't applicable in 
all networks.

There is a fairly simple and useful option allowing to combine Treatment 
Aggregates, Diffserv forwarding across an MPLS domain and 
maintenance of multiple DSCP. Per Treatment Aggregate:
- classify DSCPs by bit-mask at ingress.
- re-mark DSCPs by bit mask at ingress.
- Diffserv forwarding by Treatment Aggregate
- classify and forward by individual DSCP at the egress (if desired)
- same holds for next domain

The other simple option I see without bit mask based re-mark is, 
again per Treatment Aggregate:
- classify DSCPs by bit-mask at ingress.
- re-mark to _a single DSCP_ at ingress.
- Diffserv forwarding by Treatment Aggregate 
- classify and forward by this single DSCP at the egress
- same holds for next domain

I prefer a simple solution (and a standardized one, if possible). 

Of course it is technically possible to set up and maintain per DSCP to 
PHB and individual DSCP re-mark tables, customized for each 
interconnection. Interconnection DSCPs are not standardized.
Many carriers operate multiple interconnections. 

Regards, 

Ruediger

>> 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.
> 

+1

Regards,
 Roland

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 02 Aug 2017 13:11:41 +0100

Thanks Brian, see below

> 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.)
> 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.
> 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.
>      Brian
Best wishes,
Gorry

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 2 Aug 2017 14:31:28 +0200

Hi Rüdiger,

> DSCP is not acceptable. Hence your guidance below isn't applicable in 

Thanks for pointing out MPLS/DiffServ interworking problems.
I'm more a DiffServ purist so I wasn't aware of such operational
problems. In summary, the whole DiffServ deployment seems to be getting
more complex by integrating MPLS constraints. I'm also not aware how
common an AF deployment is, since you quoted (in your last mail) that
bit-masking AF classes can be quite useful. So if I understood your
statements correctly, it is not possible to carry a DSCP x in an
MPLS aggregate and then use the same DSCP x at the egress to the
next domain?

> I prefer a simple solution (and a standardized one, if possible). 

Speaking as DiffServ purist, DSCP classification _by bit-mask_ is
non-conforming to RFC 2474.

> Many carriers operate multiple interconnections. 

The DiffServ architecture indeed requires to have agreements
for each interconnection. However, in case you don't have negotiated
any special treatment, a mapping of "any DSCP -> default PHB" should
work. But if I understood you correctly, an incoming DSCP x may not
be acceptable for the next DS domain, so you must remark?

Regards,
 Roland

---

From: <[email-masked]>
Date: Wed, 2 Aug 2017 14:48:18 +0000

Hi Roland,

the problem with unknown DSCPs arises on the _domain internal
ingress interface_ of the MPLS egress edge router, and traffic 
leaving the domain is concerned.

It's sufficient if a vendor allows classification based on DSCP ranges. 
I can configure a behaviour like a bit mask (as these are specific 
DSCP ranges). Could be DSCP bits 0-1, bits 0-2 that way.

Commonly used MPLS Short Pipe's Pen-ultimate Hop Popping (PHP) adds the 
complexity here. I doubt it will be removed or adapted due to Diffserv issues.

I'm trying to be pragmatic and figure out how to meet a maximum of 
constraints while finding a simple solution. In the end, an administrative 
obstacle like a pool discussion might be simpler to pass than running into 
conflicts with deployed solutions. I can't claim to know 
all solutions which see deployment within Deutsche Telekom's entire 
network. If anybody knows that for a bigger company, please speak up.

Regards, Ruediger

-----Ursprüngliche Nachricht-----
Von: Bless, Roland (TM) [mailto:[email-masked]] 
Gesendet: Mittwoch, 2. August 2017 14:31
An: Geib, Rüdiger <[email-masked]>
Cc: [email-masked]
Betreff: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB?

Hi Rüdiger,

Am 02.08.2017 um 10:48 schrieb [email-masked]:
> Unfortunately the top label is removed before the last MPLS domain 
> router is reached. Then an unknown and not re-marked DSCP is not 
> acceptable. Hence your guidance below isn't applicable in all 
> networks.

Thanks for pointing out MPLS/DiffServ interworking problems.
I'm more a DiffServ purist so I wasn't aware of such operational problems. In summary, the whole DiffServ deployment seems to be getting more complex by integrating MPLS constraints. I'm also not aware how common an AF deployment is, since you quoted (in your last mail) that bit-masking AF classes can be quite useful. So if I understood your statements correctly, it is not possible to carry a DSCP x in an MPLS aggregate and then use the same DSCP x at the egress to the next domain?

> There is a fairly simple and useful option allowing to combine 
> Treatment Aggregates, Diffserv forwarding across an MPLS domain and 
> The other simple option I see without bit mask based re-mark is, again 
> per Treatment Aggregate:

Speaking as DiffServ purist, DSCP classification _by bit-mask_ is non-conforming to RFC 2474.

> Of course it is technically possible to set up and maintain per DSCP 
> to PHB and individual DSCP re-mark tables, customized for each 

The DiffServ architecture indeed requires to have agreements for each interconnection. However, in case you don't have negotiated any special treatment, a mapping of "any DSCP -> default PHB" should work. But if I understood you correctly, an incoming DSCP x may not be acceptable for the next DS domain, so you must remark?

Regards,
 Roland

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Aug 2017 11:19:34 +1200

One small remark near the end:

> internally for local use.

True, but the original hope was that people would prefer pool 2 for
local use, since there is an explicit statement in RFC2474 that
pool 3 may be released for standardisation. So pool 3 is the best
choice if we go outside pool 1.

In any case, a domain that is actively using the local-use space
presumably understands the rules about re-marking at the domain
boundary. The real problem we have is with domains that don't
perform correct re-marking and/or use lazy solutions for mapping
to the 3 bits available in MPLS.

  Brian

---

From: <[email-masked]>
Date: Wed, 9 Aug 2017 10:31:44 +0000

Gorry, all,

let me sum up what I think we've discussed. I think there was some support, but no consensus for b) . c) only saw me speaking up for it explicitely, but it might be a pragmatic way out (I can't judge how much effort the IETF pool discussion will take, however). The trouble is caused by bit mask based DSCP re-marking. I don't expect bit-mask based DSCP classification and re-marking to disappear, as it allows for transport of multiple (re-marked) DSCP by a simple configuration.

There's consensus that a DSCP 000 xyz is a good choice for a LE PHB, I think. 

In general, any configuration should be simple, hence I expect a Diffserv domain:
- to classify and re-mark DSCPs based on bit-masks (a commodity at least in some routers).
- to classify DSCPs by a bit-mask and re-mark to a single DSCP (I'd like to understand whether that is desirable).
- I didn't check whether there's a feature like "re-mark AFx to AFy" (I can't recall to have heard of that).

Related to an LE PHB, a sending domain might be sending any standard/non- standard DSCP across an interconnection without an SLA. This traffic may experience (bit-mask based) DSCP re-marking by the receiving domain. Should that happen:

a) if all unknown DSCPs are re-marked to default DSCP, that's not an issue.

b) the receiver might re-mark based on bit-masks. Then
  Any AFv DSCP might continue as 000xy0 after a bit-mask based re-mark. If z = 0 for the LE DSCP, in 
  the case of congestion, this may cause a flow to be re-ordered. Depending on the choice of LE DSCP, 
  the drop rate of a re-marked AFv1 or AFv2 may be higher than that of AFv2 or AFv3.

c) if the LE DSCP is 000xy1, bit-mask based re-marking is less harmful. The proposed DSCP is from a 
     reserved pool and this needs to settled within IETF. 

Regards,

Ruediger