Re: [Netconf] a joint discussion on dynamic subscription
"Eric Voit (evoit)" <evoit@cisco.com> Thu, 14 June 2018 17:25 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 B04E6130E57 for <netconf@ietfa.amsl.com>; Thu, 14 Jun 2018 10:25:18 -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 z0yb7GN5NGws for <netconf@ietfa.amsl.com>; Thu, 14 Jun 2018 10:25:15 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E8512785F for <netconf@ietf.org>; Thu, 14 Jun 2018 10:25:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10395; q=dns/txt; s=iport; t=1528997115; x=1530206715; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kBT2M2mAjvoHbCNpqAzNvqePAyYtyFY/eZF+TpODZZw=; b=lidIcxKQnyjqS5yf3qtFiEl5ZGynZbA7a2CA0zoFyxgkCxFFzXuR8LVB T7NycGfYjwS+oE/lDQJtgaiMBrRd0oWKCVBGbsDOo9hkUd987A2Xmo/jj 83A9t/TMbfz4cY1JsFsPEdr9t95LrirojBbZeVSnaHmSKAovJlGtHo7so 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C8AADnoyJb/5hdJa1cGQEBAQEBAQEBAQEBAQcBAQEBAYNIYn8oCotzjFKBf3WTeIF4CxgLhANGAoJJITQYAQIBAQEBAQECbRwMhSgBAQEDAQEBJRM0CwULAgEIDgQDAw0RECcLFw4CBA4FCIMcgXcID6wZM4hGgWMFiEyBVD+BD4JXBy6DEwEBgToQhWwCh1CRPgkChXeJAI1Aig2HDQIREwGBJB04gVJwFTuCQ4V9hRSFPQFvjXKBLYEaAQE
X-IronPort-AV: E=Sophos;i="5.51,222,1526342400"; d="scan'208";a="129958837"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2018 17:25:14 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w5EHPEXj016020 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Jun 2018 17:25:14 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, 14 Jun 2018 13:25:13 -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, 14 Jun 2018 13:25:13 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] a joint discussion on dynamic subscription
Thread-Index: AdQCx01ede4gaRHPTgG2WyMdkd0r2gARka+AADD1vgAAAsT/AAAFHZ7QAAloOQAACEEQAP//2xkAgABCqeA=
Date: Thu, 14 Jun 2018 17:25:12 +0000
Message-ID: <b04489db40b84484805136a66e829705@XCH-RTP-013.cisco.com>
References: <2cf5c980904346dab2ce9bce546cc763@XCH-RTP-013.cisco.com> <20180614.173336.685729077247623581.mbj@tail-f.com> <3535bb98b1f849c083e335669e24ef5a@XCH-RTP-013.cisco.com> <20180614.191752.1218490367241887144.mbj@tail-f.com>
In-Reply-To: <20180614.191752.1218490367241887144.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.228]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/GFewJgVURtays5h4ApJpWPk5xJg>
Subject: Re: [Netconf] a joint discussion on dynamic subscription
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, 14 Jun 2018 17:25:19 -0000
> From: Martin Bjorklund, June 14, 2018 1:18 PM > > "Eric Voit (evoit)" <evoit@cisco.com> wrote: > > > From: Martin Bjorklund, June 14, 2018 11:34 AM > > > > > > "Eric Voit (evoit)" <evoit@cisco.com> wrote: > > > > > From: Martin Bjorklund, June 14, 2018 4:38 AM > > > > > > > > > > Hi, > > > > > > > > > > Another thing related to this. You have: > > > > > > > > > > Receiver: A target to which a publisher pushes subscribed event > > > > > records. For dynamic subscriptions, the receiver and subscriber are > > > > > the same entity. > > > > > > > > > > But in the HTTP and UDP cases this last sentence is probably not > > > > > true, right? > > > > > > > > > > Also, I have always struggled with the terms "publisher", > > > > > "receiver", "subscriber" vs. "client" and "server". > > > > > > > > > > I think that a "subscriber" is always the "client". If so, I > > > > > think this should be mentioned in 1.2 (and the term "client" > > > > > imported from RFC 8342). > > > > > > > > The subscriber need not always the transport client. This is > > > > dependent on the transport selected. For example in the RESTCONF > > > > draft for configured subscriptions, the HTTP client is the > > > > Publisher, and the HTTP server is the receiver. See section 4.2 & > > > > Figure 3 of draft-ietf-netconf-restconf-notif. > > > > > > How does this change the fact that the subscriber is the client (RFC > > > 8342 term)? > > > > On that point, I was just trying to limit the use of the word > > "client", as it has so many meanings already. > > > > Beyond the many meanings of client, there is another reason why a > > subscriber isn't necessarily an RFC8342 client. The RFC8342 > > definition of client is based on YANG data. As event streams might > > not be YANG data, this definition isn't a full match for what is > > covered by subscribed-notifications. > > Your definition is: > > Subscriber: An entity able to request and negotiate a contract for > the generation and push of event records from a publisher. > > How can this NOT be a client, in the 8342 meaning? AFAICT, the subscriber can > either set up a dynamic subscription, using establish-subscription. This is > certainly a "client". Or it can set up a configured subscription, by creating > configuration in the /subscriptions/subscription list. This is also a "client". In RFC-8341, the term client is defined as: o client: An entity that can access YANG-defined data on a server, over some network management protocol. As an event stream might not include YANG-defined data, the definition didn't seem to fit. If we wanted to import the term RFC8342 term client, we could do in YANG-push. There we could say that a subscriber to a YANG datastore is covered by the RFC-8342 definition of client. Would this cover your concern? Eric > I do understand that the *receiver* may not be a client. > > > /martin > > > > (However it would be a match > > for a YANG-Push subscriber.) > > > > Eric > > > > > > For draft-ietf-netconf-udp-pub-channel draft, I can see the > > > > possibility of transport client session being initiated from the > > > > line cards. > > > > > > Right, that's why I assumed there is a separation between server and > publisher. > > > "server" again in RFC 8342 terms. It is the server for > > > establish-subscription or the server where configured subscriptions are > managed. > > > > > > > > > /martin > > > > > > > > > > > > > > Eric > > > > > > > > > Also, I think it would be useful to draw a picture that > > > > > demonstrates the roles: > > > > > > > > > > subscriber/client receiver > > > > > | ^ > > > > > | (1) | (3) > > > > > | | > > > > > | | > > > > > v (2) | > > > > > server ----------> publisher > > > > > > > > > > > > > > > (1) is creation of the subscriptionE; dynamic or configured > > > > > (2) is implementation specific > > > > > (3) is the delivery of notifications / event records > > > > > > > > > > NOTE: the subscriber and receiver MAY be the same entity > > > > > NOTE: for some transports, if (1) is dynamic, (3) is sent over the > > > > > same session as (1) > > > > > NOTE: for some transports, the sevrer and publisher are the same > > > > > entity > > > > > > > > > > > > > > > If we can agree on an architectural picture like this, the > > > > > different transport docs can refer to this architecture and be defined > related > > > > > to it. For example, the netconf transport doc can state that the > > > > > publisher is always the same entity etc. > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > Martin Bjorklund <mbj@tail-f.com> wrote: > > > > > > Hi, > > > > > > > > > > > > "Eric Voit (evoit)" <evoit@cisco.com> wrote: > > > > > > > Hi Tianran, > > > > > > > > > > > > > > > From: Tianran Zhou, June 12, 2018 11:47 PM > > > > > > > > > > > > > > > > Hi Eric, > > > > > > > > > > > > > > > > When we are discussing the > > > > > > > > draft-ietf-netconf-udp-pub-channel, > > > > > > > > we find a conflict with current dynamic subscription design. > > > > > > > > 1. The dynamic subscription requires notification to use > > > > > > > > the same channel as the subscription. > > > > > > > > > > > > > > This is true when you look at the NETCONF transport draft. > > > > > > > However this is *not* required by the base > > > > > > > subscribed-notification > > > draft. > > > > > > > And in fact, the HTTP transport draft might not use the same > > > > > > > logical channel. E.g., see how the URI is returned within: > > > > > > > https://github.com/netconf-wg/notif-restconf/blob/master/dra > > > > > > > ft-i > > > > > > > etf- > > > > > > > netconf-restconf-notif-05.txt > > > > > > > > > > > > > > So if you wanted to define some transport session > > > > > > > independence for a UDP transport, subscribed-notifications > > > > > > > should permit that. And if you believe there is something > > > > > > > in the text which prohibits this, let me know. > > > > > > > > > > > > Cool! I think that this should be explcitly described in the > > > > > > subscribed-notifications document. > > > > > > > > > > > > In the case of RESTCONF, decision to use a separate channel > > > > > > for the notifs is implicit in the transport of the request to > > > > > > establish-subscription. > > > > > > > > > > > > In the case of UDP, I think the idea is that the > > > > > > establish-subscription is sent over any protocol that can do > > > > > > RPCs (NETCONF, RESTCONF, ...), but then some specific input > > > > > > parameter informs the server that the notifs are supposed to > > > > > > be sent over some other transport. > > > > > > > > > > > > While reading the text about sessions, I found this: > > > > > > > > > > > > In 2.4.3: > > > > > > > > > > > > The "modify-subscription" operation permits changing the terms of > an > > > > > > existing dynamic subscription established on that transport session > > > > > > via "establish-subscription". > > > > > > > > > > > > Which session does "that transport session" mean? Perhaps simply: > > > > > > > > > > > > NEW: > > > > > > > > > > > > The "modify-subscription" operation permits changing the terms of > an > > > > > > existing dynamic subscription. > > > > > > > > > > > > > > > > > > > > 2. The RPC does not have the input information about the > > > > > > > > receiver because the above assumption. > > > > > > > > > > > > > > > > However, when we talk about the distributed data > > > > > > > > collection (multi data originators), the publication > > > > > > > > channel is always different from the subscription channel. > > > > > > > > > > > > > > While it likely isn't what you want, even with NETCONF, the > > > > > > > single NETCONF session doesn't means that distributed line > > > > > > > card generation of the notification messages is impossible. > > > > > > > For example, the inclusion of the header object > > > > > > > message-generator-id (as defined within > > > > > > > draft-ietf-netconf-notification-messages) allows the > > > > > > > notification message generation to be distributed onto > > > > > > > linecards even if the messages themselves are still driven > > > > > > > back to a central transport session. Note that I am not > > > > > > > recommending this, but the specifications would support this. > > > > > > > > > > > > > > > So either the distributed data collection does not support > > > > > > > > dynamic subscription, or current dynamic subscription > > > > > > > > definition may need modification. > > > > > > > > > > > > > > I think for UDP, you will want to define a way to bind the > > > > > > > lifecycle of the dynamic subscription's channels across > > > > > > > multiple line > > > cards. > > > > > > > This will require some thinking as well as coordination > > > > > > > within the publisher. > > > > > > > > > > > > But this is an implementation detail. However, it is true > > > > > > that the specification must work out the fate-sharing details > > > > > > between the session that sent the establish-subscription and the notif > channel. > > > > > > Just as in the "restconf" draft. > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > Perhaps returning multiple URIs (one for each linecard) > > > > > > > might be something which could make this easier. If you go > > > > > > > down this path, you still will need to fate-share the > > > > > > > lifecycle of the subscription across all of those line cards. > > > > > > > > > > > > > > Eric > > > > > > > > > > > > > > > What's your thoughts? > > > > > > > > > > > > > > > > Regards, > > > > > > > > Tianran > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Netconf mailing list > > > > > > Netconf@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > >
- Re: [Netconf] a joint discussion on dynamic subsc… Tianran Zhou
- Re: [Netconf] a joint discussion on dynamic subsc… Alexander Clemm
- Re: [Netconf] a joint discussion on dynamic subsc… Eric Voit (evoit)
- Re: [Netconf] a joint discussion on dynamic subsc… Tianran Zhou
- Re: [Netconf] a joint discussion on dynamic subsc… Martin Bjorklund
- Re: [Netconf] a joint discussion on dynamic subsc… Eric Voit (evoit)
- Re: [Netconf] a joint discussion on dynamic subsc… Martin Bjorklund
- Re: [Netconf] a joint discussion on dynamic subsc… Eric Voit (evoit)
- Re: [Netconf] a joint discussion on dynamic subsc… Martin Bjorklund
- Re: [Netconf] a joint discussion on dynamic subsc… Eric Voit (evoit)
- Re: [Netconf] a joint discussion on dynamic subsc… Martin Bjorklund
- Re: [Netconf] a joint discussion on dynamic subsc… Eric Voit (evoit)
- Re: [Netconf] a joint discussion on dynamic subsc… Martin Bjorklund
- Re: [Netconf] a joint discussion on dynamic subsc… Juergen Schoenwaelder
- Re: [Netconf] a joint discussion on dynamic subsc… Eric Voit (evoit)
- Re: [Netconf] a joint discussion on dynamic subsc… Eric Voit (evoit)
- Re: [Netconf] a joint discussion on dynamic subsc… Eric Voit (evoit)
- Re: [Netconf] a joint discussion on dynamic subsc… Eric Voit (evoit)
- Re: [Netconf] a joint discussion on dynamic subsc… Martin Bjorklund
- Re: [Netconf] a joint discussion on dynamic subsc… Tianran Zhou
- Re: [Netconf] a joint discussion on dynamic subsc… Juergen Schoenwaelder
- Re: [Netconf] a joint discussion on dynamic subsc… Tianran Zhou
- Re: [Netconf] a joint discussion on dynamic subsc… Juergen Schoenwaelder
- Re: [Netconf] a joint discussion on dynamic subsc… Martin Bjorklund
- Re: [Netconf] a joint discussion on dynamic subsc… Martin Bjorklund
- Re: [Netconf] a joint discussion on dynamic subsc… Eric Voit (evoit)
- [Netconf] a joint discussion on dynamic subscript… Tianran Zhou