Add `gre` container under next-hops aft entry state. Add `src-ip`, `dst-ip` and `ttl` under `gre` aft entry state for telemetry. #1038

romeyod · 2024-01-26T14:42:54Z

(M) aft/openconfig-aft-common.yang
(M) aft/openconfig-aft-ethernet.yang
(M) aft/openconfig-aft-ipv4.yang
(M) aft/openconfig-aft-ipv6.yang
(M) aft/openconfig-aft-mpls.yang
(M) aft/openconfig-aft-pf.yang
(M) aft/openconfig-aft-state-synced.yang
(M) aft/openconfig-aft.yang

Change Scope

Add gre container under next-hops aft entry state.
Add src-ip, dst-ip and ttl under gre aft entry state for telemetry.
This change is backwards compatible

Platform Implementations

Arista documentation

Relevant pyang output:

module: openconfig-network-instance
  +--rw network-instances
     +--rw network-instance* [name]
        +--ro afts
        |  +--ro next-hops
        |     +--ro next-hop* [index]
        |        +--ro index            -> ../state/index
        |        +--ro state
        |        |  +--ro index?                       uint64
        |        |  +--ro programmed-index?            uint64
        |        |  +--ro ip-address?                  oc-inet:ip-address
        |        |  +--ro mac-address?                 oc-yang:mac-address
        |        |  +--ro pop-top-label?               boolean
        |        |  +--ro pushed-mpls-label-stack*     oc-mplst:mpls-label
        |        |  +--ro encapsulate-header?          oc-aftt:encapsulation-header-type
        |        |  +--ro decapsulate-header?          oc-aftt:encapsulation-header-type
        |        |  +--ro origin-protocol?             identityref
        |        |  +--ro lsp-name?                    string
        |        |  +--ro counters
        |        |  |  +--ro packets-forwarded?   oc-yang:counter64
        |        |  |  +--ro octets-forwarded?    oc-yang:counter64
        |        |  +--ro vni-label?                   oc-evpn-types:evi-id
        |        |  +--ro tunnel-src-ip-address?       oc-inet:ip-address
        |        |  +--ro oc-aftni:network-instance?   oc-ni:network-instance-ref
        |        +--ro ip-in-ip
        |        |  +--ro state
        |        |     +--ro src-ip?   oc-inet:ip-address
        |        |     +--ro dst-ip?   oc-inet:ip-address
        |        +--ro gre
        |        |  +--ro state
        |        |     +--ro src-ip?   oc-inet:ip-address
        |        |     +--ro dst-ip?   oc-inet:ip-address
        |        |     +--ro ttl?      uint8
        |        +--ro interface-ref
        |           +--ro state
        |              +--ro interface?      -> /oc-if:interfaces/interface/name
        |              +--ro subinterface?   -> ../interface]/subinterfaces/subinterface/index

Add src-ip, dst-ip and ttl under gre aft entry state for telemetry.

OpenConfigBot · 2024-01-26T14:44:36Z

No major YANG version changes in commit 28166f8

robshakir

Added a few comments, but this LGTM.

One thing that I'll note is that we're going to end up with a few different places that src-ip and dst-ip leaves are duplicated for X-over-IP encaps. I'm not worried about that since I think its logical to think "this is GRE over IP and the dest of the IP header is X", but I just wanted to highlight this here.

This also LGTM for how it would be represented in gRIBI.

release/models/aft/openconfig-aft-common.yang

robshakir · 2024-01-26T16:30:00Z

Doesn't need to be handled in this PR -- but in reviewing this I had a thought. If we were doing MPLS over GRE then we'll specify something in the MPLS-related leaves and then subsequently in the GRE container. encapsulate-header today is a scalar leaf, so what would its value be if we were doing MPLS over GRE?

There are a few options:

make encapsulate-header just the outer-most header.
deprecate encapsulate-header and imply the headers from the specified leaves -- this one probably doesn't work because we then don't know what order they are applied in.
have containers that are specific to combinatorial encapsulations -- e.g., mpls-over-gre which has the MPLS and GRE leaves in it. This denormalises the model a bit and duplicates definitions.
have a new encapsulate-stack leaf-list which specifies the order that the encapsulations are being applied -- i.e., I can specify ["GRE", "MPLS"] which indicates that it's GRE+IPv[46] and then MPLS.

WDYT?

krishna-juniper · 2024-01-29T06:39:41Z

https://github.com/openconfig/public/blob/master/release/models/aft/openconfig-aft-common.yang#L272

