Re: [Netconf] Comments on draft-ietf-netconf-yang-push-18

[Andy Bierman <[e-mail]>]

On Tue, Sep 4, 2018 at 9:20 AM, Yutianpeng (Tim) <[e-mail]>
wrote:

> Hi,
> Thanks for reply.
> Some explanations as below, please check.
> Tim
>
> -----Original Message-----
> From: Netconf [mailto:[e-mail]] On Behalf Of Martin
> Bjorklund
> Sent: 04 September 2018 16:34
> To: [e-mail]
> Cc: [e-mail]; rwilton=[e-mail]
> Subject: Re: [Netconf] Comments on draft-ietf-netconf-yang-push-18
>
> Andy Bierman <[e-mail]> wrote:
> > On Tue, Sep 4, 2018 at 8:22 AM, Robert Wilton <
> > rwilton=[e-mail]> wrote:
> >
> > > Hi Tim,
> > >
> > > Please see comments (as a non author) inline ...
> > >
> > > On 29/08/2018 16:28, Yutianpeng (Tim) wrote:
> > >
> > > Hi,
> > >
> > > Some comments as below:
> > >
> > >
> > >
> > > ------------------------------
> > >
> > > There is one point missing in the draft so far I think: what if the
> > > subscriber is the initiator of the configuration changes?
> > >
> > > In this case, the subscriber is aware of configuration changes
> > > initiated by itself without relying on the push mechanism.
> > > Introducing push mechanism will dramatically impact the performance of
> the system in this case.
> > >
> > > My suggestion is:
> > >
> > > 3.3.  On-Change Considerations
> > >
> > >    5.  If the resulting patch record is non-empty, and it contains
> > > the records not initiated by the subscriber, select these records
> > > and send to corresponding subscriber.
> > >
> > > We can have further discussion on this to make it optional instead
> > > of mandatory.
> > >
> > > I'm not keen on this change.  This does not seem like a good
> > > separation of concerns.  Besides, I'm not convinced why this should
> > > really be a performance issue given that config changes are
> > > relatively rare compared to all the operational state in the system
> that may be changing.
> > >
> > >
> > +1 -- this change should not be made.
> > This is not a useful optimization.
>
> +1
>
> <Tim>
> I might haven't explain the main concerns on this clearly.
> When I see Yang-push, I find it very useful as it really solves problems
> all NMS/controllers are facing. But I do have a concern on the point I
> mentioned.
> Let me give an example that Yang-Push can be used:
> Before Yang-push:
> NMS is using Netconf yang to manage a router
> NMS is using polling mechanism to sync config
> Anyone make changes not through NMS, e.g. CLI, NMS is not aware of the
> change in time.
>
> After Yang-push:
> NMS is using Netconf yang to manage a router
> NMS is using Yang-push mechanism to sync configuration. In order to make
> sure all database in sync state, <running> database is subscribed  --- I
> believe this could be a widely use case
> In case anyone make changes not through the NMS, changes will be notified
> to NMS via push mechanism.
> With yang push solution, it solves restriction of polling mechanism pretty
> well.
> But as I explained, yang push mechanism has an obvious drawback, each
> configuration from NMS will have a push message back to NMS, which is not
> needed in many use scenarios. This behavior actually impact performance a
> lot.
> If this msg can be filtered directly without going through all Netconf
> +SSH/TLS + TCP process, the performance of the subscriber will improve a
> lot I believe.
> Based on my understanding yang-push is to solve polling latency, but it
> should not have significant performance impact on existing applications. If
> NMS configure a device with 1000 changes and the device push 1000 changes
> back to NMS, I don't think this is an elegant implementation when Netconf
> has already provide enough transaction mechanism itself. The impact of push
> mechanism is it impact performance of 99% of scenario (normal NMS->device
> configure process) to solve 1% of use case (configuration not sync in
> time).
> I understand the difficulty of introducing big changes at this stage, but
> I really wish we can have an elegant push mechanism. Appreciate any
> comments on this.
> </Tim>
>
>

