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

"Eric Voit (evoit)" <evoit@cisco.com> Tue, 23 October 2018 15:53 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 AFB3A124C04 for <netconf@ietfa.amsl.com>; Tue, 23 Oct 2018 08:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.969
X-Spam-Level:
X-Spam-Status: No, score=-14.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 LhxrI-fdO9jD for <netconf@ietfa.amsl.com>; Tue, 23 Oct 2018 08:53:42 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3B2124408 for <netconf@ietf.org>; Tue, 23 Oct 2018 08:53:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28502; q=dns/txt; s=iport; t=1540310022; x=1541519622; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=FN1xcIE+lS4ELFH1iyuiyjEX0rfaywgnYk8lJ9Eo6j4=; b=eMKO3hlVHAlq6dQcaGFY0Ufu4gGNfRoPiyNM88Tm2SBp5ips+9lj34qc Q52PM5NWb53KeQ9CUskqR3S5pBc4O7f1dKnul9ldzc/vbCnJC1i/dN25D iR+DrrVe2HTVuJFYBSP5ik7rOdj/9Tw14ShRCtXRBu8Fwouocw390dcap k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AEAADWQs9b/5JdJa1jGgEBAQEBAgEBAQEHAgEBAQGBUQUBAQEBCwGBDU0qZn8oCoNriBiMHYINlxWBegsBARgBDIQBRgIXhRMhNA0NAQMBAQIBAQJtHAyFOgEBAQQBASEKQRsCAQYCFQMNEwcDAgICJQsUEQIEARIIgk5MgR1kD4swm02BLoQwAgxAhSOLYheBQT+BEYMSgxsBAQIBARaBXh+CTYJXAohvhUiQGQkChmGKCR+BUkyEKIlqjFyJaAIRFIEmHTgngS5wFRohgmwJixCFPm+MDoEfAQE
X-IronPort-AV: E=Sophos;i="5.54,416,1534809600"; d="scan'208,217";a="189819933"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 15:53:41 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id w9NFrecx021085 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Oct 2018 15:53:41 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Oct 2018 11:53:40 -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; Tue, 23 Oct 2018 11:53:40 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Tianran Zhou <zhoutianran@huawei.com>, Martin Bjorklund <mbj@tail-f.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+cA==
Date: Tue, 23 Oct 2018 15:53:40 +0000
Message-ID: <bd73e6666dad43baad45062ee5e65555@XCH-RTP-013.cisco.com>
References: <153993704813.32028.17854286483743516126@ietfa.amsl.com>, <20181022.144802.1960504600474782721.mbj@tail-f.com> 8712B1B2-AA61-4698-A86D-8969F13F4B5B
In-Reply-To: 8712B1B2-AA61-4698-A86D-8969F13F4B5B
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: multipart/alternative; boundary="_000_bd73e6666dad43baad45062ee5e65555XCHRTP013ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/SPZ82lrc8pr7EVJRPCTEUmQBSHA>
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: Tue, 23 Oct 2018 15:53:46 -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,

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