Subject: [tsvwg] I-D Action: draft-blake-explu-dscp-rec-00.txt

From: Steven Blake <[email-masked]>
Date: Sun, 26 Apr 2020 00:56:23 -0400

Hi,

I just submitted a short I-D with recommendations for how network
operators should forward packets with EXP/LU DSCP values, namely to
forward them without DSCP bleaching (if they are not otherwise using
that specific DSCP value) and to forward them using the Default PHB.

Feedback welcome.

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Recommendations for Forwarding Packets Marked
                          with EXP/LU DSCPs in Diffserv Networks
        Author          : Steven Blake
        Filename        : draft-blake-explu-dscp-rec-00.txt
        Pages           : 6
        Date            : 2020-04-25

Abstract:
   Some network operators implementing Diffserv are purported to remark
   some IP packets with non-zero DSCP values to the default DSCP value
   '000000' at their ingress network boundaries.  This behavior is often
   not strictly necessary to protect an operator's network resources,
   and it impedes end-to-end experimentation of new differentiated
   services.  This document recommends that Diffserv network operators
   refrain from remarking packets received with an EXP/LU DSCP value
   [RFC2474][RFC8436] that is not in use within the operator's network,
   and recommends that operators forward these packets at each Diffserv
   node (DS-node) using the Default "best-effort" PHB.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-blake-explu-dscp-rec/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-blake-explu-dscp-rec-00
https://datatracker.ietf.org/doc/html/draft-blake-explu-dscp-rec-00

  
Thanks!

// Steve

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Apr 2020 08:37:36 +1200

Hi Steve,

+1, but three points:

1. I note that RFC2474 section 3 says this:

   Packets received with an unrecognized codepoint SHOULD be forwarded
   as if they were marked for the Default behavior (see Sec. 4), and
   their codepoints should not be changed.  Such packets MUST NOT cause
   the network node to malfunction.

I do wonder why the "should not" is lower case, but essentially what you propose has been the recommended behaviour since December 1998.

2. Related to that, why limit it to EXP/LU code points? If an operator doesn't happen to support EF, then it should simply transmit EF packets like any others.

So anyway... since this is a 21 year old recommendation, it seems to me that we need an operational (BCP) document saying politely: do what RFC2474 says, already!

3. There is a problem, however. Look at the second paragraph at https://tools.ietf.org/html/rfc8100#section-1 and you will see what I mean. You need to zap that text in your draft.

Regards
   Brian Carpenter

---

From: Steven Blake <[email-masked]>
Date: Sun, 26 Apr 2020 17:13:05 -0400

> Hi Steve,

Hi Brian,

> I do wonder why the "should not" is lower case, but essentially what
> you propose has been the recommended behaviour since December 1998.

I know the jerk who edited that section. No idea why that wasn't
bolded.

> 2. Related to that, why limit it to EXP/LU code points? If an
> operator doesn't happen to support EF, then it should simply transmit
> EF packets like any others.

I can agree with that. IMHO it should be the responsibility of the
receiving operator to bleach DSCPs as strictly necessary to protect
services in absence of or in violation of a TCS with its upstreams.

> So anyway... since this is a 21 year old recommendation, it seems to
> me that we need an operational (BCP) document saying politely: do
> what RFC2474 says, already!

Agreed. If there is consensus, I am happy to expand the draft to say as
such.

> 3. There is a problem, however. Look at the second paragraph at 
> https://tools.ietf.org/html/rfc8100#section-1 and you will see what I
> mean. You need to zap that text in your draft.

I also know the jerk who edited that referenced "guidance" in RFC 2475.
No idea of what he was thinking there either.

Regards,

// Steve

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Apr 2020 09:59:48 +1200

> I know the jerk who edited that section. No idea why that wasn't

Oh, that was careless checking by the idiot who was WG co-chair, I think.

   Brian

---

From: "Black, David" <[email-masked]>
Date: Sun, 26 Apr 2020 22:10:14 +0000

And to complete the picture ...

> > No idea of what he was thinking there either.

... I know the fool who wrote that paragraph in RFC 8100.  It's a small world :-).

Thanks, --David (as an individual)

> -----Original Message-----
> From: tsvwg <[email-masked]> On Behalf Of Brian E Carpenter
> Sent: Sunday, April 26, 2020 6:00 PM
> To: Steven Blake; [email-masked]
> Subject: Re: [tsvwg] I-D Action: draft-blake-explu-dscp-rec-00.txt
> 
> 
> [EXTERNAL EMAIL]
>

---

From: <[email-masked]>
Date: Mon, 27 Apr 2020 10:10:47 +0000

Hi Steven,

Brian already mentioned that this behavior is foreseen by existing standards. 

A network provider bleaching might
- operate DiffServ
- operate an architecture recommending this behavior
- be restricted by default behavior and configuration options of hardware deployed
- have no incentive to add complexity to hardware configuration and operation if that doesn't add value

Some of the above is in standards, others is from operational practice. I only speak for the operational environment, I'm in.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg <[email-masked]> Im Auftrag von Steven Blake
Gesendet: Sonntag, 26. April 2020 06:56
An: [email-masked]
Betreff: [tsvwg] I-D Action: draft-blake-explu-dscp-rec-00.txt

Hi,

I just submitted a short I-D with recommendations for how network operators should forward packets with EXP/LU DSCP values, namely to forward them without DSCP bleaching (if they are not otherwise using that specific DSCP value) and to forward them using the Default PHB.

Feedback welcome.

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Abstract:

  
  
Thanks!

// Steve