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

[Martin Bjorklund <[e-mail]>]

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

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.

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.  But it won't be
interoperable unless it is described.



/martin




> > >> >> <kent-orig> Even though it seems like ietf-netconf-server might
> > >> >> always be implemented, I do not yet think it is okay for this data
> > >> >> model to have a leafref to one of the globally-configured
> > >> >> /ncs:netconf-server/ncs:call-home/ncs:netconf-client instances,
> > >> >> since that instance would be expected to use normal NETCONF
> > >> >> interactions (i.e. client-driven); it could be a problem if the
> > >> >> server started sending <subscription-started> messages right away.
> > >> >> For this reason, maybe the SN data model needs to have its own
> > >> >> instance of the netconf-server-grouping (perhaps with the
> > >> >> top-level /listen tree pruned out), so then it's clear that these
> > >> >> netconf-server
> > >> instances are specifically for subscriptions?
> > >> >>
> > >> >> <Eric> The original thread was trying to enforce a single
> > >> >> transport across the receivers of a configured subscription, and
> > >> >> where objects specific to that transport could be augmented to those
> > receivers.
> > >> >>
> > >> >> <Kent> Sorry, can you go over this again.  What is the stated goal?
> > >> >> I recall Martin wanting the same encoding across receivers, but
> > >> >> the same transport too?  I assume you don't mean "same transport"
> > >> >> but "same
> > >> kind of transport"?
> > >> >> So, if one receiver of a subscription uses netconf-notif, they all
> > >> >> must use netconf-notif?
> > >> >
> > >> > Yes.   This was a WG decision driven through IETF 101.
> > >> >
> > >> > <mangled URL removed>
> > >>
> > >>
> > >> Okay, I see it, weak, but it's there.
> > >>
> > >> I completely understand why we'd want the same encoding, but not so
> > >> much same protocol, since each receiver has its own distinct instance
> > >> of the protocol anyway, so it doesn't seem to make a difference,
> > >> i.e. no
> > runtime optimization.
> > >> Did you ever figure it out?
> > >
> > > I have seen many subscriptions use a single NETCONF transport session.
> > >
> > > In any case my proposal was to support transport per receiver.  The WG
> > voted
> > > very clearly to use a common transport at and after IETF 101.   The WG
> > document
> > > was changed accordingly.  I consider this issue closed.
> > 
> > You didn't answer the question, which is essentially what benefit
> > having a
> > single
> > protocol provides?  Looking at the thread, I see Martin asked a
> > similar
> > question
> > which was never answered either.
> 
> Please see the slides from IETF 100 where this was debated.   
> https://datatracker.ietf.org/meeting/100/materials/slides-100-netconf-draft-ietf-netconf-yang-pushsubscribed-notifications-03
> Slide 6
> 
> Also please see the meeting minutes :
> https://datatracker.ietf.org/meeting/100/materials/minutes-100-netconf-01
> 
> and recording (starts at 16:55) which are quite clear on the decision
> criteria and decision reached.
> 
> > >> BTW, in that thread, I see Einar mentioning that the multiple
> > >> receives are there to support HA/redundancy.  As I understand this,
> > >> this would be duplicated- delivery to multiple receivers, which would
> > >> be merged into some centralized datastore, where all the duplicates
> > >> would be removed.  Is this your understanding too?
> > >
> > > Some implementations can choose to do this.
> > 
> > Yes, but I would consider it a poor choice relative to the
> > reconnection-strategy
> > in the ietf-*conf-server modules.  That said, I don't necessary
> > object, I'm just
> > hoping this isn't the primary motivation for the SN model supporting
> > multiple
> > receivers.
> 
> It isn't
> 
> > >> FWIW, the ietf-*conf-server modules also enable each call-home
> > >> connection to a logical "netconf-client" composed of multiple
> > >> endpoints, for HA purposes, but these endpoints are connected to one
> > >> at a time.  So, when thinking about incorporating the
> > >> ietf-*conf-servers, will having these two HA mechanisms in play at
> > >> the same time cause any conflict?  Would it make sense to remove the
> > >> multi-receiver HA config in SN and instead rely and the
> > >> *-conf-server's HA mechanism + dynamic-subscriptions to fill in any gaps
> > between reconnects?
> > >
> > > Multi-receiver is not just for HA.  And some HA will want multiple
> > > live connections.  But where it is used for single-live HA in NETCONF
> > > and RESTCONF, future implementations could choose to use *-conf-server
> > for this function.
> > 
> > Agreed. A subscription having a single receiver that is a
> > /netconf-server/call-\
> > home/netconf-client instance can still be HA using the built-in
> > reconnection
> > logic.  Is this what you meant by single-live HA?
> 
> Yes
> 
> > >> >> <Eric> The design pattern in the example augmentation below seems
> > >> >> to do that.  This design pattern should hold whether a leafref is
> > >> >> augmented in,
> > >> or a
> > >> >> group is augmented in.  This design pattern also works with the
> > >> >> existing
> > SN
> > >> >> model.  I don’t know of an alternate proposal which meets these
> > >> >> requirements.
> > >> >>
> > >> >> <Kent> unsure.
> > >> >
> > >> > I should have said is that there is no alternate proposal.
> > >> >
> > >> > What I am not sure about if one can even be defined with YANG using
> > >> > explicit
> > >> case structure.
> > >>
> > >> <Kent> what do you mean by "explicit case structure"?  I don't see
> > >> any in the example you shared previously...
> > >
> > > The explicit case structure was your proposed design pattern. But this
> > > pattern doesn't work.  Because you can't enforce a single transport.
> > 
> > Maybe it can and, even if it can't at the YANG-level, it doesn't mean
> > that a
> > server can't enforce it during <edit-config> processing.
> 
> That is true.  If you wish to champion this alternate proposal, please
> call the interim.
> 
> > > As there is no alternate proposal, I am asserting WG consensus that
> > > the explicit case structure is not supported.  Which is the same
> > > consensus which came out of WG 101 on this particular topic.
> > 
> > I don't think that we should put too much weight on this decision.  It
> > was
> > made before the Last Call for which we're digging into many things.
> > I'm just
> > trying to understand the motivation behind this decision.  How is
> > forcing the
> > same transport for all receivers of a subscription a "good" thing?
> 
> Per above, the decision was made in the room at IETF 100 per the
> recording and minutes above.  And the subsequent email debate.  There
> was lots of healthy debate.
> 
> > >> >> <Eric> If this makes sense, the question becomes when to apply this
> > design
> > >> >> pattern on top of SN.  I agree there are interesting questions you
> > >> >> raise
> > >> >> above.  These questions appear to be bound to NETCONF call-home, and
> > >> >> therefore the answers should be more closely aligned with
> > >> >> draft-ietf-netconf- netconf-event-notifications rather than SN itself.
> > >> >>
> > >> >> <Kent> agreed, most of this regards what's in the transport-binding
> > >> >> drafts (netconf-notif, etc.), but I'm wanting to do this to prove out
> > >> >> that the SN model.
> > >> >>
> > >> >> <Eric> That is the driver behind my
> > >> >> “ietf-netconf-subscribed-notifications-
> > >> >> plus.yang” below.  Whether it augments in a  leafref or a group, this
> > >> >> snippet of YANG provides a template for transport specific
> > >> >> augmentations.  And using this template, how to embody NETCONF call
> > >> >> home for subscriptions  could be delivered in a timeframe concurrent
> > with
> > >> “ietf-netconf-server.yang”.
> > >> >>
> > >> >> <Kent> I understand you're trying to say "let's not worry about how
> > >> >> ietf- netconf-server works with this now".  I appreciate the desire
> > >> >> to defer what we can.  I will again say, as co-chair, that I'm okay
> > >> >> with us moving without having a draft that depends on ietf-netconf-
> > server
> > >> or the ietf-restconf-server modules.
> > >> >> That said, I don't understand what value the *conf-notif drafts have
> > >> >> if they don't.
> > >> >
> > >> > Per cases (a) & (b) above, there is value.
> > >>
> > >> There is a difference between a server not *implementing* a
> > >> ietf-*conf-
> > server
> > >> module and the *conf-notif not *using* the *conf-server-grouping
> > statements.
> > >> My suggestion has been, that the *conf-notif drafts should have their
> > >> own
> > lists
> > >> of netconf-servers (via "uses" statements), and thereby not be
> > >> dependent
> > on
> > >> the existence of a global ietf-*conf-server instance (which may not
> > >> exist).
> > >
> > > While technically correct, there are several reasons why this is
> > > problematic.
> > > (1) redundancy (see the 500 above)
> > 
> > This is a non-issue (see above)
> 
> This is still an issue, as the drafts in WGLC support a single NETCONF
> session for all subscriptions and normal protocol operations.
> 
> > > (2) availability of the group means that a platform will have exposed
> > > *conf-
> > server.
> > > Explaining that a model is only available for its grouping would be
> > > quite a
> > > confusing deviation.
> > 
> > No, it's easy, this is the difference between a module being
> > *implemented* or
> > not.  The implementation status of each module is yang-library.
> 
> Yes, what you say is possible.  It is also more complex.
> 
> > > And in any case, these questions are all viable model augmentations
> > > which
> > can
> > > be performed after *conf-server progresses.  Therefore, no matter the
> > disposition,
> > > there is need be no impact to SN at this time.
> > 
> > Already, there has been an impact to SN, as we removed the "address"
> > leaf.
> 
> I will remove the leaf after the thread is successfully concluded.
> 
> > But
> > I agree that this fork in the discussion is primarily impacting the
> > *conf-notif
> > drafts (not SN), I'm just using this thread for convenience sake,
> > since all the
> > drafts are so connected.
> > 
> > 
> > >> Separately, there is the issue of how to get something to RFC status
> > >> faster
> > than
> > >> the client-server drafts (assuming that is a good idea).  My first
> > >> thought,
> > >> mentioned before, is that we could define "no-crypto" variants of the
> > modules,
> > >> thus ensuring that all the patterns are consistently applied, while
> > >> not having
> > a
> > >> dependency on those other modules.  This is hard to discuss currently
> > because
> > >> ietf-netconf-subscribed-notifications and
> > >> ietf-http-subscribed-notifications
> > >> don't actually enable configuring the transports yet…
> > >
> > > I would rather jettison the 'address' object.  This makes for a strong
> > separation
> > > of interests for call home.
> > 
> > +1
> > 
> > 
> > >> >> It seems that these drafts should depend on the ietf-*conf-server
> > >> >> modules, but in order to get something to market faster, we want them
> > >> >> to depend on something more like the ietf-*conf-no-crypto-server
> > >> >> (right?), which the SN has further reduced to a single "address"
> > >> >> leaf, which might be fine, but I don't think it should be in the SN
> > >> >> model, since the ietf-*conf-server modules already define an address
> > field,
> > >> which would be redundant.
> > >> >
> > >> > I believe there is utility in address.  But at this point I am ok with
> > >> > removing "address".  And any vendors wanting to support (b) can then
> > >> > add proprietary augmentations to do this.
> > >>
> > >> The "address" leaf would be perfect in another circumstance, but it's
> > >> redundant in conjunction with the ietf-*conf usage, which already have
> > >> an
> > >> "address" leaf, per "endpoint" no less.  My guess is that the
> > >> "address" leaf
> > >> needs to disappear from the SN module, thereby allow each transport to
> > >> augment in exactly what it needs.
> > >
> > > Let's do that and end this thread.  We have a viable solution.
> > 
> > Agreed.
> 
> So can we take out address and finally be done?  That would be a good
> thing.
> 
> 
> > >> >> <Eric> Noe: If you wanted, a possible alternative to concurrent
> > >> >> module delivery might be a single model.  To do this you would include
> > >> >> a
> > >> “subscription
> > >> >> support” feature within “ietf-netconf-server.yang”.    The needed
> > >> >> augmentation to
> > >> >> "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver"  could
> > >> >> then be made there.  (Note: that augmentation of course would be
> > >> >> refined to meet the call-home questions/considerations from this
> > >> >> thread, such as being aimed to its own instance of the
> > >> >> netconf-server-grouping.)
> > >> >>
> > >> >>> <Kent> If I understand correctly, this would be a way to flag the
> > >> >>> call-home
> > >> >> connection as being for SN, which addresses the issue I raised about
> > >> >> how that would be known.  This is possible, and it might work well,
> > >> >> but rather than put it into the ietf-*conf-server models directly, I
> > >> >> think it would be better for the *conf-notif drafts to augment in the
> > >> >> flag.
> > >> >
> > >> > The best two choices I see are:
> > >> > (1) Make an augmentation to the *conf-notif models.  This could be
> > >> > done
> > via
> > >> new
> > >> >     drafts, and the model within.
> > >> > (2) Add the flag to *conf-server models.  This eliminates the need for
> > future
> > >> >     updates to the *conf-notif drafts.  It also keeps call-home
> > >> >     specifics in
> > one
> > >> place.
> > >> >
> > >> > Both choices allow us to support (a) & (b) now.
> > >>
> > >> I like (1) more, as it then ties the existence of the flag to the
> > *implementation*
> > >> of the corresponding *conf-server module.
> > >
> > > Per the point at the beginning of the email, adding it *conf-server
> > > seems
> > much
> > > cleaner.  You only can add the leafref if the *conf-server model is
> > > available.
> > > The analysis and decision on this can be safely move later in any
> > > case.
> > 
> > We agree above that the ietf-*conf-server module may not be
> > *implemented*,
> > and
> > yet subscriptions still need to be configured, so then what they are
> > leafref-ing
> > becomes the issue.  This is why I'm suggesting the netconf-notif YANG
> > module
> > *use* the netconf-server-group itself.  This way, when the
> > *netconf-notif draft
> > is implemented, its own definition comes into play.  When done this
> > way, the
> > flag would no longer be needed since the entire netconf-server
> > instance would
> > be SN-specific.
> 
> The NETCONF-Notif draft needs to be implemented now for dynamic
> subscriptions.
> 
> An update to NETCONF-notif for configured subscriptions is possible to
> insert the call-home leafref (or insert new grouping).  But this
> update becomes unnecessary if ietf-netconf-server.yang is augmented as
> described above.
> 
> 
> > >> That said, I have to say that I'm not entirely sure if I understand if
> > >> what is
> > >> planned is legal.  For instance, in a normal NETCONF call-home
> > >> situation, the
> > >> NETCONF session begins with both sides sending <hello> messages and
> > >> then
> > >> the server waiting for the client to send RPCs, which might include a
> > >> 5277
> > >> <create-subscription>, after which the <notifications> begin to flow.
> > >> Is this
> > >> the same here, or are you expecting the <notification> messages to
> > >> start
> > flowing
> > >> immediately?
> > >
> > > A subscription started notification will be sent after the hellos are
> > > successful.
> > > Can you point to something in RFC 6241 which says a <notification>
> > > can't be
> > sent
> > > until an RPC is sent from the client?
> > 
> > It's not a very good reference, but I found this (emphasis added):
> > 
> >    o  client: Invokes protocol operations on a server.  In addition, a
> >       client can *subscribe* to receive notifications from a server.
> > 
> > We should ask the WG.  All I know is that it's always been that the
> > client does
> > something to initiate server behavior.  Admittedly, this is kind of a
> > new thing,
> > and it might be okay, but I think it warrants review by others.
> 
> You are welcome to make the request. 
> 
> Eric
> 
> > > Eric
> > 
> > Kent // contributor
> > 
> > 
> > 
> > > >> <kent-orig> I also have an issue with the proposed leafref because it
> > leaves
> > > >> open the possibility that two subscriptions could point to the same
> > > >> /ncs:netconf-server/ncs:call-home/ncs:netconf-client instance, which
> > would
> > > >> likely cause protocol and state machine problems.
> > > >>
> > > >> <Eric> Looking closer, perhaps a better place for the receiver leafref
> > > >> would
> > > be a
> > > >> choice of:
> > > >> /ncs:netconf-server/ncs:call-home/ncs:netconf-
> > > >> client/ncs:name/ncs:ssh/ncs:endpoints/ncs:endpoint/ncs:name
> > > >> or
> > > >> /ncs:netconf-server/ncs:call-home/ncs:netconf-
> > > >> client/ncs:name/ncs:tls/ncs:endpoints/ncs:endpoint/ncs:name
> > > >>
> > > >> But again, I am fine with anything which doesn’t insert redundant data
> > > >> as
> > > part
> > > >> of the receiver call home configuration.
> > > >>
> > > >> <Kent> No, just pointing to /ncs:netconf-server/ncs:call-
> > home/ncs:netconf-
> > > >> client should work, since the instance can have only one transport
> > > >> (ssh or
> > > tls)
> > > >> defined at a time.  That said, if your requirement is that they must
> > > >> all be
> > ssh
> > > or
> > > >> must all be tls, we have a bigger issue.
> > > >>
> > > >>  FYI, the list of "endpoints" is there for
> > > >> HA reasons - they're a pool of failover endpoints the server can try -
> > > >> is that
> > > >> concept consistent with the SN draft?
> > > >
> > > > I don't see any conflict.  In fact it should be a nice benefit of
> > > > pointing to
> > > *conf-server.
> > >
> > > Great!
> > >
> > >
> > > Kent // contributor
> > >
> > 
> > 
> > 
> > 
>