Re: [Netconf] YangPush now

[Robert Wilton <[e-mail]>]

I basically agree with Andy.

I appreciate from the comments that the configured subscriptions is not 
usable using standards transports yet, but it still seems that it would 
be more invasive to rip configured subscriptions out at this point in 
time.  I think as a WG we really want to get this document published 
otherwise it will be obsolete before it even has an RFC number.  We can 
fix up the configured subscriptions afterwards, and then publish a bis 
version that puts everything together.

Thanks,
Rob


On 26/07/2018 04:21, Andy Bierman wrote:
> Hi,
>
> IMO there is a good enough plan in place to complete the configured 
> subscriptions.
> The co-authors have done enough revisions. It is time to finish the 
> drafts.
>
> We should let vendors experiment and also try to create a standard 
> binary protocol.
>
>
> Andy
>
>
>
> On Tue, Jul 24, 2018 at 4:56 PM, Eric Voit (evoit) <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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/
>     <https://www.jacobs-university.de/>>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf