[netconf] Re: questions about draft-udp-notif-14

[Andy Bierman <[e-mail]>]

On Thu, Jul 18, 2024 at 8:40 AM Alex Huang Feng <
[e-mail]> wrote:

> Dear Andy,
>
> Thanks for the review and comments.
>
> Here my comments and proposal on top of Thomas’ comments.
>
> Please see inline.
>
> On 10 Jul 2024, at 19:27, Andy Bierman <[e-mail]> wrote:
>
> Hi,
>
> I am trying to implement this draft
> https://www.ietf.org/archive/id/draft-ietf-netconf-udp-notif-14.html
>
> General:
>
> The intended use of this protocol seems to be where a server creates fixed
> size reports
> and the server knows the report size. This is difficult if a report
> includes nested
> YANG list entries.
>
> YANG Push is used for multiple purposes, including datastore replication.
> Initial or resych payloads can be very large.  Datastore changes are
> subject
> to YANG validation so they cannot be refactored into many tiny
> transactions.
>
> Streaming servers may not know the exact entries or the sizes in advance.
>
>
> 1) IP fragmentation
>
> Even though a UDP segment is about 64K bytes, the max-segment-size
> is the real fragment length. (e.g. about 1200 bytes)
>
> An implementation of this specification SHOULD NOT rely on IP
> fragmentation by default to carry large messages. An implementation of this
> specification SHOULD either restrict the size of individual messages
> carried over this protocol, or support the segmentation option. The
> implementor or user SHOULD take into account the IP layer header size when
> setting the max-segment-size parameter to avoid fragmentation at the IP
> layer.
>
>
> The max-segment-size is the size of a UDP-notif segment.
>
> Definition in the YANG module:
>
> UDP-Notif provides a configurable max-segment-size to
>         control the size of each segment (UDP-Notif header, with
>         options, included).
>
>
> The last sentence about taking into account the IP layer header size is
> because a user might set the max-segment-size to the MTU of the interface.
> Given that the segment+IP header might be bigger than the MTU, the
> interface might perform IP fragmentation.
>
> Proposal:
>
>

I think it is too complicated to have this configuration.
This parameter should only apply if the segmentation feature is advertised.

 I am OK with a mandatory 1 datagram solution for unreliable use-cases.
I guess dynamic subscriptions can still be used for reliable use-cases.

UDP works for periodic updates where a missed or duplicate update does not
really cause any problems.
It is not so good for on-change subscriptions where any error causes a full
resync.

Some examples given, like monitoring interface operStatus changes, are
better handled with reliable transports.


Andy


OLD:
> Consequently, implementations of the mechanism SHOULD provide a
> configurable max-segment-size option to control the maximum size of a
> payload.
>
> NEW:
> Consequently, implementations of the mechanism SHOULD provide a
> configurable max-segment-size option to control the maximum size of a
> UDP-Notif segment.
>
> OLD:
> The implementor or user SHOULD take into account the IP layer header size
> when setting the max-segment-size parameter to avoid fragmentation at the
> IP layer.
>
> NEW:
> The implementor or user SHOULD configure the max-segment-size so that the
> size of a UDP-Notif segment and the size of the IP layer together does not
> exceed the MTU of the egress interface.
>
> 2) Segmentation option
>
> Only 32767 segments are allowed for the entire message which is about 40MB
> if IP fragmentation is being avoided.
>
> Segmentation can be disabled by the client on a per-receiver basis.
> Each receiver can set its own max-segment-size.
> This is difficult and expensive to implement.
> Expect that servers will reject complex configurations and clients will
> need to read the user documentation (not the RFC) to know what is
> supported.
>
>
> Yes, we do expect the user to read the documentation of an implementation
> to know if the max-segment-size is supported. And yes if it is not
> supported, we expect the server to reject the configuration.
>
>
> If enable-segmentation=false then the server may reject this setting.
> IMO the protocol is not useful with a max payload of 1 IP packet.
> The YANG Patch overhead alone can take up 100s of bytes.
> Expect that a server will reject a configuration attempting to set this
> parameter to false.
>
>
> The default statement of the leaf enable-segmentation should be set to
> True given the guidelines defined in RFC8085. I propose to change the
> default to True.
> Regarding setting enable-segmentation=false, we expect that in this case,
> the message will be fragmented at IP layer if the UDP-Notif message is
> bigger than the MTU.
>
>
> 3) Overflow indication
> There is no way for the server to indicate that the push update is
> truncated
> and should be discarded. A streaming server may not know how many segments
> are left for the current push update.
>
>
> This is correct. In our implementation (
> https://github.com/network-analytics/udp-notif-c-collector) we use
> timers to tackle this problem.
> The user can set after how much time, if some segments are still missing,
> to discard the received segments.
>
>
> 4) Application Layer
> NETCONF already has an application layer and application message framing.
> The UDP "application' is not clearly defined. It seems to just be "the
> notification message from NETCONF".
>
>
> UDP-Notif is a transport protocol for RFC8639 and RFC8641. We expect to
> use the application layer defined in RFC8641.
>
>
> 5) Implementation details
> For client/server tools that already support notifications, there
> is very little code reuse possible.  Code that uses the base:1.0 or
> base:1.1 message framing cannot rely at all on the transport protocol
> for proper framing.
>
> We are looking at using the NETCONF base:1.1 encoding with enhancements.
> The "NETCONF stream" encoding solves every problem mentioned above,
> except overflow indication, because that can never happen.
>
>
> I am not aware of NETCONF stream as a solution. Could you provide more
> references on this?
>
> I reflected these changes in -15:
> https://author-tools.ietf.org/diff?doc_1=draft-ietf-netconf-udp-notif-14&url_2=https://raw.githubusercontent.com/netconf-wg/udp-notif/main/draft-ietf-netconf-udp-notif-15.txt
>
> Regards,
> Alex
>
>
> Andy
>
>
>
> ReplyForward
> _______________________________________________
> netconf mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
>