Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver

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

> From: Martin Bjorklund, June 26, 2018 4:13 PM
> Subject: Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver
> 
> "Eric Voit (evoit)" <[e-mail]> wrote:
> > > From: Martin Bjorklund, June 26, 2018 2:43 PM
> > >
> > > "Eric Voit (evoit)" <[e-mail]> wrote:
> > > > > From: Martin Bjorklund, June 26, 2018 4:11 AM
> > > > >
> > > > > "Eric Voit (evoit)" <[e-mail]> wrote:
> > > > > > > From: Kent Watsen, June 25, 2018 3:43 PM
> > > > > > >
> > > > > > > >> >> <kent-orig> Okay, glad to see that you embrace using
> > > > > > > >> >> ietf-netconf-server, rather than ietf-netconf-client.
> > > > > > > >> >> And I'll grant you that it's infinitely more likely
> > > > > > > >> >> that the ietf-netconf-server module would be
> > > > > > > >> >> implemented (i.e., the top-level /ncs:netconf-server
> > > > > > > >> >> container exists), more so than the ietf-netconf-client module
> would be implemented.
> > > > > > > >> >> The WG created the top-level /ncc:netconf- client
> > > > > > > >> >> container more for the sake of symmetry than for
> > > > > > > >> >> having a use-case for when it would be implemented.  I
> > > > > > > >> >> think the question to ask is, is it
> > > > > > > >> possible that a device wants to use SN but doesn't
> > > > > > > >> *implement*
> > > > > > > >> ietf-netconf- server?
> > > > > > > >> >>
> > > > > > > >> >> <Eric> Yes, this will be possible.  Reasons would include:
> > > > > > > >> >> alternative
> > > > > > > >> transports
> > > > > > > >> >> (COMI, UDP), HTTP2 configured subscriptions (which
> > > > > > > >> >> might use
> > > > > > > >> >> ietf-restconf- server), or no need for a publisher to
> > > > > > > >> >> include the configured subscriptions feature.
> > > > > > > >> >>
> > > > > > > >> >> <Kent> I should've be more specific: is it possible
> > > > > > > >> >> that a device would use netconf-notif (where your
> > > > > > > >> >> leafref is
> > > > > > > >> >> defined) but not implement
> > > > > > > >> ietf-netconf-
> > > > > > > >> >> server?  Similarly, restconf-notif would presumably
> > > > > > > >> >> have a leafref to
> > > > > > > >> >> ietf-
> > > > > > > >> >> restconf-server, etc.
> > > > > > > >> >
> > > > > > > >> >Yes.  Cases would include:
> > > > > > > >> >(a) platform doesn't support configured subscriptions
> > > > > > > >> >(b) vendor has not yet implemented ietf-netconf-server,
> > > > > > > >> >and uses something
> > > > > > > >> else.
> > > > > > > >>
> > > > > > > >> (a) is this a valid case?  - I thought this conversion
> > > > > > > >> only regards configured subscriptions.  No leafref or
> > > > > > > >> equivalent would be needed to support a dynamic subscription.
> Right?
> > > > > > > >
> > > > > > > > Correct.  But your question was "can you use netconf-notif
> > > > > > > > without a leafref
> > > > > > > to...".
> > > > > > > > Needing both drafts is absolutely the case for dynamic
> > > > > > > > subscription support, and ietf-netconf-server would not be
> > > > > > > > needed
> > > here.
> > > > > > >
> > > > > > > I read the above a few times, but I'm having a hard time
> > > > > > > understanding it.  Can say it differently or provide an example?
> > > > > >
> > > > > > Dynamic subscriptions over NETCONF requires
> > > > > > draft-ietf-netconf-netconf-event-notifications.  With these
> > > > > > deployments, there there is no call home, there is no
> > > > > > configuration, and there need be no ietf-netconf-server.yang
> > > > > > leafref (or use of ietf-netconf-server.yang grouping).
> > > > > >
> > > > > > > >> (b) this seems like a possibility, but then I think this
> > > > > > > >> make the case for why a leafref to the global *conf
> > > > > > > >> servers definitions won't always
> > > > > > > work.
> > > > > > > >
> > > > > > > > Agree that nothing here will always work.  Deployments
> > > > > > > > commonly will have a heterogeneous mixture of model
> > > > > > > > ecosystem
> > > models.
> > > > > > > >
> > > > > > > > This actually makes a *very* strong case for why the
> > > > > > > > leafref should be added as an augmentation from the *conf-server
> models.
> > > > > > > > That way leafref augmentations are explicitly tied to the
> > > > > > > > actual implementation of the
> > > > > > > model against which they refer.
> > > > > > >
> > > > > > > Not in the *conf-server models, the augments go into the
> > > > > > > *conf-notif models, I assume that is what you meant.
> > > > > >
> > > > > > My assertion is a good solution would be updating
> > > > > > ietf-netconf-server.yang per what is below.  Note that an
> > > > > > answer even further below regarding the sharing of a single
> > > > > > NETCONF session across multiple subscriptions and typical
> > > > > > RFC6241 protocol interactions is assumed.  But we could also
> > > > > > insert your ietf-netconf-server.yang grouping just as
> > > > > > effectively where the leafref is
> > > seen.
> > > > > >
> > > > > > Anyway here are the following changes which would be made to
> > > > > > ietf-netconf-server.yang
> > > > > >
> > > > > >   import ietf-subscribed-notifications { prefix sn; }
> > > > > >   import ietf-netconf-subscribed-notifications { prefix nsn; }
> > > > > >
> > > > > >   feature subscription-support {
> > > > > >     description
> > > > > >         "The 'subscription-support' feature indicates that the
> > > > > > NETCONF
> > > server
> > > > > >          supports configured subscriptions over call-home connections.";
> > > > > >        reference
> > > > > >         "RFC xxxx: Customized Subscriptions to a Publisher's Event
> Streams";
> > > > > >      }
> > > > > >
> > > > > >  augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver"
> {
> > > > > >    if-feature "subscription-support";
> > > > > >    when 'derived-from(../../../transport, "nsn:netconf")';
> > > > > >    description
> > > > > >       "This augmentation allows NETCONF specific parameters to
> > > > > > be
> > > exposed
> > > > > >       for a receiver.";
> > > > > >     leaf netconf-endpoint {
> > > > > >       type leafref {
> > > > > >         path "/ncs:netconf-server/ncs:call-home/ncs:netconf-
> > > client/ncs:name";
> > > > > >       }
> > > > > >       description
> > > > > >         "Remote client which need to initiate the NETCONF transport if
> an
> > > > > >         existing NETCONF session from that client is not available.";
> > > > > >     }
> > > > > >   }
> > > > > >
> > > > > > With such a construct, it is impossible to add a leafref (or
> > > > > > grouping) within ietf-subscribed-notifications unless
> > > > > > ietf-netconf-server.yang exists.
> > > > > >
> > > > > > > >> This is why I
> > > > > > > >> was thinking before that your modules might themselves
> > > > > > > >> *use* the
> > > > > > > >> *conf- server-groupings (while pruning out unneeded
> > > > > > > >> parts, e.g., the "listen" subtree), so that it's
> > > > > > > >> independent of what the system has implemented at the global
> level.
> > > > > > > >
> > > > > > > > If you have 500 subscriptions, you then have to populate
> > > > > > > > 500 identical
> > > > > > > groupings.
> > > > > > >
> > > > > > > No, you have one grouping, with 500
> > > > > > > /netconf-server/call-home/netconf-client
> > > > > > > instances.
> > > > > >
> > > > > > Yes.  But I don't know why someone would voluntarily do add
> > > > > > 500 repeated elements to a configuration datastore.
> > > > > >
> > > > > > > >  And yes this is possible.  But it makes the part of me
> > > > > > > > which likes Normalized  data quite uncomfortable.
> > > > > > > >
> > > > > > > > But as I said before, it the WG wants such redundancy, fine.
> > > > > > > > Either choice need not impact decisions as part of LC.
> > > > > > >
> > > > > > > I don't believe that is a WG-preference thing, so much as an
> > > > > > > outcome of the current design, which is that each receiver
> > > > > > > for each subscription has its own state-machine and protocol
> > > > > > > messages.  There is no sharing; no two receives can use the
> > > > > > > same RFC 6241 NETCONF session, which effectively translates
> > > > > > > to each receiver having its own
> > > > > > > /netconf-server/call-home/netconf-client
> > > > > > > instance,
> > > > > > > right?
> > > > > >
> > > > > > This is incorrect.  Protocol and state-machine messages have
> > > > > > been decoupled from the transport session.
> > > > > >
> > > > > > I am not sure why you think that subscriptions are unable to
> > > > > > use a common NETCONF session?  Implementations of dynamic
> > > > > > NETCONF subscriptions have been doing this for years.
> > > > > > Subscription multiplexing of configured and dynamic
> > > > > > subscriptions over a common transport is a pre-requisite for solution
> scalability.
> > > > >
> > > > > I don't think muliplexing of configured and dynamic
> > > > > subscriptions over a single session is possible.
> > > > >
> > > > > If this is the intention of the current design, the document
> > > > > needs to explain how this is supposed to be done.
> > > >
> > > > What is your concern?
> > >
> > > Suppose a client connects to a server and starts a dynamic
> > > subscription.  Can this session somehow be used for a configured
> subscription?  I assume not.
> >
> > Why not?
> 
> How would a server know that a certain configured receiver is the same as an
> ongoing session?  And as a client, suppose I just opened a session to send one
> request and then I plan to close the sesssion.  I probably don't want notifs on
> this session as well.

