Subject: [tsvwg] Publication has been requested for draft-ietf-tsvwg-iana-dscp-registry-04

From: David Black <[email-masked]>
Date: Tue, 08 May 2018 07:00:10 -0700

David Black has requested publication of draft-ietf-tsvwg-iana-dscp-registry-04 as Proposed Standard on behalf of the TSVWG working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 9 May 2018 00:18:08 -0500

On Tue, May 8, 2018 at 9:00 AM, David Black <[email-masked]> wrote:

David Black has requested publication of draft-ietf-tsvwg-iana-dscp-registry-04
> as Proposed Standard on behalf of the TSVWG working group.
>

I have a couple of comments, but this draft is ready for Last Call. Could
you take a look at my comments, and let me know what the right thing to do
is?

Thanks!

Spencer

 There's a reference to https://tools.ietf.org/html/rfc8126#section-4.9 in
the Introduction, but that text uses "Standards Action" with the reference
but without any expansion, while further down, the next occurrence of
"Standards Action" explains that this means "values are assigned by
Standards Track or Best Current Practice RFCs", without providing a
reference. Perhaps expanding

   These are assigned by
   Standards Action, as defined in [RFC8126].

to read

   These are assigned by
   Standards Action, as defined in [RFC8126], i.e., values are assigned
   by Standards Track or Best Current Practice RFCs

and dropping the expansion from the second mention would be clearer?

Independent of that question, I had to read through the text containing the
second mention a couple of times.

  Although Pool 1 has not yet been completely exhausted, this document
   changes the IANA registration policy of Pool 3 to assignment by
   Standards Action, i.e., values are assigned by Standards Track or
   Best Current Practice RFCs.  The rationale for this update is a need
   to assign codepoints for particular PHBs that are unable to use any
   of the unassigned values in Pool 1.

Would it be correct to say

  Although Pool 1 has not yet been completely exhausted, there is a need
   to assign codepoints for particular PHBs that are unable to use any
   of the unassigned values in Pool 1. This document
   changes the IANA registration policy of Pool 3 to assignment by
   Standards Action, i.e., values are assigned by Standards Track or
   Best Current Practice RFCs, allowing these codepoints to be assigned.

?

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 09 May 2018 09:13:46 +0100

These request are all OK with me, and I have made the changes.

The recent thread on the TSVWG list has made me wonder again whether it 
is possible for me to be slightly clearer about explaining the TOS 
precedence bleaching - without drilling into all the detail. This has 
always a nightmare to write concisely, but I think I may be able to do 
better, and if you agree, I would also incorporate the slightly longer 
replacement text below:

OLD:
An example is the need to assign a suitable recommended default 
codepoint for the Lower Effort (LE) per-hop behavior (PHB) 
[I-D.ietf-tsvwg-le-phb]. The LE PHB is designed to protect best-effort 
(BE) traffic (packets forwarded with the default PHB) from LE traffic in 
congestion situations, i.e., when resources become scarce, best-effort 
traffic has precedence over LE traffic and may preempt it. The continued 
presence of bleaching of the IP precedence field, setting the first 
three bits of the former TOS byte to zero (i.e., zeroing the top three 
bits of the DSCP) in deployed networks motivates the desire for the LE 
PHB to use a DSCP with a zero value for the first three bits 
[I-D.ietf-tsvwg-le-phb].

NEW:
An example is the need to assign a suitable recommended default 
codepoint for the Lower Effort (LE) per-hop behavior (PHB) 
[I-D.ietf-tsvwg-le-phb]. The LE PHB is designed to protect best-effort 
(BE) traffic (packets forwarded with the default PHB) from LE traffic in 
congestion situations, i.e., when resources become scarce, best-effort 
traffic has precedence over LE traffic and is allowed to preempt it. The 
continued presence of bleaching of the IP precedence field in deployed 
networks can result in setting the first three bits of the former TOS 
byte to zero (disabling any class-based flow management by routers 
configured with TOS-based packet processing). There is a need to avoid 
this remapping of the DSCP for the LE PHB by assiging a codepoint that 
has a zero value in the first three bits [I-D.ietf-tsvwg-le-phb]. 
Furthermore, if the LE PHB were to have been assigned one of the 
currently unused Pool 1 codepoints with a zero value in the first three 
bits, any bleaching of the IP precedence field would result in other 
(higher assurance) traffic being remapped to the assigned DSCP. This 
remapping could then cause diffserv-marked traffic to receive an 
unintentional LE treatment for the remainder of the Internet path. It is 
therefore important to avoid the resulting priority inversion. The 
absence of unassigned codepoints in Pool 1 that exhibit these important 
properties motivates assigning a Pool 3 codepoint as the default that is 
recommended for use with this PHB.
---

- Your thoughts please, I'll hold publishing the new revision until I 
hear from you,

