Re: [Netconf] a joint discussion on dynamic subscription

"Eric Voit (evoit)" <evoit@cisco.com> Thu, 14 June 2018 18:28 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 6D7ED130E58 for <netconf@ietfa.amsl.com>; Thu, 14 Jun 2018 11:28:21 -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 dW4X9uDrncFB for <netconf@ietfa.amsl.com>; Thu, 14 Jun 2018 11:28:19 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4D8130E1D for <netconf@ietf.org>; Thu, 14 Jun 2018 11:28:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12793; q=dns/txt; s=iport; t=1529000899; x=1530210499; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HYs38iefUsv4RHxhDN7T9JBTbU567PCQa0i4rlHBR1E=; b=ZghIqID24LlkuYnw8hxcvoBOB8ZCELbd4CClbyMadfMaIR2BeTDZX2YS 0mQjKNcc+hRRvG5TGKA4lQNofuIA+97iobB11tM3XTn6W6ClVM4W9C7fR ZLMyVME1inQv3cf/kLNhXqCnqvQ3+ozBQMqgCvMfUvtwwnscIlrzOCsvW 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfAAB2syJb/4wNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNIYn8oCotzjFKBf3WTeIF4CxgLhANGAoJJITQYAQIBAQE?= =?us-ascii?q?BAQECbRwMhSgBAQEDAQEBJRM0CwULAgEIDgQDAgENERAnCxcGCAIEDgUIgxy?= =?us-ascii?q?BdwgPq34ziEWBYwWITIFUP4EPglcHLoMTAQGBOhCFbAKHUJE+CQKFd4kAjUC?= =?us-ascii?q?KDYcNAhETAYEkHTiBUnAVO4JDhX2FFIU9AW+NfIEtgRoBAQ?=
X-IronPort-AV: E=Sophos;i="5.51,222,1526342400"; d="scan'208";a="410357968"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2018 18:28:17 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w5EISG3U013078 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Jun 2018 18:28:18 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 14 Jun 2018 14:28:16 -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 14:28:16 -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//2xkAgABCqeD//80PAIAAQqjg
Date: Thu, 14 Jun 2018 18:28:16 +0000
Message-ID: <2f880653fa5742c0b1770da73e3814a4@XCH-RTP-013.cisco.com>
References: <3535bb98b1f849c083e335669e24ef5a@XCH-RTP-013.cisco.com> <20180614.191752.1218490367241887144.mbj@tail-f.com> <b04489db40b84484805136a66e829705@XCH-RTP-013.cisco.com> <20180614.201408.2242971347993162967.mbj@tail-f.com>
In-Reply-To: <20180614.201408.2242971347993162967.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/xO4AiUHusqKRvAXn_oO8C3N4pJA>
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 18:28:22 -0000

> From: Martin Bjorklund, June 14, 2018 2:14 PM
>
> Subject: Re: [Netconf] a joint discussion on dynamic subscription
> 
> "Eric Voit (evoit)" <evoit@cisco.com> wrote:
> > > 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.
> 
> But the subscriber doesn't even see content from any event stream, so how
> does this matter?  An entity that sends the RPC "establish-subscription" *is* a
> "client".

Hmm.  So your augment is that as the subscriber never receives event records (this is always the receiver), then even a subscribed-notifications subscriber is a valid RFC-8342 client.   

As not all clients are subscribers. I can see where it could be useful to make this correlation within subscribed-notifications.  To support this, are you good with a tweak of the definition of Subscriber to:

OLD
An entity able to request and negotiate a contract for the generation and push of event records from a publisher.  For dynamic subscriptions, the receiver and subscriber are the same entity.

NEW
An RFC-8342 client able to request and negotiate a contract for the generation and push of event records from a publisher.  For dynamic subscriptions, the receiver and subscriber are the same entity.

Eric
 
> > 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?
> 
> No, see above.
> 
> 
> /martin
> 
> 
> 
> >
> > 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
> > > > > > > >
> > > > > >
> > > >
> >