Skip to content

Minutes 2016 10 26

Jump to bottom
ericvoit edited this page Oct 26, 2016 · 4 revisions
Meeting Materials Attending
WebEx Recording password: qAb6KumY Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard, Eric Voit, Tim Jenkins, Balazs Lengyel, Kent Watsen, Ambika Tripathy

Modifications to Latest 5277bis

  • Alex, Eric, Alberto have updated model and draft. Look for latest shortly posted to IETF
  • Two YANG models have converged into one. However 5277 namespace compatibility will result in the model split back into two.
  • Definitions updated throughout from 5277 for Publisher (from Event Server) and Subscriber (from Client)
  • Text simplifications/reductions
  • Discussed on the call to still be mixed into the text. (upcoming update will include)
  • Notifications: Remove added-to-subscription, and removed-from-subscription notifications.
  • Dynamic Subscriptions: don't allow modification to streams or encoding for modify-subscription RPC.

Filters and Streams

  • Reviewed Andy's proposal for a new filter type based on hierarchical event type metadata
  • Seems like a good idea. The hard part will be defining the event hierarchy. That will play out in the IETF somewhat decoupled from subscriptions as it could be used for GET filter as well.
  • Need for a new Draft including Metadata filtering
  • There is not an existing YANG filter for Metadata. Nor is there a filter for metadata + subtree filtering. This needs to be solved for GET operations (i.e., this is not just about subscriptions).
  • For populating the metadata: Subtrees will inherit the event-types of their parents, unless otherwise indicated via a deviations file.
  • For metadata filters, there needs to be some mechanism that the on-change notification for metadata pushed data in the sequential order of operations on a device. For example, you want to push object metadata changes for before you see the same object's corresponding changes for datastore.
  • Open question on filters: Are the capabilities in a filter type allowed to be mixed/matched to make a more complex union or intersection filter within a subscription?
  • Eric recommendation: We don't allow application of multiple filters concurrently. Building a filter syntax for unions and intersections across filter types is interesting, but hard. Problematically it puts us in the business where we have to define what is possible (or not) via the combination of any two filter types. It would be simpler to leave the valid combinations of filter capabilities to any particular normative reference.
  • We should advocate for a new IETF draft (above) which defines this.
  • Streams
  • Streams are optional, and will include NETCONF and custom-stream entries. We will not try to standardize any new IETF streams at this point.
  • Metadata would allow filtering on OpState info (upcoming draft from the datastore design team). This would accomplish the same business objectives as what we were talking about previously with IETF standardized streams. Anyone who wants to meet those objectives prior to having a filter on OpState metadata can define their own custom-stream.

Partial/incremental push of periodic data

  • Einar believes real world examples necessitate that a Publisher be able to partition and sequence the push updates.
    • This means no need to aggregate a single push from different linecards
    • Then able to load balance pushed for different objects with a different push timestamp.
  • Belief that Anchor-time is not the right object to use for determining whether partial push updates are acceptable to be sent. Instead a new periodic type subscription object should be created. Perhaps "partial-push-accepted"?
  • Proposal to be brought to mailing list (by Einar?) as people are worried about the extra complexity this will introduce. Topics to address include:
    • A push update for a subscription with the partial-push-accepted flag = yes is not assumed to be a complete representation of the datastore, it just contains that set of objects/values at that particular time of a push update.
    • Integrity across the datastore extract cannot be assumed.
    • Can be used during negotiation if an internally consistent set of objects should not be assumed by the receiver.
    • Push updates are accumulated across a known period established across a subscription, with the last value received being current. Object which is older than the period is assumed to be stale or deleted.
    • Establish proper meaning of updates-not-sent flag.
Clone this wiki locally