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

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

Hi Kent,

> From: Kent Watsen, June 22, 2018 4:30 PM
> 
> Hi Eric,
> 
> 
> >> <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.
 
> (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.

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

> > As the draft-ietf-netconf-server-model is currently expired, I believe it safe to
> assume (b) will be common.
> 
> Good grief, the WG abandoned that draft two years ago during a factoring
> effort.  The current draft is here, and it's very much alive; there was big update
> a couple weeks ago.  Here's the latest: https://tools.ietf.org/html/draft-ietf-
> netconf-netconf-client-server-06.

Ahh.  I guess that is what I get for searching Google using the name of the YANG model...

> >> <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.
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > -
> 2Darchive_web_netconf_current_msg13875.html&d=DwIGaQ&c=HAkYuh63rs
> uhr6
> > Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISla
> >
> JdcZo&m=k7VsSkN2Q165UV6B4VmVssEhPOMrwj4K7_BDR5wHSc0&s=Q6QpnX
> Zg_HVNPxTC
> > Tjdf20mC56AQyCPM55K_23ouVeQ&e=
> 
> 
> 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.

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

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

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

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.

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

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

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

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

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

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