This is a valid scenario.  And while a fix for the current solution would be quite easy to do in text (i.e., through defining expectations of client behavior), it is not necessary to force this complexity on the client.  So instead I propose updating the first paragraph of NETCONF-notif, section 6.2 to the following:

"When a configured subscription enters the "valid" state, there is no guarantee a usable NETCONF transport session is currently in place with each associated receiver.     As a result, the first configured subscription to a specific receiver MUST establish a NETCONF transport session via NETCONF call home [RFC8071] , section 4.1.  This transport session MUST then be used by additional configured subscriptions targeting that the same receiver.   This same receiver is identifiable on the publisher as one which targets the same address and port used to establish the existing NETCONF call home connection. This transport session MAY also be used by dynamic subscriptions and/or non-subscription related NETCONF operations originated by the NETCONF client.

Until a "subscription-started" state change notification is successfully sent for a configured subscription, that subscription's receiver MUST remain in either the "connecting" or the "timeout" state."

> > > > > Multiplexing multiple configured subscriptions over a single
> > > > > transport session could be possible, but the document doesn't
> > > > > mention
> > > this.
> > > > > Again, if this is the intention, it needs to be properly
> > > > > described in the document.
> > > >
> > > > What is missing?  The subscribed-notification draft section 2.5.1
> > > > and Figure 9 describe how each receiver is pushed their own state
> > > > notifications.  (I.e., the state machine is per-receiver.  It is
> > > > not per-subscription, nor is it per-transport.)
> > >
> > > If there are two different subscriptions configured, each has its
> > > own list of receivers.  Under which circumstances will the server
> > > decide to use a single transport session for these two different
> subscriptions?
> >
> > If the "transport", "address", "port" are the same, then a single
> > transport session can be used.
> 
> What if the encoding is different?  

