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

[Gorry Fairhurst <[e-mail]>]

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.

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

    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.

    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.

    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.

    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?

    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.

    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.

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