Subject: [Netconf] I-D Action: draft-ietf-netconf-udp-pub-channel-04.txt

From: [email-masked]
Date: Fri, 19 Oct 2018 01:17:28 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : UDP based Publication Channel for Streaming Telemetry
        Authors         : Guangying Zheng
                          Tianran Zhou
                          Alexander Clemm
	Filename        : draft-ietf-netconf-udp-pub-channel-04.txt
	Pages           : 22
	Date            : 2018-10-19

Abstract:
   This document describes a UDP-based publication channel for streaming
   telemetry use to collect data from devices.  A new shim header is
   proposed to facilitate the distributed data collection mechanism
   which directly pushes data from line cards to the collector.  Because
   of the lightweight UDP encapsulation, higher frequency and better
   transit performance can be achieved.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-channel/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-udp-pub-channel-04
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-pub-channel-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-udp-pub-channel-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 22 Oct 2018 14:48:02 +0200 (CEST)

Hi,

In section 4.1, this draft explains how a dynamic subscription can be
used with UPC.  How is this supposed to work?  There is no way to
indicate in an <establish-subscription> that the UPC protocol should
be used instead of sending <notifications> to the NETCONF client that
sent the <establish-subscription>.

/martin

[email-masked] wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 23 Oct 2018 13:53:41 +0000

Hi Martin,

Thank you for the review. You are right, that is also our concern on the dynamic subscription.
Is this operation legal by the dynamic subscription definition?
If so, we can augment the establish-subsciption RPC with an transport option.

Tianran

--------------------------------------------------
Sent from WeLink
发件人：Martin Bjorklund
收件人：[email-masked],
时间：2018-10-22 21:48:43
主 题：Re: [Netconf] I-D Action: draft-ietf-netconf-udp-pub-channel-04.txt

Hi,

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 23 Oct 2018 15:53:40 +0000

Hi Tianran,

The definition of dynamic subscription does allow for different transports to be used for notifications.   So I agree that augmenting “transport” into the <establish-subscription>  RPC is the way to accomplish this.  As a “transport” object already exists in the Data Nodes, this should be a minimalistic addition for supporting this.

The choice of the transport carrying the <establish-subscription> RPC itself does matter for your draft.  Section 4.1 does note that both NETCONF and RESTCONF can be used for signaling.  Looking at those two transport drafts:

·       For NETCONF, draft-ietf-netconf-netconf-event-notifications section 6, says: “ For dynamic subscriptions, all notification messages MUST use the NETCONF transport session used by the <establish-subscription> RPC.  Based on this, you will need to clarify the proper operation if you use that document as upon which to build your specification.

·       For RESTCONF, you will also need to decide if you will be building on top of draft-ietf-netconf-restconf-notif and its embedded YANG model.  In draft-ietf-netconf-restconf-notif, a separate session is used to make the connection for the notifications, and SSE is used.  Which is would need to be clarified quite a bit.

One other thing you might want to consider augmenting is the <establish-subscription>  RPC response.  draft-ietf-netconf-restconf-notif augments extra parameters into a successful response to an <establish-subscription>  request.    I believe a similar mechanism can be used in your draft to match what is needed to support the channels (b) in Fig 2.  Specifically, the <establish-subscription> response could be able to send a list of information component subscription servers from which notifications should be expected.

Additionally if you wanted,  information on Figure 2’s destination ports or addresses/ports could be augmented in as part of an <establish-subscription> request.  But whether that is needed is up to you.

Eric

From: Tianran Zhou, October 23, 2018 9:54 AM

Hi Martin,

Tianran
--------------------------------------------------
Sent from WeLink
发件人：Martin Bjorklund
收件人：[email-masked]<mailto:[email-masked]>,
时间：2018-10-22 21:48:43
主 题：Re: [Netconf] I-D Action: draft-ietf-netconf-udp-pub-channel-04.txt

Hi,

/martin

[email-masked]<mailto:[email-masked]> wrote:
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 23 Oct 2018 20:59:49 +0200 (CEST)

Hi,

"Eric Voit (evoit)" <[email-masked]> wrote:
> Hi Tianran,
> 
> The definition of dynamic subscription does allow for different
> transports to be used for notifications.  So I agree that augmenting
> “transport” into the <establish-subscription> RPC is the way to
> accomplish this.

Which module should do this augment?  If this really is the intention,
why not put this leaf in the base SN model?  (Wasn't it present in
some previous version?)

[...]

