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

[Kent Watsen <[e-mail]>]

>> > 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 you say it differently or provide an example?
>
> Dynamic subscriptions over NETCONF requires draft-ietf-netconf-netconf-event-
> notifications.   

Where is the dependency?  I don't see anywhere in the 3 RPCs and associated 
error-info definitions that have a reference to the identity in that draft.



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

True.


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

True, and thanks for providing a concreate example.  Though I thought we concluded
before that there might be cases where the global netconf-server isn't implemented?
Now you're okay making that a requirement?  (I'm okay with that, if it works)

FWIW, I think that an import statement can also assert that a dependent module is
implemented.  For instance, in the below case, the xpath in the leafref forces
that the module is implemented:

  module ietf-netconf-subscribed-notifications {
    prefix nsn;
    import ietf-netconf-server { prefix ncs; }
    import ietf-subscribed-notifications { prefix sn; }
 
    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.";
      }
    }
    ...
  }

I prefer this arrangement because it gives tangible meaning for what it means
to *implement* the netconf-subscribed-notifications module.



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

At first I was going to point out that, even if using to global netconf server
container, there would still be 500 /netconf-server/call-home/netconf-client
instances, but in looking ahead, I'm wondering if I misunderstand the intended
relationship between transports, subscriptions, and receivers.

If it turns out that receivers from different subscriptions can leafref the 
same /netconf-server/call-home/netconf-client, then the 500 becomes 1, and 
the duplicate data-entry concern goes away.



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

As mentioned above, I'm wondering if I misunderstand the intended relationship
between transports, subscriptions, receivers, and maybe publishers too.  Can
you put together a diagram that describes these relationships?


> 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 think because its underspecified in the SN draft, and there was confusion
with the address and port leafs, and ietf-netconf-subscribed-notifications
only defines an identity (no configuration data model).


>> >> <snip/>
>> >> 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.   
> <mangled url snipped/>
> Slide 6
>
> Also please see the meeting minutes :
> <mangled url snipped/>
>
> and recording (starts at 16:55) which are quite clear on the decision
> criteria and decision reached.

Okay, the answer is that its considered "simpler" to use a single kind
(not instance) of transport.  So, the outcome is, if one receiver of a 
subscription is using a NETCONF-based transport, then all the other 
receivers of that subscription MUST also be using a NETCONF-based 
transport, albeit a different instance of a NETCONF-based transport 
(as it would be redundant otherwise).  Correct?

Assuming this is the case, my question is, why is this "simpler"?  I mean,
assuming an event occurs that a subscription matches, the publisher will
encode a notification message to send, and then iterate over its list of
receivers, sending the same encoded-message to each.  But why is it less
simple if different transports (netconf, restconf, etc.) are used?

BTW, separately, I kind of but not really understand why there is a desire
for the fixed encoding for all the receivers in a subscription.  I understand
the efficiency angle (see prev paragraph), but I get stuck on the idea that,
if there is a *need* to send a different encoding (e.g., "encode-json"),
another encoded message structure is going to have to be created anyway; it
seems like the same number of instructions from that perspective.  Then it
goes to looping over one-subscription-tree or one-tree-per-encoding.  Okay,
then, what makes it better?  The only thing I can come up with is that it
might be difficult otherwise to express in YANG what encoding is being used
for that receiver.  For instances, if there is a leafref to /restconf-server\
/call-home/restconf-client, nowhere is there an "encoding" field.  Hmmm, 
maybe the encodings a restconf server supports could be specified at a 
higher level (e.g., /restconf-server/encodings/...), and then it would be
known, on a per-receiver basis, what encoding is used (netconf is always
xml, restconf is per configuration).  Anyway, I'm just wondering if this
is why the encoding for all the receivers in a subscription must be the
same, or is it something else?



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

Okay.



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

Okay.



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

In this particular fork in the thread, I think that we're discussing the merits
if leafref-ing vs using a grouping.  If it is the case that the same transport
can be used across subscriptions, then 1) it swings things back to leafref 
approach being needed and 2) this fork in the thread is done.  [Assuming that
it’s a leafref, we still need to finalize if it's a leafref to the global
server instance or some SN-specific instance.]


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

What I know is that this was before the LC, back when these drafts were 
pretty difficult to understand and details about how to configure the
transports were missing.

Regardless, to the question about how it is a "good" thing (what this fork
in the thread is about), I determine above that the WG wanted "simpler".


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

As said before, sharing the same transport across subscriptions wasn't clear
to me before.  Still, even as 500 becomes 1, there remains the discussion if
it's the one is the global server instance or some SN-specific server instance.



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

Not just possible, it is actually how it happens.  The client-server modules
are highly sensitive to implementation status.  FWIW, I never expect the
ietf-*conf-client modules to ever be implemented, and the ietf-*conf-server
modules to be implemented "sometimes".  FWIW, the global server instances
we keep talking about only happen *if* the ietf-*conf-server modules are
implemented.   



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

Okay.



> <big snip/>
>
> So can we take out address and finally be done?   That would be a good thing.

Yes, take out the address leaf but I think that, if we want to progress the
SN draft along with a transport binding definition that doesn't depend on
the ietf-*conf-server modules, then we might define something else like:

  module ietf-netconf-no-crypto-subscribed-notifications {
    prefix nncsn;
    import ietf-subscribed-notifications { prefix sn; }

    container implicit-netconf-receivers {
      list implicit-netconf-receiver {
        key name;
        leaf name { ... }
        leaf address { ... }
        leaf port { ... }
      }
    }
    augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
      if-feature "subscription-support";
      when 'derived-from(../../../transport, "nsn:netconf")';   
      leaf netconf-endpoint {
        type leafref {
          path "/nncsn:implicit-netconf-receivers/nnccs:implicit-netconf-"
               + "receiver/nnccs:name";
        }
      }
    }
    ...
  }


I don't quite understand how the server is supposed to know how to configure
the call-home parameters or the transport parameters, but at least this
would be on par with what you had before.



>> <big snip/> 
>> 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.

From above, and I can't ascertain why this is, when dynamic subscriptions don't
appear to utilize the "netconf" identity in any way...


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

Perhaps, but it seems unnatural to do it this way.  What makes sense to me is 
for the module that claims to be the transport-binding module to provide the
configuration for binding the transport.


>> >> 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, you are the Editor.  But beware, this could blow up and we decide to
drop the netconf and restconf protocols bindings entirely and only focus 
on transport bindings for things like gRPC and udp-pub-channel.  If NC/RC
are needed, then the server could configure a standard call-home connection
(via the ietf-*conf-server modules) from which the client can issue a start
a dynamic subscription.  Just thinking this might be a better win.


> Eric

Kent // contributor