Re: [tsvwg] Opsdir last call review of draft-ietf-tsvwg-dscp-considerations-13

Gorry Fairhurst <> Tue, 16 May 2023 15:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F4179C15154D for <>; Tue, 16 May 2023 08:34:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QARxandeqKgK for <>; Tue, 16 May 2023 08:34:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CD1C5C15155E for <>; Tue, 16 May 2023 08:34:05 -0700 (PDT)
Received: from [IPV6:2001:630:42:110:c91b:2d5:ad88:f619] (unknown [IPv6:2001:630:42:110:c91b:2d5:ad88:f619]) by (Postfix) with ESMTPSA id 48D181B00171; Tue, 16 May 2023 16:34:02 +0100 (BST)
Message-ID: <>
Date: Tue, 16 May 2023 16:34:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.1
Content-Language: en-US
References: <>
From: Gorry Fairhurst <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [tsvwg] Opsdir last call review of draft-ietf-tsvwg-dscp-considerations-13
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 May 2023 15:34:10 -0000

On 16/05/2023 16:24, Qin Wu wrote:
> Gorry:
> Sorry for late review, since this review assigned to me has been 
> forgotten in my review list without any notification or reminder, 
> which is strange.
> Thanks for clarification and suggested changes. I am happy to see this 
> draft can be improved with my additional comments. See reply inline below.
> *发件人:*Gorry Fairhurst []
> *发送时间:*2023年5月16日22:41
> *收件人:*Qin Wu <>;
> *抄送:*;
> *主题:*Re: [tsvwg] Opsdir last call review of 
> draft-ietf-tsvwg-dscp-considerations-13
> Thanks for your review. This email is an OPS DIR review that was 
> received after IESG and the document is now with RFC-Ed.
> I have added further responses marked “GF:” below in this email.
>     Reviewer: Qin Wu
>     Review result: Has Issues
>     I have reviewed this document as part of the Ops area
>     directorate's ongoing
>     effort to review all IETF documents being processed by the IESG. 
>     These
>     comments were written primarily for the benefit of the Ops area
>     directors.Document editors and WG chairs should treat these
>     comments just like
>     any other last-call comments.
>     Thanks for writing this draft, this is a very interesting
>     document. This
>     document extends DSCP usage from the limited domain to end to end
>     manner. One
>     of interesting use case is to map 3GPP QCI/5QI to DSCP and support
>     consistent
>     end to end QoS.
>     Here are a few comments I made for this latest version.
>     1.Section 1
>     My general question is support end to end QoS across multiple
>     domains, why RSVP
>     or Interserv is not sufficient? How does we use diffserv to
>     provide consistent
>     QoS requirements?
> GF: The story of inter-domain RSVP is indeed interesting, but is not 
> one that I’d like to enter into for this particular draft. To give 
> more context on that, I wrote some text for section 5.2 of 
> which could be a starting place, but I think it is really a separate 
> topic.
> */[Qin Wu] Agree, will take a look at the relevant work you are 
> pointing to./*
>     2.Section 3.1 DSCP Pool 3 description said:
>     “Pool 3 codepoints are now "utilized for standards assignments and
>     are no
>     longer available for assignment to experimental or local use"
>     [RFC8436]. “
>     Really, this seems not what RFC8436 said, RFC8436 add one
>     constraint which is
>     only when Pool 1 is ever exhausted, do we intend to update RFC8436
>     to further
>     relax constraint? If that is the case, how do we provide back
>     compatibility to
>     RFC what RFC8436 stipulated?
> GF: You will note in the abstract of RFC 8436 that it says “This 
> update to RFC 2474 changes the IANA registration policy for Pool 3 of 
> the registry (i.e., DSCP values of the form xxxx01) to Standards 
> Action, i.e., values are assigned through a Standards Track or Best 
> Current Practice RFC.  The update also removes permission for 
> experimental and local use of the codepoints that form Pool 3 of the 
> DSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form 
> xxxx11) remain available for these purposes.”
> - I expect this answers your question about the status of IANA Pool 2, 
> and describes the update relative to [RFC2474].
> */[Qin Wu] Thanks for clarification, you address my comment./*
>     3.Section 3.1 said:
>     “ Table showing the summary of the DSCP abbreviations used in
>     published
>        RFCs.“
>     Just want to confirm what table shows is DSCP abbreviations or PHB
>     abbreviation?
> GF:  I suggest the ID is about DSCPs and it makes most sense to speak 
> of these code points, but would take a better formulation of words if 
> one was offered. The abbreviations (with the exception of VA for 
> Voice-Admit) also appear as listed DSCPs in 
> */[Qin Wu] sounds good to me, thank for you explanation./*
>     4. Section 3.2 said:
>     ”The traffic consists of the network control service class and the
>     OAM service
>     class. “ Is there any possibility DSCP CS2 used for OAM service
>     class is
>     overridden by some other data traffic? If that is the case, how do
>     you detect
>     some conflict? What is the impact on other data traffic? How such
>     conflict can
>     be resolved?
> GF: CS2 could indeed be remarked, because the DS architecture permits 
> all traffic to be remarked, but an operator using CS2 for OAM would 
> likely prevent unwanted ingress traffic from using that code point and 
> then configure it consistently within the DS domain. We don't think a 
> change is needed here.
> */[Qin Wu] sounds good to me./*
>     5. Section 4 said:
>     “The DiffServ field
>        can also be re-marked based on common semantics and agreements
>        between providers at an exchange point. ”
>     Common semantics and agreement usually is reached in the provider
>     to provider
>     interconnection domain or inter-domain or inter-provider use case?
> GF: Thanks, this would be normally at the edge of DS domain. We 
> suggest we update the text to say a "diffserv domain boundary", which 
> would actually be much clearer.
> */[Qin Wu] Agree, would like to see this change to be implemented./*
>     6. Section 4 said:
>     “If packets are received that are
>        marked with an unknown or an unexpected DSCP by a DiffServ domain
>        interior node, [RFC2474] recommends forwarding the packet using a
>        default (best effort) treatment, but without changing the DSCP”
>     Isn’t DSCP value unique and has ,consistent meaning in each
>     domain? I want to
>     see the text be specific about the reasons why DSCP is unknown or
>     unexpected?
>     E.g., some border router doesn’t support new DSCP value? Some of
>     DSCP bits are
>     set to zero? I see the big challenges when DSCP is remarked in
>     each domain and
>     match different local policy, in that sense, it seems hard to provide
>     consistent end to end QoS? No?
> GF: I think an operator will likely deploy a PHB and set a policy for 
> managing traffic that carries the associated DSCP. The IETF defines 
> standards-track PHBs and an associated DSCP via the IANA registry. A 
> particular deployment may, or may not, support all PHBs. There is a 
> chance that traffic arrives with a DSCP that is not known to the 
> network - perhaps a new PHB, or perhaps as a result of some remarking, 
> so if this traffic is not associated with a PHB, the DSCP is 
> “unknown”. An unexpected value could also arise from misconfiguration, 
> or because there is no consistent policy in place. This follows RFC 2474.
> GF: Is some new text needed to explain this?
> */[Qin Wu] Good clarification, if there are some new text to explain 
> this, that will be great, especially when you say/*
> */“/*
> so if this traffic is not associated with a PHB, the DSCP is 
> “unknown”. An unexpected value could also arise from misconfiguration*//*
> */”/*
> */Which make me more clear./*
>     7. Section 5.1.1 said:
>     “This aligned with the now deprecated use of CS1 as the codepoint
>     for the lower
>     effort service, as previously specified in [RFC4594]. ” This
>     alignment is
>     referred to PCP1 or PCP0? My impression is PCP1, no?
> GF: Yes, you are correct in asking this question. We did mean PCP1. 
> RFC 3662 originally proposed use of CS1 for the LE PHB, whereas RFC 
> 8622 has later specified the LE DSCP for this purpose. We think the 
> extra sentence that explains the history for the PCP codepoint 
> assignments is perhaps confusing. We now propose to remove this 
> expalnatory sentence.
> */[Qin Wu] make sense. Thanks for proposed change./*
>     8.Section 5.1, table:
>     The table provided here is not completely consistent with figure 7
>     in RFC7222,
>     e.g., in figure 7 of RFC7222, PHB assigned to background is BE
>     while in this
>     draft, PHB assigned to background is CS0. Please make them
>     consistent ”
> GF:  This is a really good review comment. We will update CS0 to be BE 
> to match the spec (BE and CS0 have the same DSCP), and then  also add 
> a short footnote to explain how the word "background" is used in RFC7222.
> */[Qin Wu] Thanks for taking my comments into account, this document 
> is extremely useful to me./*
> Thanks again for the time you have spent preparing your review and 
> please let me know if further action is needed - since this is post 
> IESG, I’ll also ensure the required changes are confirmed by our AD.
> Gorry Fairhurst
Thanks again and OK.

We'll also then suggest a clarification on the meaning of "unknown DSCP".

Gorry & Ana