Description of tunnel-src-ip-address is confusing. It can be used to populate gre tunnel src address.
can we update the description to make it specific to EVPN/VXLAN?

romeyod · 2024-01-29T15:56:28Z

Doesn't need to be handled in this PR -- but in reviewing this I had a thought. If we were doing MPLS over GRE then we'll specify something in the MPLS-related leaves and then subsequently in the GRE container. encapsulate-header today is a scalar leaf, so what would its value be if we were doing MPLS over GRE?

There are a few options:

make encapsulate-header just the outer-most header.

deprecate encapsulate-header and imply the headers from the specified leaves -- this one probably doesn't work because we then don't know what order they are applied in.

have containers that are specific to combinatorial encapsulations -- e.g., mpls-over-gre which has the MPLS and GRE leaves in it. This denormalises the model a bit and duplicates definitions.

have a new encapsulate-stack leaf-list which specifies the order that the encapsulations are being applied -- i.e., I can specify ["GRE", "MPLS"] which indicates that it's GRE+IPv[46] and then MPLS.

WDYT?

IMHO a new encapsulate-stack leaf-list seems like the best path forward at first glance.

romeyod · 2024-01-29T15:58:07Z

https://github.com/openconfig/public/blob/master/release/models/aft/openconfig-aft-common.yang#L272

Description of tunnel-src-ip-address is confusing. It can be used to populate gre tunnel src address. can we update the description to make it specific to EVPN/VXLAN?

Makes sense to update the documentation. Not sure if we should couple that with this PR. Maybe file a issue and @robshakir and company to start a separate discussion.

wenovus · 2024-02-05T17:47:58Z

Merging into main branch for pyangbind check fix.

robshakir · 2024-02-05T21:35:15Z

w.r.t

https://github.com/openconfig/public/blob/master/release/models/aft/openconfig-aft-common.yang#L272
Description of tunnel-src-ip-address is confusing. It can be used to populate gre tunnel src address. can we update the description to make it specific to EVPN/VXLAN?

Makes sense to update the documentation. Not sure if we should couple that with this PR. Maybe file a issue and @robshakir and company to start a separate discussion.

let's continue this discussion here: #1040

dplore · 2024-03-07T22:56:54Z

/gcbrun

dplore · 2024-03-07T22:59:24Z

/gcbrun

dplore · 2024-03-07T23:48:53Z

Doesn't need to be handled in this PR -- but in reviewing this I had a thought. If we were doing MPLS over GRE then we'll specify something in the MPLS-related leaves and then subsequently in the GRE container. encapsulate-header today is a scalar leaf, so what would its value be if we were doing MPLS over GRE?
There are a few options:

make encapsulate-header just the outer-most header.

deprecate encapsulate-header and imply the headers from the specified leaves -- this one probably doesn't work because we then don't know what order they are applied in.

have containers that are specific to combinatorial encapsulations -- e.g., mpls-over-gre which has the MPLS and GRE leaves in it. This denormalises the model a bit and duplicates definitions.

have a new encapsulate-stack leaf-list which specifies the order that the encapsulations are being applied -- i.e., I can specify ["GRE", "MPLS"] which indicates that it's GRE+IPv[46] and then MPLS.

WDYT?

IMHO a new encapsulate-stack leaf-list seems like the best path forward at first glance.

Agreed, ideally we have some option that allows exposing any number of nested encapsulations. I like this option because it keeps the afts table flat.

Do you mind refactoring this PR to implement leaf-list for the list of encaps? Something like:

module: openconfig-network-instance
  +--rw network-instances
     +--rw network-instance* [name]
        +--ro afts
        |  +--ro next-hops
        |     +--ro next-hop* [index]
        |        x--ro ip-in-ip     (deprecated)
        |        |  x--ro state     (deprecated)
        |        |     x--ro src-ip?   oc-inet:ip-address  (deprecated)
        |        |     x--ro dst-ip?   oc-inet:ip-address  (deprecated)
        |        +--ro encapsulate
        |        |  +--ro state
        |        |     +--ro stack*?   oc-types:encap-types   
        |        |     +--ro src-ip?   oc-inet:ip-address
        |        |     +--ro dst-ip?   oc-inet:ip-address
        |        |     +--ro ttl?      uint8
        |        +--ro interface-ref
        |           +--ro state
        |              +--ro interface?      -> /oc-if:interfaces/interface/name
        |              +--ro subinterface?   -> ../interface]/subinterfaces/subinterface/index**

