Re: [tsvwg] NQB draft updates

[[e-mail]]

Hi Greg,

[RG] removing requirements terminology helps. I agree to removing the part of the sentence starting with , e.g.,… Further:


[RG] I still don’t get why a network operator willing to negotiate a DiffServ SLA/TCA with a peer/customer domain would need to be told that a DSCP is required per negotiated PHB by any draft other than RFC2475. If this sentence needs to be part of the draft, please reword:

OLD: To support NQB, networks will need to preserve a DSCP marking distinction between NQB traffic and Default traffic when forwarding via an interconnect from or to another network.

NEW: To support forwarding NQB traffic from or to a negotiated DiffServ interconnection, networks will need to preserve a DSCP marking distinction between NQB traffic and Default traffic.

-----------------
OLD: Similar to the handling of DSCPs for other PHBs (and as discussed in [RFC2475]), networks can re-mark NQB traffic to a DSCP other than 45 for internal usage, as long as the appropriate NQB DSCP is restored when forwarding to another network.

[RG] I’d prefer that to be two sentences, to clearly separate what’s discussed by RFC2475 and what’s not discussed by RFC 2475:
NEW: Similar to the handling of DSCPs for other PHBs (and as discussed in [RFC2475]), networks can re-mark NQB traffic to a DSCP other than 45 for internal usage. As mentioned earlier, the appropriate NQB DSCP should be restored when forwarding to another network.

----------------

[RG] Further please explain the difference in content of the following two statement chains:

  1.  If NQB support is extended across a DiffServ domain boundary, the interconnected networks agreeing to support NQB SHOULD use the value 45 for NQB at network interconnection, unless a different DSCP is explicitly documented in the TCA (Traffic Conditioning Agreement, see [RFC2475]) for that interconnection. Similar to the handling of DSCPs for other PHBs (and as discussed in [RFC2475]), networks can re-mark NQB traffic to a DSCP other than 45 for internal usage. As mentioned earlier, the appropriate NQB DSCP should be restored when forwarding to another network.
  2.  As discussed in [RFC2475], to ensure reliable end-to-end NQB PHB forwarding, a TCA determining a suitable DSCP at interconnection would need to be negotiated by any network that uses a DSCP other than DSCP 45 for NQB traffic.

[RG] I don’t understand which guidance is given by statement b), that hasn’t been given by text in a):

  *   Standard requirement SHOULD use DSCP 45 for intercon TCA
  *   Intercon TCA may specify a different DSCP
  *   Internally, a DSCP other than 45 may be used.
Please explain which info is added by b), which isn’t contained in a).


Regards,

Ruediger


Von: Greg White <[e-mail]>
Gesendet: Donnerstag, 8. September 2022 23:31
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]
Betreff: Re: [tsvwg] NQB draft updates

Thanks Ruediger.

Unless I’m misunderstanding, your point related to the requirement sentences that you suggest deleting is that these are not new requirements introduced by NQB, but are simply statements of fact, or restatements of concepts from RFC2475.

If I got that right, how would you feel about simply deleting the MUST/SHOULD/MAY language, and adding references to RFC2475? Something along the lines of:

To support NQB, networks will need to preserve a DSCP marking distinction between NQB traffic and Default traffic when forwarding via an interconnect from or to another network. If NQB support is extended across a DiffServ domain boundary, the interconnected networks agreeing to support NQB SHOULD use the value 45 for NQB at network interconnection, unless a different DSCP is explicitly documented in the TCA (Traffic Conditioning Agreement, see [RFC2475]) for that interconnection.  Similar to the handling of DSCPs for other PHBs (and as discussed in [RFC2475]), networks can re-mark NQB traffic to a DSCP other than 45 for internal usage, as long as the appropriate NQB DSCP is restored when forwarding to another network, e.g., networks that internally use DSCP 45 for a local use, and thus have to re-mark traffic marked by DSCP 45 to another DSCP within their domain. As discussed in [RFC2475], to ensure reliable end-to-end NQB PHB forwarding, a TCA determining a suitable DSCP at interconnection would need to be negotiated by any network that uses a DSCP other than DSCP 45 for NQB traffic.

I think I’d prefer to keep the information here rather than assume that the reader is an expert on RFC2475.
(That said, I’d be fine with deleting the “e.g., networks that internally use DSCP 45 for a local use, and thus have to re-mark traffic marked by DSCP 45 to another DSCP within their domain.”)

-Greg


From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, September 8, 2022 at 4:28 AM
To: Greg White <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: AW: [tsvwg] NQB draft updates

Greg,

I propose the following change of the text:

