ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-netmod-interfaces-cfg-10.txt> (A YANG DataModel for Interface Management) to Proposed Standard

2013-04-23 06:25:53
David

A thoughtful assessment, and what it brings out for me is that we do not
have an Information Model:-(  That is, we could have reverse engineered
an Information Model from the IF-MIB and then produced a data model in
YANG, but that did not happen.  Rather, there is a new and different
(implicit) Information Model underlying the data model in YANG, as
opposed to the one for the IF-MIB, and that has surfaced a number of
times on the netmod list, not just for this module but equally for the
routing, system and ip modules.  The differences are not great, but they
are there.

So the question is, should we have the same Information Model in YANG as
in MIBs, or do we let them diverge?  and if they diverge, then do we
need to record that in some standard way?  I don't know, but think that
it needs discussing.  It may not be a big issue in the IETF but I am
sure that it will be for those who operate networks!

Tom Petch

----- Original Message -----
From: "David Harrington" <ietfdbh(_at_)comcast(_dot_)net>
To: "IETF Discussion List" <ietf(_at_)ietf(_dot_)org>
Sent: Monday, April 22, 2013 9:21 PM

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.
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).
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.

2) ifType - can an interface be hot-swapped to use a different type?
Is
this discussed someplace?

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?

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?

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?

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?
Is there a simple way for an operator to tell whether the
implementation
supports the restrictions (other than deliberately triggering an
error)?

7) what should an NM application or operator do if the YANG
oper-status
and the IF-MIB operStatus differ?
IF-MIB has substantial discussion of the relationship between
ifAdminStatus and ifOperStatus. The YANG module doesn't have a
comparable
discussion.
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"?

9) persistence isn't discussed in the config object descriptions. Do
they
match the IF-MIB object persistences?

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?
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)

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?
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. 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?

13) Some of the questions about counters might be covered in
yang-types;
it would help if the imports clause indicated the relevant RFCs.

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.

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.

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.

Hope this helps,
--
David Harrington
Ietfdbh(_at_)comcast(_dot_)net
+1-603-828-1401





On 4/19/13 9:25 AM, "The IESG" <noreply(_at_)ietf(_dot_)org> wrote:


The IESG has received a request from the NETCONF Data Modeling
Language
WG (netmod) to consider the following document:
- 'A YANG Data Model for Interface Management'
 <draft-ietf-netmod-interfaces-cfg-10.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to
the
ietf(_at_)ietf(_dot_)org mailing lists by 2013-05-03. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines a YANG data model for the management of
network
  interfaces.  It is expected that interface type specific data
models
  augment the generic interfaces data model defined in this
document.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/

IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/ballot
/


No IPR declarations have been submitted directly on this I-D.







<Prev in Thread] Current Thread [Next in Thread>