When there really is a different encoding for NETCONF (which is currently not supported in accordance with you earlier comments), we have the option of adding "encoding" to the list of properties which demand a different transport.  However as there are not multiple encodings for NETCONF here, it is easy to ignore for now, especially as an implementation can simply define a different port for the target connection should the receiver really want different encoding someday.  

> What if the users are different?

As you can identify specific ports with different call home, this will cover different users if a receiver can't de-multiplex.  

> Etc.  The point is that maybe there are cases when this can be done, but you
> need to spell this out.

For receiver configuration data right now, we just have receiver "name" which is a string.   There is no need to tell vendors how to do call home configuration as this isn't really in scope.  Solutions here will come soon enough with Kent's draft.

> > During the reviews however, you and Kent have argued away both "port"
> > and "address" from being objects under the receiver.  So vendor
> > specific augmentations will be needed to identify "address"
> > and "port".
> 
> I expect such objects to be added by the transport docs, not by vendors
> (except for vendor-specific transports).

Per the parallel thread with Kent, I fully support augmenting the call home document when it is ready.   

I think what we have now is fine.   Note: we can always re-add "address" and "port" back to SN if enough people want to re-insert explicit receiver identification within the YANG model, and not leave it up to vendors.   But we have already argued this one sufficiently.  I would rather just declare the current solution sufficient.

> > (Unless you are now ok with letting these objects back into the draft,
> > just for the purposes of enable this a common receiver transport
> > session identification.)  The other option is to have a future leafref
> > augmented to ietf-netconf-server.yang as described above.
> 
> >
> > >  I can't see any text about this in the document.
> >
> > I have added the following to the NETCONF-Notif document section on
> configured subscriptions:
> >
> 
> > "It is possible to have multiple configured subscriptions sharing a
> > common transport to a single receiver.  The method of identifying that
> > a receiver happens to be the same as used with another subscription is
> > left up to implementers of this specification."
> 
> I don't think this helps.  It means that the client has no way of knowing on
> which sessions to expect notifs.

You are right that it won't be in the YANG file.  But that is the result when you argued "address" and "port" out of receivers.  So for now the configuration is buried in vendor specific call home information.  That information of course can be referenced by vendor specific additions. 

I think it best to leave it as is.   And at some point we will have the ietf-netconf-server.yang model which will allow the vendor specific part go away.

Eric
 
> > The text above can be changed if you are ok with adding "address"
> > and "port" back into the draft.
> >
> > > > > This said, "session sharing" can be acheived with the current
> > > > > design, as well as with the alternative design where the
> > > > > protocol is defined per receiver rather than per subscription.
> > > >
> > > > Agree.  Any issues with NETCONF transport multiplexing of
> > > > subscriptions
> > > should be independent of the receiver YANG model.
> > > >
> > > > > But it won't be interoperable unless it is described.
> > > >
> > > > Likely NETCONF specific concerns would land in the NETCONF-notif.
> > > > I am
> > > happy to make any needed clarifications.
> > >
> > > I think you will need specific text in both subscribed-notifications
> > > and in the transport drafts, if this is what you want to support.
> >
> > I have added text to NETCONF-notif per above.
> >
> > For subscribed-notifications, I have added the sentence to the first paragraph
> of the "configured subscriptions" section:
> >
> > "Multiple configured subscriptions MUST be supportable over a single
> > transport session."
> 
> See above.
> 
> 
> /martin
> 
> 
> 
> >
> > >
> > > /martin
> > >
> > >
> > >
> > > >
> > > > Eric
> > > >
> > > > > /martin
> > > >
> >