Skip to content

Minutes 2016 07 27

Jump to bottom
ericvoit edited this page Jul 29, 2016 · 3 revisions
Meeting Materials Attending
WebEx Recording password: EeMSmEh6 Andy Beirman, Balasz Lengel, Ambika Prasad Tripathy, Alexander Clemm, Alberto Gonzalez Prieto, Sharon Chisholm, Eric Voit, Susan Hares, Tim Jenkins, Michael Wang, Yan Gang, Walker, Kent Watsen

Action Items

  • Next Meeting moved to Thursday

Balazs drove disussion items based on his email

Issue YP6: Dealing with on-change loss.

  • "Push updates not sent" Notification.
  • Agreement that having this kind of notification is useful.
  • Alex: when to differentiate this from “suspend” subscription should be articulated in the draft
  • We have to differentiate this from dampening period but there will not be direct interactions
  • Even without a suspend, we need to have a resynch mechanism
  • Open Issue YP6: We need to aligning on-change align a GET
  • Eric Proposal: Draft needs text to ensure that an independently initiated get which contains some or all of the subtrees of a subscription never has a push update timestamp which is (incorrectly) later that a subsequent change push timestamp. I don't think text is complete on this point yet.
  • Open issue: Handling missing/lost messages.
  • Could happen several ways
    • Loss detected by sequence-id
    • Loss from suspend-resume
    • Loss detected by "push updates not sent" message
  • Eric Proposal adding to Alex' thoughts: we should have an automatic on-change patch push after a suspend/resume. This shouldn't even be a configurable option. If info cannot be sent here, then we should send a "notifications not sent" message
  • Might be relevant for config data, but not counters. Might also be relevant for operational events (interface up/down). Therefore not all datastores or
    • Option 1: full resynch is always possible with a GET. But we must ensure YP6 is covered (Issue: this could drive too much volume, use carefully)
    • Option 2: Replay support for all patches operations from some previous time.
  • Other options? Ways of using entity tag where it is available
  • Sue: Do we want a count of number of items lost?
    • Perhaps an optional leaf for counters of on-change?
    • If we are sending both a suspend/resume and an option to patch on-change updates, then an optional counters object for number of changes by object should be able to indicate routing churn.

Issue YP1: Streams (or are they event types?)

  • Do we want to do anything with streams? Has its time come? Are dynamic filters enough? Should we call it Events?
  • Should we subscribe to Events-types? Does this accomplish effectively the same thing just using different words?
  • Independent of its name, a benefit of the overall streams concept is that it simplifies the filter definition which must be defined by the user
  • Independent of its name, a benefit of the overall streams concept is that more complex internal filtering might be allowed than can/should be expressed via the filtering language.
  • OAM Notifications should be treated differently
  • Example replay must only go to replaying device. Can we use existing flag?
  • Replay complete messages should only go to the requester of the replay to ensure that it is a private notification. There should be no need for a separate specific notification.
  • RFC-5277 implications
  • Need to ensure backwards compatibility with NETCONF event stream. This means we need to ensure many new types of YANG push events must be excluded.
  • Eric Proposal: Should we have a CASE statement for separating Stream/Event YANG objects?
  • Will need a close match of stream/events to opstate work currently underway.

On change or periodic

  • Both as optional.
  • Is it possible with YANG to enforce one of them to be populated?
  • Kent: We might need a change type to shows statistical outliers.
  • Eric: This is a type of on-change with more advanced filter types

Issue YP2: "on-change subscribable"

  • Agreement on the goal that this functionality is needed.
  • What about existing models that don't have that info?
  • Tagging is likely the best way. Are there others?
  • Not agreement at this point the only way to accomplish by an flag.
  • Failure to make shouldn't cause a melt-down
  • This should reasonable work if people forget to set this field. Don't allow a default value to break the system.
  • Need to handle on-change for advance filter types for CPU temp and power levels For example,
Clone this wiki locally