On Wed, Jun 29, 2022 at 07:34:40PM +0200, Oleksandr Natalenko wrote: > Hello. > > On středa 29. června 2022 19:24:28 CEST Pablo Neira Ayuso wrote: > > On Tue, Jun 28, 2022 at 08:29:42PM +0200, Oleksandr Natalenko wrote: > > > On pondělí 27. června 2022 19:31:27 CEST Pablo Neira Ayuso wrote: > > > > On Mon, Jun 20, 2022 at 08:58:07PM +0200, Oleksandr Natalenko wrote: > > > > > Add a couple of aliases for well-known DSCP values. > > > > > > > > > > As per RFC 4594, add "df" as an alias of "cs0" with 0x00 value. > > > > > > > > > > As per RFC 5865, add "va" for VOICE-ADMIT with 0x2c value. > > > > > > > > Quickly browsing, I don't find "va" nor 0x2c in this RFC above? Could > > > > you refer to page? > > > > > > As per my understanding it's page 11 ("2.3. Recommendations on implementation of an Admitted Telephony Service Class") here: > > > > > > Name Space Reference > > > --------- ------- --------- > > > VOICE-ADMIT 101100 [RFC5865] > > > > > > Am I wrong? > > > > Ok, hence the 'va'. > > Yes. OK. > > > > > As per RFC 8622, add "le" for Lower-Effort with 0x01 value. > > > > > > > > This RFC refers to replacing CS1 by LE > > > > > > > > o This update to RFC 4594 removes the following entry from its > > > > Figure 4: > > > > > > > > |---------------+------+-------------------+---------+--------+----| > > > > | Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes| > > > > | Data | | | | | | > > > > ------------------------------------------------------------------ > > > > > > > > and replaces it with the following entry: > > > > > > > > |---------------+------+-------------------+----------+--------+----| > > > > | Low-Priority | LE | Not applicable | RFC 8622 | Rate | Yes| > > > > | Data | | | | | | > > > > ------------------------------------------------------------------- > > > > > > > > > > > > static const struct symbol_table dscp_type_tbl = { > > > > .base = BASE_HEXADECIMAL, > > > > .symbols = { > > > > [...] > > > > SYMBOL("cs1", 0x08), > > > > [...] > > > > SYMBOL("le", 0x01), > > > > > > I think we shouldn't remove existing symbol, should we? Please let > > > me know if I missed any suggested action item for myself here. > > > > Not removing. I mean, if I understood correctly, the RFC says LE == cs1 ? > > To my understanding, no. The RFC talks about obsoleting: > > "This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification." > > > But the values are different. > > Yes, as a consequence of obsoleting, not replacing. OK. > > > > > tc-cake(8) in diffserv8 mode would benefit from having "le" alias since > > > > > it corresponds to "Tin 0". > > > > > > > > Aliasing is fine, let's just clarify this first. > > > > > > I mean, "le" would be an alias to "0x01", not to "cs1". > > > > > > BTW, the reason I included Loganaden Velvindron in Cc is that "le" > > > was already added in the past, but got quickly reverted as it broke > > > some tests. Shall "le" interfere with "less-equal", or what could be > > > the issue with it? If the name is not acceptable, "lephb" or similar > > > can be used instead. > > > > Oh right, this is an issue for the parser, the 'le' keyword is an > > alias of '<='. > > OK, then another name should be found. > > > What does 'lephb' stands for BTW? > > "LE PHB" originally, as described in the RFC, it's Lower-Effort Per-Hop Behavior. Fine with me.