Re: [Netconf] a joint discussion on dynamic subscription

Martin Bjorklund <mbj@tail-f.com> Thu, 14 June 2018 15:37 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 1A4B1130E45 for <netconf@ietfa.amsl.com>; Thu, 14 Jun 2018 08:37:06 -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 fKPko-82ZUP3 for <netconf@ietfa.amsl.com>; Thu, 14 Jun 2018 08:37:04 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFBB130E7B for <netconf@ietf.org>; Thu, 14 Jun 2018 08:36:53 -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 6A6001AE01AA; Thu, 14 Jun 2018 17:36:52 +0200 (CEST)
Date: Thu, 14 Jun 2018 17:36:52 +0200 (CEST)
Message-Id: <20180614.173652.1677338076411920615.mbj@tail-f.com>
To: evoit@cisco.com
Cc: j.schoenwaelder@jacobs-university.de, zhoutianran@huawei.com, zhengguangying@huawei.com, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <7d8930974acf4fd28b7e60a24c5d2196@XCH-RTP-013.cisco.com>
References: <20180614095701.74rqetmhark3tzpd@anna.jacobs.jacobs-university.de> <20180614.153824.1029993696264171685.mbj@tail-f.com> <7d8930974acf4fd28b7e60a24c5d2196@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/JGLEtRWV9iV7eop0XTKkx1P4NIo>
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:37:06 -0000

"Eric Voit (evoit)" <evoit@cisco.com> wrote:
> > From: Martin Bjorklund, June 14, 2018 9:38 AM
> 
> >
> 
> > Juergen Schoenwaelder
> > <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>>
> > wrote:
> 
> > > On Thu, Jun 14, 2018 at 10:37:46AM +0200, Martin Bjorklund wrote:
> 
> > > >
> 
> > > > 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
> 
> > >
> 
> > > So why do we need the distinct role of a publisher?
> 
> 
> 
> I would argue that the server and publisher are the same (see below
> for why).  If this is true perhaps we could define the term
> "distributed publisher"

I'd say that if this is true, let's use the term "server" (RFC 8342)
and do not introduce new terms!

> which matches to the term "Subscribed Domain"
> in draft-ietf-netconf-udp-pub-channel.  A distributed publisher would
> be a type of publisher, inheriting all requirements for that device
> from subscribed-notifications.
> 
> 
> 
> If this is acceptable, then (2) is an implementation detail which can
> be hidden.  This addresses Juergen's comment that having (2) inserts
> error conditions which might need to be understood by the outside
> world.  My mental model for udp on mult-linecard (when building on the
> terminology of subscribed-notifications) would be something like:
> 
> 
> 
>        subscriber        receiver
> 
>            |             ^     ^
> 
>            | (1)         | (3) |
> 
>             |             |     |
> 
>         .---V-------------|-----|-------.
> 
>        | .------.  .-------. .-------. |
> 
>        | |master|  | agent | | agent | |
> 
>         | '------'  '-------' '-------' |
> 
>        |    distributed  publisher     |
> 
>         '-------------------------------'
> 
> 
> 
> Note that this is very close to figure 1 of the UDP draft.  The
> difference is that it gets rid of the 's' in Agents and Receivers.
> And turns subscribed domain into a single publisher.  This allows the
> hiding of error states between master and agent.
> 
> 
> Note that this is different than the distribution of terms within
> draft-zhou-netconf-multi-stream-originators.  And some work would be
> needed there to merge the terminology.
> 
> 
> 
> > > > 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.
> 
> > >
> 
> > > So we introduce the role of a publisher because of some transports
> 
> > > that do have a server?
> 
> >
> 
> > I assume you mean "do not".  Yes, that's my understanding.  But I
> > might be
> 
> > wrong.  Eric and Alex?
> 
> 
> 
> The term "server" is only used once in
> draft-ietf-netconf-udp-pub-channel.  And then it refers to "push
> server".  I am assuming the "push server" is a publisher.  Based on
> this, I do believe we can get away from using the term "server".

Again, I think it is useful to use terms that already exists.  So if
publisher and server means the same thing, let's stick to server.



/martin


> 
> Eric
> 
> 
> 
> > > If the publisher is truely distinct entity from the server (and the
> 
> > > state it has), we may get interesting security considerations to
> 
> > > write.
> 
> >
> 
> > Isn't this what the UDP transport does?  It uses a NETCONF/RESTCONF
> > server
> 
> > to set up the subscription, then UDP to send the notifications.
> 
> >
> 
> >
> 
> > /martin