| Message ID | 20220620185807.968658-1-oleksandr@natalenko.name |
|---|---|
| State | Changes Requested |
| Delegated to: | Pablo Neira |
| Headers | show |
| Series | src: proto: support DF, LE, VA for DSCP | expand |
Hi, 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 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), > 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. Thanks.
Hello. Thank you for your response. Please find my comments inline. 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? > > 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. > > 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. Thanks. Thanks.
On Tue, Jun 28, 2022 at 08:29:42PM +0200, Oleksandr Natalenko wrote: > Hello. > > Thank you for your response. Please find my comments inline. > > 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'. > > > 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 ? But the values are different. > > > 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 '<='. What does 'lephb' stands for BTW? Note that these aliases will be lost when listing back the ruleset from the kernel, so it is only working as an input.
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. > > > > 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. > > > > 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. > Note that these aliases will be lost when listing back the ruleset > from the kernel, so it is only working as an input. Sure thing. Thanks.
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.
diff --git a/src/proto.c b/src/proto.c index a013a00d..84555b9e 100644 --- a/src/proto.c +++ b/src/proto.c @@ -684,7 +684,9 @@ static const struct symbol_table dscp_type_tbl = { SYMBOL("cs5", 0x28), SYMBOL("cs6", 0x30), SYMBOL("cs7", 0x38), + SYMBOL("df", 0x00), SYMBOL("be", 0x00), + SYMBOL("le", 0x01), SYMBOL("af11", 0x0a), SYMBOL("af12", 0x0c), SYMBOL("af13", 0x0e), @@ -697,6 +699,7 @@ static const struct symbol_table dscp_type_tbl = { SYMBOL("af41", 0x22), SYMBOL("af42", 0x24), SYMBOL("af43", 0x26), + SYMBOL("va", 0x2c), SYMBOL("ef", 0x2e), SYMBOL_LIST_END },
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. As per RFC 8622, add "le" for Lower-Effort with 0x01 value. tc-cake(8) in diffserv8 mode would benefit from having "le" alias since it corresponds to "Tin 0". Signed-off-by: Oleksandr Natalenko <oleksandr@natalenko.name> --- src/proto.c | 3 +++ 1 file changed, 3 insertions(+)