Re: [Netconf] a joint discussion on dynamic subscription

[Martin Bjorklund <[e-mail]>]

"Eric Voit (evoit)" <[e-mail]> wrote:
> > From: Martin Bjorklund, June 14, 2018 1:18 PM
> > 
> > "Eric Voit (evoit)" <[e-mail]> wrote:
> > > > From: Martin Bjorklund, June 14, 2018 11:34 AM
> > > >
> > > > "Eric Voit (evoit)" <[e-mail]> wrote:
> > > > > > From: Martin Bjorklund, June 14, 2018 4:38 AM
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Another thing related to this.   You have:
> > > > > >
> > > > > >    Receiver: A target to which a publisher pushes subscribed event
> > > > > >    records.  For dynamic subscriptions, the receiver and subscriber are
> > > > > >    the same entity.
> > > > > >
> > > > > > But in the HTTP and UDP cases this last sentence is probably not
> > > > > > true, right?
> > > > > >
> > > > > > Also, I have always struggled with the terms "publisher",
> > > > > > "receiver", "subscriber" vs. "client" and "server".
> > > > > >
> > > > > > I think that a "subscriber" is always the "client".  If so, I
> > > > > > think this should be mentioned in 1.2 (and the term "client"
> > > > > > imported from RFC 8342).
> > > > >
> > > > > The subscriber need not always the transport client.  This is
> > > > > dependent on the transport selected.  For example in the RESTCONF
> > > > > draft for configured subscriptions, the HTTP client is the
> > > > > Publisher, and the HTTP server is the receiver.  See section 4.2 &
> > > > > Figure 3 of draft-ietf-netconf-restconf-notif.
> > > >
> > > > How does this change the fact that the subscriber is the client (RFC
> > > > 8342 term)?
> > >
> > > On that point, I was just trying to limit the use of the word
> > > "client", as it has so many meanings already.
> > >
> > > Beyond the many meanings of client, there is another reason why a
> > > subscriber isn't necessarily an RFC8342 client.  The RFC8342
> > > definition of client is based on YANG data.  As event streams might
> > > not be YANG data, this definition isn't a full match for what is
> > > covered by subscribed-notifications.
> > 
> > Your definition is:
> > 
> >    Subscriber: An entity able to request and negotiate a contract for
> >    the generation and push of event records from a publisher.
> > 
> > How can this NOT be a client, in the 8342 meaning?  AFAICT, the
> > subscriber can 
> > either set up a dynamic subscription, using establish-subscription.  This is
> > certainly a "client".  Or it can set up a configured subscription,
> > by creating 
> > configuration in the /subscriptions/subscription list.  This is
> > also a "client". 
> 
> In RFC-8341, the term client is defined as:
> 
>    o  client: An entity that can access YANG-defined data on a server,
>       over some network management protocol.
> 
> As an event stream might not include YANG-defined data, the
> definition didn't seem to fit.

But the subscriber doesn't even see content from any event stream, so
how does this matter?  An entity that sends the RPC
"establish-subscription" *is* a "client".

> If we wanted to import the term RFC8342 term client, we could do in
> YANG-push.  There we could say that a subscriber to a YANG datastore
> is covered by the RFC-8342 definition of client.
> 
> Would this cover your concern?

No, see above.


/martin



