Re: [Netconf] a joint discussion on dynamic subscription

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 15 June 2018 17:36 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 2491A12872C for <netconf@ietfa.amsl.com>; Fri, 15 Jun 2018 10:36:13 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 wcWXxQnzl9sJ for <netconf@ietfa.amsl.com>; Fri, 15 Jun 2018 10:36:09 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B3F124D68 for <netconf@ietf.org>; Fri, 15 Jun 2018 10:36:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60326; q=dns/txt; s=iport; t=1529084169; x=1530293769; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=16KLy5Ztj4bdSrG7tBAXlBILYPsFekbj6y57UmeB4tM=; b=VJJJayltYhOcVIbv/2nXvnzjSuM3cvQH2EcCxNqOPydmibWx17UipjtC MsSJjbRaSyu2HYm850QxXyFQCCUxbo1ebmxJRpCAX4SHQng5mJXxhQjWp bYiRlIeZtTWa/WXdTu6DJQUNhZOdAMoe8DEpr6p1N93zc1W8TOoXbqtN5 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CoAQAU+CNb/4kNJK1bGQEBAQEBAQEBAQEBAQcBAQEBAYJTdWJ/KAqDMD+UVoF/lG+BeAuBVoMWAheCOyE2FgECAQEBAQEBAm0ohSgBAQEDAQwXBAZMBQsCAQYCEAIDEBMBBgMCAgIwFAMOAQEEAQ0FCIMcgRtcCI42m0eBaTODewGETYFoiEyBVD+BD4JeLoRfLR+CS4JVAodQhGmMVQkCjneNQJEaAhETAYEkJAMuJoEscBWCfoIhF41hATVvjz+BGgEB
X-IronPort-AV: E=Sophos;i="5.51,228,1526342400"; d="scan'208,217";a="130171804"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2018 17:36:08 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w5FHa8Qs008027 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Jun 2018 17:36:08 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 15 Jun 2018 13:36:07 -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; Fri, 15 Jun 2018 13:36:07 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Tianran Zhou <zhoutianran@huawei.com>, Martin Bjorklund <mbj@tail-f.com>, "j.schoenwaelder@jacobs-university.de" <j.schoenwaelder@jacobs-university.de>, "Zhengguangying (Walker)" <zhengguangying@huawei.com>, "alex@clemm.org" <alex@clemm.org>, "alexander.clemm@huawei.com" <alexander.clemm@huawei.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] a joint discussion on dynamic subscription
Thread-Index: AdQEuiPwde4gaRHPTgG2WyMdkd0r2gACo0qQ
Date: Fri, 15 Jun 2018 17:36:07 +0000
Message-ID: <7cc07aab4bdf4467a86b0d25d4e46437@XCH-RTP-013.cisco.com>
References: <BBA82579FD347748BEADC4C445EA0F21B55CEB74@NKGEML515-MBX.china.huawei.com>
In-Reply-To: <BBA82579FD347748BEADC4C445EA0F21B55CEB74@NKGEML515-MBX.china.huawei.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: multipart/alternative; boundary="_000_7cc07aab4bdf4467a86b0d25d4e46437XCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/YX8yiDAVBhJUzbdsaA1jL5CFytY>
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: Fri, 15 Jun 2018 17:36:14 -0000

Hi Tianran,

There are certainly good aspects to the proposal.  And I agree distributed subscription handling does need some constructs beyond subscribed-notifications.  And below you have bound the problem to be one of internal coordination.  It is then up to the master to provide any details of the distribution of the covered elements of the subscription back to the subscriber.

So I like the general breakdown of boxes. Proper naming of the boxes will matter.  So let me make a proposal below:


        subscriber       receiver

             +            ^   ^

             |            |   |

             |  +---------+   |

             |  |             |

+---------------------------------------+

| Publisher  |  |             |         |

|     +------v--+---+  +------+------+  |

|     | Subscription|  | Component   |  |

|     | Server      |  | Subscription|  |

|     |             |  | Server      |  |

|     | (or master) |  | (or agent)  |  |

|     +-------------+  +-------------+  |

|                                       |

+---------------------------------------+

There are two reason for “publisher” is a good name for the outer box.  First, before multi-stream-originators, implementations of subscription are not distributed. Therefore breaking out and exposing the internal components is not necessary.  Where multi-stream is not needed, the term publisher is the single one which best fits the network role.  Second, right now the subscribed-notifications YANG model and document of exposes its features and capabilities based on the larger dotted boxes.  So if we choose to continue to call that larger box the publisher, none of the existing subscription terminology in other drafts need to change.

Whether we should call the internal boxes “Subscription Server” or “Master” or something is fine with me.

One final thought on your point below.   Regarding your agent acting as a client -- this is the exact reason why HTTP2 configured subscriptions has defined the publisher being an HTTP2 client.

Thanks,
Eric


From: Tianran Zhou, June 15, 2018 11:47 AM


Hi,



I have to say we created some new terms in draft-zhou-netconf-multi-stream-originators, because I think the distributed data collection makes something new.

Firstly, I do not think the subscription server and the publisher are the same, but they are in the same entity. There are indeed two components one to accept subscriptions via a subscription channel, and the other to send notifications to the receiver. These two channels may use different transport and connection. And the publisher is more like a client.

Yes, maybe no need to expose the internal. But we want to explain some more about the subscription decomposition. I.e., the subscriber send a request to the subscription server on the master, then the subscription server will decompose the subscription and relay it to the subscription server on the agent, which we call it component subscription server.

Secondly, we call the entity which contains the subscription server and the publisher the stream originator. Both master and agent are roles of the stream originators. I do not want to make master and agent to be entity itself.



We may simplify the figure to reduce the use of new terms by call the entity as the publisher, and do not show the internal detail. Like this:



     subscriber       receiver

          +            ^   ^

          |            |   |

          |  +---------+   |

          |  |             |

+----------------------------------+

| master  |  |      agent  |       |

|  +------v--+-+    +------+----+  |

|  | publisher |    | publisher |  |

|  +-----------+    +-----------+  |

|                                  |

+----------------------------------+



What’s your thoughts?



BR,

Tianran







发件人: Eric Voit (evoit) [mailto:evoit@cisco.com]

发送时间: 2018年6月14日 23:04

收件人: Martin Bjorklund <mbj@tail-f.com<mailto:mbj@tail-f.com>>; j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>; Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>; Zhengguangying (Walker) <zhengguangying@huawei.com<mailto:zhengguangying@huawei.com>>

抄送: netconf@ietf.org<mailto:netconf@ietf.org>

主题: RE: [Netconf] a joint discussion on dynamic subscription



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

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