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

[Kent Watsen <[e-mail]>]

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



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


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


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




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


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


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



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


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


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


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


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


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


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


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