You are assuming the code that changed the configuration is also the code
that implements
the YP subscriber function, and there is some internal optimization to
update the data maintained
by the subscriber.

The standard imposes no such requirement -- the subscriber code can be
completely independent
of all other network management -- this goes for server-side as well.


Andy



> > >
> > >
> > > -----------------------------
> > >
> > > Both “subscriber” and “receiver” are used, bit confusing sometimes.
> > > Shall we only use “subscriber”
> > >
> > > They are different entities, the definitions are in
> > > draft-ietf-netconf-subscribed-notifications:
> > >
> > >    Receiver: A target to which a publisher pushes subscribed event
> > >    records.  For dynamic subscriptions, the receiver and subscriber are
> > >    the same entity.
> > >
> > >    Subscriber: A client able to request and negotiate a contract for
> the
> > >    generation and push of event records from a publisher.  For dynamic
> > >    subscriptions, the receiver and subscriber are the same entity.
> > >
> > >
> > >
> > >
> > >
> > > ------------------------
> > >
> > > 3.11.1.  Robustness and reliability
> > >
> > >    Note: It is perfectly acceptable to have a series of
> > > "push-change-
> > >
> > >    update" notifications (and even "push update" notifications)
> > > serially
> > >
> > >    queued at the transport layer awaiting transmission.  It is not
> > >
> > >    required to merge pending update records.  I.e., the dampening
> > > period
> > >
> > >    applies to update record creation, not transmission.
> > >
> > > My suggestion is:
> > >
> > > The publisher should increase dampening period automatically in case
> > > the message queue reaches a limit.
> > >
> > > This is to avoid notifications lost due to queue limit in case
> > > subscriber is busy or temporarily unreachable.
> > >
> > > I don't think that this is how the dampening that is currently
> > > defined should work, since it is expected to provide a strong
> > > guarantee that it will either deliver the notifications to the
> > > receiver, or otherwise notify to the receiver that some updates [may]
> have been lost.
> > >
> > > I could imagine that another, softer type of dampening, could
> > > potentially be defined in future as a separate
> > > extension/augmentation, but I don't think that should go into this
> > > document, because it would massively slow it down, and the industry
> already needs this standard now.
> > >
> > >
> > +1 -- the server does what it is told and does not decide to change
> > +the
> > subscription on its own
>
> +1
>
>
> /martin
>
> >
> >
> >
> > >
> > >
> > > -----------------------------
> > >
> > > It would be appreciated if suggestions can be given on how push
> > > shall be used on running, startup and candidate datastores
> > >
> > > It should work the same way as YANG push on any other datastore.
> > > The mechanism described in the draft seems to be entirely datastore
> agnostic.
> > > In what way do you think it may behave differently?
> > >
> > > Although I could imagine that implementations may not support
> > > subscriptions on startup or candidate, in which case I would expect
> > > that the subscription would be rejected.
> > >
> <Tim>
> Thanks Rob.
> I think you understand my concerns. The whole yang push mechanism is
> datastore agnostic.
> But my position is: if we follow this draft, I am pretty sure
> implementation of yang push later will be different across all vendors.
> Someone will accept subscription on startup but others will reject. Some
> will support pushing changes on candidate but others not.
> I believe the original intention of Netconf to provide a standardized
> mechanism and we are all working to scandalized as much as possible to
> allow different vendors to have interoperability with each other.
> If IETF working group can give instructions on how push mechanism can be
> adopted to different datastores instead of let vendors make decisions
> themselves, I believe we have a solution easier get interoperated.
> </Tim>
>
>
> > > Thanks,
> > > Rob
> > >
> > >
> > >
> >
> > Andy
> >
> >
> > >
> > >
> > > -------------------------------
> > >
> > >
> > >
> > > Regards,
> > >
> > > Tim
> > >
> > >
> > > _______________________________________________
> > > Netconf mailing
> > > [e-mail]://www.ietf.org/mailman/listinfo/netconf
> > >
> > >
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netconf
> > >
> > >
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>