Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver

"Eric Voit (evoit)" <evoit@cisco.com> Thu, 21 June 2018 16:59 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 65BFD130E42 for <netconf@ietfa.amsl.com>; Thu, 21 Jun 2018 09:59:33 -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_HIGH=-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 G--AzKoJ8No2 for <netconf@ietfa.amsl.com>; Thu, 21 Jun 2018 09:59:29 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3C4130E9C for <netconf@ietf.org>; Thu, 21 Jun 2018 09:59:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11328; q=dns/txt; s=iport; t=1529600369; x=1530809969; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7xvD5PFg1FA6tapWhIoTCXQu4bnM0hNaCBZU2Y6lfMo=; b=XjufJbwYeYZ44lK9MJOxmSfTae4VaoQH1M8JtH1pgLr8qK4Le3Oyw7uK 4HDjy8elw7Z//ACx/y4FoACVsbu+1QwRrtN7mj3saqYwRCV1/jdNJu9As 6z+gL5TvnedGgL7vASjSPmbFIJDkeAxjp0dDbJVeA+hqqo7wVUtrBxnbd s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BQAgDG2Ctb/4sNJK1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNJYn8oCoNvlESCBZUAgXkLI4QDRgIXgmQhNhYBAgEBAQE?= =?us-ascii?q?BAQJtHAyFKAEBAQECASMRRQULAgEGAg4HBQIJHQICAjAVEAIEAQ0Ngx6Bdwg?= =?us-ascii?q?Pjy+bR4IciEZoBYELhhmBMIFUP4EPghF+gUGBVwIBgT8BAQgtI4JHglUCh02?= =?us-ascii?q?EdYEmiz4JAohfhieNSZE5AhETAYEkJAEwgVJwFTuCZ4IhF4hZhT5vAY1ygR+?= =?us-ascii?q?BGgEB?=
X-IronPort-AV: E=Sophos;i="5.51,252,1526342400"; d="scan'208";a="411519492"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2018 16:59:28 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w5LGxRLi009982 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Jun 2018 16:59:27 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.1320.4; Thu, 21 Jun 2018 12:59:26 -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, 21 Jun 2018 12:59:26 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Kent Watsen <kwatsen@juniper.net>, Martin Bjorklund <mbj@tail-f.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] IETF 101 SN Question 1: Proper designation of receiver
Thread-Index: AQHT7qZjKKPiRp7oL0Gw54ItH09w2qQ1f5yAgABaRoCAAFIXAP//0cbAgCYz3oCAALf2gIALzo6AgACF3OCAAIGQgP//v4TQgAHRv4D//78WkA==
Date: Thu, 21 Jun 2018 16:59:26 +0000
Message-ID: <cd9b7871b2ce4ad9987b6d782e6bcc3d@XCH-RTP-013.cisco.com>
References: <0c1b4c46d2de4190af83488dff293181@XCH-RTP-013.cisco.com> <20180518.144414.334141005925835002.mbj@tail-f.com> <fbb940135ccb465eb3f5b95d1fb53721@XCH-RTP-013.cisco.com> <20180518.170823.427077888694872498.mbj@tail-f.com> <595D0676-7DBD-4339-A551-374FBED705EC@juniper.net> <4a1e2f7367d54d088e517f7f6614765a@XCH-RTP-013.cisco.com> <ED90F588-9BCC-49C6-B8FF-18554247BD7F@juniper.net> <0a3b0b0b29e246b98c684d13162e15a8@XCH-RTP-013.cisco.com> <B8385EF7-C565-4F63-90AC-A4B36679B406@juniper.net> <c3b9cd55b30647e582d905320562a0eb@XCH-RTP-013.cisco.com> <CFB4FA41-C614-4604-B869-267533368335@juniper.net> <73ec3c52ffde452cae47642ce5ff2dd2@XCH-RTP-013.cisco.com> <DA6A819A-680E-4524-A5B7-E2E36466FA8D@juniper.net>
In-Reply-To: <DA6A819A-680E-4524-A5B7-E2E36466FA8D@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.228]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ZQ_S-PXEXlUAoNKCCJ1Bj-RH6ZE>
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: Thu, 21 Jun 2018 16:59:33 -0000

> From: Kent Watsen, June 21, 2018 11:36 AM
> 
> Search for <Kent> below.
> 
> // contributor
> 
> 
> <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.

As the draft-ietf-netconf-server-model is currently expired, I believe it safe to assume (b) will be common.

> <kent-orig> Even though it seems like ietf-netconf-server might always be
> implemented, I do not yet think it is okay for this data model to have a leafref
> to one of the globally-configured /ncs:netconf-server/ncs:call-
> home/ncs:netconf-client instances, since that instance would be expected to
> use normal NETCONF interactions (i.e. client-driven); it could be a problem if
> the server started sending <subscription-started> messages right away.  For
> this reason, maybe the SN data model needs to have its own instance of the
> netconf-server-grouping (perhaps with the top-level /listen tree pruned out),
> so then it's clear that these netconf-server instances are specifically for
> subscriptions?
> 
> <Eric> The original thread was trying to enforce a single transport across the
> receivers of a configured subscription, and where objects specific to that
> transport could be augmented to those receivers.
> 
> <Kent> Sorry, can you go over this again.  What is the stated goal?  I recall
> Martin wanting the same encoding across receivers, but the same transport
> too?  I assume you don't mean "same transport" but "same kind of transport"?
> So, if one receiver of a subscription uses netconf-notif, they all must use
> netconf-notif?