Gorry

On 09/05/2018, 06:18, Spencer Dawkins at IETF wrote:
> On Tue, May 8, 2018 at 9:00 AM, David Black <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     David Black has requested publication of
>     draft-ietf-tsvwg-iana-dscp-registry-04 as Proposed Standard on
>     behalf of the TSVWG working group.
>
>     Please verify the document's state at
>     https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/
>     <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/>
>
>
> I have a couple of comments, but this draft is ready for Last Call. 
> Could you take a look at my comments, and let me know what the right 
> thing to do is?
>
> Thanks!
>
> Spencer
>
>  There's a reference to 
> https://tools.ietf.org/html/rfc8126#section-4.9 in the Introduction, 
> but that text uses "Standards Action" with the reference but without 
> any expansion, while further down, the next occurrence of "Standards 
> Action" explains that this means "values are assigned by Standards 
> Track or Best Current Practice RFCs", without providing a reference. 
> Perhaps expanding
>    These are assigned by
> Independent of that question, I had to read through the text 
> containing the second mention a couple of times.
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 9 May 2018 14:04:51 -0500

Hi, Gorry,

On Wed, May 9, 2018 at 3:13 AM, Gorry Fairhurst <[email-masked]>
wrote:

> The recent thread on the TSVWG list has made me wonder again whether it is
> possible for me to be slightly clearer about explaining the TOS precedence
> bleaching - without drilling into all the detail. This has always a
> nightmare to write concisely, but I think I may be able to do better, and
> if you agree, I would also incorporate the slightly longer replacement text
> below:
>
> OLD:
> An example is the need to assign a suitable recommended default codepoint
> for the Lower Effort (LE) per-hop behavior (PHB) [I-D.ietf-tsvwg-le-phb].
> The LE PHB is designed to protect best-effort (BE) traffic (packets
> forwarded with the default PHB) from LE traffic in congestion situations,
> i.e., when resources become scarce, best-effort traffic has precedence over
> LE traffic and may preempt it. The continued presence of bleaching of the
> IP precedence field, setting the first three bits of the former TOS byte to
> zero (i.e., zeroing the top three bits of the DSCP) in deployed networks
> motivates the desire for the LE PHB to use a DSCP with a zero value for the
> first three bits [I-D.ietf-tsvwg-le-phb].
>
> NEW:
> An example is the need to assign a suitable recommended default codepoint
> for the Lower Effort (LE) per-hop behavior (PHB) [I-D.ietf-tsvwg-le-phb].
> The LE PHB is designed to protect best-effort (BE) traffic (packets
> forwarded with the default PHB) from LE traffic in congestion situations,
> i.e., when resources become scarce, best-effort traffic has precedence over
> LE traffic and is allowed to preempt it. The continued presence of
> bleaching of the IP precedence field in deployed networks can result in
> setting the first three bits of the former TOS byte to zero (disabling any
> class-based flow management by routers configured with TOS-based packet
> processing). There is a need to avoid this remapping of the DSCP for the LE
> PHB by assiging a codepoint that has a zero value in the first three bits
> [I-D.ietf-tsvwg-le-phb]. Furthermore, if the LE PHB were to have been
> assigned one of the currently unused Pool 1 codepoints with a zero value in
> the first three bits, any bleaching of the IP precedence field would result
> in other (higher assurance) traffic being remapped to the assigned DSCP.
> This remapping could then cause diffserv-marked traffic to receive an
> therefore important to avoid the resulting priority inversion. The absence
> of unassigned codepoints in Pool 1 that exhibit these important properties
> motivates assigning a Pool 3 codepoint as the default that is recommended
> for use with this PHB.
> ---
>
> - Your thoughts please, I'll hold publishing the new revision until I hear
> from you,
>

I don't object to the new text, but it looks like there's still some
mailing list traffic on this draft - I'll go read that next.

If you do the right thing, that will be fine with me, of course ...

Spencer

> On Tue, May 8, 2018 at 9:00 AM, David Black <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
>>  There's a reference to https://tools.ietf.org/html/rfc8126#section-4.9
>> in the Introduction, but that text uses "Standards Action" with the
>> reference but without any expansion, while further down, the next
>> occurrence of "Standards Action" explains that this means "values are
>> assigned by Standards Track or Best Current Practice RFCs", without
>> providing a reference. Perhaps expanding
>>    These are assigned by
>> Independent of that question, I had to read through the text containing
>> the second mention a couple of times.
>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 9 May 2018 14:32:20 -0500

And, just following up ...

> If you do the right thing, that will be fine with me, of course ...

Having caught up on the mailing list traffic, I still think you're doing
the right thing.

Thanks!

Spencer

>>> Could you take a look at my comments, and let me know what the right thing
>>> to do is?
>>>
>>> Thanks!
>>>
>>> Spencer
>>>