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

[Tianran Zhou <[e-mail]>]

Hi Eric and Martin,

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

What we want to do is an easy way just specific to this UPC module. We may add an transport leaf and the receiver info.
But I would like to hear how this can be generalized so that draft-zhou-netconf-multi-stream-originators may use. I did not quite realize how this fate-sharing is generally exist.
For example, for this UPC. If the subscription channel is terminated, just terminate the UPC as well. What's the problem? I really hope the experience on the restconf transport can help. Thanks.


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

I also think the SN YANG model need to be extended to support multi-publishers. For example, as in the new update, https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stream-originators/
To check the data integrity, in section 6, we require a list of message generator IDs included in the response of the "establish-subscription" and "modify-subscription", and "subscription-started" and "subscription-modified" notifications as well.
But to Eric's example "e.g., what subset of XPATH filters should be handled by each "component subscription server"", what's the problem? What do you think should be considered to extend the SN YANG model?

Thanks,
Tianran

-----邮件原件-----
发件人: Eric Voit (evoit) [mailto:[e-mail]] 
发送时间: 2018年10月24日 23:58
收件人: Martin Bjorklund <[e-mail]>
抄送: Tianran Zhou <[e-mail]>; [e-mail]
主题: RE: [Netconf] I-D Action: draft-ietf-netconf-udp-pub-channel-04.txt

> From: Martin Bjorklund, October 24, 2018 10:54 AM
> 
> "Eric Voit (evoit)" <[e-mail]> wrote:
> > Hi Martin,
> >
> > > Hi,
> > >
> > > "Eric Voit (evoit)" <[e-mail]> 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?
> >
> > 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?

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

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

> > 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.
> 
> Ok.
> /martin
> 
> 
> >
> > > [...]
> > >
> > > > 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?
> >
> > 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: Tianran Zhou, October 23, 2018 9:54 AM
> > > >
> > > > 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
> > > > 收件人：[e-mail]<mailto:[e-mail]>,
> > > > 时间：2018-10-22 21:48:43
> > > > 主 题：Re: [Netconf] I-D Action:
> > > > draft-ietf-netconf-udp-pub-channel-04.txt
> > > >
> > > > 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
> > > >
> > > >
> > > >
> > > > [e-mail]<mailto:[e-mail]> wrote:
> > > > >
> > > > > 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-ch
> > > > > an
> > > > > nel/
> > > > >
> > > > > There are also htmlized versions available at:
> > > > > https://tools.ietf.org/html/draft-ietf-netconf-udp-pub-channel
> > > > > -0
> > > > > 4
> > > > > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-p
> > > > > ub
> > > > > -cha
> > > > > nnel-04
> > > > >
> > > > > A diff from the previous version is available at:
> > > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-udp-pub-c
> > > > > ha
> > > > > 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.
> > > > >
> > > > > Internet-Drafts are also available by anonymous FTP at:
> > > > > ftp://ftp.ietf.org/internet-drafts/
> > > > >
> > > > > _______________________________________________
> > > > > Netconf mailing list
> > > > > [e-mail]<mailto:[e-mail]>
> > > > > https://www.ietf.org/mailman/listinfo/netconf
> > > > >
> > > >
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > [e-mail]<mailto:[e-mail]>
> > > > https://www.ietf.org/mailman/listinfo/netconf