Re: [Netconf] a joint discussion on dynamic subscription

[Tianran Zhou <[e-mail]>]

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:[e-mail]]

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

收件人: Martin Bjorklund <[e-mail]>; [e-mail]; Tianran Zhou <[e-mail]>; Zhengguangying (Walker) <[e-mail]>

抄送: [e-mail]

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



> From: Martin Bjorklund, June 14, 2018 9:38 AM

>

> Juergen Schoenwaelder <[e-mail]> 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