Re: [Netconf] configuration models status and timeline

[Andy Bierman <[e-mail]>]

On Wed, Jul 18, 2018 at 8:02 AM, Juergen Schoenwaelder <
[e-mail]> wrote:

> On Wed, Jul 18, 2018 at 02:25:06PM +0000, Kent Watsen wrote:
> > Hi Juergen,
> >
> > Thanks for the analysis.  I was also thinking that it seems that just a
> couple issues were left, and then we could go to last call, potentially
> well within the timeframe needed for the YANG-push set of drafts.
> >
> > Regarding #4: I met with two Security+YANG folks from Huawei yesterday,
> who have agreed to help me with this issue.  We also plan to try to loop
> back in Gary Wu, who created the identities in the ietf-ssh/tls-common
> modules in the first place.  Our tentative plan is a meet in a couple weeks.
>
> Good. Sooner is better. ;-)
>
> > Regarding #6: my understanding (from Tim C. and Balazs L.) is to use
> some combination of a notification and an RPC to stimulate traffic.
> Presumably:
> >
> >   For when the NC/RC-client is the transport-initiator (normal):
> >
> >     - if there is a lull, the client could send a bogus RPC of
> >       some sort (e.g., an <edit-config> that selects nothing)
> >       and wait for the server sends an RPC-reply.
>
> Ideally, the keep alive would just be handled at the session layer. I am
> not sure where the NC spec allows
>
> C: <rpc message-id="101"
> C:      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>
> S: <rpc-reply message-id="101"
> S:      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>
>
> otherwise one could define a noop RPC (I am not sure invoking a fake
> edit-config is necessarily a good idea).
>


I prefer an <no-op> RPC for this purpose.
It would be better if the session counters were not affected,
but that would require protocol changes.
Causing error counters to increment for keep-alives is bad.


Andy


> >   For when the NC/RC-server is the transport-initiator (call-home):
> >
> >     - if there is a lull, the server could send a notification
> >       and wait for the client to send an RPC of some sort, which
> >       the server would, presumably, send a reply for, to complete
> >       the protocol transaction.  The downside to this approach
> >       is that it is wholly dependent on the client processing the
> >       notification correctly (i.e., it's not baked into the NC/RC
> >       protocols themselves).
>
> If you do call-home, there is still a client who could send keep alive
> messages. But yes, if you only stream notifications, then the server
> receives no feedback from the client in NETCONF (and I assume the same
> it true for RESTCONF notification streams).  So here it is easier to
> say "protocol keep alive" than it is to work out the details.
>
> >   As for removing keepalives altogether, please note the SHOULD
> >   in RFC 8071, S7.
>
> Yep, but this text is specific for TLS and SSH and it seems TLS
> libraries practically have an issue here.
>
> >   Another idea is to keep them, but add an
> >   enumeration called something like "protocol-layer" (which
> >   protocol layer should the keepalives occur) with a single
> >   built-in option ("crypto-layer"?) and then let some future
> >   module augment-in an additional enum like "app-layer".
>
> My point is that working out protocol layer keep alives is not as easy
> as it may sound (unless someone has a solution I can't think of) and
> the question is whether we want to hold off the documents until
> someone found a solution. It seems, we can define crypto layer
> keep-alives with a feature and then implementations will have to deal
> with this (for SSH this seems less an issue, so this affects NC over
> TLS primarily and also RC) and perhaps we can also define TCP layer
> keep-alives with a feature and with a warning attached to it (could be
> that the security ADs are OK with that if the warning makes the issues
> clear). For both keep-alives, we know how they would work.
>
> Protocol layer keep-alives are something new to be invented and it is
> somewhat unclear how they would work for the notification streaming
> case. It seems protocol layer keep-alives can be developed separately
> and then augmented in where the keep-alives are configured. A short
> RFC that details how the keep-alive messages work plus an augmentation
> of the configuration model (perhaps even just the definition of another
> identity).
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>