Re: [Netconf] Anyone want just Configured Subscriptions?

[Andy Bierman <[e-mail]>]

On Sat, Jul 7, 2018 at 4:50 PM, Kent Watsen <[e-mail]> wrote:

>
>
>
>
> > IMO there needs to be at least 1 complete standard solution that servers
> must support.
>
> > I would prefer that configured subscriptions be held back until a
> fully-baked standard
>
> > solution is ready.
>
>
>
> This option will be discussed in Montreal.  If the WG agrees, then the
> below can be
>
> discussed later.
>
>
>
>
>


You convinced me that binary encoding of regular <rpc> message flows
is not a high priority for NETCONF.  If the device or network is that
constrained,
maybe CoMI is a better choice.  Also, use of <get> will probably diminish
as YANG Push
is available instead.


> I don't think this fits the intent of CallHome.
>
>
>
> RFC 8071 is very clear (see C8 and S6), the NC or RC protocol *starts*.
> Also, from
>
> https://mailarchive.ietf.org/arch/msg/netconf/QS14f-6w-BzCD9280uuO06CZK6c,
> I
>
> wrote:
>
>
>
>  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?
>
>
>

The problem is that the RFC allows the callhome session to be used for
normal NETCONF operations,
so the client can send <rpc> requests in XML at any time.

I suppose there is a use-case for pre-configuring the subscriptions and then
using call-home to connect to a controller that somehow knows all the
subscriptions that could be configured (so no reads required).
Since the controller needs to know about all the subscriptions anyway,
it can just all <establish-subscription>


>
>
> > IMO a new protocol is needed that is dedicated to the binary transport
>
> > of notification subscription data.
>
>
>
> Agreed, and I'd like that protocol to be:
>
>   1) mandatory to implement, if the "configured" feature is enabled.
>

I would give it its own feature


>   2) run over UDP, so events can go out line cards directly.
>

or run over TCP I hope



>   3) be optionally encrypted, as there are scenarios where it's safe to
> send unencrypted
>
>       events to a receiver within a security perimeter, which can relay
> the events over an
>
>       encrypted connection to a remote system, so as to offload the burden
> from the NE
>
>       equipment to a cheaper general purpose computer.
>
>
>

This was discussed in I2RS WG and a YANG extension can be used to tag
ok-for-unencrypted, so this might get approved by the IESG.



> FWIW, COAP is on top of UDP, and its use of DTLS is optional, so it seems
> like a good
>
> match, though I don't know if it also needs a client-initiated RPC to
> start the flow of logs.
>
> Out of curiosity, has anyone ever compared COAP to gRPC?
>
>
>


We have implemented RESTCONF over CoAP, but not with DTLS.
This was also XML and JSON, not CBOR.

I would rather let TCP deal with fragmentation instead of using CoAP Block.
IMO the new protocol will be easier to get approved (i.e., much smaller in
scope)
if CoAP is reused instead of using raw UDP.

GPB proto files have to be defined in advance.
Generic protobuffs like gNMI are not as efficient.
CBOR+SID requires no static templates, but does require that
a lot of SID state be kept. IMO the efficiency is very impressive, and
quite worth
the SID caching for YANG Push.



>
> Kent // contributor
>
>
>
>
>
>
>


Andy