romeyod · 2024-03-08T14:22:08Z

Doesn't need to be handled in this PR -- but in reviewing this I had a thought. If we were doing MPLS over GRE then we'll specify something in the MPLS-related leaves and then subsequently in the GRE container. encapsulate-header today is a scalar leaf, so what would its value be if we were doing MPLS over GRE?
There are a few options:

make encapsulate-header just the outer-most header.

deprecate encapsulate-header and imply the headers from the specified leaves -- this one probably doesn't work because we then don't know what order they are applied in.

have containers that are specific to combinatorial encapsulations -- e.g., mpls-over-gre which has the MPLS and GRE leaves in it. This denormalises the model a bit and duplicates definitions.

have a new encapsulate-stack leaf-list which specifies the order that the encapsulations are being applied -- i.e., I can specify ["GRE", "MPLS"] which indicates that it's GRE+IPv[46] and then MPLS.

WDYT?

IMHO a new encapsulate-stack leaf-list seems like the best path forward at first glance.

Agreed, ideally we have some option that allows exposing any number of nested encapsulations. I like this option because it keeps the afts table flat.

Do you mind refactoring this PR to implement leaf-list for the list of encaps? Something like:
module: openconfig-network-instance
  +--rw network-instances
     +--rw network-instance* [name]
        +--ro afts
        |  +--ro next-hops
        |     +--ro next-hop* [index]
        |        x--ro ip-in-ip     (deprecated)
        |        |  x--ro state     (deprecated)
        |        |     x--ro src-ip?   oc-inet:ip-address  (deprecated)
        |        |     x--ro dst-ip?   oc-inet:ip-address  (deprecated)
        |        +--ro encapsulate
        |        |  +--ro state
        |        |     +--ro stack*?   oc-types:encap-types   
        |        |     +--ro src-ip?   oc-inet:ip-address
        |        |     +--ro dst-ip?   oc-inet:ip-address
        |        |     +--ro ttl?      uint8
        |        +--ro interface-ref
        |           +--ro state
        |              +--ro interface?      -> /oc-if:interfaces/interface/name
        |              +--ro subinterface?   -> ../interface]/subinterfaces/subinterface/index**

This will need to a LIST of the entire encap header state since src-ip, dst-ip, ttl, tos (in the future) could be part unique per encap, right? Something like:

|        +--ro encapsulate
|        |  +--ro state
|        |     +--ro stack*?   oc-types:encap-header  
|        |      |     +--ro encap?   oc-types:encap-type
|        |      |     +--ro src-ip?   oc-inet:ip-address
|        |      |     +--ro dst-ip?   oc-inet:ip-address
|        |      |     +--ro ttl?         uint8
|        |      |     +--ro tos?       uint8

@robshakir @dplore let me know your thoughts on this.

Not sure if we can make each of the "encap-header" definition different per encap type i.e. aft-common-entry-nexthop-gre-state aft-common-entry-nexthop-ip-in-ip-state etc and they are still be part of "encap-header" List. This will make the documentation per "encap-header" definition easier as well.

romeyod · 2024-04-19T13:24:34Z

Doesn't need to be handled in this PR -- but in reviewing this I had a thought. If we were doing MPLS over GRE then we'll specify something in the MPLS-related leaves and then subsequently in the GRE container. encapsulate-header today is a scalar leaf, so what would its value be if we were doing MPLS over GRE?
There are a few options:

make encapsulate-header just the outer-most header.

deprecate encapsulate-header and imply the headers from the specified leaves -- this one probably doesn't work because we then don't know what order they are applied in.

have containers that are specific to combinatorial encapsulations -- e.g., mpls-over-gre which has the MPLS and GRE leaves in it. This denormalises the model a bit and duplicates definitions.

have a new encapsulate-stack leaf-list which specifies the order that the encapsulations are being applied -- i.e., I can specify ["GRE", "MPLS"] which indicates that it's GRE+IPv[46] and then MPLS.

WDYT?

IMHO a new encapsulate-stack leaf-list seems like the best path forward at first glance.

