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

From: Tianran Zhou <[email-masked]>
Date: Thu, 7 Jun 2018 02:03:05 +0000

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

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 7 Jun 2018 16:52:32 +0800

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

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.

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.

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.

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

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:[email-masked]] On Behalf Of Tianran 
> Zhou
> Sent: Thursday, June 07, 2018 10:03 AM
> To: [email-masked]
> 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.
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 8 Jun 2018 08:06:15 +0000

Hi Aijun,

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

Best,
Tianran

> From: Aijun Wang [mailto:[email-masked]]
> Sent: Thursday, June 07, 2018 4:53 PM
> To: Tianran Zhou <[email-masked]>
> Cc: [email-masked]
> Subject: Re: request for comments on draft-ietf-netconf-udp-pub-channel
> 
> Hi Tianran,
> 
> 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.

> 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/

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

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

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

---

From: "Zhengguangying (Walker)" <[email-masked]>
Date: Mon, 11 Jun 2018 02:35:35 +0000

Hi Aijun, Tianran,

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

>https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stream-originators/

[Guangying]: Yes, the data send out from line cards will use the consistent format with same YANG schema, no matter what format internally, when it send out will convert to make sure it comply the same YANG schema.

Best,
Guangying (Walker)

-----Original Message-----
From: Tianran Zhou 
Sent: 2018年6月8日 16:06
To: Aijun Wang; Zhengguangying (Walker)
Cc: [email-masked]
Subject: RE: request for comments on draft-ietf-netconf-udp-pub-channel

Hi Aijun,

Best,
Tianran

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

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

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

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

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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 Jun 2018 09:48:24 +0200 (CEST)

Hi,

I have read draft-ietf-netconf-udp-pub-channel-02, but struggle with
some basics.

I don't understand how this new transport is supposed to fit into the
design of draft-ietf-netconf-subscribed-notifications.  For example,
the udp-pub-channel draft seems to expect a request to
"establish-subscription" over NETCONF to send the notifications over
UDP.  But AFAICT this is not possible with the current design of
establish-subscription.

Is the transport in this draft supposed to work for notifications in
general, or only YANG push notifications?

Also, it seems many of the references to yang-push really should be to
subscribed-notifications.

It would also be useful to align terminology with the other
documents.  It seems a "Master" is really the management protocol
server?  And "Agent" is what subscribed-notifications calls a
"publisher"?  Or maybe the "Master" is the "publisher"?

You also use the term "data originator", but I am not quite sure if
that is the same as "Agent"?

/martin

Tianran Zhou <[email-masked]> wrote:
> Streaming Telemetry. And we are going to update it, specifically on
> the security aspect.

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 12 Jun 2018 09:51:00 +0000

Hi Martin,

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

Best Regards,
Tianran

> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Monday, June 11, 2018 3:48 PM
> Subject: Re: [Netconf] request for comments on
> I have read draft-ietf-netconf-udp-pub-channel-02, but struggle with some
> basics.
> 
> I don't understand how this new transport is supposed to fit into the design
> of draft-ietf-netconf-subscribed-notifications.  For example, the
> udp-pub-channel draft seems to expect a request to "establish-subscription"
> over NETCONF to send the notifications over UDP.  But AFAICT this is not
> possible with the current design of establish-subscription.

[ztr]:
Yes, within the design team, we discussed this also. We tried to fit the existing design of draft-ietf-netconf-subscribed-notifications(SN).
In the case of "establish-subscription", existing SN design require the notification to use the same channel as the subscription. But the distributed data collection mechanism(draft-zhou-netconf-multi-stream-originators-02) cannot meet this. Because the notification channel and the subscription channel are always separated. So we require:
   "the Receiver and the Subscriber
   SHOULD be collocated.  So UPC can use the source IP address of the
   Subscription Channel as it's destination IP address.  The Receiver
   MUST support listening messages at the IANA-assigned PORT-X, but MAY
   be configured to listen at a different port."

It's not the only one issue. For configured subscription, SN requires the "subscription-started" message before sending notifications. However, for UDP, we cannot guarantee the notifications arrive the receiver after the "subscription-started". We cannot guarantee "subscription-started" will not lost neither. So I am wandering if the "subscription-started" message is still necessary. 

> Is the transport in this draft supposed to work for notifications in general,
> or only YANG push notifications?
> 

[ztr]:
We want to work for notifications in general. I noticed that subscribed-notifications draft describes event stream. And YANG-Push augments the SN and add datastore.
What's your suggestion for the reference if we want to work for both event stream and datastore?

> It would also be useful to align terminology with the other documents.  It
> seems a "Master" is really the management protocol server?  And "Agent" is
> what subscribed-notifications calls a "publisher"?  Or maybe the "Master"
> is the "publisher"?
> 
> You also use the term "data originator", but I am not quite sure if that is
> the same as "Agent"?