OLD:
To support NQB, networks MUST preserve a DSCP marking distinction between NQB traffic and Default traffic when forwarding via an interconnect from or to another network. Networks that support NQB SHOULD use the value 45 for NQB at network interconnects, unless a different DSCP is explicitly documented in the TCA (Traffic Conditioning Agreement, see [RFC2475]) for that interconnection.   Networks MAY re-mark NQB traffic to a DSCP other than 45 for internal usage, as long as the appropriate NQB DSCP is restored when forwarding to another network, e.g., networks that internally use DSCP 45 for a local use, and thus have to re-mark traffic marked by DSCP 45 to another DSCP within their domain. To ensure reliable end-to-end NQB PHB forwarding, a TCA determining a suitable DSCP at interconnection SHOULD be negotiated by any network that uses a DSCP other than DSCP 45 for NQB traffic.

NEW:
If NQB support is extended across a DiffServ domain boundary, the interconnected networks agreeing to support NQB SHOULD use the value 45 for NQB at network interconnection, unless a different DSCP is explicitly documented in the TCA (Traffic Conditioning Agreement, see [RFC2475]) for that interconnection.

RG: The text provides for the “SHOULD” desired by the authors in that case. I’d suggest to remove the other text due the reasons given below:

Statement: To support NQB, networks MUST preserve a DSCP marking distinction between NQB traffic and Default traffic when forwarding via an interconnect from or to another network.
RG: The statement is correct. Classification based on DSCPs and DSCP traffic marking are fundamental DiffServ properties. If there’s anything else which this sentence is supposed to express, please reword. If not, it should be deleted.

Statement: Networks MAY re-mark NQB traffic to a DSCP other than 45 for internal usage, as long as the appropriate NQB DSCP is restored when forwarding to another network, e.g., networks that internally use DSCP 45 for a local use, and thus have to re-mark traffic marked by DSCP 45 to another DSCP within their domain.
RG: That statement is correct, see https://datatracker.ietf.org/doc/html/rfc2475#section-2.3.4.2. Unless the draft statement is intended to update RFC 2475, I suggest to delete it.

Statement: To ensure reliable end-to-end NQB PHB forwarding, a TCA determining a suitable DSCP at interconnection SHOULD be negotiated by any network that uses a DSCP other than DSCP 45 for NQB traffic.
RG: That statement is correct, see https://datatracker.ietf.org/doc/html/rfc2475#section-2.3. Unless the draft statement is intended to update RFC 2475, I suggest to delete it.

Regards,

Ruediger


Von: tsvwg <[e-mail]<mailto:[e-mail]>> Im Auftrag von Greg White
Gesendet: Mittwoch, 7. September 2022 22:24
An: [e-mail]<mailto:[e-mail]>
Betreff: Re: [tsvwg] NQB draft updates