Yes.   This was a WG decision driven through IETF 101.

https://www.ietf.org/mail-archive/web/netconf/current/msg13875.html

 
> <Eric> The design pattern in the example augmentation below seems to do
> that.  This design pattern should hold whether a leafref is augmented in, or a
> group is augmented in.   This design pattern also works with the existing SN
> model.  I don’t know of an alternate proposal which meets these
> requirements.
> 
> <Kent> unsure.

I should have said is that there is no alternate proposal.  

What I am not sure about if one can even be defined with YANG using explicit case structure.
 
> <Eric> If this makes sense, the question becomes when to apply this design
> pattern on top of SN.   I agree there are interesting questions you raise
> above.  These questions appear to be bound to NETCONF call-home, and
> therefore the answers should be more closely aligned with draft-ietf-netconf-
> netconf-event-notifications rather than SN itself.
> 
> <Kent> agreed, most of this regards what's in the transport-binding drafts
> (netconf-notif, etc.), but I'm wanting to do this to prove out that the SN
> model.
> 
> <Eric> That is the driver behind my “ietf-netconf-subscribed-notifications-
> plus.yang” below.  Whether it augments in a  leafref or a group, this snippet of
> YANG provides a template for transport specific augmentations.  And using this
> template, how to embody NETCONF call home for subscriptions  could be
> delivered in a timeframe concurrent with “ietf-netconf-server.yang”.
> 
> <Kent> I understand you're trying to say "let's not worry about how ietf-
> netconf-server works with this now".  I appreciate the desire to defer what we
> can.  I will again say, as co-chair, that I'm okay with us moving without having a
> draft that depends on ietf-netconf-server or the ietf-restconf-server modules.
> That said, I don't understand what value the *conf-notif drafts have if they
> don't.  

Per cases (a) & (b) above, there is value.

>It seems that these drafts should depend on the ietf-*conf-server
> modules, but in order to get something to market faster, we want them to
> depend on something more like the ietf-*conf-no-crypto-server (right?), which
> the SN has further reduced to a single "address" leaf, which might be fine, but I
> don't think it should be in the SN model, since the ietf-*conf-server modules
> already define an address field, which would be redundant.

I believe there is utility in address.  But at this point I am ok with removing "address".  And any vendors wanting to support (b) can then add proprietary augmentations to do this.

> <Eric> Noe: If you wanted, a possible alternative to concurrent module delivery
> might be a single model.  To do this you would include a “subscription
> support” feature within “ietf-netconf-server.yang”.    The needed
> augmentation to
> "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver"  could then be
> made there.  (Note: that augmentation of course would be refined to meet the
> call-home questions/considerations from this thread, such as being aimed to
> its own instance of the netconf-server-grouping.)
> 
> <Kent> If I understand correctly, this would be a way to flag the call-home
> connection as being for SN, which addresses the I raised about how that would
> be known.  This is possible, and it might work well, but rather than put it into
> the ietf-*conf-server models directly, I think it would be better for the *conf-
> notif drafts to augment in the flag.

The best two choices I see are:
(1) Make an augmentation to the *conf-notif models.  This could be done via new drafts, and the model within. 
(2) Add the flag to *conf-server models.  This eliminates the need for future updates to the *conf-notif drafts.  It also keeps call-home specifics in one place.

Both choices allow us to support (a) & (b) now.

> <kent-orig> I also have an issue with the proposed leafref because it leaves
> open the possibility that two subscriptions could point to the same
> /ncs:netconf-server/ncs:call-home/ncs:netconf-client instance, which would
> likely cause protocol and state machine problems.
> 
> <Eric> Looking closer, perhaps a better place for the receiver leafref would be a
> choice of:
> /ncs:netconf-server/ncs:call-home/ncs:netconf-
> client/ncs:name/ncs:ssh/ncs:endpoints/ncs:endpoint/ncs:name
> or
> /ncs:netconf-server/ncs:call-home/ncs:netconf-
> client/ncs:name/ncs:tls/ncs:endpoints/ncs:endpoint/ncs:name
> 
> But again, I am fine with anything which doesn’t insert redundant data as part
> of the receiver call home configuration.
> 
> <Kent> No, just pointing to /ncs:netconf-server/ncs:call-home/ncs:netconf-
> client should work, since the instance can have only one transport (ssh or tls)
> defined at a time.  That said, if your requirement is that they must all be ssh or
> must all be tls, we have a bigger issue. 

There is no such requirement for all ssh or tls.  So it looks like such a future leafref might work.

>  FYI, the list of "endpoints" is there for
> HA reasons - they're a pool of failover endpoints the server can try - is that
> concept consistent with the SN draft?

I don't see any conflict.   In fact it should be a nice benefit of pointing to *conf-server.

Eric

> /kw
> 
> 
>