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

Kent Watsen <kwatsen@juniper.net> Fri, 22 June 2018 22:09 UTC

Return-Path: <kwatsen@juniper.net>
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 C7F57130F02 for <netconf@ietfa.amsl.com>; Fri, 22 Jun 2018 15:09:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 iXq8TWHzCUEv for <netconf@ietfa.amsl.com>; Fri, 22 Jun 2018 15:09:47 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1582130EF2 for <netconf@ietf.org>; Fri, 22 Jun 2018 15:09:46 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5MKT994015704; Fri, 22 Jun 2018 13:30:22 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=kGeG7JAHG9Dib8/zycK9UgiYC9HTRGC6HV+dunkFexw=; b=NFCCAM3DcbRyH+pbrSWK9OJwt7fjpSZiHGyym1r1FXsrua+7VaEmWpvTYgQlCaE7T/+J Ae9DMsGC3DD4xj+s8G7gwII64F/Mb77cfVYOcaiarcw5liLNCUf0wzmkbxohywGGLHly DgfKNQWQwXJBayG/hUIw3lqrkWkq6QnLicbdVoqzhehhNnRYJYNdYeYSusqEdyMBx4i/ QImbkwna+ho98jBeBn7P1+jfoxAW+xDHTkEyoUruPGwHkbbWHXwdkoWYFmok74kjr4+n S8Dp8DDBtMlaxLkhwNmvxVGkvsS/uehVBHtdKLPsL0fz4qD8lT58isIVaDJbTH3Bk9vR bA==
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0016.outbound.protection.outlook.com [216.32.180.16]) by mx0b-00273201.pphosted.com with ESMTP id 2js7mar1mp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 22 Jun 2018 13:30:22 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4055.namprd05.prod.outlook.com (52.135.199.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.15; Fri, 22 Jun 2018 20:30:20 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc%4]) with mapi id 15.20.0884.010; Fri, 22 Jun 2018 20:30:20 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "Eric Voit (evoit)" <evoit@cisco.com>, 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: AQHT7qXx6AR0hwD/VEqFVDxs31zp6aQ1kroAgAAEGoCAAA8IgIAAYuSAgCWiwACAAZ7SAIAK57IAgAEbxgD//+unAIAAbY0AgAEjt4CAAFpqAIABijQA
Date: Fri, 22 Jun 2018 20:30:20 +0000
Message-ID: <38D9AA27-DFFE-4BA3-9B9A-F33BD24B9C21@juniper.net>
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> <cd9b7871b2ce4ad9987b6d782e6bcc3d@XCH-RTP-013.cisco.com>
In-Reply-To: <cd9b7871b2ce4ad9987b6d782e6bcc3d@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4055; 7:SR17Zaf/7CVzD8Pk3VuTuXQkpriDGqt5EfCgQe1xZCbqGqrCOAsEubgzhuwzM5V7D2yL/AL1int7cnNUuuA4qOc36d3VU7y+pc02yhd0RLM7FmwWWFNqK9eSrOnGB4YQngyA2rcLSzFVHPvJ5D15ALLQubHZPPSkhnSAkX3wIX/TEhmFLQ8ioES29CcXobzM3cF0C/tCVaQOysRiLDrNsJZaSyUMoXDmkzDpEa90FRL41h1AP4zkNHLJbCOZyedE
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 36039c82-e3a6-47ad-5b61-08d5d87ef978
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4055;
x-ms-traffictypediagnostic: BYAPR05MB4055:
x-microsoft-antispam-prvs: <BYAPR05MB40551603CC77AFE608A9E31DA5750@BYAPR05MB4055.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231254)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4055; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4055;
x-forefront-prvs: 071156160B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(366004)(396003)(39380400002)(199004)(189003)(52314003)(69234005)(6436002)(6506007)(476003)(446003)(6116002)(53936002)(6246003)(99286004)(3280700002)(66066001)(59450400001)(3846002)(86362001)(2900100001)(2616005)(6486002)(575784001)(229853002)(11346002)(76176011)(102836004)(25786009)(83716003)(6306002)(93886005)(26005)(6512007)(486006)(14454004)(186003)(4326008)(105586002)(82746002)(58126008)(305945005)(316002)(7736002)(966005)(81166006)(68736007)(5250100002)(33656002)(561944003)(81156014)(8676002)(36756003)(8936002)(5660300001)(3660700001)(97736004)(2906002)(110136005)(478600001)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4055; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: UFcW7p44tXc+7oXhEzXMOpgidwGv/JlCrdWamLZnhWb7QYmi3Nuz9XJlZQWtRwwhfhie8xW8HN6g/YD3sPJ6MY+zWFmS+m5UKa8jorgfUH7KMOFNW6OzpTsPrJeLBFrySl5is8Qo6c3wSdyzJDp4/sFRXFElLUjyKyRhM2yUlsg+1yuyjY9yQszBtwA6gGxGgCyL4OHa24TfOJXYYPctHY/369f4h2ZJ04inBLsuCL9jyQU3SkgNEh5jQEMaSFcdCKTccaBXOhULGWbRwahU125IDO25fwsKOC+/AWfyRwXWSUOpjSdxdwFp2Y3OXe9XF7/Xw7Np95JeMbe6CvTBqQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <ADACB38D77E0FD4AB688DD1B3BE81D40@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 36039c82-e3a6-47ad-5b61-08d5d87ef978
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2018 20:30:20.5066 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4055
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-22_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806220227
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/QS14f-6w-BzCD9280uuO06CZK6c>
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: Fri, 22 Jun 2018 22:09:50 -0000

