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

"Eric Voit (evoit)" <evoit@cisco.com> Wed, 24 October 2018 14:28 UTC

Return-Path: <evoit@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565BB1200D7 for <netconf@ietfa.amsl.com>; Wed, 24 Oct 2018 07:28:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aipvwhwG9yRs for <netconf@ietfa.amsl.com>; Wed, 24 Oct 2018 07:28:15 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C238D12F295 for <netconf@ietf.org>; Wed, 24 Oct 2018 07:28:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7008; q=dns/txt; s=iport; t=1540391294; x=1541600894; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tHE1h+9g2c2SbcLpAoBw0vdixUaWIwpBgnM2rg/Gcew=; b=FBXOZYVjUZqWgz9EBJSX+yfhjhvMacLeF8LBqOipDPYa0LW/1B7CFm3y fsFPxY332urja6aLuGOh7397zM2Pv3KJHZaNE57KHx2Hp/bELdLZh8dS3 89jNMH1C6YDmaJB+RZo7NOj38Tor4B9b9FNw8Rb15Z81+MPCIQOd8q8yV M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AOAAD1gNBb/4oNJK1jGgEBAQEBAgEBAQEHAgEBAQGBUQUBAQEBCwGBVQUqZn8oCoNriBiMGIINgz+TVoF6CwEBGAuEA0YCF4J0ITQNDQEDAQECAQECbRwMhToBAQEDAQEBIRE6CwULAgEGAg4HAwICCRoDAgICJQsUARACBA4FCIJOTIF5CA+MQZtNgS6EMAIMQIUkgQuKVxeBQT+EI4MbAQECAQEWgV6CbIJXAohrBJVhCQKGYYoJH4FSTIQoiWqMXIloAhEUgSYdOIFVcBUaIYJsCYsQhT5vjA6BHwEB
X-IronPort-AV: E=Sophos;i="5.54,420,1534809600"; d="scan'208";a="471045625"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2018 14:28:13 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id w9OESCqs012249 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Oct 2018 14:28:13 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 24 Oct 2018 10:28:12 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1395.000; Wed, 24 Oct 2018 10:28:12 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "zhoutianran@huawei.com" <zhoutianran@huawei.com>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-udp-pub-channel-04.txt
Thread-Index: AQHUZ4Rrm8pfbSLxKUe+ngRTKIVD9qUqtcoAgAIqymyAAAS+cIAAk9eA///9weA=
Date: Wed, 24 Oct 2018 14:28:12 +0000
Message-ID: <8888c964b0f74f6184731672bfc3ccc5@XCH-RTP-013.cisco.com>
References: <153993704813.32028.17854286483743516126@ietfa.amsl.com> <20181022.144802.1960504600474782721.mbj@tail-f.com> <bd73e6666dad43baad45062ee5e65555@XCH-RTP-013.cisco.com> <20181023.205949.331237716902693817.mbj@tail-f.com>
In-Reply-To: <20181023.205949.331237716902693817.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.234]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/tmK52a4sU7hKtatZPPjDmYKTuH8>
Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-udp-pub-channel-04.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2018 14:28:21 -0000

Hi Martin,

> Hi,
> 
> "Eric Voit (evoit)" <evoit@cisco.com> 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.

>  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.
 
> [...]
> 
> > 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
> > 收件人:netconf@ietf.org<mailto:netconf@ietf.org>,
> > 时间: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
> >
> >
> >
> > internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> 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
> > > Netconf@ietf.org<mailto:Netconf@ietf.org>
> > > https://www.ietf.org/mailman/listinfo/netconf
> > >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org<mailto:Netconf@ietf.org>
> > https://www.ietf.org/mailman/listinfo/netconf