Re: [Netconf] YangPush now

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

Hi Juergen,

> From: Juergen Schoenwaelder, July 20, 2018 6:14 AM
> 
> On Thu, Jul 19, 2018 at 09:41:00AM +0000, Eric Voit (evoit) wrote:
> 
> > That is what I was hoping would be accomplished with the text:
> >
> >    The method of identifying the targeted receiver IP address, port, and
> >    security credentials are left up to implementers of this
> >    specification.  For implementation guidance and a YANG model for this
> >    function, please look to
> >    [I-D.draft-ietf-netconf-netconf-client-server].
> 
> I said this is to vague for me to understand. Repeating the pointer does not
> help me to understand. If this I-D has a clear solution, why not put it in
> place?

The recommended solution is for vendors to augment in their own leafrefs into existing vendor specific call home configurations.   Alternatively, solutions can be integrated within non-YANG based configuration structures.  This is how our configured subscription implementation works.  

To clarify the recommended solution, I have updated the reference above to:

The method of identifying the targeted receiver IP address, port, and security credentials are left up to implementers of this specification.  For implementation guidance on how a leafref might constructed to accomplish this function, consider the following augmentation which would need to be made if the necessary connection parameters are maintained with ietf-netconf-client.yang as specified by [I-D.draft-ietf-netconf-netconf-client-server].

  import ietf-netconf-client { prefix ncc; }
  import ietf-subscribed-notifications { prefix sn; }
  import ietf-netconf-subscribed-notifications { prefix nsn; }

  augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
   when 'derived-from(../../../transport, "nsn:netconf")';   
   leaf netconf-endpoint {
      type leafref {
        path "/ncc:netconf-client/ncc:initiate/ncc:netconf-server/ncc:endpoints/ncc:endpoint/ncc:name";
      }
      description
        "Points to a remote NETCONF client intended to support a particular configured subscription.";
    }
  }
  
> > To cover this, there is the following text in Section 5 of draft-ietf-netconf-
> netconf-event-notifications:
> >
> >    publisher SHOULD place the receiver into the
> >    "timeout" state after a predetermined number of either failed call
> >    home attempts or NETCONF sessions remotely terminated by the
> >    receiver.
> >
> >    Until NETCONF transport with a receiver has been established, and a
> >    "subscription-started" state change notification has been
> >    successfully sent for a configured subscription, that subscription's
> >    receiver MUST remain in either the "connecting" or the "timeout"
> >    state.
> 
>     <-- call home -->
>  C: <hello>
>  S: <hello>
>  S: <notification>
>     <-- session terminated -->
> 
> The server believes 'notification has been successfully sent'.  The other
> alternative would be a client that throws away notification messages not
> expected:
> 
>     <-- call home -->
>  C: <hello>
>  S: <hello>
>  S: <notification> // -> discarded
>  S: <notification> // -> discarded
>  S: <notification> // -> discarded
>     [...]
> 
> Both scenarioes are problematic. 

Agree that there are these two scenarios.  

The first scenario isn't elegant, but I don't see it as problematic.  Per SN, transport loss places all receivers back into their connecting state.   And the NETCONF-Notif text quoted above shows that multiple session terminations places the subscription into "timeout" so that something can figure out what is wrong.

The second scenario requires that NETCONF Call home is successfully configured with the right credentials on both sides of the connection, and that the receiver's NETCONF client implementation is unable to terminate a session receiving unwanted notification traffic.  This is a concern, but an implementer at least has some protections by controlling the call home connectivity parameters tied to a specific receiver.   (See continue reasoning below)

> This is why I suggested that there needs to
> be some mechanism that tells the server that the client is willing to receive
> configured subscriptions before the server throws <notification> messages
> at the client. You will find differnet ideas in the mailing list archive.

In talking about this issue in the past, suggestions were made that the NETCONF client could advertise its capabilities for supporting configured subscriptions as part of the hello exchange.  And that can be a partial(*) solution to the problem.  However there was pushback to this based on NETCONF client to server implementations not typically exchanging and interpreting the results of NETCONF client asserted capabilities.  

(*) the reason it is partial is that even if the client advertises support for NETCONF configured subscriptions, there is still the possibility that something goes wrong with the receiver's receiving process with the second scenario above.  In which case you still need to have a way to terminate the incoming notification stream by pulling down the NETCONF session.  Still, there are obviously benefits of client capability signaling as an extra layer of misconfiguration protections included.

Looking at what is in the v10 draft, there are some protections for both your scenarios above.  But certainly it is not robust.   And certainly having the client advertise configured receiver support would be nice, but this would require more development.   As based on the amount of development,  we used the design philosophy of "it is better to start with an 80% solution than a 120% solution :-)."  

I agree that the current protection could have an improved description.  So I have placed the following text into the NETCONF-Notif security considerations section:

" For a configured subscription, if NETCONF call home has been configured with the working credentials, yet that the receiver's NETCONF client implementation is both unable to process inbound notifications and unable to terminate a session receiving unwanted traffic, then the receiver may receive unwanted event records.  To minimize this risk, a publisher implementation should use dedicated call home connectivity port numbers and credentials specific to configured subscriptions.  This will minimize the chance that an unplanned NETCONF receiver will receive configured subscription notifications unexpectedly."
 
> > > I do not buy the IoT argument. What is wrong with requiring that a
> > > NETCONF server must support at least the NETCONF transport and that
> > > a RESTCONF server must support at the RESTCONF transport?
> >
> > Ahh.  I thought you meant that there should be a default transport for SN
> alone.    SN in section 1.0 & the end of 5.3 points to transport documents
> for such guidance.
> >
> > Then looking at Section 1.0 in draft-ietf-netconf-netconf-event-
> notification:
> >
> >    This document provides a binding for events streamed over the
> NETCONF
> >    protocol [RFC6241] as per
> >    [I-D.draft-ietf-netconf-subscribed-notifications].  In addition, as
> >    [I-D.ietf-netconf-yang-push] is itself built upon
> >    [I-D.draft-ietf-netconf-subscribed-notifications], this document
> >    enables a NETCONF client to request and receive updates from a YANG
> >    datastore located on a NETCONF server.
> >
> 
> Yes. But this text does not say that 'if a NETCONF server supports
> configured subscriptions, then it MUST implement the notification
> transport as defined in section 5.2 (or whatever the section will be).
> This way, a NETCONF client using configured subscriptions would know one
> transport that actually works (if the details are fully worked out). 

Added the text to the top of configured subscriptions section:

"To allow the configuration of NETCONF for configured subscription transport, a publisher MUST support the YANG module defined in Section 8.  Advertisement of this module will indicate support the "netconf" transport identity, and therefore the ability to use NETCONF as the selected transport.".

> Perhaps
> this is not what people really want, so I will start another thread to figure
> this out.

See the thread.  Wil reply to it.

Eric

 > /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>