[libyang bug] workaround leaf-list via uses bug in BGP route-map

[bradh352]

Why I did it

There is a bug in libyang when attempting to validate table BGP_PEER_GROUP_AF and likely BGP_NEIGHBOR_AF in respect to route_map_in and route_map_out.

The issue is with the use of leaf-list specifically when it is pulled in via a uses clause of bgpcmn:sonic-bgp-cmn-af.

The error message resembles that of if a child is specified that isn't recognized at all:

All Keys are not parsed in BGP_PEER_GROUP_AF
dict_keys(['default|PEERS|ipv4_unicast'])
exceptionList:["'route_map_in'"]

Work item tracking

How I did it

Moving the leaf-list to the parent rather than being imported through the uses clause works around this issue.

Again, this is a bug in libyang itself, and the same block in sonic-bgp-cmn-af was simply moved to the parents and it magically fixes the issue.

How to verify it

Relevant config section to cause the issue (probably included too much here, but none-the-less effective):

{
    "DEVICE_METADATA": {
        "localhost": {
           {# ... #}
            "docker_routing_config_mode": "unified",
            "frr_mgmt_framework_config": "true"
           {# ... #}
        }
    },
    "BGP_GLOBALS": {
        "default": {
            "load_balance_mp_relax": "true",
            "local_asn": "4210000001",
            "log_nbr_state_changes": "true",
            "router_id": "172.16.0.1"
        }
    },
    "BGP_GLOBALS_AF": {
        "default|ipv4_unicast": {
            "max_ebgp_paths": "2"
        },
        "default|ipv6_unicast": {
            "max_ebgp_paths": "2"
        },
        "default|l2vpn_evpn": {
            "advertise-all-vni": "true"
        }
    },
    "BGP_NEIGHBOR": {
        "default|Ethernet72": {
            "peer_group_name": "PEERS"
        }
    },
    "BGP_PEER_GROUP": {
        "default|PEERS": {
            "bfd": "true",
            "capability_ext_nexthop": "true",
            "ebgp_multihop": "true",
            "holdtime": "9",
            "keepalive": "3",
            "min_adv_interval": "5",
            "peer_type": "external"
        }
    },
    "BGP_PEER_GROUP_AF": {
        "default|PEERS|ipv4_unicast": {
            "admin_status": "up",
            "route_map_in": [
                "ALLOW"
            ],
            "route_map_out": [
                "ALLOW"
            ]
        },
        "default|PEERS|ipv6_unicast": {
            "admin_status": "up",
            "route_map_in": [
                "ALLOW"
            ],
            "route_map_out": [
                "ALLOW"
            ]
        },
        "default|PEERS|l2vpn_evpn": {
            "admin_status": "up",
            "route_map_in": [
                "ALLOW"
            ],
            "route_map_out": [
                "ALLOW"
            ],
            "unchanged_nexthop": "true"
        }
    },
    "ROUTE_MAP": {
        "ALLOW|1": {
            "route_operation": "permit"
        }
    },
    "ROUTE_MAP_SET": {
        "ALLOW": {}
    }
}

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

• 202411

Tested branch (Please provide the tested image version)

master as of 20241206

Description for the changelog

[libyang bug] workaround leaf-list via uses bug in BGP route-map

Link to config_db schema for YANG module changes

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

Signed-off-by: Brad House (@bradh352)

[bradh352]

rebased to force rebuild to see if general sonic CI tests are working yet

[bradh352]

@qiluo-msft @lguohan please review

[mssonicbld]

/azp run Azure.sonic-buildimage

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[bradh352]

rebased to try to force rebuild since last build hung

[bradh352]

rebased again since last build failed in unrelated test

[mssonicbld]

/azp run Azure.sonic-buildimage

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[bradh352]

@ganglyu interestingly, this bug is still present after upgrading to libyang3.

After further research, it appears this is due to a bug in sonic-yang-mgmt. It tries to translate config_db.json format to a valid yang data format, and in doing so it uses the raw parsed yang schema to try to determine how it needs to be formatted. Being that it is a raw format (rather than the compiled schema), it then has to merge things like 'uses' clauses, and is only merging leaf nodes and not leaf-list nodes, hence the issue.

It shouldn't be a big deal to fix this oversight, but honestly the overall approach it is taken probably needs to be rethought at some point.

sonic-mgmt-common also does this conversion, but in a different way, and in Golang. As of the pending libyang3 PRs, at least that is occurring on the compiled schema format so it doesn't have to do things like uses clause evaluation.

Considering how complex this process is, it would probably be beneficial to have this conversion done in one place that is shared .... that said being one is in python and one is in Golang, that is easier said than done.

[ganglyu]

@bradh352
I'm not familiar with sonic-yang-mgmt, could you please discuss this issue in the UMF work group meeting?

[bradh352]

closing, proper fix in #21907 ganglyu you previously approved this PR. I'm going to close it since an actual fix is now available. Please review that PR and approve.