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

From: Martin Bjorklund <[email-masked]>
Date: Tue, 30 Apr 2013 12:20:49 +0200 (CEST)

Hi David,

Thank you for your detailed review!  Comments inline.

David Harrington <[email-masked]> 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

---

From: Benoit Claise <[email-masked]>
Date: Tue, 30 Apr 2013 13:07:15 +0200

Martin,

It's interesting to note that Dave came up with similar feedback as I 
had during my AD review.
And you had to re-explain this again, via email. This leads me to think 
that we need some more background information, typically in "Operational 
Considerations" section.
http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-10#section-4 
could be part of that new section, but other topics could/should be 
addressed:
- Failure to sync the ifIndex
- is there a reason why "description" value MAY match IF-MIB ifAlias 
***and MAY restrict the values***?
-  what should an NM application or operator do if the YANG oper-status 
and the IF-MIB operStatus differ?
- persistence
- Is it expected that counters in ietf-interfaces and counters in IF-MIB 
are synchronized?
- etc...

Basically addressing many points made by Dave

Regards, Benoit
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
>

---

From: Benoit Claise <[email-masked]>
Date: Tue, 30 Apr 2013 13:25:46 +0200

On 30/04/2013 13:07, Benoit Claise wrote:
> And you had to re-explain this again, via email. This leads me to 
> think that we need some more background information, typically in 
> "Operational Considerations" section.
> -  what should an NM application or operator do if the YANG 
> oper-status and the IF-MIB operStatus differ?
> - persistence
> - Is it expected that counters in ietf-interfaces and counters in 
> IF-MIB are synchronized?
> - etc...
>
And I see that Carlos, part of the "Re: RtgDir review: 
draft-ietf-netmod-interfaces-cfg-10.txt" feedback has got some similar  
points.
- physical versus virtual interfaces
- location
- counter32 and counter64, and mapping to the MIB OIDs
- etc...

That reinforces in my thinking that we need an "operational 
considerations" section.

Regards, Benoit

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 30 Apr 2013 13:29:43 +0200 (CEST)

Hi,

I am pruning the Cc a bit so we can discuss this in the WG first.

> - Failure to sync the ifIndex

Apparently, the current text somehow seems to imply that there is a
synchronization problem.  But to be honest, I cannot see why.  This is
the current text:

      leaf if-index {
        config false;
        ...
        description    
          "The ifIndex value for the ifEntry represented by this
           interface.
           ...";
      }

So we have a config false leaf that is described as being the ifIndex
value of the ifEntry.   Please help me to improve this text so the
meaning is clear.

> - ***and MAY restrict the values***?

Ok, I suggest we add a paragraph like this:

  The configured "description" of an "interface" has traditionally
  been mapped to ifAlias in some implementations.  This document allow
  this mapping, but implementers should be aware of the differences in
  the value space for these objects.

> -  and the IF-MIB operStatus differ?

I need help also with this one.  I do not understand the problem, so I
cannot suggest a solution :(

> - persistence

I don't think this document is the right place to describe the
persistency model for SNMP vs. NETCONF - if we do it here we probably
have to do it in all other data-model specific documents as well...

> - are synchronized?

Again, I don't really see the problem, and I do not understand what it
means for counters to be synchronized.  Please suggest some text to
add.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 30 Apr 2013 13:41:47 +0200

> this is what many implementations do.  So we wanted to point out the

I think it is a dubious practice.

> "description", and in this case the "description" value cannot be used

If I correctly understand IF-MIB, a natural mapping would be

       +----------------------------------+------------------------+
       | YANG data node                   | IF-MIB object          |
       +----------------------------------+------------------------+
       | name                             | ifAlias                |
       | local-name                       | ifName                 |
       +----------------------------------+------------------------+

with "local-name" being a new config=false leaf. The "location" leaf then could be removed.
The lack of correspondence between "name" and "ifName" is somewhat confusing, so perhaps an alternative could be to follow suit of IF-MIB and use "alias" (== ifAlias) as the key of interface list, and "name" (== ifName) as the config=false local name. 

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 30 Apr 2013 14:33:29 +0000

On Apr 30, 2013, at 7:25 AM, Benoit Claise <[email-masked]> wrote:

>> It's interesting to note that Dave came up with similar feedback as I had during my AD review.
>> And you had to re-explain this again, via email. This leads me to think that we need some more background information, typically in "Operational Considerations" section.
>> http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-10#section-4 could be part of that new section, but other topics could/should be addressed:
>> - is there a reason why "description" value MAY match IF-MIB ifAlias ***and MAY restrict the values***?
>> -  what should an NM application or operator do if the YANG oper-status and the IF-MIB operStatus differ?
>> - persistence
>> - Is it expected that counters in ietf-interfaces and counters in IF-MIB are synchronized?
>> - etc...
>> 
> And I see that Carlos, part of the "Re: RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt" feedback has got some similar  points.
> That reinforces in my thinking that we need an "operational considerations" section.

+1.

I think that an "Operational Considerations" addressing these issues would be a most useful addition to this document.

For context, full review at http://www.ietf.org/mail-archive/web/netmod/current/msg08035.html

Thanks,

-- Carlos.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 30 Apr 2013 16:34:24 +0200

Hi Martin,
> synchronization problem.  But to be honest, I cannot see why.
The point is not that there is something wrong with your text.
The point is that you have 2 types of audience for this document.
1. the data model audience
2. the operators audience.

A typical question the audience 2. will ask themselves, while reading 
this draft, is: what about the relationship regarding the ifIndex (which 
I know about)?
And we could make this more obvious in a "operational considerations" 
section, if I understand David correctly.
For example (I trust you on the right text):

    The ifIndex value must match the YANG if-index leaf. So a change in
    the ifIndex allocation (RFC 2863 points out that an ifIndex must not
    be reused until after the following re-initialization of the network
    management system) implies a change in the YANG if-index leaf. The
    key in interface list is the "name", therefore an ifIndex change
    doesn't require a full table discovery (as it is the case with the
    ifTable)

> This is
Perfect text for this "operational considerations" section
> means for counters to be synchronized.  Please suggest some text to
I'm an operator. The simple question is: I can query the counters with 
SNMP or with NETCONF. Are these counters the same?

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Apr 2013 17:23:22 +0200

> means for counters to be synchronized.  Please suggest some text to

The counters typically exist has hardware registers on line cards or
as software counters in an OS kernel. The managment protocols read
those counters and export them - they do not maintain these counters
themself. As such, there is no synchronization issue.

That said, operators were somewhat fed up (they had clear words about
this) with counter accuracy at the NM IAB workshop because they
experienced that SNMP counters sometimes do not line up with CLI
counters. Part of the problem is that SNMP agents sometimes cache
values for performance optimizations or other weird reasons influence
the accuracy (e.g. row-by-row table retrieval can very easily screw
your data accuracy in SNMP land generally). As such, this is mostly an
implementation issue and an SNMP protocol, not a counter specification
issue. Will NETCONF implementations do better? We hope so.

In other words, I assume operators prefer that NETCONF counters are
'synchronized' with CLI counters much more than being 'synchronized'
with potentially screwed SNMP counters. I hope we do not end with
"SNMP had screwed counters" so lets be consistent with our standards
and mandate that NETCONF also reports the same screwed SNMP counters.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>