Re: [netconf] Comments on draft-ietf-netconf-distributed-notif

[Mahesh Jethanandani <[e-mail]>]

Hi Thomas,

I see that the authors have published an updated version of both the distributed-notif and udp-notif draft. But I believe the issues I raised in and after IETF 113 do not seem to have been addressed in the latest version of the drafts.

There were two asks. One was to show an example of how a notification would be setup between publisher and receiver. Note, this is different from establishing a subscription. In the example, you need to show how a publisher knows where to send a notification message, the transport parameters that need to configured, what data encoding is being used etc. I do not see such an example. BTW, the figure numbers are completely messed up

Figure 3: Fig. 4 "establish-subscription" Request

The second ask was around clarification of Observation Domain ID, and what happens to that ID if the transport is something other than UDP. Currently, Observation Domain ID is defined as follows. 



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-----+-+-------+---------------+-------------------------------+
     | Ver |S|  MT   |  Header Len   |      Message Length           |
     +-----+-+-------+---------------+-------------------------------+
     |                    Observation-Domain-ID                      |
     +---------------------------------------------------------------+
     |                         Message-ID                            |
     +---------------------------------------------------------------+
     ~                          Options                              ~
     +---------------------------------------------------------------+

                 Figure 2: UDP-Notif Message Header Format


Per this figure, the Observation Domain ID is very much a part of the UDP-Notif Message Header. This header therefore is applicable when the transport is UDP.  However, per the draft, these notifications can be transported over other transports also. If the transport is TCP/HTTP or QUIC, can you specify what happens to this header, and how is Observation Domain ID carried in other transport formats?

Thanks

