Re: [Netconf] request for comments on draft-ietf-netconf-udp-pub-channel

Hi Aijun,

Thank you very much for your review and comments. Please see my reply in line.

Best,
Tianran

> -----Original Message-----
> From: Aijun Wang [mailto:wangaijun@tsinghua.org.cn]
> Sent: Thursday, June 07, 2018 4:53 PM
> To: Tianran Zhou <zhoutianran@huawei.com>
> Cc: netconf@ietf.org
> Subject: Re: request for comments on draft-ietf-netconf-udp-pub-channel
> 
> Hi Tianran,
> 
> I have read this document. In general, it's in good shape and useful.
> Here I have some comments:
> 
> 1. Section 1, the "Introduction" mentions: "Firstly, data collector will
> suffer a lot of TCP connections from, for example, many line cards equipped
> on different devices." and follows "the centralized design requires data to
> be internally forwarded from those line cards to the push server, presumably
> on a main board, which then combines the individual data items into a single
> consolidated stream."
> I agree with the later point. And if so, why do you think the first point
> is sustained, i.e., the data collector should not be the bottle neck.

[Tianran]: These two are not conflict. The logic is like this:
a) distributed data collection is necessary because of the later point. 
b) this(a) will generate a lot of connections to the collector if TCP is used.  
We will try to rephrase these section later to make it clear.

> 2. Section 3, the "Solution Overview" mentions: "The Component Subscriptions
> are distributed to the Agents. Subsequently, each data originator generates
> its own stream of telemetry data, collecting and encapsulating the packets
> per the Component Subscription and streaming them to the designated
> Receivers."
> Does the line card store data with consistent format follows the YANG schema?
> Otherwise how to achieve the mechanism that described by this document?

[Tianran]: I would leave this question to Guangying. He will respond later. But we have some more details on the dependent draft: 
https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stream-originators/

> 3. Section 4.2 "Configured Subscription" says "The first message MUST be a
> separate subscription-started notification to indicate the Receiver that the
> pushing is started. Then, the notifications can be sent immediately without
> any wait."
> But you did not explain why this is "MUST". It seems not obviously necessary.

[Tianran]: This message just follows some other YANG-Push transport (e.g. http). We want to use the same state machine. But here the UDP message may not be sequential. So I agree with you that the "subscription-started" message is not so necessary.

> 4. Section 5.2, in "Data Format of the Message Header", is a line cards ID
> necessary? So that the receiver know where the data is from. This may be useful
> when a line card has problem and wrongly send a lot of data.

[Tianran]: Instead of the line card ID, we designed the Subscribed Domain ID. With this parameter, the receiver can easily identify messages generated from the same Subscription Domain. I.e., Multiple line card belongs to the same router will use the same Subscribed Domain ID. Because when subscription, all the line cards are invisible to the collector. So here the receiver should not know which line card has problem, and it's actually no use for the collector. If there is feedback mechanism, the collector should notice the master that some messages are wrongly received with the content ID (say the path). And the master can detect the problem happened.

> 5. Section 5.3.1., why "Reliability Option" is necessary. If I need a reliable
> transport, why not just use a TCP based channel? Then all the retransmission,
> congestion control are solved. And if "Reliable Streaming Mode" is enabled,
> the line card need to maintain the state, which loss the simple merit of UDP.

[Tianran]: When we choose UDP instead of TCP, we pay more attention on the performance. Firstly, reliability is optional. Then, even if it's used, it's only use for the receiver to check whether all the messages are received. It will not cause the flow/congestion control. And the retransmission is not necessarily supported. So the state is much simpler then TCP.  

> 6. I do not quite understand the example showed in section 5.3.1. Is there
> any problem on the received ID? Which is the Message ID and which is the
> previous ID? Why Message ID 9 is not received by B? ...

[Tianran]: This is a good catch. Message ID 9 was missed. I am sorry that we have not make it clear, we will rephrase this example later. We showed the example as [previous message ID, message ID].

> 
> Best Regards.
> 
> Aijun Wang
> Network R&D and Operation Support Department China Telecom Corporation
> Limited Beijing Research Institute,Beijing, China.
> 
> > -----Original Message-----
> > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Tianran
> > Zhou
> > Sent: Thursday, June 07, 2018 10:03 AM
> > To: netconf@ietf.org
> > Subject: [Netconf] request for comments on
> > draft-ietf-netconf-udp-pub-channel
> >
> > Hi WG,
> >
> > We've got some comments on the UDP based Publication Channel for
> > Streaming Telemetry. And we are going to update it, specifically on
> > the
> security aspect.
> > https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-channel/
> >
> > Could you please help to review?
> > Any comment is appreciated.
> >
> > Thanks,
> > Tianran
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf