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

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

> From: Kent Watsen, June 21, 2018 11:36 AM
> 
> Search for <Kent> below.
> 
> // contributor
> 
> 
> <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.

As the draft-ietf-netconf-server-model is currently expired, I believe it safe to assume (b) will be common.

> <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://www.ietf.org/mail-archive/web/netconf/current/msg13875.html

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

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

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

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

There is no such requirement for all ssh or tls.  So it looks like such a future leafref might work.

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

Eric

> /kw
> 
> 
>