Make NAT translation reporting generic by bewing · Pull Request #1467 · openconfig/public

bewing · 2026-04-02T18:59:09Z

Change Scope

Rewrite nat-translation-entry-state to cover all use cases and convey more information
This is incompatible with the initial release of the NAT model

Platform Implementations

Implementation A: Linux Conntrack
Implementation B: Arista

Tree View

module: openconfig-nat
  +--rw nat
     +--rw instances
        +--rw instance* [name]
            +--ro translations
               +--ro translation* [translation-id]
                  +--ro translation-id    -> ../state/translation-id
                  +--ro state
                     +--ro translation-id?     uint64
-                    +--ro internal-address?   inet:ip-address
-                    +--ro internal-port?      inet:port-number
-                    +--ro external-address?   inet:ip-address
-                    +--ro external-port?      inet:port-number
                     +--ro protocol?           protocol-type
+                    +--ro nat-type?         nat-translation-type
+                    +--ro interface?        oc-if:base-interface-ref
+                    +--ro original
+                    |  +--ro src-address?   inet:ip-address
+                    |  +--ro src-port?      inet:port-number
+                    |  +--ro dst-address?   inet:ip-address
+                    |  +--ro dst-port?      inet:port-number
+                    +--ro translated
+                    |  +--ro src-address?   inet:ip-address
+                    |  +--ro src-port?      inet:port-number
+                    |  +--ro dst-address?   inet:ip-address
+                    |  +--ro dst-port?      inet:port-number
                     +--ro creation-time?      yang:date-and-time
                     +--ro last-activity?      yang:date-and-time
                     +--ro timeout?            uint32
-                    +--ro source-pool?        string
-                    +--ro source-mapping?     string
+                    +--ro nat-pool?         string
+                    +--ro nat-mapping?      string
                     +--ro counters
-                       +--ro packet-count-inbound?    yang:counter64
-                       +--ro packet-count-outbound?   yang:counter64
-                       +--ro byte-count-inbound?      yang:counter64
-                       +--ro byte-count-outbound?     yang:counter64
+                       +--ro original-direction
+                       |  +--ro packets?   yang:counter64
+                       |  +--ro bytes?     yang:counter64
+                       +--ro reply-direction
+                          +--ro packets?   yang:counter64
+                          +--ro bytes?     yang:counter64

gemini-code-assist

Code Review

This pull request refactors the NAT operational state model in openconfig-nat.yang by replacing the flat internal/external address structure with a more flexible 5-tuple representation (original and translated) to support SNAT, DNAT, and double NAT. It also renames pool and mapping leaves and restructures counters to be direction-based. Feedback indicates that these breaking changes require a version bump and revision history update. Additionally, suggestions were made to add a NONE or PASSTHROUGH enum to nat-translation-type and to use a less restrictive interface reference type to support subinterfaces.

gemini-code-assist · 2026-04-02T19:01:22Z

