Re: [Netconf] a joint discussion on dynamic subscription

Tianran Zhou <zhoutianran@huawei.com> Tue, 19 June 2018 03:20 UTC

Return-Path: <zhoutianran@huawei.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 08368131066 for <netconf@ietfa.amsl.com>; Mon, 18 Jun 2018 20:20:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 9JDkkeU-Vcyn for <netconf@ietfa.amsl.com>; Mon, 18 Jun 2018 20:20:32 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BCC12D949 for <netconf@ietf.org>; Mon, 18 Jun 2018 20:20:31 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id DD8623976D896; Tue, 19 Jun 2018 04:20:25 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 19 Jun 2018 04:20:27 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0382.000; Tue, 19 Jun 2018 11:20:15 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: "Eric Voit (evoit)" <evoit@cisco.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 <alexander.clemm@huawei.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] a joint discussion on dynamic subscription
Thread-Index: AdQEuiPwleA73iSHT9WWcs04T6Gmb///pEqA//ogRLA=
Date: Tue, 19 Jun 2018 03:20:14 +0000
Message-ID: <BBA82579FD347748BEADC4C445EA0F21B55CF3C7@NKGEML515-MBX.china.huawei.com>
References: <BBA82579FD347748BEADC4C445EA0F21B55CEB74@NKGEML515-MBX.china.huawei.com> <7cc07aab4bdf4467a86b0d25d4e46437@XCH-RTP-013.cisco.com>
In-Reply-To: <7cc07aab4bdf4467a86b0d25d4e46437@XCH-RTP-013.cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.156.116]
Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21B55CF3C7NKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/xz3uYRkUgee-jcOJWF_32fXfNBI>
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: Tue, 19 Jun 2018 03:20:36 -0000

Thanks Eric for your proposal. It makes sense to me.
I would like to update both documents based on this idea.

Cheers,
Tianran

From: Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Saturday, June 16, 2018 1:36 AM
To: Tianran Zhou <zhoutianran@huawei.com>; Martin Bjorklund <mbj@tail-f.com>; j.schoenwaelder@jacobs-university.de; Zhengguangying (Walker) <zhengguangying@huawei.com>; alex@clemm.org; Alexander Clemm <alexander.clemm@huawei.com>
Cc: netconf@ietf.org
Subject: RE: [Netconf] a joint discussion on dynamic subscription

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