[netconf] Re: WGLC for udp-notif

[Andy Bierman <[e-mail]>]

Hi,

I have implemented most of this draft for the publisher and collector,
as part of the following module set:

    ietf-distributed-notif@2024-04-21
    ietf-notification-capabilities@2022-02-17
    ietf-sid-file@2024-07-31
    ietf-subscribed-notif-receivers@2024-02-01
    ietf-subscribed-notifications@2019-09-09
      Features:
         configured
         dscp
         encode-json
         encode-xml
         replay
         subtree
         xpath
    ietf-system-capabilities@2022-02-17
    ietf-udp-client@2024-06-27 (I)
    ietf-udp-notif-transport@2024-10-17
      Features:
         encode-cbor
         segmentation
    ietf-yang-library@2019-01-04
    ietf-yang-patch@2017-02-22
    ietf-yang-push@2019-09-09
      Features:
         on-change
    ietf-yang-push-revision@2024-12-17
      Features:
         yang-push-revision-supported
    ietf-yang-revisions@2024-06-04 (I)
    ietf-yang-semver@2025-01-21 (I)


The following comments are related to the UDP-Notif draft.


Andy



# Applicability Issues

Configured subscriptions are allowed for event streams and datastores.
The UDP-Notif protocol may not be suitable for all use-cases covered
by configured subscriptions.

## Event streams

These messages are probably sensitive to loss and reordering.
There are no mechanisms to break into smaller events or even indicate
that a partial message was sent, so segmentation needs to be supported.

The 'subscription-started' and 'subscription-modified' messages
are very important mandatory subscription-state events that have this same
issue.

## Datastores

The existing YANG Push solution needs some improvements, but it does
allow the operator to control the scope of the updates, so it is quite
possible to use UDP-Notif even without segmentation.

Some YANG Push Concepts:

-  The datastore + filter defines the scope of the reports for the
subscription
-  A get-data() operation on the same datastore + filter is expected to
produce
   the same 'full result' as a push-update.
-  A server is free to send any 'edits' to the full result in a
   push-change-update, using any valid YANG Patch structure.

UDP-Notif Improvements:

There is a much better solution (although spread out over many drafts),
so not sure if this draft needs more text, except to explain the use-cases.

Instead of sending the entire full result in a push-update, send an
idempotent patch for a predictable subset, where it is
OK to replace the current subtree with the new subtree, and deletions/moves
are not expected.

This is implied by the '/interfaces' example where
an update for a single interface list entry is sent each push-update.
This also works well for distributed publishers, each sending updates for a
subset
of list entries (e.g., interfaces).

YANG Patch was not designed for high frequency YANG Push and it is too
complicated
for a collector to support.

# YANG Module Issues

- feature segmentation

The 'segmentation' feature should be removed, so that it is mandatory to
implement by the publisher, and optional-to-use (via the subscription
config);.
It is not difficult for the sender to support segmentation.


-  leaf max-segment-size

     when "../enable-segmentation = 'true'";


This when-stmt should be removed, and the leaf applies in either case.
There is no need to rely on a proprietary setting when the module has
this leaf.

     type uint16;


Not sure why a server should support a full uint16 for the segment size.
We are supporting range "1000 .. 9000".


# Implementation Issues

1) setup time

YANG Push says the publisher can start sending updates immediately after
the 'subscription-started' event. It would be better if a configurable
leaf for 'setup-time' was available, so the UDP-Notif Collector has
enough time to setup the YANG modules and SID files for the updates.

2) message state

The UDP-Notif Collector must keep state for each segmented message stream.
The 'host-name' leaf is not available to the collector.
E.g. the 'recvfrom' system API returns only a sockaddr for the sender.

A segmented message stream is scoped as follows:

  ip-addr . publisher-id  . message-id  . segment-id

There is a requirement that all publishers using the same source IP address
have a unique publisher-ID.

The transport layer should not need to parse and use the payload message
to reassemble messages.

The application layer can still manage updates by host-name.

On Thu, Jan 30, 2025 at 7:07 AM Per Andersson <[e-mail]> wrote:

> Hi!
>
> This email begins a two-week WGLC on:
>
> UDP-based Transport for Configured Subscriptions
> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-18
>
> Please take time to review this draft and post comments by February
> 13.  Favorable comments are especially welcomed.
>
> None of the authors or contributors have declared IPR:
>
> https://mailarchive.ietf.org/arch/msg/netconf/VQUz-x7mEWVmdxwG_ZZAbN-mlUk/
>
>
> --
> Per, co-chair
>
> _______________________________________________
> netconf mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>