I received a suggestion for wordsmithing of the second paragraph in 4.3 (https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-11.html#section-4.3-2).

Here’s an html formatted version showing the changes (not sure how this renders in plaintext):
To support NQB, networks MUST preserve a DSCP marking distinction between NQB traffic and Default traffic when forwarding via an interconnect from or to another network. Networks that support NQB SHOULD use the value 45 for NQB at network interconnects, unless a different DSCP is explicitly documented in the TCA (Traffic Conditioning Agreement, see [RFC2475]) for that interconnection.   To be clear, interconnecting networks are not precluded from negotiating (via an SLA, TCA, or some other agreement) a different DSCP to use to signal NQB across an interconnect. Additionally, the fact that this PHB is intended for end-to-end usage does not preclude networks from mapping theNetworks MAY re-mark NQB traffic to a DSCP to a value other than 45 for internal usage, as long as the appropriate NQB DSCP is restored when forwarding to another network, e.g., . There may exist networks that internally use DSCP 45 for a local use, and thus have to re-mark  classify traffic marked by DSCP 45 to another PHB DSCP within their domain. When receiving traffic marked by DSCP 45 at an interconnection, such a domain should be expected to remark this traffic. To ensure reliable end-to-end NQB PHB forwarding, a TCA determining a suitable DSCP at interconnection should SHOULD be negotiated by any network that uses a DSCP other than DSCP 45 for NQB traffic.


In case that renders poorly, here is a plaintext version of the suggested text:
To support NQB, networks MUST preserve a DSCP marking distinction between NQB traffic and Default traffic when forwarding via an interconnect from or to another network. Networks that support NQB SHOULD use the value 45 for NQB at network interconnects, unless a different DSCP is explicitly documented in the TCA (Traffic Conditioning Agreement, see [RFC2475]) for that interconnection.   Networks MAY re-mark NQB traffic to a DSCP other than 45 for internal usage, as long as the appropriate NQB DSCP is restored when forwarding to another network, e.g., networks that internally use DSCP 45 for a local use, and thus have to re-mark traffic marked by DSCP 45 to another DSCP within their domain. To ensure reliable end-to-end NQB PHB forwarding, a TCA determining a suitable DSCP at interconnection SHOULD be negotiated by any network that uses a DSCP other than DSCP 45 for NQB traffic.

(also attached is an html diff)

Let me know if anyone has a concern with making this change.

-Greg





From: tsvwg <[e-mail]<mailto:[e-mail]>> on behalf of Greg White <[e-mail]<mailto:[e-mail]>>
Date: Monday, September 5, 2022 at 9:39 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [tsvwg] NQB draft updates

All,

I’ve posted an updated draft (-11) that addresses the 5 issues listed below. In addition, this update has a few editorial fixes.

For items 4&5 below, I ended up re-working section 4.3.1 a fair amount, using more general terms rather than assuming that the “unmanaged network” is in all cases a residential broadband home network containing legacy Wi-Fi gear.

I also did add a mention that some managed Wi-Fi gear can have the DSCP-to-UP mapping set via TR-369.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-11.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-nqb-11


-Greg


From: tsvwg <[e-mail]<mailto:[e-mail]>> on behalf of Greg White <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, August 30, 2022 at 5:06 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [tsvwg] NQB draft updates

All,


Here is a collection of points made either on the list, at the mic, or offline to me that I am planning to address in the current revision (I hope I’ve not missed any!):


1.      Regarding the use of the DSCPs 45 and 5, I believe where we’ve settled on this is to *only* reference the value 45 in the draft (and only request IANA registration of that value) and eliminate the requirements to re-mark traffic.  This was motivated by three factors, one being a reluctance to adopt an approach that would make transparent DSCP passthrough non-compliant with IETF RFCs, another other being concern about consuming two codepoints (from a limited set), and the third being general discomfort with the complexity and potential for operational issues that might result. So, I’ll remove the references to DSCP 5. I’ll change the language in https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-10.html#section-4.3 that currently says networks SHOULD NOT use 45 at network interconnects, to say networks SHOULD use 45, unless a different DSCP is explicitly documented in a TCA for that interconnection, and add: “There may exist networks that internally use DSCP 45 for a local use, and thus classify traffic marked by DSCP 45 to another PHB within their domain. When receiving traffic marked by DSCP 45 at an interconnection, such a domain should be expected to remark this traffic. To ensure reliable end-to-end NQB PHB forwarding, a Traffic Conditioning Agreement determining a suitable DSCP at interconnection should be negotiated.”

2.      Regarding prioritization of NQB traffic (and Existing WiFi Networks), add some text in the Primary [PHB] Requirements section (https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-10.html#section-5.1 ) along the lines of:  “In some cases, existing network gear has been deployed that cannot readily be upgraded or configured to support the PHB requirements. In some cases, this equipment can however loosely support an NQB service – see Section 8.3.1 for an example where this is particularly important. A similar approach may prove necessary in other network environments.”

3.      There was an objection made to discussing IP Precedence as an expected usage of the DiffServ field.  Rather, it was suggested that we reference  https://www.ietf.org/archive/id/draft-ietf-tsvwg-dscp-considerations-03.html#section-4.2.1 discussion on the impact of ToS Precedence Bleaching, and describe more fully the ramifications of this (the current text in https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-10.html#appendix-A isn’t sufficient).  Specifically talk about the fact that various re-marking policies (e.g. MPLS mappings) could result in QB traffic being aggregated with (and DSCP marked identically as) NQB traffic , and this is another motivation for implementing Traffic Protection.

4.      In the section on Unmanaged Networks https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-10.html#section-4.3.1 , it is unclear what is meant by an “unmanaged network”, so link this text to the discussion of interoperability in the last sentence of the 4th paragraph in:  https://www.rfc-editor.org/rfc/rfc2475#section-4  (“Where there is no knowledge ….”).

5.      Also in Section 4.3.1, along the lines of point 1 above, there was an objection to mandating DSCP re-marking, and it was requested to change the … MUST by default ensure that NQB traffic is marked with a DSCP that selects WiFI AC_BE …  to “SHOULD”, and change the other MUST around supporting reconfigurable mappings to a SHOULD as well.

Please let me know if I’ve missed any points in this summary, or if there are further comments on the above.  I’ll be working on the edits to the draft over the next few days.

Best Regards,
Greg