Agreed, ideally we have some option that allows exposing any number of nested encapsulations. I like this option because it keeps the afts table flat.
Do you mind refactoring this PR to implement leaf-list for the list of encaps? Something like:
module: openconfig-network-instance
  +--rw network-instances
     +--rw network-instance* [name]
        +--ro afts
        |  +--ro next-hops
        |     +--ro next-hop* [index]
        |        x--ro ip-in-ip     (deprecated)
        |        |  x--ro state     (deprecated)
        |        |     x--ro src-ip?   oc-inet:ip-address  (deprecated)
        |        |     x--ro dst-ip?   oc-inet:ip-address  (deprecated)
        |        +--ro encapsulate
        |        |  +--ro state
        |        |     +--ro stack*?   oc-types:encap-types   
        |        |     +--ro src-ip?   oc-inet:ip-address
        |        |     +--ro dst-ip?   oc-inet:ip-address
        |        |     +--ro ttl?      uint8
        |        +--ro interface-ref
        |           +--ro state
        |              +--ro interface?      -> /oc-if:interfaces/interface/name
        |              +--ro subinterface?   -> ../interface]/subinterfaces/subinterface/index**
This will need to a LIST of the entire encap header state since src-ip, dst-ip, ttl, tos (in the future) could be part unique per encap, right? Something like:
|        +--ro encapsulate
|        |  +--ro state
|        |     +--ro stack*?   oc-types:encap-header  
|        |      |     +--ro encap?   oc-types:encap-type
|        |      |     +--ro src-ip?   oc-inet:ip-address
|        |      |     +--ro dst-ip?   oc-inet:ip-address
|        |      |     +--ro ttl?         uint8
|        |      |     +--ro tos?       uint8
@robshakir @dplore let me know your thoughts on this.

Not sure if we can make each of the "encap-header" definition different per encap type i.e. aft-common-entry-nexthop-gre-state aft-common-entry-nexthop-ip-in-ip-state etc and they are still be part of "encap-header" List. This will make the documentation per "encap-header" definition easier as well.

So we need to have a leaf-list of encap-headers that has a typedef/container with all the fields per encapsulation like src-ip, dst-ip, ttl and tos as well as the encapsulation header type. This way will be more future safe and we can support any encapsulation combination including theoretically GRE over GRE and more.

dplore · 2024-04-20T00:54:57Z

How about defining containers for each encap with it's own set of custom state leaves? Since encaps can be quite different, I am not sure it is feasible to have a list of encaps, but rather models containers for each encap with typed leaves.

  +--rw network-instances
     +--rw network-instance* [name]
        +--ro afts
        |  +--ro next-hops
        |     +--ro next-hop* [index]
        |        +--ro ip-in-ip   
        |        |  +--ro state   
        |        |     +--ro <state leafs added here>
        |        +--ro <my other encap container>
        |        |  +--ro state   
        |        |     +--ro <my other encap state leafs added here>

romeyod · 2024-04-23T19:17:56Z

How about defining containers for each encap with it's own set of custom state leaves? Since encaps can be quite different, I am not sure it is feasible to have a list of encaps, but rather models containers for each encap with typed leaves.
  +--rw network-instances
     +--rw network-instance* [name]
        +--ro afts
        |  +--ro next-hops
        |     +--ro next-hop* [index]
        |        +--ro ip-in-ip   
        |        |  +--ro state   
        |        |     +--ro <state leafs added here>
        |        +--ro <my other encap container>
        |        |  +--ro state   
        |        |     +--ro <my other encap state leafs added here>

@dplore Maybe I am being a bit dense here. Can you please simplify your suggestion for me?

The original intent of the PR was to add gre container under next-hops aft entry state. Add src-ip, dst-ip and ttl under gre aft entry state for telemetry. This was being achieved by using uses but is there a different way to typed leaves each of them?

The only reason the List/stack on encap can into the discussion was as a suggestion/food for thought by @robshakir and we were planning to take it up later.

I know this PR has dragged on for a while so I am just TLDRing it for any other reader/party that comes across it :)

dplore · 2024-04-24T21:00:43Z

https://github.com/openconfig/public/blob/master/release/models/aft/openconfig-aft-common.yang#L272
Description of tunnel-src-ip-address is confusing. It can be used to populate gre tunnel src address. can we update the description to make it specific to EVPN/VXLAN?

Makes sense to update the documentation. Not sure if we should couple that with this PR. Maybe file a issue and @robshakir and company to start a separate discussion.

Please add this description change. It should be in this PR because this PR introduces a src-ip leaf which could be confused with the existing tunnel-src-ip-address. Clarifying that tunnel-src-ip-address is not used for gre in the formal description is good. This will cause the git history to also point to this PR for context.

dplore · 2024-04-24T21:03:05Z

