-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gNMI update with explicit deletion #201
gNMI update with explicit deletion #201
Conversation
Updated wording to clarify explicit deletion section 3.5.2.3.
Eliminated a proposed change.
Which implementations currently send deletions when in sample mode? |
@ccole-juniper the purpose of this proposed change to the wording of the specification is not to call out who currently implements what, it is to clarify wording to as to eliminate a broader spectrum of interpretations. Posting this change is also a time for the audience to weigh in on the proposed change. If there is a specific reason why you would not be in favor of supporting such change, please contribute so it can be reviewed by the group. |
Asking for current and prior art is the intention, and I'd still like to hear from other vendors and operators re: their particular implementation. From my experience with SNMP and similar frameworks I'm not familiar with the mixture of change tracking into the equivalent of sample mode. Previous and current implementations will help to inform intention when there's ambiguity. |
When would deletions be expected to be delivered: promptly on deletion ("out of sample") or at the next sample ("in sample")? If "in sample", I would expect that the notification timestamp would need to reflect the time of deletion which can significantly precede the time of the sample. |
This was reviewed in Nov 14, 2023 OC Operators meeting without objection. Added to Dec 7, 2023 OC Community meeting for broader awareness. |
Thanks Darren,
upon further review we noticed that rollback reset functionality is not
available.
Here is the review comment I left for this
#196 (review)
…On Thu, Nov 16, 2023 at 5:34 PM Darren Loher ***@***.***> wrote:
This was reviewed in Nov 14, 2023 OC Operators meeting without objection.
Added to Dec 7, 2023 OC Community meeting
<https://docs.google.com/document/d/11sXUF2zujhbPs_bt-RFJhh2DcIbEvnOpd9GypE-u3cc/edit#heading=h.1cdzya92dfta>
for broader awareness.
—
Reply to this email directly, view it on GitHub
<#201 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABLKV5MNVYCMXEJ56NKJXHLYEZFBHAVCNFSM6AAAAAA7BSXPM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJUHEYTQNRUGQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
I think this comment is misplaced? This PR (#201) is about gNMI |
pardon, replied to a wrong thread indeed, @dplore |
I posted on question on openconfig google group on what should be the expectation from a spec perspective for a delete notification. Assume here that interface is not limited to a physically present port on the router and can be a logical construct representing some L2/L3 service endpoint. |
When a node in the tree is removed, a DELETE must be sent. This includes /interfaces/interface/state. It is ok to DELETE a parent node and expect clients to recursively remove all the children nodes. See gnmi reference 3.4.6 In practice there are scenarios where physical interfaces can be persistent or ephemeral. For example, a persistent interface could be a fixed 100GE port. A configuration for an IP address could be added or removed from this interface, but the interface will still exist as An ephemeral interface could be a breakout port. Take a 400GE Ethernet which has a breakout capable transceiver inserted. When a breakout is configured, new interfaces are created, including their I would expect logical interfaces to be treated the same way as the breakout port example above. |
I had two other suggestions for notes that would be good to add here:
|
Rewording after OpenConfig Community meeting call feedback.
Changed wording for required in ON-CHANGE subscription mode and optional for SAMPLE subscription mode after OpenConfig Community meeting discussions. |
Can we clarify the behavior for TARGET_DEFINED streams? When a client makes a Subscribe request with mode TARGET_DEFINED, it doesn't know if server is going to reply with ON_CHANGE or SAMPLE (per leaf). The client then can't know if the absence of updates means some paths were implicitly deleted or that haven't been any changes. |
Good idea, we should attempt to address delete behavior when TARGET_DEFINED is used. In practice, TARGET_DEFINED behavior is expected to be "do the right thing" where rapidly changing leaf values (like counters) are sampled and infrequently changing leaves (like the state copy of config leaves) are sent ON_CHANGE. Likewise one way to define this is the DELETE behavior is also "TARGET_DEFINED". We could elaborate that a target is expected to send delete for leaves which are updated only when they change and optionally send a DELETE for leaves which are updated periodically (ie: even if they don't change). We will touch on this topic at the March 26,2024 OC Operators meeting. |
No objections were recorded regarding |
Added explicit deletion verbiage for TARGET-DEFINED.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added verbiage for TARGET-DEFINED explicit deletion.
Thanks @gwizdms . This change is set to last call for June 11, 2024 |
Added clarity for delete path discussed in gnmi repo issue 145.