Skip to content

Minutes 2016 09 14

Jump to bottom
ericvoit edited this page Sep 20, 2016 · 2 revisions
Meeting Materials Attending
WebEx Recording password: JgFMHvr5 Alexander Clemm, Alberto Gonzalez Prieto, Eric Voit, Susan Hares, Tim Jenkins, Balazs Lengyel, Walker, Kent Watsen, Einar Nilsen-Nygaard

(This update includes both meeting minutes and some follow-on items that have happened subsequent to the meeting. These will be highlighted)

All WG drafts are now posted

RFC5277bis

  • First WG version of RFC5277bis posted, and now reflected on web site
  • Changes which have been made are reflected in the resolved issues list. These include: Stream discovery, no default transport, etc.
  • Editorial changes to remove duplication with YANG Push draft

Restconf/HTTP transport call flow discussions

Below new call flows and their Rationale are discussed...

  • Common across call flows

  • No requirement for a "200 OK" to be returned for each push update

    • Andy's point about slowing things down should be covered

  • subscription-modified notifications follow the push update data path so that you know exactly when the notification is effective. This ensures you know where in the push update stream a change to subscribed objects occurs

  • Subscription started, suspended, resumed, and terminate notifications are messages will go on a different stream for reasons of:

    • separation and prioritization of control plane notifications
    • option of allowing an independent stream to be used for each HTTP2 transaction.

  • HTTP2 Configured Call Flow

  • Should be compliant with GRPC interaction model driven by POST (would love a double-check on this)

  • No need for Restconf at all, HTTP2 GOAWAY on stream lost will tear down subscription and force re-establishment

  • Restconf / HTTP2.0 Dynamic Call Flow
  • POST selected for data path establishment for GRPC commonality
  • Simplest mode is for each establish-subscription to drive a new subscription to its own stream
  • It is possible to bundle many subscriptions to the same stream, but this efficiency is only needed if there are a lot of small subscriptions with updates a fraction of the size of the header. We shouldn't preclude the possibility, but this doesn't look to be a best-practice.

  • Restconf / HTTP1.1 Dynamic Call Flow
  • Kent asked for an HTTP 1.1 call flow during the call.
  • After the call, Eric has come up with a call flow which should be fully compliant with Restconf
  • Different TCP is used for control messages and push updates
    • Only on the first subscription is a new TCP established, and a POST message sent. After that is set up, subsequent subscriptions use the existing path for push updates
    • Possible but not necessary to tear down the TCP should all subscriptions gracefully end.
  • should be compliant with Restconf SSE definitions

  • HTTP Configured
  • No desire for a HTTP1.1 configured subscription specification
Clone this wiki locally