[ztr]:
Yes, that's a good suggestion. Figure 1 is too simple and not clear. We will try to do this in the next version. We have a more detailed framework description with figures in draft-zhou-netconf-multi-stream-originators-02. It would be really appreciated if you can review that document. And you may help use normalize the terms. 
The master will decompose the subscription and distributed the requests to each agent. Both master and the agent contains a publisher as shown in Figure 3 in draft-zhou-netconf-multi-stream-originators-02. "data originator" in this draft is more like master + agent.

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 12 Jun 2018 12:02:45 +0200 (CEST)

Hi,

Tianran Zhou <[email-masked]> wrote:
> > some
> > design
> Yes, within the design team, we discussed this also. We tried to fit
> the existing design of
> draft-ietf-netconf-subscribed-notifications(SN).
> In the case of "establish-subscription", existing SN design require
> the notification to use the same channel as the subscription. But the
> distributed data collection
> mechanism(draft-zhou-netconf-multi-stream-originators-02) cannot meet
> this. Because the notification channel and the subscription channel
> are always separated. So we require:

I don't think this solves the problem.  I see two alternatives:

1)  Extend the definition of establish-subscription in the
    subscribed-notification draft so that it can handle notifications
    on a different transport than the existing session.  Work out fate
    sharing details etc.

2)  Do not allow dynamic subscriptions for this notification
    transport.

> It's not the only one issue. For configured subscription, SN requires
> the "subscription-started" message before sending
> notifications. However, for UDP, we cannot guarantee the notifications
> arrive the receiver after the "subscription-started". We cannot
> guarantee "subscription-started" will not lost neither. So I am
> wandering if the "subscription-started" message is still necessary.

I'd rather have a single procedure for sending notfifs, and then
document in this draft that due to the nature of UDP a receiver cannot
depend on these state-notifs being received (or any notif).

> We want to work for notifications in general. I noticed that
> subscribed-notifications draft describes event stream. And YANG-Push
> augments the SN and add datastore.

In most cases simply reference subscribed-notifications.  Push comes
for free, since push uses subscribed-notifications.

> Yes, that's a good suggestion. Figure 1 is too simple and not
> clear. We will try to do this in the next version. We have a more
> detailed framework description with figures in
> draft-zhou-netconf-multi-stream-originators-02. It would be really
> appreciated if you can review that document. And you may help use
> normalize the terms.
> The master will decompose the subscription and distributed the
> requests to each agent. Both master and the agent contains a publisher
> as shown in Figure 3 in
> draft-zhou-netconf-multi-stream-originators-02. "data originator" in
> this draft is more like master + agent.

Ok, will do.  In general, try to stick with existing terms, and don't
invent new unless the existing ones really can't be used.

/martin

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 13 Jun 2018 03:30:05 +0000

Hi Martin,

Thanks for your suggestions.
Please see in line.

Best Regards,
Tianran
> Sent: Tuesday, June 12, 2018 6:03 PM
> > > I don't understand how this new transport is supposed to fit into
> > > the design of draft-ietf-netconf-subscribed-notifications.  For
> > > example, the udp-pub-channel draft seems to expect a request to
> > > "establish-subscription"
> > > over NETCONF to send the notifications over UDP.  But AFAICT this is
> > > not possible with the current design of establish-subscription.
> >
> > [ztr]:

[ztr]: I prefer option 1. Because, though separate channels(i.e., the way to do notification changed), the user requirements of dynamic subscription do not change. Let's have a joint discussion with the SN authors in the mailing list.

> > the "subscription-started" message before sending notifications.
> > However, for UDP, we cannot guarantee the notifications arrive the
> > receiver after the "subscription-started". We cannot guarantee
> > "subscription-started" will not lost neither. So I am wandering if the
> > "subscription-started" message is still necessary.
> 
> I'd rather have a single procedure for sending notfifs, and then document
> in this draft that due to the nature of UDP a receiver cannot depend on these
> state-notifs being received (or any notif).

[ztr]: Do you mean the receiver is always ready for accepting data, no matter what state-notifications are received? The publisher will still send those state-notifications anyway. But the receiver will only consider them for reference.

> > > Also, it seems many of the references to yang-push really should be
> > > to subscribed-notifications.
> >
> > [ztr]:
> In most cases simply reference subscribed-notifications.  Push comes for
> free, since push uses subscribed-notifications.

[ztr]: OK, I will update the document.

> > > seems a "Master" is really the management protocol server?  And
> > > "Agent" is what subscribed-notifications calls a "publisher"?  Or
> > > maybe the "Master"
> > > is the "publisher"?
> > >
> > Yes, that's a good suggestion. Figure 1 is too simple and not clear.
> > We will try to do this in the next version. We have a more detailed
> > framework description with figures in
> Ok, will do.  In general, try to stick with existing terms, and don't invent
> new unless the existing ones really can't be used.

[ztr]: Thank you. I will update the document.

> > > > Streaming Telemetry. And we are going to update it, specifically
> > > > on the security aspect.