Re: [Netconf] LC on subscribed-notifications-10

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 06 July 2018 00:07 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 A9A47130F7F for <netconf@ietfa.amsl.com>; Thu, 5 Jul 2018 17:07:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01, 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 3T8-CCCP4M0V for <netconf@ietfa.amsl.com>; Thu, 5 Jul 2018 17:07:04 -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 1D424130FE8 for <netconf@ietf.org>; Thu, 5 Jul 2018 17:07:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25452; q=dns/txt; s=iport; t=1530835621; x=1532045221; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qwxNHpXSVE72v0D1pRlI0zdKns4EmafGRKYXZIHEODw=; b=fJ4Nd51EOhyLG5iREUGKnyX1Ly8ARLNTGntv8L0cOwelXcdDEEwaegAd i/7BWkWiqbBWDEEWvG2GOweylJ2GaUcdJOreFmmDS7Cgl62V1RA4ekK8i JRmbhjwqO1xu/79Gl/Mf0Cg8EZZ17vbG0yk63NqMm2KUo1Y/+ikg2wb3h Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DpAADnsT5b/5FdJa1bGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYJTTCpifygKg3CIBIw1ggeVMIF6CyWERwIXghYhNBgBAgEBAgE?= =?us-ascii?q?BAm0cDIU2AQEBAgIjCkoCEAIBCA4HEB0CAgIwJQIEDg0TgjpMgRtkD6lgghw?= =?us-ascii?q?fiDGBNQWIbYFWP4QegxgCAYFtgnOCVQKZTAkChgSJEo1fijWHLQIREwGBJB0?= =?us-ascii?q?4gVJwFYMkhgCKUm+OIoEaAQE?=
X-IronPort-AV: E=Sophos;i="5.51,314,1526342400"; d="scan'208,217";a="138634971"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2018 00:07:00 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w6606xxv032301 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Jul 2018 00:07:00 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 5 Jul 2018 20:06:59 -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.1320.000; Thu, 5 Jul 2018 20:06:59 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Kent Watsen <kwatsen@juniper.net>
CC: "netconf@ietf.org" <netconf@ietf.org>, Alexander Clemm <ludwig@clemm.org>
Thread-Topic: [Netconf] LC on subscribed-notifications-10
Thread-Index: AQHTvAAnP4UPxNeFY0CSJ8tCCoPN1aPROUcQgATP1QCAHwQrAIADjkNQgA1teoD//750sIAJjRkA///cqgCAA11fAIAAqbKwgBOiSQCAARvxAIAIk/4AgACP9NCADaFDgIAAiRzAgAubxgD///ywEAJlO7OAACjJQxABysFmgAAIUZsAAI1lOQAABkzf0ACFw/GAAP59NtAAcDoxgAAGk67A
Date: Fri, 6 Jul 2018 00:06:59 +0000
Message-ID: <a7d654fc37284449ba8c1306a9ce3146@XCH-RTP-013.cisco.com>
References: <17B884BF-0BB8-4B7C-BFBB-0AAFBEA857F6@juniper.net> <aedeb7390d0b4faa9f2bf12c2fe45cd2@XCH-RTP-013.cisco.com> <040a01d3be9f$09700490$1c500db0$@clemm.org> <2089023D-DA09-48E9-8F37-8FE459DC4F49@juniper.net> <dfc78f2b1062498388824b1f6dd97ff6@XCH-RTP-013.cisco.com> <1EC2E732-C524-4552-A3AD-27507239F763@juniper.net> <2b788c22f7ee4af889813b805348d69a@XCH-RTP-013.cisco.com> <9E7F3A66-98B9-4528-882C-43AAD19F0AEC@juniper.net> <96615f0331cd455182901ddf3e6ece23@XCH-RTP-013.cisco.com> <7F8F2AF4-28A5-4016-B727-10CAF6A093AF@juniper.net> <87fbe3cb907a473f816295c4545bd7fa@XCH-RTP-013.cisco.com> <CEE5B81C-31AE-40C6-B2F0-23D93C644D85@juniper.net> <fd172bddff134db6aeda49b7e8bfd3e9@XCH-RTP-013.cisco.com> <B112DC20-D6FC-44BA-AACE-0E641D49C5C3@juniper.net> <3b4744f4e2144ee18b9bfd5225360bf4@XCH-RTP-013.cisco.com> <01486F5E-CEE3-4BDD-9CD2-CA2754981000@juniper.net> <e414fe96c38f4aeba97dd56592748a23@XCH-RTP-013.cisco.com> <49943A03-D229-4084-9947-3065CE58A672@juniper.net> <a18cacd026e046b0a0c08f7a3fc969d2@XCH-RTP-013.cisco.com> <470391DD-9A9E-47EC-9CEC-E8E6BABE3DDF@juniper.net> <b94935c9fbbb4ced8b7393ea42457471@XCH-RTP-013.cisco.com> <38DB151D-81C9-49E4-B6A3-73D083298C53@juniper.net> <fd74cc7419894fec87f5af3e7dc688bd@XCH-RTP-013.cisco.com> <230D4B7A-42E6-4A9E-909B-BE91EE5D2FF3@juniper.net> <bc1b705b88f04d368334b78fbe91b7dd@XCH-RTP-013.cisco.com> <4146A91F-42E3-4C81-A414-C27920CA30C0@juniper.net> <9721a7a06f9543a1b510988b087da6b3@XCH-RTP-013.cisco.com> <BB246B62-0A79-4FAD-9C23-B5EC40AE394D@juniper.net>
In-Reply-To: <BB246B62-0A79-4FAD-9C23-B5EC40AE394D@juniper.net>
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.230]
Content-Type: multipart/alternative; boundary="_000_a7d654fc37284449ba8c1306a9ce3146XCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Onn1tVbcs-UxFlr2duI0hHtIJ8o>
Subject: Re: [Netconf] LC on subscribed-notifications-10
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 06 Jul 2018 00:07:12 -0000