Hi Eric,


>> <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?

(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.  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.



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

Good grief, the WG abandoned that draft two years ago during a factoring effort.  The current draft is here, and it's very much alive; there was big update a couple weeks ago.  Here's the latest: https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-06.


>> <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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_netconf_current_msg13875.html&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=k7VsSkN2Q165UV6B4VmVssEhPOMrwj4K7_BDR5wHSc0&s=Q6QpnXZg_HVNPxTCTjdf20mC56AQyCPM55K_23ouVeQ&e=


Okay, I see it, weak, but it's there.

I completely understand why we'd want the same encoding, but not so much same protocol, since each receiver has its own distinct instance of the protocol anyway, so it doesn't seem to make a difference, i.e. no runtime optimization.  Did you ever figure it out?

BTW, in that thread, I see Einar mentioning that the multiple receives are there to support HA/redundancy.  As I understand this, this would be duplicated-delivery to multiple receivers, which would be merged into some centralized datastore, where all the duplicates would be removed.  Is this your understanding too?  FWIW, the ietf-*conf-server modules also enable each call-home connection to a logical "netconf-client" composed of multiple endpoints, for HA purposes, but these endpoints are connected to one at a time.  So, when thinking about incorporating the ietf-*conf-servers, will having these two HA mechanisms in play at the same time cause any conflict?  Would it make sense to remove the multi-receiver HA config in SN and instead rely and the *-conf-server's HA mechanism + dynamic-subscriptions to fill in any gaps between reconnects?


 
>> <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.
 
<Kent> what do you mean by "explicit case structure"?  I don't see any in the example you shared previously...




>> <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.

There is a difference between a server not *implementing* a ietf-*conf-server 
module and the *conf-notif not *using* the *conf-server-grouping statements.
My suggestion has been, that the *conf-notif drafts should have their own lists
of netconf-servers (via "uses" statements), and thereby not be dependent on the
existence of a global ietf-*conf-server instance (which may not exist).

Separately, there is the issue of how to get something to RFC status faster
than the client-server drafts (assuming that is a good idea).  My first thought,
mentioned before, is that we could define "no-crypto" variants of the modules,
thus ensuring that all the patterns are consistently applied, while not having
a dependency on those other modules.  This is hard to discuss currently because
ietf-netconf-subscribed-notifications and ietf-http-subscribed-notifications
don't actually enable configuring the transports yet…



>> 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.

The "address" leaf would be perfect in another circumstance, but it's redundant
in conjunction with the ietf-*conf usage, which already have an "address" leaf,
per "endpoint" no less.  My guess is that the "address" leaf needs to disappear
from the SN module, thereby allow each transport to augment in exactly what it
needs.



>> <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 issue 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.

I like (1) more, as it then ties the existence of the flag to the *implementation*
of the corresponding *conf-server module.  

That said, I have to say that I'm not entirely sure if I understand if what is planned
is legal.  For instance, in a normal NETCONF call-home situation, the NETCONF session
begins with both sides sending <hello> messages and then the server waiting for the
client to send RPCs, which might include a 5277 <create-subscription>, after which
the <notifications> begin to flow.  Is this the same here, or are you expecting the 
<notification> messages to start flowing immediately?




>> <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. 
>>
>>  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.

Great!


Kent // contributor