How about defining containers for each encap with it's own set of custom state leaves? Since encaps can be quite different, I am not sure it is feasible to have a list of encaps, but rather models containers for each encap with typed leaves.
  +--rw network-instances
     +--rw network-instance* [name]
        +--ro afts
        |  +--ro next-hops
        |     +--ro next-hop* [index]
        |        +--ro ip-in-ip   
        |        |  +--ro state   
        |        |     +--ro <state leafs added here>
        |        +--ro <my other encap container>
        |        |  +--ro state   
        |        |     +--ro <my other encap state leafs added here>
@dplore Maybe I am being a bit dense here. Can you please simplify your suggestion for me?

The original intent of the PR was to add gre container under next-hops aft entry state. Add src-ip, dst-ip and ttl under gre aft entry state for telemetry. This was being achieved by using uses but is there a different way to typed leaves each of them?

The only reason the List/stack on encap can into the discussion was as a suggestion/food for thought by @robshakir and we were planning to take it up later.

I know this PR has dragged on for a while so I am just TLDRing it for any other reader/party that comes across it :)

Ah yes, let's consider this comment thread out of scope for this PR. The current PR scope for GRE only is ok as is and does not need to consider refactoring how any/all tunnel encapsulations are modeled in OC.

dplore

Please add a description change for tunnel-src-ip-address as per the issue:

https://github.com/openconfig/public/blob/master/release/models/aft/openconfig-aft-common.yang#L272

I think it is appropriate for this description change to be in this PR because this PR introduces a new src-ip leaf which could be confused with the existing tunnel-src-ip-address. Clarifying that tunnel-src-ip-address is only used for vxlan in the formal description is good.

The git history will point to this PR and our mention of #1040 for additional context.

Other than this, LGTM. This will be reviewed at the Apr 30, 2024 OC Operators meeting

romeyod · 2024-04-25T18:59:20Z

Please add a description change for tunnel-src-ip-address as per the issue:

https://github.com/openconfig/public/blob/master/release/models/aft/openconfig-aft-common.yang#L272

I think it is appropriate for this description change to be in this PR because this PR introduces a new src-ip leaf which could be confused with the existing tunnel-src-ip-address. Clarifying that tunnel-src-ip-address is only used for vxlan in the formal description is good.

The git history will point to this PR and our mention of #1040 for additional context.

Other than this, LGTM. This will be reviewed at the Apr 30, 2024 OC Operators meeting

Thansk @dplore. I have updated the PR with the requested changes. Let me know if any other action is needed.

dplore · 2024-04-25T19:21:29Z

/gcbrun

dplore

One more comment on the description for src-ip and I think it's ready to review at the April 30th OC operators meeting.

release/models/aft/openconfig-aft-common.yang

Co-authored-by: Darren Loher <[email protected]>

romeyod · 2024-04-25T21:19:35Z

One more comment on the description for src-ip and I think it's ready to review at the April 30th OC operators meeting.

Thanks @dplore
Committed the suggestion. I am assuming the Changes requested blocking item will be resolved after the OC operators meeting

dplore · 2024-04-25T22:01:29Z

/gcbrun

dplore

Thanks, I don't see any additional changes needed. This is ready to merge, pending Apr 30, 2024 OC Operators review.

dplore · 2024-04-30T16:08:51Z

Reviewed in Apr 30 OC operators meeting without objection.

Add gre container under next-hops aft entry state.

43fa12f

Add src-ip, dst-ip and ttl under gre aft entry state for telemetry.

romeyod requested a review from a team as a code owner January 26, 2024 14:42

OpenConfigBot added the non-breaking label Jan 26, 2024

robshakir reviewed Jan 26, 2024

View reviewed changes

dplore assigned robshakir Jan 29, 2024

krishna-juniper mentioned this pull request Jan 30, 2024

update the description of tunnel-src-ip-address leaf in openconfig-aft-common.yang file #1040

Closed

romeyod and others added 3 commits January 31, 2024 06:57

addressed review feedback

b2e6809

Merge branch 'master' into nhg-Name

b88f903

Merge branch 'master' into nhg-Name

bb525e9

romeyod added 3 commits February 14, 2024 15:14

Merge branch 'master' into nhg-Name

4a0ac71

Merge branch 'master' into nhg-Name

1fdbdc9

Merge branch 'master' into nhg-Name

0ffca4f

Merge branch 'master' into nhg-Name

41fa5c7

dplore linked an issue Mar 8, 2024 that may be closed by this pull request