> 
> Eric
> 
> 
> > I do understand that the *receiver* may not be a client.
> > 
> > 
> > /martin
> > 
> > 
> > 
> > (However it would be a match
> > > for a YANG-Push subscriber.)
> > >
> > > Eric
> > >
> > > > > For draft-ietf-netconf-udp-pub-channel draft, I can see the
> > > > > possibility of transport client session being initiated from the
> > > > > line cards.
> > > >
> > > > Right, that's why I assumed there is a separation between server and
> > publisher.
> > > > "server" again in RFC 8342 terms.  It is the server for
> > > > establish-subscription or the server where configured subscriptions are
> > managed.
> > > >
> > > >
> > > > /martin
> > > >
> > > >
> > > > >
> > > > > Eric
> > > > >
> > > > > > Also, I think it would be useful to draw a picture that
> > > > > > demonstrates the roles:
> > > > > >
> > > > > >       subscriber/client    receiver
> > > > > >           |                   ^
> > > > > >           | (1)               | (3)
> > > > > >           |                   |
> > > > > >           |                   |
> > > > > >           v        (2)        |
> > > > > >         server  ----------> publisher
> > > > > >
> > > > > >
> > > > > > (1) is creation of the subscriptionE; dynamic or configured
> > > > > > (2) is implementation specific
> > > > > > (3) is the delivery of notifications / event records
> > > > > >
> > > > > > NOTE: the subscriber and receiver MAY be the same entity
> > > > > > NOTE: for some transports, if (1) is dynamic, (3) is sent over the
> > > > > >       same session as (1)
> > > > > > NOTE: for some transports, the sevrer and publisher are the same
> > > > > > entity
> > > > > >
> > > > > >
> > > > > > If we can agree on an architectural picture like this, the
> > > > > > different transport docs can refer to this architecture and be defined
> > related
> > > > > > to it.   For example, the netconf transport doc can state that the
> > > > > > publisher is always the same entity etc.
> > > > > >
> > > > > >
> > > > > >
> > > > > > /martin
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Martin Bjorklund <[e-mail]> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > "Eric Voit (evoit)" <[e-mail]> wrote:
> > > > > > > > Hi Tianran,
> > > > > > > >
> > > > > > > > > From: Tianran Zhou, June 12, 2018 11:47 PM
> > > > > > > > >
> > > > > > > > > Hi Eric,
> > > > > > > > >
> > > > > > > > > When we are discussing the
> > > > > > > > > draft-ietf-netconf-udp-pub-channel,
> > > > > > > > > we find a conflict with current dynamic subscription design.
> > > > > > > > > 1. The dynamic subscription requires notification to use
> > > > > > > > > the same channel as the subscription.
> > > > > > > >
> > > > > > > > This is true when you look at the NETCONF transport draft.
> > > > > > > > However this is *not* required by the base
> > > > > > > > subscribed-notification
> > > > draft.
> > > > > > > > And in fact, the HTTP transport draft might not use the same
> > > > > > > > logical channel.  E.g., see how the URI is returned within:
> > > > > > > > https://github.com/netconf-wg/notif-restconf/blob/master/dra
> > > > > > > > ft-i
> > > > > > > > etf-
> > > > > > > > netconf-restconf-notif-05.txt
> > > > > > > >
> > > > > > > > So if you wanted to define some transport session
> > > > > > > > independence for a UDP transport, subscribed-notifications
> > > > > > > > should permit that.  And if you believe there is something
> > > > > > > > in the text which prohibits this, let me know.
> > > > > > >
> > > > > > > Cool!  I think that this should be explcitly described in the
> > > > > > > subscribed-notifications document.
> > > > > > >
> > > > > > > In the case of RESTCONF, decision to use a separate channel
> > > > > > > for the notifs is implicit in the transport of the request to
> > > > > > > establish-subscription.
> > > > > > >
> > > > > > > In the case of UDP, I think the idea is that the
> > > > > > > establish-subscription is sent over any protocol that can do
> > > > > > > RPCs (NETCONF, RESTCONF, ...), but then some specific input
> > > > > > > parameter informs the server that the notifs are supposed to
> > > > > > > be sent over some other transport.
> > > > > > >
> > > > > > > While reading the text about sessions, I found this:
> > > > > > >
> > > > > > > In 2.4.3:
> > > > > > >
> > > > > > >    The "modify-subscription" operation permits changing the terms of
> > an
> > > > > > >    existing dynamic subscription established on that transport session
> > > > > > >    via "establish-subscription".
> > > > > > >
> > > > > > > Which session does "that transport session" mean?  Perhaps simply:
> > > > > > >
> > > > > > > NEW:
> > > > > > >
> > > > > > >    The "modify-subscription" operation permits changing the terms of
> > an
> > > > > > >    existing dynamic subscription.
> > > > > > >
> > > > > > >
> > > > > > > > > 2. The RPC does not have the input information about the
> > > > > > > > > receiver because the above assumption.
> > > > > > > > >
> > > > > > > > > However, when we talk about the distributed data
> > > > > > > > > collection (multi data originators), the publication
> > > > > > > > > channel is always different from the subscription channel.
> > > > > > > >
> > > > > > > > While it likely isn't what you want, even with NETCONF, the
> > > > > > > > single NETCONF session doesn't means that distributed line
> > > > > > > > card generation of the notification messages is impossible.
> > > > > > > > For example, the inclusion of the header object
> > > > > > > > message-generator-id (as defined within
> > > > > > > > draft-ietf-netconf-notification-messages) allows the
> > > > > > > > notification message generation to be distributed onto
> > > > > > > > linecards even if the messages themselves are still driven
> > > > > > > > back to a central transport session.  Note that I am not
> > > > > > > > recommending this, but the specifications would support this.
> > > > > > > >
> > > > > > > > > So either the distributed data collection does not support
> > > > > > > > > dynamic subscription, or current dynamic subscription
> > > > > > > > > definition may need modification.
> > > > > > > >
> > > > > > > > I think for UDP, you will want to define a way to bind the
> > > > > > > > lifecycle of the dynamic subscription's channels across
> > > > > > > > multiple line
> > > > cards.
> > > > > > > > This will require some thinking as well as coordination
> > > > > > > > within the publisher.
> > > > > > >
> > > > > > > But this is an implementation detail.  However, it is true
> > > > > > > that the specification must work out the fate-sharing details
> > > > > > > between the session that sent the establish-subscription and the notif
> > channel.
> > > > > > > Just as in the "restconf" draft.
> > > > > > >
> > > > > > >
> > > > > > > /martin
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > Perhaps returning multiple URIs (one for each linecard)
> > > > > > > > might be something which could make this easier.  If you go
> > > > > > > > down this path, you still will need to fate-share the
> > > > > > > > lifecycle of the subscription across all of those line cards.
> > > > > > > >
> > > > > > > > Eric
> > > > > > > >
> > > > > > > > > What's your thoughts?
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Tianran
> > > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Netconf mailing list
> > > > > > > [e-mail]
> > > > > > > https://www.ietf.org/mailman/listinfo/netconf
> > > > > > >
> > > > >
> > >
>