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

Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Sep 4, 2018 at 8:22 AM, Robert Wilton <
> rwilton=40cisco.com@dmarc.ietf.org> 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

> >
> >
> > -----------------------------
> >
> > 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.
> >
> > Thanks,
> > Rob
> >
> >
> >
> 
> Andy
> 
> 
> >
> >
> > -------------------------------
> >
> >
> >
> > Regards,
> >
> > Tim
> >
> >
> > _______________________________________________
> > Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
> >
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >
> >