<Eric14>

From: Kent Watsen, July 5, 2018 6:19 PM


<Kent9> it might be typical/common desire, but it's still once in the lifetime of the configured subscription.  It seems like, if the device supports dynamic subscriptions, after receiving subscription-started, the client could a) pause the configured subscription, b) use a dynamic subscript to fetch the missing logs, and then c) resume the flow of logs from the configured subscriptions.



<Eric10> Your proposal still precludes (b)-(d) above.   In addition for your step a), there is no RPC or action which allows the event records from a configured (or dynamic) subscription to be paused.  The solution also adds complexity into the client to recognize that early events might be missing, to issue an establish-subscription, and then to tie the results of the independent subscriptions together.



<Kent10> pausing can be implemented by the receiver not reading any more from the TCP socket, or something else.



<Eric11> There is no mechanism for a receiver to pause a single subscription without pausing other subscriptions on the TCP session (as subscriptions typically would share a common TCP.)



<Kent11> Different "receivers" of different configured subscriptions pointing to the same underlying netconf or restconf call-home connection?



<Eric12> Yes



<Kent12> Ack.  So, *if* we were to do this, the client would either have to pause all the subscriptions, or do a dynamic fetch in parallel.  Hmmm, given that we're talking about the *configured* replay-start-time, which kicks in after a reboot, all the subscriptions would be restarted simultaneously (right?), so maybe this isn't a big issue?



<Eric13> Per this thread, this is now a configured-replay empty object (rather than a start-time).  This empty object simply tells the publisher to push off all events retained from a stream since reboot.  And yes, all configured subscriptions will restart simultaneously.  But without this feature, receivers will not see events from boot to transport establishment.  And without this feature, two different configured receivers might get different initial events as the transport might not be brought up simultaneously.



<Kent13> I'm unsure how this addresses my concern that replaying is unnecessary for configured subscriptions…I somehow thought that it might be related since it's listed here.   Separately, I'm unclear about what this change does, I know you provide some explanation above, but you can say it differently or provide an example or two to illustrate what you mean?   Does this change introduce the problem you mentioned before about duplicates events being sent?



<Eric14>  Here is a link to the slides which I have put together for IETF 102 which hopefully hits your request above:



https://github.com/netconf-wg/rfc5277bis/blob/master/draft-configured-replay-slides-ietf102.pdf





BTW, the description statement on replay-start-time seems incorrect, with the node now being config false, how can it be used to "trigger" anything?



<Eric14>  replay-start-time exists as part of the establish-subscription RPC.   The RPC is where the triggering occurs.



Eric













Kent // contributer