Re: [Netconf] a joint discussion on dynamic subscription

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

> 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.   

For draft-ietf-netconf-udp-pub-channel draft, I can see the possibility of transport client session being initiated from the line cards.

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/draft-ietf-
> > > 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
> >