Question re AFT model

[upavlo]

Hi, there seems to be some confusion on my part with this leaf: /network-instances/network-instance[name]/afts/next-hops/next-hop[index]/state/origin-protocol

It implies that i's possible to determine how a specific next-hop was learned, which is not the case. Shouldn't this leaf be under ipv4-entry/state and ipv6-entry/state instead? (since it is possible to determine where a prefix that was pushed to FIB came from).

[robshakir]

Apologies for the delay in responding.

The reason that we left this leaf in place for the AFT model was to ensure that we had some way to track what protocol installed a next-hop when there were not direct forwarding entries associated with it. For example, let's consider an RSVP-TE LSP that's installed at a head-end -- in this scenario, we'd expect that there's a next-hop with a particular output label allocated, but RSVP-TE itself does not install prefixes or labels that are to be forwarded into that LSP. The same can be true with gRIBI installed entries. We would not expect that this leaf need be populated for all entries - i.e., where the next-hop is then recursively looked up, then clearly the next-hop's entry in its corresponding table would be used - but this was the utility of maintaining it in the model.

I agree that we should likely have this for both ipv4-entry and ipv6-entry too.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.

[dplore]

FYI, origin-protocol now exists for ipv4-entry and ipv6-entry

openconfig-network-instance /network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/state/origin-protocol leaf identityref openconfig-network-instance /network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/state/origin-protocol leaf identityref