pbrd: show '0' DSCP / ECN-based PBR Match

[soumyar-roy]

As per RFC rfc3168 section 5, the ECN field in the IP header has two bits, allowing for four ECN codepoints from '00' to '11'. DSCP/ECN with a value of 0 should be treated like any other value. This also applies to the 6 bits of DSCP in the IP header.

For example:

0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | DS FIELD, DSCP | ECN FIELD | +-----+-----+-----+-----+-----+-----+-----+-----+ DSCP: differentiated services codepoint ECN: Explicit Congestion Notification

There are four options of these two ECN bits 00 – Non-ECN Packet ==> still valid (0-3) 01 – ECN capable 10 – ECN capable 11 – Congestion experienced (CE) Both 10 and 01 are same

Before fix: pbr-map l3_intf_pbr_map seq 1 match src-ip 191.1.1.1/24 exit !

After fix: pbr-map l3_intf_pbr_map seq 1 match src-ip 191.1.1.1/24 match dscp 0 match ecn 0 exit !

Ticket: #3472824

[Jafaral]

Isn't this a behavior change?

Before fix:

pbr-map l3_intf_pbr_map seq 1
match src-ip 191.1.1.1/24
exit

!

After fix:

pbr-map l3_intf_pbr_map seq 1
match src-ip 191.1.1.1/24
match dscp 0
match ecn 0
exit

The first config doesn't match the dscp/ecn, and now we want to treat that as match zero values? I.e, the way I read the first one is match any value, whereas with the new change, it is not "match any" anymore, it is match zero only.

This is OK if the user can still express "match any". I.e, it isn't clear without diving into code if this only affect the case where the user actually configured a match dscp/ecn rule.

[soumyar-roy]

Thanks for reviewing, I have discussed this with original writer, @routingrocks for the commit., it had another associated commit too(not added , as I found out later). Original issue was, if user configures explicitly match dscp 0 or match ecn 0, they were not showing up in show run. But I have checked in current upstream this issue is not reproducible. So closing this PR for now.