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

[Gorry Fairhurst <[e-mail]>]

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 [mailto:[e-mail]]
> *发送时间:*2023年5月16日22:41
> *收件人:*Qin Wu <[e-mail]>; [e-mail]
> *抄送:*[e-mail]; [e-mail]
> *主题:*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 
> https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/13/, 
> 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 
> https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml.
>
> */[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