+    leaf interface {
+      type oc-if:base-interface-ref;


The interface leaf uses oc-if:base-interface-ref, which only allows referencing a top-level interface. Since NAT is frequently applied to subinterfaces (where L3 configuration resides in OpenConfig), this type may be too restrictive. Consider using a type that allows referencing subinterfaces (like a simple string or a more complex interface-ref structure), or clarify if only base interfaces are intended to be reported here.

oc-if:base-interface-ref is used in several other places already in the model - should I update all instances of it to use oc-if:interface-ref-common ?

Let's leave it as is for now. If subinterface-level NAT is needed in the future, both the config and state references should be upgraded to interface-ref together in a follow-up PR.

bewing · 2026-04-02T19:04:14Z

Does the OC team prefer force pushes in response to feedback, or incremental commits for each discussion item?

dplore · 2026-04-07T18:05:54Z

@nleiva would you like to review?

dplore · 2026-04-07T18:06:00Z

/gcbrun

OpenConfigBot · 2026-04-07T18:07:59Z

No major YANG version changes in commit 31c7a62

nleiva · 2026-04-07T18:24:56Z

@nleiva would you like to review?

Of course, give me a week or two. Got this and SNMP on my TODO list now.

rolandphung · 2026-04-08T23:04:58Z

@dplore Just looking at this in a process perspective, I noticed that this is marked automatically as non-breaking, while the model change is clearly breaking. Digging a bit further I noticed that the entire nat model is not referenced anywhere in the documentation (specifically https://openconfig.net/projects/models/paths/).

My question is that are we still considering this as unpublished so we can make backwards incompatible changes? Is that why non-breaking is tagged here?

If unpublished, when are we going to add /nat root? If not, should this be considered breaking?

ElodinLaarz · 2026-04-14T16:18:48Z

@dplore Just looking at this in a process perspective, I noticed that this is marked automatically as non-breaking, while the model change is clearly breaking. Digging a bit further I noticed that the entire nat model is not referenced anywhere in the documentation (specifically https://openconfig.net/projects/models/paths/).

My question is that are we still considering this as unpublished so we can make backwards incompatible changes? Is that why non-breaking is tagged here?

If unpublished, when are we going to add /nat root? If not, should this be considered breaking?

Since the major version in the OC yang is 0, the CI does not look for breaking changes.

If this is something where we already have production use, we should increment the version to 1.X.X.

The documentation absence seems like a separate issue? Will look into it. @dplore

nleiva · 2026-04-15T13:21:20Z

Change Scope

Rewrite nat-translation-entry-state to cover all use cases and convey more information

This is incompatible with the initial release of the NAT model

Platform Implementations

Implementation A: Linux Conntrack

Implementation B: Arista

Tree View
module: openconfig-nat
  +--rw nat
     +--rw instances
        +--rw instance* [name]
            +--ro translations
               +--ro translation* [translation-id]
                  +--ro translation-id    -> ../state/translation-id

Thanks @bewing for your contribution, it looks good to me.

What do you think about adding direction to the config section as well to make it consistent with the state changes? Something along the lines of:

grouping nat-static-config {
  // ... existing leaves ...

  leaf nat-direction {
    type enumeration {
      enum SOURCE { ... }
      enum DESTINATION { ... }
    }
    description
      "Direction of this static mapping. SOURCE translates
      the source address; DESTINATION translates the
      destination address.";
  }

  leaf original-address {
    type inet:ip-address;
    description
      "Address before NAT is applied for this mapping.";
  }

  leaf translated-address {
    type inet:ip-address;
    description
      "Address after NAT is applied for this mapping.";
  }
}

Arista and Juniper support this config option.

bewing · 2026-05-05T19:04:15Z

Thanks @bewing for your contribution, it looks good to me.

What do you think about adding direction to the config section as well to make it consistent with the state changes? Something along the lines of:

Something like this?

            +--rw static
            |  +--rw mapping* [name]
            |     +--rw name      -> ../config/name
            |     +--rw config
            |     |  +--rw name?               string
-           |     |  +--rw type?               identityref
-           |     |  +--rw internal-address?   inet:ip-address
-           |     |  +--rw external-address?   inet:ip-address
-           |     |  +--rw internal-port?      inet:port-number
-           |     |  +--rw external-port?      inet:port-number
+           |     |  +--rw nat-direction?      identityref
+           |     |  +--rw original
+           |     |  |  +--rw src-address?   inet:ip-address
+           |     |  |  +--rw src-port?      inet:port-number
+           |     |  |  +--rw dst-address?   inet:ip-address
+           |     |  |  +--rw dst-port?      inet:port-number
+           |     |  +--rw translated
+           |     |  |  +--rw src-address?   inet:ip-address
+           |     |  |  +--rw src-port?      inet:port-number
+           |     |  |  +--rw dst-address?   inet:ip-address
+           |     |  |  +--rw dst-port?      inet:port-number
            |     |  +--rw protocol?           protocol-type
            |     |  +--rw acl-set?            -> /oc-acl:acl/acl-sets/acl-set/config/name
            |     |  +--rw max-translations?   uint64
            |     +--ro state

Probably also worth discussing nat-type/nat-direction, and whether we are better served by an ENUM or an identityref

nleiva · 2026-05-12T14:35:11Z

Thanks @bewing for your contribution, it looks good to me.
What do you think about adding direction to the config section as well to make it consistent with the state changes? Something along the lines of:

...

Probably also worth discussing nat-type/nat-direction, and whether we are better served by an ENUM or an identityref

Yeah, something like that.

Regarding identityref, I believe it's better suited for cases where a vendor might need to augment it via an external module.

  identity NAT_TYPE {
    description
      "Base identity for NAT types.";
  }

  identity SOURCE {
    base NAT_TYPE;
    description
      "Source NAT - translates source addresses/ports of outbound
      traffic.";
  }

  identity DESTINATION {
    base NAT_TYPE;
    description
      "Destination NAT - translates destination addresses/ports
      of inbound traffic.";
  }

nat-translation-type wouldn't need extensions, it covers all potential options. On the other hand, config might not need BOTH if twice-NAT is modeled as two separate static mappings correlated by an ID.

  typedef nat-translation-type {
    type enumeration {
      enum NONE {
        description
          "No translation was performed (pass-through).";
      }
      enum SOURCE {
        description
          "Source address/port was translated (SNAT/PAT).";
      }
      enum DESTINATION {
        description
          "Destination address/port was translated (DNAT).";
      }
      enum BOTH {
        description
          "Both source and destination were translated
          (double NAT).";
      }
    }
    description
      "Which packet fields were modified by NAT in this entry.";
  }

What do you think?

Make NAT translation reporting generic

46f4349

bewing requested a review from a team as a code owner April 2, 2026 18:59

github-project-automation Bot added this to OC Operator Review Apr 2, 2026

gemini-code-assist Bot reviewed Apr 2, 2026

View reviewed changes

bewing added 2 commits April 2, 2026 14:16

Update NAT model minor version number

b2032f5

Add passthrough NAT type enum

31c7a62

dplore assigned nleiva Apr 7, 2026

OpenConfigBot added the non-breaking label Apr 7, 2026

Merge branch 'master' into feat/nat-remote-tuple

b8cc7d7

Conversation

bewing commented Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Change Scope

Platform Implementations

Tree View

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

gemini-code-assist Bot Apr 2, 2026

Choose a reason for hiding this comment

Uh oh!

bewing Apr 2, 2026

Choose a reason for hiding this comment

Uh oh!

nleiva May 12, 2026

Choose a reason for hiding this comment

Uh oh!

bewing commented Apr 2, 2026

Uh oh!

dplore commented Apr 7, 2026

Uh oh!

dplore commented Apr 7, 2026

Uh oh!

OpenConfigBot commented Apr 7, 2026

Uh oh!

nleiva commented Apr 7, 2026

Uh oh!

rolandphung commented Apr 8, 2026

Uh oh!

ElodinLaarz commented Apr 14, 2026

Uh oh!

nleiva commented Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Change Scope

Platform Implementations

Tree View

Uh oh!

bewing commented May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nleiva commented May 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

bewing commented Apr 2, 2026 •

edited

Loading

nleiva commented Apr 15, 2026 •

edited

Loading

bewing commented May 5, 2026 •

edited

Loading