The SRv6 uA behavior is associated with a L3 adjacency.
This commit extends the staticd YANG model by adding two leafs
`interface` and `next-hop` under the `static-sids` container. This
extension allows us to associate an interface and a nexthop when
configuring an SRv6 uA SID.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
The staticd YANG conversion completely f*cked up dst-src routes.
Stupidly enough, the correct thing is much simpler as seen by the amount
of deletes in this commit.
This does, unfortunately, involve a rather annoying YANG edge case with
what should reasonably be an optional leaf as part of a list key, which
is not possible. It uses `::/0` as unconditional filler instead, since
that is semantically correct.
The `test_yang_mgmt` topotest needed to be adjusted after this to add
`src-prefix='::/0'`.
Fixes: 88fa5104a0 ("staticd : Configuration northbound implementation")
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
YANG files get to keep their license boilerplate in addition to the SPDX
header, since they are likely to be copied around individually.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Define a generic BFD monitoring group template and use it to add support
for static route monitoring.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
modified the yang model for path-list.
table-id should be a key, as one route can have
multiple table-ids.
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
To address the ip mroute command there is a need to add
safi as a key. So adding the afi-safi-type identityref
as a key.
Signed-off-by: VishalDhingra <vdhingra@vmware.com>
staticd yang has been modified to support below use cases
1. src-table for IPV6 address family.
2. distance,tag and table-id would be the key for a given prefix.
Signed-off-by: VishalDhingra <vdhingra@vmware.com>
Yang files for staticd to use northbound APIs
Co-authored-by: Santosh P K <sapk@vmware.com>
Co-authored-by: vishaldhingra <vdhingra@vmware.com>
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
