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

[Andy Bierman <[e-mail]>]

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.¶
<https://www.ietf.org/archive/id/draft-ietf-netconf-udp-notif-14.html#section-4.1-6>
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.

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.

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.

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".

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.

Andy



ReplyForward