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

[Andy Bierman <[e-mail]>]

On Fri, Jul 19, 2024 at 6:58 AM <[e-mail]> wrote:

> Dear Andy,
>
>
>
> Two comments.
>
>
>
> What you are proposing is that the transport now is the semantic of the
> notification in the messaging layer. That would break the boundary of
> network layers.
>
>
>

OK never mind.
I think the application layer is already coupled to the UDP datagram and
only one message is allowed.
The draft is clearly not being used as the transport for the NETCONF
application layer since
NETCONF has message framing and no artificial limits on application message
size.

eventTime and observation-time have two different semantics. They are not
> interchangeable.
>
>
>

eventTime was added mostly to support replay, which is not relevant to YANG
Push.
I was not suggesting it was the same as observation time.
I was suggesting eventTime could be optional.
IMO if the 2 timestamps are within a few seconds of each other, the 2nd
timestamp is not useful.
Since the gap is usually milliseconds, the NETCONF WG left it out of RFC
5277.

Best wishes
>
> Thomas
>

Andy


>
>
> *From:* Andy Bierman <[e-mail]>
> *Sent:* Thursday, July 18, 2024 1:11 PM
> *To:* Alex Huang Feng <[e-mail]>
> *Cc:* Netconf <[e-mail]>
> *Subject:* [netconf] Re: questions about draft-udp-notif-14
>
>
>
> *Be aware:* This is an external email.
>
>
>
>
>
>
>
> 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.
>
>
>
>
>
> I just realized that the solution for UDP is already available.
>
> Since the application message is just the notification, the SID for
> 'notification' is redundant
>
> and not needed.
>
>
>
> If there is an observation timestamp then eventTime is not really needed.
>
> The eventTime leaf could be encoded as an option if needed.
>
> The XML, JSON, or CBOR payload would represent just the event from the
> notification-stmt.
>
> There is no need for this UDP protocol to use RFC 5277
> message header format.
>
>
>
>
>
> Andy
>
>
>
>
>
> 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:
>
>
>
> 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]
>
>
>
>