Re: [Netconf] a joint discussion on dynamic subscription

Martin Bjorklund <mbj@tail-f.com> Thu, 14 June 2018 15:33 UTC

Return-Path: <mbj@tail-f.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 8A156130E34 for <netconf@ietfa.amsl.com>; Thu, 14 Jun 2018 08:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ATECbwsGR4Ax for <netconf@ietfa.amsl.com>; Thu, 14 Jun 2018 08:33:38 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C9F4B130E30 for <netconf@ietf.org>; Thu, 14 Jun 2018 08:33:37 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id C974E1AE01AA; Thu, 14 Jun 2018 17:33:36 +0200 (CEST)
Date: Thu, 14 Jun 2018 17:33:36 +0200 (CEST)
Message-Id: <20180614.173336.685729077247623581.mbj@tail-f.com>
To: evoit@cisco.com
Cc: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <2cf5c980904346dab2ce9bce546cc763@XCH-RTP-013.cisco.com>
References: <20180614.091828.21142123428745204.mbj@tail-f.com> <20180614.103746.8291316293283106.mbj@tail-f.com> <2cf5c980904346dab2ce9bce546cc763@XCH-RTP-013.cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/O91eGnscUSPzaRH0NCgYa6wcGUs>
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 15:33:41 -0000

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

> 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/draft-ietf-
> > > > 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
> > >
>