Re: [netconf] Issues with draft-ietf-netconf-udp-notif-04

[Pierre Francois <[e-mail]>]

Hello Andy,

Thanks for the feedback, answers inline.

Le mar. 16 nov. 2021 à 04:45, Andy Bierman <[e-mail]> a écrit :

> Hi,
>
> I am wondering if there implementations of this draft already.
> IMO there are problems with in that prevent reasonable and
> optimal implementations.
>

There is support of udp-notif publisher in VRP.
There is a C collector lib for udp-notif in
https://github.com/insa-unyte/udp-notif-c-collector


> 1) Use of UDP as the Application Message Framing
> UDP is a transport protocol.  Tightly coupling one
> NETCONF notification message to one UDP frame (+ fragments)
> is not very optimal.
>

There is a segmentation option in the protocol, so a udp notif message is
not tightly coupled to a UDP frame.


>
> 1A) wastes space in the UDP frame if the NETCONF notification
>     happens to be short
>

I don't get it, I'm sorry. To me a UDP header + small udp-notif header is
rather short.


> 1B) imposes an application-level max-message-size
>

Not with the segmentation option, do we agree?


>
> 2) Not Efficient for Streaming Servers (no Message Chunking)
> The application framing in NETCONF and RESTCONF (HTTP) is not
> coupled to any transport protocol. Instead, a sender may emit as
> many message chunks as desired. This is how a streaming server works.
> Content comes from many different sources and it is sent on-the-fly
> in chunks, instead of constructing large replies.
>
>     - Application framing allows multiple notifications in one UDP frame
>     - Application framing does not need a max-message-size.
>       Streaming servers often do not know the size of the data that will
> be sent
>       in a notification.
>

I think we meet these goals. Let me think about this further.


>
> Q1) Should proprietary encoding be used to support application-layer
> framing
>        or should the standard support it?
>

I think we'd need to meet on this or else it will end up with thousands of
long emails ;)


>
> 3) Protocol Message Encoding for CBOR
> The NETCONF notification message is not modelled in YANG.
> This is an open issue for YANG to CBOR encoding.
> https://github.com/core-wg/yang-cbor/issues/96
>
> The "notification" and "eventTime" elements do not have YANG definitions.
> SID assignments for these elements will be needed.
> This draft is the likely place for these SID assignment requests to
> the IESG and IANA.
>

Shouldn't these be transport agnostic? I don't see why this would be bound
to udp-notif only and not, say, https-notif.


>
> 4) Subscription-ID Missing from Header
> It is quite possible for one message generator to create
> messages for multiple subscriptions.  The subscription-ID
> will be needed to dispatch notifications to subscribers correctly.
> The Observation-Domain-ID is not sufficient.
>

Same answer as above, we understand obs-domain-id to be used in the
transport to meet load-balancing goals, but thought it would violate layers
to place subscription-IDs in the transport itself.


>
> 5) Private Encoding Option does not seem interoperable
>
The "Enc. Descr" field is completely opaque.
>

Correct.


> This field could be structured to provide the "ET number space owner"
> e.g, urn [wsp description]
>

Mmm it's a valid option. Our opinion was that once you want it
interoperable, you should make it standard instead of private.
If the wg thinks we should kinda standardize private options, I'm
personally okay to add that to the draft.


>
> Andy
>

Thanks a lot for your comments,

Pierre.

Le mar. 16 nov. 2021 à 04:45, Andy Bierman <[e-mail]> a écrit :

> Hi,
>
> I am wondering if there implementations of this draft already.
> IMO there are problems with in that prevent reasonable and
> optimal implementations.
>
> 1) Use of UDP as the Application Message Framing
> UDP is a transport protocol.  Tightly coupling one
> NETCONF notification message to one UDP frame (+ fragments)
> is not very optimal.
>
> 1A) wastes space in the UDP frame if the NETCONF notification
>     happens to be short
> 1B) imposes an application-level max-message-size
>
> 2) Not Efficient for Streaming Servers (no Message Chunking)
> The application framing in NETCONF and RESTCONF (HTTP) is not
> coupled to any transport protocol. Instead, a sender may emit as
> many message chunks as desired. This is how a streaming server works.
> Content comes from many different sources and it is sent on-the-fly
> in chunks, instead of constructing large replies.
>
>     - Application framing allows multiple notifications in one UDP frame
>     - Application framing does not need a max-message-size.
>       Streaming servers often do not know the size of the data that will
> be sent
>       in a notification.
>
> Q1) Should proprietary encoding be used to support application-layer
> framing
>        or should the standard support it?
>
> 3) Protocol Message Encoding for CBOR
> The NETCONF notification message is not modelled in YANG.
> This is an open issue for YANG to CBOR encoding.
> https://github.com/core-wg/yang-cbor/issues/96
>
> The "notification" and "eventTime" elements do not have YANG definitions.
> SID assignments for these elements will be needed.
> This draft is the likely place for these SID assignment requests to
> the IESG and IANA.
>
> 4) Subscription-ID Missing from Header
> It is quite possible for one message generator to create
> messages for multiple subscriptions.  The subscription-ID
> will be needed to dispatch notifications to subscribers correctly.
> The Observation-Domain-ID is not sufficient.
>
> 5) Private Encoding Option does not seem interoperable
> The "Enc. Descr" field is completely opaque.
> This field could be structured to provide the "ET number space owner"
> e.g, urn [wsp description]
>
>
> Andy
>
>
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>