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

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

Hi Martin,

> From: Martin Bjorklund, June 29, 2018 4:34 AM
> 
> Hi,
> 
> 
> "Eric Voit (evoit)" <[e-mail]> wrote:
> > > 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 is not enough / correct.  You also need to take the user name into
> account.

Per your other note, I think we are good here.
 
> > 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.
> 
> The solution must be robust enough to correctly handle all cases that it allows
> to be confgigured.
> 
> Anyway, if this whole issue is handled in the transport documents, I am happy.
> Some transports will likely support this, and some will not.

Works for me.

> > > 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
> 
> No!  That would be a big mistake, since address and port are not enough for
> receiver identification.  Hopefully you agree by now.

I do agree.  I was trying to give a placeholder for Kent's "no-crypto" proposal.  

Per below, I think it better just to leave both "address" and "port" out.

> > , 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.
> 
> See above.

Yes.  The version posted today will leave "address" and "port" out, leaving this issue up to vendors until ietf-netconf-server.yang completes.

Eric

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