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

[Martin Bjorklund <[e-mail]>]

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


> >  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.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-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-cha
> > > > nnel-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/
> > > >
> > > > _______________________________________________
> > > > 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