uRPF through another VRF OC proposal

[nupkanoi]

Change Scope

• Please briefly describe the change that is being made to the models- this change adds support for uRPF to be able validation source IP address from a different instance/vrf from the forwarding instance/vrf.
• Please indicate whether this change is backwards compatible - Yes

module: openconfig-interfaces
  +--rw interfaces
     +--rw interface* [name]
        +--rw subinterfaces
           +--rw subinterface* [index]
              +--rw oc-ip:ipv4
               | +--rw oc-ip:urpf
               |    +--rw oc-ip:config
               |    |  +--rw urpf-lookup-network-instance         oc-ni:network-instance-ref
               |    +--rw oc-ip:state
               |       +--rw urpf-lookup-network-instance         oc-ni:network-instance-ref
              +--rw oc-ip:ipv6
                 +--rw oc-ip:urpf
                    +--rw oc-ip:config
                    |  +--rw urpf-lookup-network-instance         oc-ni:network-instance-ref
                    +--rw oc-ip:state
                       +--rw urpf-lookup-network-instance         oc-ni:network-instance-ref

Platform Implementations

• Implementation A: Arista implementation
• Implementation B: Cisco is already developing this feature

[dplore]

/gcbrun

[OpenConfigBot]

No major YANG version changes in commit b1145b8

[dplore]

In concept this LGTM. It should be rebased to be compatible with #1307 which should merge in the next day or so.

Also, please update the "Change Scope" with a description of the change.

[nupkanoi]

/gcbrun

[nupkanoi]

In concept this LGTM. It should be rebased to be compatible with #1307 which should merge in the next day or so.

Also, please update the "Change Scope" with a description of the change.

Done

[dplore]

/gcbrun

[dplore]

/gcbrun

[dplore]

/gcbrun

[dplore]

Will review at July 1, 2025 OC Operators meeting. Setting last call for July 8th

[ElodinLaarz]

Discussed at the July 1st OC Operators Meeting-- Sounds good to me.

[dplore]

/gcbrun

[akvasu]

Hi, From Cisco, we would like a little more time to review this model internally as uRPF is generally expected to run on the network instance associated with the interface.

[ElodinLaarz]

Sounds reasonable. We can delay last call by a week for now and if we need more time, we can revisit. - OC Operators Meeting July 8th.

[ElodinLaarz]

@akvasu This is scheduled to merge today-- any last comments here?

[Tavneet-Sidhu13]

@akvasu This is scheduled to merge today-- any last comments here?

Request one more week to review feasibility of this OC model

[dplore]

@akvasu This is scheduled to merge today-- any last comments here?

Request one more week to review feasibility of this OC model

Thank you @Tavneet-Sidhu13 , I have extended the last call to July 23, 2025

[amogh-vk]

Since the urpf-lookup-network-instance is part of the subinterface container, should we assume the interface will be associated with the defined VRFs, or will it remain part of the default VRFs?

Also, please hold off on merging for one more week. We need a little more time to analyze this.

[earies]

Since the urpf-lookup-network-instance is part of the subinterface container, should we assume the interface will be associated with the defined VRFs, or will it remain part of the default VRFs?

Also, please hold off on merging for one more week. We need a little more time to analyze this.

This model proposal allows for any combination to cross VRF/NI boundaries and would imply the opposite. The subinterface this is set on is not a member of the target NI used for lookup (otherwise the tagged NI would be redundant and unnecessary)

[earies]

Nit: No need to repeat urpf- here as this already falls under a urpf container

[earies]

Suggested change

	up in the forwarding network-instance.";
	up in the network-instance in which this interface is a member of.";