Hi David,
Thank you for your detailed review! Comments inline.
David Harrington <ietfdbh@xxxxxxxxxxx> wrote:
Hi,
I have reviewed this document and feel that is almost ready for approval.
This document defines a new data model in YANG format, based on the same
information model as the Interfaces MIB module (IF-MIB).
Effectively, the YANG model is a second (duplicative) standard for much of
the same information.
It is expected that devices may implement both the MIB and the YANG data
models.
My primary concern regards co-existence and synchronization across data
models.
I think this document would benefit from an Operational Considerations
section that discusses synchronization, or an explanation why they might
reasonably be out-of-sync.
Here are a few points to consider:
1) the ifIndex of an interface is used within the YANG model, matching the
ifIndex in IF-MIB.
RFC2863 discusses the fact that ifIndex numbering might change during
hot-swaps.
Actually, RFC 2863 points out that a ifIndex must not be reused until
after the following re-initialization of the network management
system.
This document does not discuss the need to ensure that IF-MIB ifIndex
changes need to be reflected in the YANG model.
The ifIndex in the YANG module must match that in IF-MIB (really, that in
the underlying instrumentation).
Absolutely! That's the intention. The description for the read-only
leaf if-index says:
The ifIndex value for the ifEntry represented by this
interface.
Failure to sync the ifIndex could lead NM applications to confuse which
already-retrieved data records are related to which interface.
This could cause an NM application to misinterpret/corrupt gathered
trending information, and possibly to apply changes to the wrong
interfaces.
Fully agree - this is why the if-index is present; to facilitate the
mapping between the models.
2) ifType - can an interface be hot-swapped to use a different type? Is
this discussed someplace?
Hot-swapping sounds like a physical property. The data model in this
document can handle this -- provided the system physically supports
it, of course. Note that the type is a writable leaf just like
others. You can change it, but as with any other leaf a device that
cannot support a particular change will reject it.
3) ifType - the description says the value of this mandatory object MAY be
initialized. What value should an NM application expect if it is NOT
initialized?
None. And since it is mandatory, in this case the NM application has
to explicitly provide the type. If you write a completely generic NM
application you would probably always provide the type, since you
cannot count on the server auto-initializing it. But if you *know*
that the server auto-initialize the type, you don't have to provide
it.
4) enabled - "Systems that implement the IF-MIB use the value of this leaf
to set IF-MIB.ifAdminStatus ..."; should this be a MAY/SHOULD/MUST? How
will this coexist with SNMP-based NM applications? Is there potential for
conflict? What if NETCONF sets this as enabled, then an operator sets it
to disabled via SNMP?
Does NETCONF know that its "enable" value (adminStatus) is out of date?
(does it matter? See note 7).
What if the NETCONF system directky changes the underlying instrumentation
for adminstatus without going through the MIB?
It is not clear to me if we can / want to require that these objects
share the same instrumentation.
Some of this might be b/c ifAdminStatus is a a bit unclear in some
regards. For example, it talks about how
per configuration information
retained by the managed system, ifAdminStatus is then
changed [...]
I would assume (but this might be incorrect) that the "configuration
information" could be things configured through the CLI for example,
and this "configuration information" could thus also be the data
defined in this YANG model.
So it seems RFC 2863 makes a distinction between ifAdminStatus and
what is actually configured.
Also, the description of ifAdminStatus doesn't say anything about
persistence, so it might be impossible to map this to the persistently
stored configuration.
5) is there a reason why "description" value MAY match IF-MIB ifAlias
***and MAY restrict the values***?
Is there a particular use case for this lack of standardization of
restrictions across data models?
The persistence is a pretty important restriction related to the
functionality of ifAlias, and the dynamism of ifIndex.
If NETCONF is used to set the value, ignoring IF-MIB restrictions, what
happens to IF-MIB ifAlias as a persistent "handle" to the interface?
The only reason the "description" leaf is mapped to ifAlias is b/c
this is what many implementations do. So we wanted to point out the
differences in the value space for these objects so that implementers
are aware of this.
And of course it is not possible to actually set *ifAlias* and ignore
its syntax constraints. However, you can use non 7-bit ascii in
"description", and in this case the "description" value cannot be used
unmodified as ifAlias.
6) What error is returned via NETCONF if YANG attempts to set a value that
violates the SNMP agent implementation restrictions, and the SNMP agent
refuses the requested SET operation to ifAlias?
The draft says:
If a NETCONF server that implements this restriction is
sent a value that doesn't match the restriction, it MUST
reply with an rpc-error with the error-tag
'invalid-value'.
Is there a simple way for an operator to tell whether the implementation
supports the restrictions (other than deliberately triggering an error)?
No.
7) what should an NM application or operator do if the YANG oper-status
and the IF-MIB operStatus differ?
The intention is that they share the same instrumentation.
IF-MIB has substantial discussion of the relationship between
ifAdminStatus and ifOperStatus. The YANG module doesn't have a comparable
discussion.
Which text in the MIB do you mean? There is some text in the
description of "oper-status".
Given that there could e additional delay incurred between setting enable,
updating ifAdminStatus, the change to ifOperStatus, and the update to
oper-status, I recommend some mention in the description of enable and/or
oper-status of the detailed description in RFC2863, and applicability to
ietf-interfaces.
8) link-up-down-trap-enable: The text says this "indicates" whether traps
should be generated for the interface; shouldn't this be "configures"?
Or maybe "Controls ..."?
9) persistence isn't discussed in the config object descriptions. Do they
match the IF-MIB object persistences?
Persistence in NETCONF is different from SNMP, in general. In NETCONF,
the persistence is defined by the data store where you write the data.
10) IF-MIB counters do not typically start at zero; a delta must be
calculated. This is a common misunderstanding for new MIB developers and
users.
I don't see any comparable discussion related to ietf-interfaces counters.
Where should one look for a discussion of YANG counter initialization
values?
Where should one look for a discussion of YANG counter rollover?
The couters are defined as yang:counter32 and yang:counter64. The
"yang" prefix means module "ietf-yang-types". This module is defined
in RFC 6021. This RFC discusses initial values and discontinuities.
(ok, this was also suggested by yourself further below!)
It would help to have a discussion of how to utilize discontinuity_time
and counters, especially for implementers not familiar with SNMP (and not
implementing IF-MIB).
11) Is it expected that counters in ietf-interfaces and counters in IF-MIB
are synchronized? Can an NM application reasonably compare two readings -
one of in-octets and one of ifHCInOctets? If not, I think that should be
made clear. (The reference clauses seem to link them)
I think the intention is that the instrumentation is shared. There is
most probably a single hw register / kernel counter for these objects,
and this is what will be used for these counters.
12) From IF-MIB: "Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at other times as
indicated by the value of ifCounterDiscontinuityTime."
From ietf-interfaces: "Discontinuities in the value of this counter can
occur at re-initialization of the management system, and at other times as
indicated by the value of 'discontinuity-time'."
I think it is ambiguous as to whether both sets of text refer to the same
"management system". Is the IF-MIB management-system the SNMP agent? And
the YANG management-system the YANG server? Or are both based on the
underlying (e.g, hardware or native) management system?
Good question! The term is not defined anywhere (as far as I know),
and thus there is some liberty in the interpretation of it. But I
don't think it matters. It seems unlikely that a
NM application sometimes reads a counter over SNMP and sometimes the
same counter from the same device over NETCONF and then compare the
values.
Are ifCounterDiscontinuityTime and discontinuity-time synchronized or
independent? If they are independent, then the YANG counters and MIB
counters could contain very different values; it might help operators to
have this pointed out.
See above. There is no requirement that they MUST be synchronized,
but they surely can be.
It might help implementers to know whether to try
to synchronize them or not.
Can an operator force restart of both YANG and MIB systems to force
synchronization of counters?
No. Is there a way to force a restart of the "MIB system"?
13) Some of the questions about counters might be covered in yang-types;
it would help if the imports clause indicated the relevant RFCs.
As a comment? I will raise this issue in the WG.
14) IF-MIB has both 32-bit and 64-bit counters; YANG only duplicates the
64-bit counters, generally. It might be good to discuss this in an
Operations Considerations section, to explain some potential anomalies at
the NM application side.
In practice I don't think this is a problem. It seems unlikely that a
NM application sometimes reads a counter over SNMP and sometimes the
same counter from the same device over NETCONF and then compare the
values.
15) ietf-interfaces can modify the SNMP trap-enable settings; enabling
lots of traps could impact denial of service, disabling could hide
interface changes made by an attacker; it should probably be mentioned in
security considerations.
I was thinking we could simply reference the Security Considerations
section in RFC 2863 for this, but it doesn't discuss this.
16) Many operators/developers may have experience with IF-MIB, and some
applications might be rewritten to utilize ietf-interfaces rather than (or
to supplement) IF-MIB. Not all IF-MIB objects are reflected in
ietf-interfaces; it might be helpful to show which IF-MIB objects are not
mapped to ietf-interfaces, and discuss why, and whether comparable info
can be derived using other YANG approaches.
17) The copyright in the module description clause needs updating.
Ok.
/martin
_______________________________________________
netmod mailing list
netmod@xxxxxxxx
https://www.ietf.org/mailman/listinfo/netmod