Thanks for the comments Benoit. Some thoughts in-line…
From: i2rs, March 19, 2015 9:54 AM
Dear all,
- Arguably the biggest shortcoming
of SNMP for those applications concerns the need to rely on periodic
polling, because it introduces additional load on the network and
devices, is brittle in case polling cycles are missed, and is hard to
synchronize and calibrate across a network, making data obtained from
multiple devices less comparable.
The DISMAN WG produced in the past the RFC 2981 and RFC 2982 to avoid the
polling issue,
but the event and expression MIBs never took off. These were hard to configure
<Eric> Configuration ease will be something we need to continually keep in
mind. Pub/Sub is one technology where we can make too many knobs.
-
A Subscription Request for one or more YANG subtrees made by the
Subscriber of a Publisher and targeted to a Receiver. A Subscription
MAY include constraints which dictates how often or under what
conditions YANG subtree updates might be sent.
...
An Update provides object changes which have occurred within
subscribed YANG subtree(s).
Is this always a subtree? Could it a single leaf?
<Eric> Yes, it can be a leaf.
- You should have requirements in the terminology section, specifically as you
have a requirement section.
<Eric> will fix next version.
A Subscription Request for one or more YANG subtrees made by the
Subscriber of a Publisher and targeted to a Receiver. A Subscription
MAY include constraints which dictates how often or under what
conditions YANG subtree updates might be sent.
- On the use of MUST, SHOULD, etc. keywords in requirements document, it's
preferable to use lower case because these are not RFC 2119 keywords.
The alternative is to stress the specific meaning of those keywords in this
document.
<Eric> will stop shouting in upper case in the next version.
-
A Subscriber MAY provide QoS criteria to the Subscription Service
such that if the Subscription Service is unable to meet those
criteria, the Subscription should not be established.
A Subscription Service SHOULD be able to interpret Subscription
Requests QoS Policy requests, and only establish a Subscription if it
is possible to meet the QoS those QoS Policy requests.
At first glance, I thought you wanted to have a one-way delay type of end to
end QoS metric
(between the subscriber and publisher). This is complex.
Then I saw:
A Subscription Service SHOULD be able to negotiate QoS criteria for a
Subscription. Examples of QoS criteria MAY include reliability of
the Subscription Service, reaction time between a monitored YANG
subtree/object change and a corresponding notification push, and the
Subscription Service's ability to support certain levels of object
liveliness.
You want to be precise with the QoS definition scope in this document.
It's only when I read section 4.2.6 that I understood your QoS definition.
In the end, I believe a forward pointer is all that is needd
<Eric> I will put a reference to the specific definition of QoS when QoS is
first mentioned in the document.
- What about the notion of time in pub/sub?
One typical problem with SNMP polling is polling different variables at the
same time (interface counter, QoS counter, for example).
This is solved in SNMP by combining those OID in a single PDU. How is it done
with pub/sub? Actually, the right question is: what is the requirement?
<Eric> We have a start time and a period associated with a subscription upon
certain objects. From there the ending period timestamp for info collection
should be established. It is possible that other objects might also be
subscribed on the same device, and might have the same ending period timestamp.
There are no requirements in the document right now which talk about how
multiple subscription updates might be bundled. We could certainly add
requirements/mechanisms for this bundling if there is need.
-
If on-change updates were
requested with a dampening period, the minimum acceptable dampening
period SHOULD be included,
What if the dampening period is different per subscriber?
Aren't we adding extra states to the device?
<Eric> How many extra states is up to the implementation within the device. As
the dampening period is negotiable, the network element does not have to accept
the subscription terms initially requested by a subscriber. Therefore it can
refuse subscriptions with unsupportable minimum acceptable dampening periods.
A best practice might be that a network element only offer the same dampening
period for all subscribers of an object.
-
A Subscription Service SHOULD support different transports.
A Subscription Service SHOULD support different encodings of payload.
Don't you want to start with a single one, for interoperability reasons? At
least for the encoding?
For the transport, I could agree with the reliability aspects in section 4.2.6.3
<Eric> Agree.
One of the things about this document is that it is supposed to include YANG
Pub/Sub requirements from various sources. Building a requirements document
which doesn’t have the minimal requirements for a first specific implementation
exposes options which are not desired for the first implementations.
/Eric
Regards, Benoit
A few editorial comments below.
- capitalize NETCONF, RESTCONF
- OLD:
These refinements include: periodicity of object updates, filtering
out of objects underneath a requested a subtree, and delivery QoS
guarantee
NEW:
These refinements include: periodicity of object updates, filtering
out of objects underneath a requested subtree, and delivery QoS
guarantee
-
YANG has gained acceptance as the data definition language of choice
for control and management related information.
=> as the data modeling language of choice
- what is OMG/DDS in:
With the support of standards bodies such as OMG (DDS),
XMPP.org standard
Please a reference
-
"However RFC5277<http://tools.ietf.org/html/rfc5277>
does not follow the Pub/Sub paradigm, does not allow the explicit
deletion of subscriptions, and predates YANG."
You might want to expand on "predates YANG", expressing that RFC 5277 doesn't
allow the monitoring of YANG objects
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