update the description of tunnel-src-ip-address leaf in openconfig-aft-common.yang file #1040

Closed

dplore self-assigned this Mar 8, 2024

dplore requested changes Apr 24, 2024

View reviewed changes

romeyod and others added 2 commits April 25, 2024 14:29

Merge branch 'master' into nhg-Name

770c9b7

Addressed review comments

7b8b12d

dplore reviewed Apr 25, 2024

View reviewed changes

release/models/aft/openconfig-aft-common.yang Outdated Show resolved Hide resolved

Update release/models/aft/openconfig-aft-common.yang

e952946

Co-authored-by: Darren Loher <[email protected]>

Update openconfig-aft-common.yang: remove whitespace

28166f8

dplore approved these changes Apr 25, 2024

View reviewed changes

dplore merged commit e519064 into openconfig:master Apr 30, 2024
14 checks passed

akalluru1 mentioned this pull request Aug 27, 2024

Add aft encapsulation-headers #1153

Merged

dplore mentioned this pull request Sep 25, 2024

Add gRIBI support for OC AFT model 2.7.0 openconfig/gribi#93

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add `gre` container under next-hops aft entry state. Add `src-ip`, `dst-ip` and `ttl` under `gre` aft entry state for telemetry. #1038

Add `gre` container under next-hops aft entry state. Add `src-ip`, `dst-ip` and `ttl` under `gre` aft entry state for telemetry. #1038

romeyod commented Jan 26, 2024 •

edited

Loading

OpenConfigBot commented Jan 26, 2024 •

edited

Loading

robshakir left a comment

robshakir commented Jan 26, 2024

krishna-juniper commented Jan 29, 2024

romeyod commented Jan 29, 2024

romeyod commented Jan 29, 2024

wenovus commented Feb 5, 2024

robshakir commented Feb 5, 2024

dplore commented Mar 7, 2024

dplore commented Mar 7, 2024

dplore commented Mar 7, 2024 •

edited

Loading

romeyod commented Mar 8, 2024

romeyod commented Apr 19, 2024

dplore commented Apr 20, 2024

romeyod commented Apr 23, 2024

dplore commented Apr 24, 2024

dplore commented Apr 24, 2024

dplore left a comment

romeyod commented Apr 25, 2024

dplore commented Apr 25, 2024

dplore left a comment

romeyod commented Apr 25, 2024

dplore commented Apr 25, 2024

dplore left a comment •

edited

Loading

dplore commented Apr 30, 2024

Add gre container under next-hops aft entry state. Add src-ip, dst-ip and ttl under gre aft entry state for telemetry. #1038

Add gre container under next-hops aft entry state. Add src-ip, dst-ip and ttl under gre aft entry state for telemetry. #1038

Conversation

romeyod commented Jan 26, 2024 • edited Loading

OpenConfigBot commented Jan 26, 2024 • edited Loading

robshakir left a comment

Choose a reason for hiding this comment

robshakir commented Jan 26, 2024

krishna-juniper commented Jan 29, 2024

romeyod commented Jan 29, 2024

romeyod commented Jan 29, 2024

wenovus commented Feb 5, 2024

robshakir commented Feb 5, 2024

dplore commented Mar 7, 2024

dplore commented Mar 7, 2024

dplore commented Mar 7, 2024 • edited Loading

romeyod commented Mar 8, 2024

romeyod commented Apr 19, 2024

dplore commented Apr 20, 2024

romeyod commented Apr 23, 2024

dplore commented Apr 24, 2024

dplore commented Apr 24, 2024

dplore left a comment

Choose a reason for hiding this comment

romeyod commented Apr 25, 2024

dplore commented Apr 25, 2024

dplore left a comment

Choose a reason for hiding this comment

romeyod commented Apr 25, 2024

dplore commented Apr 25, 2024

dplore left a comment • edited Loading

Choose a reason for hiding this comment

dplore commented Apr 30, 2024

Add `gre` container under next-hops aft entry state. Add `src-ip`, `dst-ip` and `ttl` under `gre` aft entry state for telemetry. #1038

Add `gre` container under next-hops aft entry state. Add `src-ip`, `dst-ip` and `ttl` under `gre` aft entry state for telemetry. #1038

romeyod commented Jan 26, 2024 •

edited

Loading

OpenConfigBot commented Jan 26, 2024 •

edited

Loading

dplore commented Mar 7, 2024 •

edited

Loading

dplore left a comment •

edited

Loading