Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver
"Eric Voit (evoit)" <evoit@cisco.com> Tue, 26 June 2018 17:08 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 7B489130EB1 for <netconf@ietfa.amsl.com>; Tue, 26 Jun 2018 10:08:58 -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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 NmH243QcdBXd for <netconf@ietfa.amsl.com>; Tue, 26 Jun 2018 10:08:56 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE619130E20 for <netconf@ietf.org>; Tue, 26 Jun 2018 10:08:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11590; q=dns/txt; s=iport; t=1530032935; x=1531242535; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IMNQ2rAxdgTXveSTZWAANi4lYIWswXeED/A9k2skfuY=; b=fSd2doM7gkOVqyv5mJEWcTHS2ESZYO/mOKznygynQtiTRZDxN1Yenb1j LJdwArfrSYblYlBCfvFCy/LOAolfzI9hMSRc5StyfftfIbe0/etSvGG17 5pRF1CG+/YwgiNMkUmGRpAcgjkpf4Yx2kWqJyDEQoI1Sgkv9FX6fvm67F E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DqAQCCcjJb/4UNJK1cGQEBAQEBAQEBAQEBAQcBAQEBAYMqAQEBARwFYn8oCoNviASOTJUVgXoLhGwCF4J8ITQYAQIBAQEBAQECbSiFNgEBAQMBIxFFBQsCAQgOBwMCAgkdAgICMBUQAgQOBQgTgwuBdwitM4IciEqBGoELh2KBVj+BD4MPgUGDI1CCR4JVAoxGAYxqCQKPCoFIhnGFGZFKAhETAYEkHTiBUnAVgySCIxeOF2+OZoEaAQE
X-IronPort-AV: E=Sophos;i="5.51,275,1526342400"; d="scan'208";a="134394188"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2018 17:08:54 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w5QH8siq022843 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Jun 2018 17:08:54 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 26 Jun 2018 13:08:53 -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; Tue, 26 Jun 2018 13:08:53 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "kwatsen@juniper.net" <kwatsen@juniper.net>, "netconf@ietf.org" <netconf@ietf.org>, "Tim Jenkins (timjenki)" <timjenki@cisco.com>, "alex@clemm.org" <alex@clemm.org>
Thread-Topic: [Netconf] IETF 101 SN Question 1: Proper designation of receiver
Thread-Index: AQHT7qZjKKPiRp7oL0Gw54ItH09w2qQ1f5yAgABaRoCAAFIXAP//0cbAgCYz3oCAALf2gIALzo6AgACF3OCAAIGQgP//v4TQgAHRv4D//78WkABEsRYAAAapTSAAjo35gAAIQuKQABHb3oAACd63QA==
Date: Tue, 26 Jun 2018 17:08:53 +0000
Message-ID: <58867a306a1b4c2db94d98726a8fb40e@XCH-RTP-013.cisco.com>
References: <5682ba83228f41e6b6a04a866b3dc49d@XCH-RTP-013.cisco.com> <2BE57A46-2D39-46D8-B751-203681C23F43@juniper.net> <c034b39204074d36abdc9f57a6d7537b@XCH-RTP-013.cisco.com> <20180626.101045.358495650140202205.mbj@tail-f.com>
In-Reply-To: <20180626.101045.358495650140202205.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.230]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/slJSzyyRmZNLPAOHbzrzvXhjhcs>
Subject: Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver
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: Tue, 26 Jun 2018 17:08:59 -0000
> From: Martin Bjorklund, June 26, 2018 4:11 AM > > "Eric Voit (evoit)" <evoit@cisco.com> wrote: > > > From: Kent Watsen, June 25, 2018 3:43 PM > > > > > > >> >> <kent-orig> Okay, glad to see that you embrace using > > > >> >> ietf-netconf-server, rather than ietf-netconf-client. And > > > >> >> I'll grant you that it's infinitely more likely that the > > > >> >> ietf-netconf-server module would be implemented (i.e., the > > > >> >> top-level /ncs:netconf-server container exists), more so than > > > >> >> the ietf-netconf-client module would be implemented. The WG > > > >> >> created the top-level /ncc:netconf- client container more for > > > >> >> the sake of symmetry than for having a use-case for when it > > > >> >> would be implemented. I think the question to ask is, is it > > > >> possible that a device wants to use SN but doesn't *implement* > > > >> ietf-netconf- server? > > > >> >> > > > >> >> <Eric> Yes, this will be possible. Reasons would include: > > > >> >> alternative > > > >> transports > > > >> >> (COMI, UDP), HTTP2 configured subscriptions (which might use > > > >> >> ietf-restconf- server), or no need for a publisher to include > > > >> >> the configured subscriptions feature. > > > >> >> > > > >> >> <Kent> I should've be more specific: is it possible that a > > > >> >> device would use netconf-notif (where your leafref is defined) > > > >> >> but not implement > > > >> ietf-netconf- > > > >> >> server? Similarly, restconf-notif would presumably have a > > > >> >> leafref to > > > >> >> ietf- > > > >> >> restconf-server, etc. > > > >> > > > > >> >Yes. Cases would include: > > > >> >(a) platform doesn't support configured subscriptions > > > >> >(b) vendor has not yet implemented ietf-netconf-server, and uses > > > >> >something > > > >> else. > > > >> > > > >> (a) is this a valid case? - I thought this conversion only > > > >> regards configured subscriptions. No leafref or equivalent would > > > >> be needed to support a dynamic subscription. Right? > > > > > > > > Correct. But your question was "can you use netconf-notif without > > > > a leafref > > > to...". > > > > Needing both drafts is absolutely the case for dynamic > > > > subscription support, and ietf-netconf-server would not be needed here. > > > > > > I read the above a few times, but I'm having a hard time > > > understanding it. Can say it differently or provide an example? > > > > Dynamic subscriptions over NETCONF requires > > draft-ietf-netconf-netconf-event-notifications. With these > > deployments, there there is no call home, there is no configuration, > > and there need be no ietf-netconf-server.yang leafref (or use of > > ietf-netconf-server.yang grouping). > > > > > >> (b) this seems like a possibility, but then I think this make the > > > >> case for why a leafref to the global *conf servers definitions > > > >> won't always > > > work. > > > > > > > > Agree that nothing here will always work. Deployments commonly > > > > will have a heterogeneous mixture of model ecosystem models. > > > > > > > > This actually makes a *very* strong case for why the leafref > > > > should be added as an augmentation from the *conf-server models. > > > > That way leafref augmentations are explicitly tied to the actual > > > > implementation of the > > > model against which they refer. > > > > > > Not in the *conf-server models, the augments go into the *conf-notif > > > models, I assume that is what you meant. > > > > My assertion is a good solution would be updating > > ietf-netconf-server.yang per what is below. Note that an answer even > > further below regarding the sharing of a single NETCONF session across > > multiple subscriptions and typical RFC6241 protocol interactions is > > assumed. But we could also insert your ietf-netconf-server.yang > > grouping just as effectively where the leafref is seen. > > > > Anyway here are the following changes which would be made to > > ietf-netconf-server.yang > > > > import ietf-subscribed-notifications { prefix sn; } > > import ietf-netconf-subscribed-notifications { prefix nsn; } > > > > feature subscription-support { > > description > > "The 'subscription-support' feature indicates that the NETCONF server > > supports configured subscriptions over call-home connections."; > > reference > > "RFC xxxx: Customized Subscriptions to a Publisher's Event Streams"; > > } > > > > augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" { > > if-feature "subscription-support"; > > when 'derived-from(../../../transport, "nsn:netconf")'; > > description > > "This augmentation allows NETCONF specific parameters to be exposed > > for a receiver."; > > leaf netconf-endpoint { > > type leafref { > > path "/ncs:netconf-server/ncs:call-home/ncs:netconf-client/ncs:name"; > > } > > description > > "Remote client which need to initiate the NETCONF transport if an > > existing NETCONF session from that client is not available."; > > } > > } > > > > With such a construct, it is impossible to add a leafref (or grouping) > > within ietf-subscribed-notifications unless ietf-netconf-server.yang > > exists. > > > > > >> This is why I > > > >> was thinking before that your modules might themselves *use* the > > > >> *conf- server-groupings (while pruning out unneeded parts, e.g., > > > >> the "listen" subtree), so that it's independent of what the > > > >> system has implemented at the global level. > > > > > > > > If you have 500 subscriptions, you then have to populate 500 > > > > identical > > > groupings. > > > > > > No, you have one grouping, with 500 > > > /netconf-server/call-home/netconf-client > > > instances. > > > > Yes. But I don't know why someone would voluntarily do add 500 > > repeated elements to a configuration datastore. > > > > > > And yes this is possible. But it makes the part of me which > > > > likes Normalized data quite uncomfortable. > > > > > > > > But as I said before, it the WG wants such redundancy, fine. > > > > Either choice need not impact decisions as part of LC. > > > > > > I don't believe that is a WG-preference thing, so much as an outcome > > > of the current design, which is that each receiver for each > > > subscription has its own state-machine and protocol messages. There > > > is no sharing; no two receives can use the same RFC 6241 NETCONF > > > session, which effectively translates to each receiver having its > > > own /netconf-server/call-home/netconf-client > > > instance, > > > right? > > > > This is incorrect. Protocol and state-machine messages have been > > decoupled from the transport session. > > > > I am not sure why you think that subscriptions are unable to use a > > common NETCONF session? Implementations of dynamic NETCONF > > subscriptions have been doing this for years. Subscription > > multiplexing of configured and dynamic subscriptions over a common > > transport is a pre-requisite for solution scalability. > > I don't think muliplexing of configured and dynamic subscriptions over a single > session is possible. > > If this is the intention of the current design, the document > needs to explain how this is supposed to be done. What is your concern? > Multiplexing multiple configured subscriptions over a single transport session > could be possible, but the document doesn't mention this. > Again, if this is the intention, it needs to be properly described in the > document. What is missing? The subscribed-notification draft section 2.5.1 and Figure 9 describe how each receiver is pushed their own state notifications. (I.e., the state machine is per-receiver. It is not per-subscription, nor is it per-transport.) > This said, "session sharing" can be acheived with the current design, as well as > with the alternative design where the protocol is defined per receiver rather > than per subscription. Agree. Any issues with NETCONF transport multiplexing of subscriptions should be independent of the receiver YANG model. > But it won't be interoperable unless it is described. Likely NETCONF specific concerns would land in the NETCONF-notif. I am happy to make any needed clarifications. Eric > /martin
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- [Netconf] IETF 101 SN Question 1: Proper designat… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)