Re: [netconf] Tsvart early review of draft-ietf-netconf-udp-notif-11

[Alex Huang Feng <[e-mail]>]

Dear Michael,

Thanks for all the comments and raised issues. 
Thanks Mahesh for arranging the tsvdir review.

We have submitted a new version of the draft addressing the raised issues: 
- https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-12
- Diff: https://author-tools.ietf.org/iddiff?url1=draft-ietf-netconf-udp-notif-11&url2=draft-ietf-netconf-udp-notif-12&difftype=--html

We also have some comments regarding some raised points:

* I wonder how the sender side knows, what the receiver is able to process.
  It might make sense to exchange this information at the beginning of
  the communication.
AHF: UDP-notif is designed for “Configured Subscriptions”, meaning it is expected that the operator configures transport in the exporter node and the collector.

* Using the suggested protocol results in a high bandwidth using UDP based
  communication. It is really suggested to use some sort of congestion
  control. However, the document arguments that this is not needed, since
  the protocol is used only on "managed networks" as stated in Section 5.1.
  What confuses me is that in Section 6, the document discusses the use
  of the protocol in "open or unsecured" networks. How does this relates
  to "managed networks"? In my understanding, this does not fit. Do you
  really not need some congestion controller?
  I would expect to see some sort of circuit breaker, but have not seen
  a description of it.
AHF: We have removed “open networks” from the draft. UDP-notif is designed to be deployed in controlled environments provisioned for the purpose of monitoring, not the General Internet as defined in https://www.rfc-editor.org/rfc/rfc8085.html#section-3.6

* Section 4.2
  What should happen if the Private Encoding Option is present, but the S-bit is
  not set? What should happen if the S-bit is set, but the Private Encoding Option
  is not present?
AHF: The private Encoding Option is informative, the operator can configure the collector anticipating the collection of a private encoding.
We have added that when S is set, the private option SHOULD be present.

Cheers,

Alex, on behalf of the authors


> On 17 Nov 2023, at 17:52, [e-mail] wrote:
> 
>> On Nov 16, 2023, at 01:37, Mahesh Jethanandani <[e-mail]> wrote:
>> 
>> 
>> 
>>> On Nov 15, 2023, at 2:17 PM, [e-mail] wrote:
>>> 
>>>> On Nov 15, 2023, at 22:47, Mahesh Jethanandani <[e-mail]> wrote:
>>>> 
>>>> Hi Michael,
>>>> 
>>>> Thanks for your review of the document.
>>>> 
>>>> One of the discussions before the WG was on what the draft calls out as “segmentation”. The draft proposes this solution to deal with UDP packets that are larger than the path MTU, and will result in fragmentation at the IP level. Note, the end application requires that packets be received in sequence and be complete for the application to process. Otherwise, the packet needs to be discarded. Also to note is that there is no retransmission of the frame if the packet is discarded for any reason.
>>>> 
>>>> Did you have any comments from a transport perspective, on applications that run over UDP, and propose to use fragmentation (segmentation in this draft) and reassembly logic at the application level with no retransmission?
>>> Hi Mahesh,
>>> 
>>> what user message sizes or number of fragments per user message do you expect?
>> 
>> The discussion was for max-size UDP message - 64K.
> I updated the review. Sorry for missing to read the comment in the review request.
> 
> If you have further questions, please let me know.
> 
> Best regards
> Michael
>> 
>> Thanks
>> 
>>> 
>>> Best regards
>>> Michael
>>>> 
>>>> Thanks.
>>>> 
>>>>> On Nov 15, 2023, at 7:14 AM, Michael Tüxen via Datatracker <[e-mail]> wrote:
>>>>> 
>>>>> Reviewer: Michael Tüxen
>>>>> Review result: Not Ready
>>>>> 
>>>>> Major issue:
>>>>> Using the suggested protocol results in a high bandwidth using UDP based
>>>>> communication. It is really suggested to use some sort of congestion
>>>>> control. However, the document arguments that this is not needed, since
>>>>> the protocol is used only on "managed networks" as stated in Section 5.1.
>>>>> What confuses me is that in Section 6, the document discusses the use
>>>>> of the protocol in "open or unsecured" networks. How does this relates
>>>>> to "managed networks"? In my understanding, this does not fit. Do you
>>>>> really not need some congestion controller?
>>>>> I would expect to see some sort of circuit breaker, but have not seen
>>>>> a description of it.
>>>>> 
>>>>> Minor issues:
>>>>> * Section 3.2
>>>>> I guess all binary fields in the header shown are expected to be transmitted
>>>>> and received in network byte order (big endian), but I would prefer to make
>>>>> this explicit.
>>>>> * Section 3.2
>>>>> Is it allowed that the Message ID wraps around? It seems so, but I think it is
>>>>> better to make that explicit.
>>>>> * Section 4.1
>>>>> The length field in the UDP header is limited to 65535 bytes, therefore the
>>>>> UDP payload is limited to 65535 - 8 bytes, which is 65527 bytes. This is smaller
>>>>> than stated in the first sentence. In addition to that, when using IPv4, the size
>>>>> is even 20 bytes smaller, since the IPv6 header contains a 16-bit field holding
>>>>> the total length of the IPv4 packet.
>>>>> * Section 4.2
>>>>> What should happen if the Private Encoding Option is present, but the S-bit is
>>>>> not set? What should happen if the S-bit is set, but the Private Encoding Option
>>>>> is not present?
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> Mahesh Jethanandani
>>>> [e-mail]
>> 
>> 
>> 
>> Mahesh Jethanandani
>> [e-mail]
>> 
>> 
>> 
>> 
>> 
>> 
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf