Re: [Netconf] LC on subscribed-notifications-10

["Eric Voit (evoit)" <[e-mail]>]

And <Eric12>

From: Kent Watsen, June 25, 2018 4:29 PM

Please look for <Kent11> below.


<snip>






<Kent4> this I agree with, but I really don't like the fact that receiver MUST do a short-lived dynamic subscription to scoop-up any possibly-missed logs, for which there may be none.  Perhaps we could add more values into the "subscription-started" notification message that would enable to receiver to make a local determination if such a dynamic subscription would be  helpful?



<Eric5> I recommend against providing extra objects/reasons in the “subscription-started” at this time.  Publishers might not want to advertise a reboot, and they might not want to advertise why there was loss in event continuity.   All that should matter to a receiver is that such a discontinuity existed, and they have a way to try to fill event the gap should they care.  If the need for more data and the cause of the discontinuity turns out to be required, we can always augment here with future objects.



<KENT5> first, I'm still not 100% sure if this is just a reboot problem, or any time the subscription is restarted/resumed.



<Eric6> Per above: retrieving missing event records is not a reboot specific problem.  But unintentionally replicating event records is reboot specific.  (Otherwise the configured replay-start-time would drive a repeat of everything on each and every reboot.)



<Kent6> okay, I think I got it this time.  Having a *configurable* replay-start-time is so confusing.  Is it really worth having?



<Eric7>   Yes it is worth having.

(a) In many environments, reboot is very infrequent.  Without configurable start time, an operator setting up a configured subscription would not have the ability to designate what to send.  It could only send the full log (at whatever size).

(b) on-publisher security or troubleshooting diagnostics might identify a breach or some event where streaming recent historical event records is a MUST.  As a result, it might want to stream a subset of event records off a box going back in time to potential events which might have been evidence or contributing factors.



<Kent7> Let me come at this another way.  Assume we drop all support for *configurable* replay-start-time.  As such, configured subscriptions always start with the next-generated event (no replay at all).   This covers most use-cases, right?   For those receivers that really wanted the older logs, can't they just do a dynamic subscription to collect them, same as we've been discussing above?



<Eric8> Some reasons this might not always be practical:

(a) IoT devices just might want to passively listen to event streams of Telemetry.  (I.e., this would force configured receivers to support dynamic subscriptions.)

(b) This forces complexity onto applications which only ever need to track what has happened since boot.  (E.g., per above, continuous Integrity Measurement Architecture (IMA) boot log streaming and evaluation.)

(c) Publisher access permissions for who can use the establish-subscription RPC might have to be expanded to include lots of configured receivers.  This might open up a vector to control plane DDoS.  Right now the access permissions would just have to allow the receiver read access to the event records.

(d) A publisher may choose to firewall classes of receivers (or locations of receivers) into a listen-only mode without the ability to establish subscriptions.



<Kent8> This response seems to address the "can't they just do a dynamic subscription" aspect of my comment, but doesn't really address the "why is it important" (I paraphrase) part.  My contention is that the concept of a *configurable* replay-start-time seems confusing and of low value.   I acknowledge that there is some value, but it seems like the value is limited to a one-time start-up optimization that can be alternatively addressed by a dynamic subscription to fetch earlier events (assuming it's allowed, per your points b-d).   Additionally, FWIW, I've never seen such a feature implemented before, and logging mechanisms have been around for decades, so this makes me think that this is something that probably isn't worth having.



<Eric9> As you point out, the why "can't they just do a dynamic subscription" is covered, and we shouldn’t always assume away (b)-(d) as they can matter in some scenarios.  So if we want to support the use case of streaming log entries made after boot, but before the transport session is available, the only alternative I see is to have a configured replay-flag rather than a configuring a start-time.  Are you ok with a flag instead?  Or do you have an alternative suggestion?



<Kent9> see below.



In terms of using this configured replay capability, Cisco’s Integrity Verification application

https://www.cisco.com/c/dam/en/us/td/docs/cloud-systems-management/application-policy-infrastructure-controller-enterprise-module/1-5-x/integrity_verification/user-guide/Cisco_Integrity_Verification_Application_APIC-EM_User_Guide_1_5_0_x.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.cisco.com_c_dam_en_us_td_docs_cloud-2Dsystems-2Dmanagement_application-2Dpolicy-2Dinfrastructure-2Dcontroller-2Denterprise-2Dmodule_1-2D5-2Dx_integrity-5Fverification_user-2Dguide_Cisco-5FIntegrity-5FVerification-5FApplication-5FAPIC-2DEM-5FUser-5FGuide-5F1-5F5-5F0-5Fx.pdf&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=YLzifR1978kb_hHj64ZtYbrlHE2fJaofeSKu9OAFQXg&s=Vc8m5WAJJE8YkQIpZuxlnVTgAtVKQZ-n0dyoRKX3Eao&e=>

does do a shell access event log fetch of the full log after boot, and then just does incremental fetch the deltas of the log (based on log line numbers).  This application is interested in configured subscriptions subsequent to boot for this purpose.  So such incremental streaming of portions of syslog after boot seems like a typical/common need to me.



<Kent9> it might be typical/common desire, but it's still once in the lifetime of the configured subscription.  It seems like, if the device supports dynamic subscriptions, after receiving subscription-started, the client could a) pause the configured subscription, b) use a dynamic subscript to fetch the missing logs, and then c) resume the flow of logs from the configured subscriptions.



<Eric10> Your proposal still precludes (b)-(d) above.   In addition for your step a), there is no RPC or action which allows the event records from a configured (or dynamic) subscription to be paused.  The solution also adds complexity into the client to recognize that early events might be missing, to issue an establish-subscription, and then to tie the results of the independent subscriptions together.



<Kent10> pausing can be implemented by the receiver not reading any more from the TCP socket, or something else.



<Eric11> There is no mechanism for a receiver to pause a single subscription without pausing other subscriptions on the TCP session (as subscriptions typically would share a common TCP.)



<Kent11> Different "receivers" of different configured subscriptions pointing to the same underlying netconf or restconf call-home connection?



<Eric12> Yes





How is it any more complex for the client/receiver than the following in the SN draft already?



   When a receiver of a configured subscription gets a new

   "subscription-started" message for a known subscription where it is

   already consuming events, the receiver SHOULD retrieve any event

   records generated since the last event record was received.  This can

   be accomplish by establishing a separate dynamic replay subscription

   with the same filtering criteria with the publisher", assuming the

   publisher supports the "replay" feature.



<Eric11> It is the same general process.  But it turns the SHOULD into a MUST for applications which need to know the events since boot.  It also doesn’t deliver the events in order to the application, delaying application event analysis.



<Kent11> here's another question that might be good to raise to the WG level.   Please be sure to capture my general concern and also the availability of this workaround.  Thanks.



<Eric12>  You are welcome to take the question to the WG level.  I have no desire to waste people’s time with such an obvious question:

- The current solution does not add the extra complexity described above for configured subscription replay.

- The current solution supports deployment scenarios (b)-(d) above.

- The current solution has far less implementation complexity and error reconciliation states for the client.



/Eric12





Eric



/Kent11