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. |
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