Re: [Netconf] YangPush now

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

Hi Juergen,

> From: Juergen Schoenwaelder, July 23, 2018 10:14 AM
> 
> On Fri, Jul 20, 2018 at 06:47:48PM +0000, Eric Voit (evoit) wrote:
> > 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.";
> >     }
> >   }
> 
> So why do we create a _standard_ that says take the other standard and
> then roll your own non-standard module to make them work together?

My reading of your request was to make the current draft text less vague.   Hopefully providing an example augmentation based on a referenced standard-in-progress removes this ambiguity.   

I would hope that when the other standard is ready, it doesn't take something non-standard to bind them.  There are earlier threads on how this might be done.

> > > > 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)
> 
> There is nothing in NETCONF that requires a client to terminate a session if
> the client receives an unexpected message. The control of call home
> parameters is no answer (first this is out of hands for the implementor and
> second the problem is likely a misconfiguration in the first place that leads
> to something not useful). I do not think your answers provide a solution - I
> am not interested in justifications.

A solution based on the correct call home parameter configuration does work.  But other than that, I agree with you: the current NETCONF configured subscription solution does take some valid error conditions out of the hands of implementers, and places them in the hands of operators.  

The biggest question I see is whether implementers want to do the leg-work needed to building out the client capability advertisement capability to protect against these failure scenarios.   It would be great if NETCONF implementers signaled they are ready to pick this up.  

> > > 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.
> 
> Simply pushing data to a receiver before checking that the receiver is willing
> and able to consume the data is in my view not good protocol design. There
> are cases where this is unavoidable but here we do have a client and server
> talking to each other that can do better.
> 
> > 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 :-)."
> 
> There was also another proposal, namely to have the client request the
> start of notifications (like you would do with RC and SSE). I do not buy the
> 80% solution argument for an excuse of poor protocol design.

The other proposal is absolutely a valid way to do this.  And as Andy and others have pointed out, the current dynamic <establish-subscription> RPC can be kicked off by such a process.   

However the call flow has more error conditions.   As a result, three years ago during scoping of the current suite of IETF subscription drafts, this proposal was determined to be out-of-scope.  This decision was not necessarily a bad choice as I have seen proprietary non-NETCONF configured subscription deployments thrive without a publisher requesting that a client invoke the <establish-subscription>.

As a result of the decision several years ago, no one has proposed an IETF standards based call flow to invoke a client based <establish-subscription>.  It would be excellent if someone wanted to propose a draft for this.   
 
> > 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."
> 
> Well, I would rather fix the issue than pushing the problem ultimately to
> operators.

Your position is a valid one for sure.   I have not yet heard of operator wanting to attempt these more robust configuration protection mechanisms yet.  And as noted above, this is not a key use case for the deployments I am seeing yet.

Eric

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