Static route next network-instance option

[rszarecki]

Change Scope

This change introduces new option for static route, allowing further destination lookup in context of other network-instance.

module: openconfig-network-instance
  +--rw network-instances
     +--rw network-instance* [name]
        +--rw protocols
           +--rw protocol* [identifier name]
              +--rw static-routes
                 +--rw static* [prefix]
                    +--rw next-network-instance
                       +--rw config
                       |  +--rw next-network-instance?   -> ../../../../../../../config/name
                       +--rw state
                          +--rw next-network-instance?   -> ../../../../../../../state/name

This change is non-disruptive.

Platform Implementations

• Juniper: Enabling Internet Access for Layer 3 VPNs
  

[edit]
routing-instances {
   vpna {
       instance-type vrf;
       routing-options {
           static {
               route 0.0.0.0/0 next-table inet.0;
           }
       }

• Cisco XR: link to documentation

router static
vrf vrf_A
address ipv4 unicast
172.168.40.0/24 loopback 1
172.168.50.0/24 vrf vrf_B 192.168.1.2

implementation output.

[dplore]

/gcbrun

[OpenConfigBot]

No major YANG version changes in commit 7a75980

[dplore]

Thanks for the PR.

It looks like this PR needs to be caught up to the latest commit in master? It's missing the changes from earlier commits in master.

Also this PR contains commits for the uRPF changes which is probably not intended.

[dplore]

Should follow the precedence from the afts model where a lookup is intended to be triggered in a different, destination network-instance. The leaf used there is next-hop-group-network-instance

/network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/state/next-hop-group-network-instance

A similar pattern for static-routes could be:

/network-instances/network-instance/protocols/protocol/static-routes/static/config/next-hop-group-network-instance

[akalluru1]

Isn't this change analogous to #1219, i.e., resolution of next-hop in a different network-instance?

If so, Isn't it better & flexible to emulate the same model here for IP routes as well? i.e., Adding a next-hop-network-instance leaf under /network-instances/network-instance/protocols/protocol/static-routes/static/next-hops/next-hop/config, same leaf should be added in next-hop/state container as well.

Please correct me if I completely misunderstood the intent of this PR.

[LimeHat]

Implementation references contain links to two different features:

• Juniper implementation simply suggests that a hierarchical lookup (in another network instance) is performed,
• Cisco implementation suggests that a specific next-hop is resolved in another NI (and, in addition to that, the route is active only when that next-hop is in fact resolved)

[rszarecki]

Good point @LimeHat .

I was thinking of juniper-like implementation. And I do have use case for it.
One would be internet access from vpn/vrf. Other would be some prod scenario, where subset of routes only are used for uRPF.
But indeed is not same as Arista and Cisco. Probably for this NI shall be option of next-hop not of prefixes.

What is your take?

[dplore]

So the destination NI leaf should probably be added to the nexthops as suggested above.

For example:
/network-instances/network-instance/protocols/protocol/static-routes/static/next-hops/next-hop/config/next-network-instance

We also need some additional description to clarify the behavior.

next-network-instance:

The next-hop for this static route should be looked up in the specified network-instance. For example, if the current network instance is named 'Blue' and the route destination is '1.1.1.1'  and the next-hop next-network-instance is 'DEFAULT', then 
a. a lookup for '1.1.1.1' in the network-instance 'DEFAULT' should be performed 
b. any next-hop IP address that exists in the 'DEFAULT' network-instance should be returned.  
c. the packet should be forwarded to the next-hop from step b. in network-instance 'DEFAULT'

Is that a good description on what you're looking specify @rszarecki