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

[Martin Bjorklund <[e-mail]>]

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

> > > > 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?  What if the users are different?
Etc.  The point is that maybe there are cases when this can be done,
but you need to spell this out.

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

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

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