Add static GUE encapsulation #1234
Conversation
|
Dan, thanks for the contribution! I'm not sure that this should be modelled this way. A few concerns:
Happy to discuss further. |
|
I see the discussion in #1208 that covered the objection to this being in If this is always going to be specified via a static route -- then I suggest that we have this configured under the static routing sections of the model. I'd like to understand what the plan is to make this consistent with GRE encapsulation. (i.e., will we deprecate There's some history of how this is modelled here: https://drive.google.com/file/d/1GVzP6ZQFlvbZvdLSZnhYlwrL6AIaLJl-/view?usp=sharing |
I actually recommended to Dan that we create next-hop-groups at this level. I'm happy to entertain some other suggestion though? The intended concept is these user defined next-hop-groups are the static equivalent of gRIBI programmed next-hop-groups. User defined next-hop-groups (and their child next-hops) can be referenced by static-routes, policy-forwarding and generically anything that would set or reference (user defined) next-hop-groups. WDYT? |
|
/gcbrun |
|
No major YANG version changes in commit e68b038 |
I think this is quite messy. There are some implementation questions I have here (why not just inject these via gRIBI is one -- we can take this offline) -- but generally, I think that we don't have a general purpose way in existing implementations to create gRIBI-like NHGs+NHs that are re-used across protocols. Can we point to multiple implementations that look like this? I would prefer that we map this in a way that: a) makes it really clear what the entries that we are creating are and how they can be used, What is the specification that is being asked for here? Is it to require this to be re-used across |
|
Hi Darren/Dan - We have been working on a proposal from Cisco, and we defined the next-hop group and next-hops (encap header) containers under the local-routing module (static route) like Rob suggested above. In addition, we were trying to define a "template" for common fields like the source-ip, dscp, ttl which can be re-used in all the next hops. This was just to reduce the repetition of fields, which in some cases can hit resource constraints on the ASIC (for example, an ASIC might only support a limited number of Source IP's or only a global UDP destination port) unless the backend implementation forces some form of templatization. The connection-endpoint can be extended to act as a template for such common fields. Finally the local route prefix would just use the next-hop group similar to how it currently refers to the local-next-hop. Most ACL and Policy forwarding implementations already support a redirect to a nexthop IP, and the local-route prefix can be used easily in such flows. Let us know what you think? Thanks |
Thanks for the comment. We're working to produce another revision. I like to idea of some way to reduce the repetition of the fields for the encap-headers. One idea that comes to mind is to place the fields on the next-hop-group and declare that all the next-hops in that group must use the fields. Just thinking out loud. |
Hi Darren, Yes the next-hop container might be one place to hold on the common fields. We were considering the connection-point as it already does something similar for VxLAN - https://openconfig.net/projects/models/schemadocs/yangdoc/openconfig-network-instance.html#network-instances-network-instance-connection-points-connection-point-endpoints-endpoint-vxlan We can discuss further. Let us know if you would like to review what we've been working on at Cisco for this usecase. |
|
Ok, so the proposal is to move the next-hop-group/next-hops into the local-routing module, perhaps rooted at
(following the pattern of local-aggregates, static-routes which are also part of local-routing) And move the attributes (encap-headers) from the next-hop up to the next-hop-group. ie: Thoughts? |
|
The addition of statically configured next-hop-groups to OC (in local-routing context) is a very good step (a very big +1 from us) but please don't limit it to containing next-hops that only do tunnel encapsulation (GUE or other). All types of next-hops used by static routes should be supported. It is an implementation-specific matter if some types of next-hops cannot be combined with other types in the same NHG. I don't have a strong view on whether the NHGs should be limited to use by static routes or also include use by policy-forwarding. If a statically configured NHG is bound to a static route prefix I assume it will not be valid to define individual next-hops for that static route -- in other words, the use of NHG should be mutually exclusive with the use of individual next-hops. |
Change Scope
next-hop-groupsandnext-hopsunder network instance to mimic existing AFT tree. This will allow systems to configure these in a network instance.Platform Implementations
Tree view
Flatten view