> Additionally if you wanted, information on Figure 2’s destination
> ports or addresses/ports could be augmented in as part of an
> <establish-subscription> request.  But whether that is needed is up to
> you.

Hmm, was this the reason for not having a generic 'transport' in
establish-subscription?

/martin

> 主 题：Re: [Netconf] I-D Action:
> draft-ietf-netconf-udp-pub-channel-04.txt
> 
> Hi,
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 24 Oct 2018 14:28:12 +0000

Hi Martin,

> Which module should do this augment? 

My assumption is that a new model contained within this draft will be needed to do the augmentations described within this thread.

>  If this really is the intention, why not put this leaf in the base SN model? 

We didn't put it in due to the complexity.  It is true that enabling an optional leaf in the RPC would be easy.  However the rules for fate-sharing these event notifications with an independent signaling transport session are not so easy to do in a transport agnostic specification.  

I.e., defining how to handle/fate-share different transports for dynamic subscription signaling and event delivery is a bit of complexity which didn't need to be taken on by the base SN draft. 

> (Wasn't it present in some previous version?)

I don't believe so.
 
> Hmm, was this the reason for not having a generic 'transport' in establish-
> subscription?

A reason, but not the prime reason.  The prime reason was that in the simplest/dominant case it is easy to use the transport of the RPC is the desired transport for the event notifications.  It is always possible to augment.

Thanks,
Eric

> > > Please note that it may take a couple of minutes from the time of
> > > submission until the htmlized version and diff are available at
> > > tools.ietf.org.
> > >

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 Oct 2018 16:53:42 +0200 (CEST)

"Eric Voit (evoit)" <[email-masked]> wrote:
> My assumption is that a new model contained within this draft will be
> needed to do the augmentations described within this thread.

Do you mean a new transport-agnostic model?

> We didn't put it in due to the complexity.  It is true that enabling
> an optional leaf in the RPC would be easy.  However the rules for
> fate-sharing these event notifications with an independent signaling
> transport session are not so easy to do in a transport agnostic
> specification.

So this have to be dealt with now, in this draft?

> I.e., defining how to handle/fate-share different transports for
> dynamic subscription signaling and event delivery is a bit of
> complexity which didn't need to be taken on by the base SN draft.
> 

Ok.

/martin

> > establish-
> A reason, but not the prime reason.  The prime reason was that in the
> simplest/dominant case it is easy to use the transport of the RPC is
> the desired transport for the event notifications.  It is always
> possible to augment.
> 
> Thanks,
> Eric
> 
> > /martin
> > 
> > 
> > >
> > > Eric
> > >

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 24 Oct 2018 15:58:13 +0000

> From: Martin Bjorklund, October 24, 2018 10:54 AM
> 
> > > > transports to be used for notifications.  So I agree that
> > > > augmenting “transport” into the <establish-subscription> RPC is
> > > > the way to accomplish this.
> > >

In theory it could be transport-agnostic.  But it also could be specific to what the authors are trying to do with UDP and draft-zhou-netconf-multi-stream-originators.   (If the authors wants to attempt a generalization here, I would be interested in providing review/input.  It is a complex topic.)

> So this have to be dealt with now, in this draft?

I think so.  There are other coupled complexities which likely need to be addressed in unison.  These include the independent entities "subscription server" and "component subscription server" described in the solution overview.   While these entities are best defined in draft-zhou-netconf-multi-stream-originators, the pub-channel draft does depend on that componentization.  And this breakdown should add new items to the SN YANG model.  (e.g., what subset of XPATH filters should be handled by each "component subscription server".)

Eric

> > > > <establish-subscription> request.  But whether that is needed is
> > > > up to you.
> > >
> > > > In section 4.1, this draft explains how a dynamic subscription can
> > > > be used with UPC.  How is this supposed to work?  There is no way
> > > > to indicate in an <establish-subscription> that the UPC protocol
> > > > should be used instead of sending <notifications> to the NETCONF
> > > > client that sent the <establish-subscription>.
> > > >
> > > >
> > > > /martin
> > > >
> > > >
> > > >
> > > > > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-pub
> > > > > -cha
> > > > > nnel-04
> > > > >
> > > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-udp-pub-cha
> > > > > nnel
> > > > > -04
> > > > >
> > > > >
> > > > > Please note that it may take a couple of minutes from the time
> > > > > of submission until the htmlized version and diff are available
> > > > > at tools.ietf.org.
> > > > >