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

[Qin Wu <[e-mail]>]

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