> On Mar 22, 2022, at 8:39 AM, [e-mail] wrote:
> 
> Hi Mahesh,
> Is that the case? And does the following figure capture your point?
> Yes. Both correct.
> That is correct, and preferably an example for each type of transport supported.
> Ack. Will be addressed in the next version.
> [mj] What is your recommendation? If you believe the Observation Domain ID should be part of the message header, then your message header is different for different transports. If your recommendation is that it should be part of the notification, then you need to modify the message header in the UDP-Notif draft to move it out of the Message Header and show it as part of Notif Message.
> For protocols which share the same transport session and support segmentation, Observation Domain ID should be in the transport header so that the transport protocol doesn't need to inspect the upper layer. If segmentation support is not needed, then notification header would be a good choice.
>  
> Best wishes
> Thomas
>  
> From: Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>> 
> Sent: Tuesday, March 22, 2022 3:36 PM
> To: Graf Thomas, INI-NET-TCZ-ZH1 <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: Re: [netconf] Comments on draft-ietf-netconf-distributed-notif
>  
> Hi Thomas,
>  
> Thanks for your responses. Please see inline.
> 
> 
> On Mar 22, 2022, at 2:13 PM, <[e-mail] <mailto:[e-mail]>> <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Hi Mahesh,
>  
> Section 3 of the document (https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif#section-3 <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-distributed-notif%23section-3&data=04%7C01%7CThomas.Graf%40swisscom.com%7Ca8c3039756fa468dadbd08da0c116036%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637835566017125200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xiLrr7spyt%2BZI%2FvBi54UCkK1PVNnJRkQcupUr0XhcIo%3D&reserved=0>) describes the motivation. Being able to recognize lost and corrupt YANG notification messages when multiple publisher process sharing the same transport session properties.
>  
> Section 8 (https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif#section-8 <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-distributed-notif%23section-8&data=04%7C01%7CThomas.Graf%40swisscom.com%7Ca8c3039756fa468dadbd08da0c116036%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637835566017125200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fH71Cdoru%2FE2QsQyBr%2BYeaRO8SS7lYfa8%2Fj7S%2BfV4hw%3D&reserved=0>) describes the differences between draft-ietf-netconf-udp-notif and draft-ietf-netconf-https-notif.
>  
> If this was transported over another transport, e.g. TCP/HTTP or QUIC, would they require a similar header?
>  
> If multiple publisher process sharing the same transport session properties, yes.
>  
> If so, what would it look like.
>  
> Section 2 (https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif#section-2 <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-distributed-notif%23section-2&data=04%7C01%7CThomas.Graf%40swisscom.com%7Ca8c3039756fa468dadbd08da0c116036%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637835566017125200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Vxuy1iAQr4aePMSaGaCp%2FFoCDrqfjRA3m1Clz2ZXCMs%3D&reserved=0>) describes Observation Domain ID as a 32-bit identifier. 
>  
> Observation Domain ID can also be part of the YANG notification messages header as describes in draft-ietf-netconf-distributed-notif Section 3(https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif#section-3 <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-distributed-notif%23section-3&data=04%7C01%7CThomas.Graf%40swisscom.com%7Ca8c3039756fa468dadbd08da0c116036%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637835566017125200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xiLrr7spyt%2BZI%2FvBi54UCkK1PVNnJRkQcupUr0XhcIo%3D&reserved=0>)
>  
> [mj] My first observation is that UDP transport header format for that you describe in Section 3.2 of draft-ietf-netconf-udp-notif is more than just a 32-bit field that describes the Observation Domain ID. Most of the other fields are there to support the transport, i.e. UDP in this case. You seem to be suggesting that for TCP/HTTP  (and maybe for QUIC also), only the 32-bit field is needed between the transport layer and the notification messages. Is that the case? And does the following figure capture your point?
>  
> <image001.png>
> 
> 
>  
> With this transport message header, do you still believe you are transport independent?
>  
> Yes. Because the Observation Domain ID can be either be implemented in the transport header or in the YANG notification messages header.
>  
> [mj] What is your recommendation? If you believe the Observation Domain ID should be part of the message header, then your message header is different for different transports. If your recommendation is that it should be part of the notification, then you need to modify the message header in the UDP-Notif draft to move it out of the Message Header and show it as part of Notif Message.
> 
> 
>  
> How does the publisher know where to send the notification messages? If this configuration a part of yang push, maybe an example of how yang push needs to be configured would be nice.
>  
> Yes it is part of the YANG push configuration. If I understand you correctly, you would like to see an example YANG push subscription including with the transport session properties as well. Correct?
>  
> [mj] That is correct, and preferably an example for each type of transport supported.
>  
> Thanks.
> 
> 
>  
> Best wishes
> Thomas
>  
> From: netconf <[e-mail] <mailto:[e-mail]>> On Behalf Of Mahesh Jethanandani
> Sent: Tuesday, March 22, 2022 11:00 AM
> To: Netconf <[e-mail] <mailto:[e-mail]>>
> Subject: [netconf] Comments on draft-ietf-netconf-distributed-notif
>  
> Hi Authors,
>  
> I promised in the NETCONF WG 113 meeting that I would provide comments on the draft. These comments were provided in the meeting, and I will expand on them here. 
>  
> My first comments was on the transport. The authors have asserted that this draft is transport independent. The motivation section of the draft, Section 3, talks about Observation Domain ID in the transport message header of the YANG notification, and very specifically cite how the UDP transport draft supports this header. Two comments. If this was transported over another transport, e.g. TCP/HTTP or QUIC, would they require a similar header? If so, what would it look like. If not, why not? With this transport message header, do you still believe you are transport independent?
>  
> My second comment was around examples. The examples in the Appendix focus on establishing subscription, modify subscription, and subscription started. However, it was not clear how would a notification be setup between publisher and receiver. How does the publisher know where to send the notification messages? If this configuration a part of yang push, maybe an example of how yang push needs to be configured would be nice. Similarly, if UDP transport is used for transport, what needs to be configured to use UDP transport, including any DTLS configuration.
>  
> Thanks.
>  
> 
> Mahesh Jethanandani (as contributor)
>  
>  
>  
>  
> 
>  


Mahesh Jethanandani (as a contributor)
[e-mail]