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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Gorry,

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

> 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,
>

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


> Gorry
>
> On 09/05/2018, 06:18, Spencer Dawkins at IETF wrote:
>
> On Tue, May 8, 2018 at 9:00 AM, David Black <[e-mail] <mailto:
>> [e-mail]>> 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
>>    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.
>>
>> ?
>>
>
>