Define SYSTEM_DEFAULTS table to control tunnel_qos_remap

[bingwang-ms]

Signed-off-by: bingwang [email protected]

Why I did it

This PR is to define a new table SYSTEM_DEFAULTS to turn on/off new features in SONiC.
Currently, only the flag to turn on/off tunnel_qos_remap is in the new table.
HLD sonic-net/SONiC#982

How I did it

1. Define a new section in minigraph.xml

<SystemDefaultsDeclaration>
    <a:SystemDefaults xmlns:a="http://schemas.datacontract.org/2004/07/Microsoft.Search.Autopilot.Evolution">
		 <a:SystemDefault>
            <a:Name>TunnelQosRemapEnabled</a:Name>
            <a:Value>True</a:Value>
         </a:SystemDefault>
    </a:SystemDefaults>
</SystemDefaultsDeclaration>

2. Update minigrapg.py to parse the new section, and write into config_db.
3. The Tunnel Qos remapping feature will be turn off if TunnelQosRemapEnabled=False. Otherwise minigraph.py will try to parse new fields in minigraph.xml, and write the parsed value into config_db.
   The extra values for tunnel qos remapping are as below.

 "src_ip": "25.1.1.10",
 "decap_dscp_to_tc_map": "AZURE_TUNNEL",
 "decap_tc_to_pg_map": "AZURE_TUNNEL",
 "encap_tc_to_dscp_map": "AZURE_TUNNEL",
 "encap_tc_to_queue_map": "AZURE_TUNNEL"

Changes for the templates will be raised in another PR.

How to verify it

Verified by adding new UT cases.

Which release branch to backport (provide reason below if selected)

• 201811
• 201911
• 202006
• 202012
• 202106
• 202111

Description for the changelog

Define SYSTEM_DEFAULTS table to control tunnel_qos_remap.

Link to config_db schema for YANG module changes

A picture of a cute animal (not mandatory but encouraged)

[bingwang-ms]

/azp run Azure.sonic-buildimage

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[prsunny]

Since the minigraph is anyways changing, can we have the src_ip to be coming from minigraph TunnelInterface instead of having the logic to determine from peer_switch_ip ?

[bingwang-ms]

I was also thinking about that. The problem is, I'm afraid it's not easy to implement that logic in Metadata.
For example, for upper_tor, the peer_ip would be 10.1.0.33, while for lower_tor, it would be 10.1.0.32. That means we have to generate different minigraph for upper_tor/lower_tor. I don't konw if it's doable. It may require a bunch of code change. So I put it in minigraph parser.

[prsunny]

IMO, this would be pretty simple to implement. And btw, the minigraph is indeed different for upper and lower tor. Approving this!

[bingwang-ms]

/azp run Azure.sonic-buildimage

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[bingwang-ms]

/azp run Azure.sonic-buildimage

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[lolyu]

LGTM, thanks!

[bingwang-ms]

/azp run Azure.sonic-buildimage

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).