Subject: Re: [netmod] comment on ietf-interfaces module

From: Martin Bjorklund <[email-masked]>
Date: Wed, 01 Aug 2012 15:46:36 -0700 (PDT)

Hi,

It seems people want to add the config false "if stack" objects
proposed below:

Martin Bjorklund <[email-masked]> wrote:
>     leaf-list subordinate-if { ... }
>     leaf-list superior-if { ... }

If we add this, I suggest we also add a leaf if-oper-status, with
the same syntax and semantics as ifOperStatus, so that clients doesn't
have to rely on the MIB data for this rather important object.

/martin

---

From: Chris Elliott <[email-masked]>
Date: Wed, 1 Aug 2012 16:30:49 -0700

+1

On Wed, Aug 1, 2012 at 3:46 PM, Martin Bjorklund <[email-masked]> wrote:

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

-- 
Chris Elliott
[email-masked]

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Thu, 2 Aug 2012 11:52:16 +0000

Hi Martin,

If we take this step, which I am not opposed to, and following your reasoning, then why not go the full nine yards and come up with a YANG equivalent of the IF-MIB?

Patrick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Wednesday, August 01, 2012 6:47 PM
To: [email-masked]
Subject: Re: [netmod] comment on ietf-interfaces module

Hi,

It seems people want to add the config false "if stack" objects proposed below:

>     leaf-list superior-if { ... }

If we add this, I suggest we also add a leaf if-oper-status, with the same syntax and semantics as ifOperStatus, so that clients doesn't have to rely on the MIB data for this rather important object.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Aug 2012 07:56:46 -0700

> If we take this step, which I am not opposed to, and following your reasoning, then why not go the full nine yards and come up with a YANG equivalent of the IF-MIB?

Agreed.  This data is too important to rely on SNMP for some of it.
We made a custom YANG version of ifType just to add some
description-stmts.  This seems much more important than that.
Perhaps we have learned some things about interface management
since IF-MIB was published, and the direct SMIv2 to YANG translation
is not sufficient.  IMO, the scope should lean towards complete
management, not just configuration.

> Patrick

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Aug 2012 17:47:36 +0200

> management, not just configuration.

Is redefining all the counters really a high priority activity given
that there is already a way of retrieving them via NETCONF?

/js (speaking as contributor)

-- 
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/>

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Thu, 2 Aug 2012 15:48:32 +0000

We've been scratching our heads wondering about the YANG modules currently defined by I-Ds in the NETMOD WG:

- Why the bias toward configuration? I don't buy this argument that NETCONF is for configuration and SNMP for monitoring. If one of our customers or partners developers a management application with the capability to manage interfaces, why is it the expectation that use NETCONF for configuration and SNMP for monitoring? If this is not the expectation, then why define separate YANG modules. If I were to develop an API to manage interfaces supported by a device, I certainly wouldn't define one API for the purpose of configuring these interfaces and another API for the purpose of monitoring them.

- Why are we not building on the work done for SNMP-based management? If we are indeed building on it, then the definitions of the YANG modules don't necessarily reflect it.

- SMIv2-to-YANG conversion is insufficient for the simple reason that YANG provides a more robust meta-model for the purpose of describing "managed data". It would be akin to converting C code to Java without taking advantage of the object oriented capabilities supported by the language. Through the decades, the implementation of MIB modules have presented network equipment vendors with unique challenges which we have the opportunity to eliminate, but only if we take the time define YANG modules with consideration for the robustness of the meta-model, rather than simply emulating SNMP over NETCONF.

Patrick

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, August 02, 2012 10:57 AM
To: Patrick Gili (pgili)
Cc: Martin Bjorklund; [email-masked]
Subject: Re: [netmod] comment on ietf-interfaces module

Agreed.  This data is too important to rely on SNMP for some of it.
We made a custom YANG version of ifType just to add some description-stmts.  This seems much more important than that.
Perhaps we have learned some things about interface management since IF-MIB was published, and the direct SMIv2 to YANG translation is not sufficient.  IMO, the scope should lean towards complete management, not just configuration.

Andy

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Thu, 2 Aug 2012 15:50:07 +0000

Hi Juergen,

I'm not familiar with how one goes about retrieving interface counters via NETCONF without formally defining them in a YANG module. Could you please elaborate?

Patrick

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, August 02, 2012 11:48 AM
To: Andy Bierman
Cc: Patrick Gili (pgili); [email-masked]
Subject: Re: [netmod] comment on ietf-interfaces module

On Thu, Aug 02, 2012 at 07:56:46AM -0700, Andy Bierman wrote:
> Perhaps we have learned some things about interface management since 
> IF-MIB was published, and the direct SMIv2 to YANG translation is not 
> sufficient.  IMO, the scope should lean towards complete management, 
> not just configuration.
> 

Is redefining all the counters really a high priority activity given that there is already a way of retrieving them via NETCONF?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Aug 2012 18:04:03 +0200

Hi,

See RFC 6643 for the details. If you have smidump, run smidump -f yang
and there is the YANG module to use.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Aug 2012 18:09:05 +0200

On Thu, Aug 02, 2012 at 03:48:32PM +0000, Patrick Gili (pgili) wrote:

> - SMIv2-to-YANG conversion is insufficient for the simple reason
>   that YANG provides a more robust meta-model for the purpose of
>   describing "managed data". It would be akin to converting C code
>   to Java without taking advantage of the object oriented
>   capabilities supported by the language. Through the decades, the
>   implementation of MIB modules have presented network equipment
>   vendors with unique challenges which we have the opportunity to
>   eliminate, but only if we take the time define YANG modules with
>   consideration for the robustness of the meta-model, rather than
>   simply emulating SNMP over NETCONF.

I do not buy the comparison. For most of the counters, it does not
apply. In fact, even if we redefine them, we won't change their
semantics because the instrumentation is often embedded in hardware or
OS kernels and that stuff won't change.

There are things where redefinitions make sense, I doubt that counters
are typically good examples for this. Also note that you do not have
to go though SNMP implementation complexities to provide the data via
NETCONF.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Aug 2012 18:12:01 +0200

> and there is the YANG module to use.

Well, to be precise, you need a fairly recent version of smidump to
get the correct YANG module that is consistent with RFC 6643.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Aug 2012 09:29:58 -0700

+1

I do not understand why we are bothering making a new module
for something trivial like ifType because the SMIv2 to YANG translation
is not good enough, but for important things like the monitoring
data, the direct mapping is supposedly good enough.

The ifIndex is not even available if the IF-MIB is not also
supported in SNMP.  Retrieving 1 table to get ifIndex values
and then going to another table to retrieve counters based
on ifIndex is non-optimal.  Forcing SNMP implementation
of the IF-MIB in order to allow the server to expose interface counters
in NETCONF is unnecessary.  This new ietf-interfaces module
should be completely usable on its own, without any requirement
for the server to implement SNMP.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Aug 2012 18:33:23 +0200

> data, the direct mapping is supposedly good enough.

Lets recall, the interface type is needed for type specific interface
augmentations.

/js

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Thu, 2 Aug 2012 16:35:17 +0000

I have a lot of problems with this approach:

1) We are relying on vendors/partners/customers to perform this conversion, and while there is an RFC defining this translation, who is to guarantee that all implementations result in the same YANG module?

2) There is a lot of potential for overlap with YANG modules defined by standards bodies, such as the IETF and IEEE. Consider the example we're discussing in this thread. If I run the IF-MIB through a translator to generate a YANG module, then there is certainly a lot of overlap with ietf-interfaces YANG module. Worse, the keys are different.

3) When done, I still don't have a formal, standards document defining a YANG module describing interface counters.

Patrick

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, August 02, 2012 12:09 PM
To: Patrick Gili (pgili)
Cc: Andy Bierman; [email-masked]
Subject: Re: [netmod] comment on ietf-interfaces module

>   simply emulating SNMP over NETCONF.

I do not buy the comparison. For most of the counters, it does not apply. In fact, even if we redefine them, we won't change their semantics because the instrumentation is often embedded in hardware or OS kernels and that stuff won't change.

There are things where redefinitions make sense, I doubt that counters are typically good examples for this. Also note that you do not have to go though SNMP implementation complexities to provide the data via NETCONF.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Aug 2012 18:45:54 +0200

> 3) When done, I still don't have a formal, standards document defining a YANG module describing interface counters.

There is a standard for the input and a standard for the translation.
If needed, someone can perhaps post the translation result on a common
public place to help people. The value here is that you can start
today - no need to wait for yangification of > 100 IETF MIB modules
and the publication of corresponding RFCs. And if needed, one can even
write tools that automate the implementation by generating the code
hooking into existing SNMP instrumentation. Of course, this is
implementation specific.

/js

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Thu, 2 Aug 2012 16:56:05 +0000

Juergen,

I'm not arguing the value of having a SMIv2-to-YANG translator, so much as I'm questioning the approach we're taking to define YANG modules. As long as we're defining a YANG module for the purpose of describing the common management data relating to network interfaces, why not make the effort to do it right. In the meantime, someone waiting for the IEEE to crank out an Etherlike YANG module using smidump. However, when the IEEE does eventually define an Etherlike YANG module, I hope that use the robustness of YANG and properly augment the ietf-interfaces YANG module.

However, it still raises questions when namespaces aren't aligned. For example, interface-related MIB modules uniquely identifies interfaces using ifIndex, while the ietf-interfaces YANG module uniquely identifies interfaces using an interface's name.

An Andy raises an appropriate question regarding devices that implement the IF-MIB (or maybe they forego SNMP altogether). I notice a lot of discussion regarding "constrained devices". Personally, if I had to start making decisions based on memory footprint, SNMP would be at the top of my list of features to punt.

Patrick

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, August 02, 2012 12:46 PM
To: Patrick Gili (pgili)
Cc: Andy Bierman; [email-masked]
Subject: Re: [netmod] comment on ietf-interfaces module

There is a standard for the input and a standard for the translation.
If needed, someone can perhaps post the translation result on a common public place to help people. The value here is that you can start today - no need to wait for yangification of > 100 IETF MIB modules and the publication of corresponding RFCs. And if needed, one can even write tools that automate the implementation by generating the code hooking into existing SNMP instrumentation. Of course, this is implementation specific.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Aug 2012 10:03:17 -0700

> Lets recall, the interface type is needed for type specific interface

So you are making Patrick's point.
We could rely on the SMIv2 translation of IANAifType-MIB
and not publish the iana-if-type.yang module.

IMO, it is unacceptable to rely on the existence of IF-MIB
in order to retrieve interface counters.  I think this will
become more true over time, not less.  Assuming all
NETCONF servers are co-located with SNMP agents
is not a good idea for the long-term.

The IF-MIB translation does not put counters in the /interfaces/interface
list entry.  It is a completely different data structure, so it is not
good enough.

Andy

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Thu, 2 Aug 2012 17:07:18 +0000

There are already "constrained devices" on the market that have made the choice, and they have decided to go with NETCONF or REST interfaces over SNMP. Such devices would be at certain disadvantage if they had to rely on YANG modules that were merely a translation of MIB modules.

Patrick

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, August 02, 2012 1:03 PM
To: Juergen Schoenwaelder; Andy Bierman; Patrick Gili (pgili); [email-masked]
Subject: Re: [netmod] comment on ietf-interfaces module

On Thu, Aug 2, 2012 at 9:33 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>> I do not understand why we are bothering making a new module for 
>> something trivial like ifType because the SMIv2 to YANG translation 

So you are making Patrick's point.
We could rely on the SMIv2 translation of IANAifType-MIB and not publish the iana-if-type.yang module.

IMO, it is unacceptable to rely on the existence of IF-MIB in order to retrieve interface counters.  I think this will become more true over time, not less.  Assuming all NETCONF servers are co-located with SNMP agents is not a good idea for the long-term.

The IF-MIB translation does not put counters in the /interfaces/interface list entry.  It is a completely different data structure, so it is not good enough.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Aug 2012 19:14:35 +0200

> There are already "constrained devices" on the market that have made the choice, and they have decided to go with NETCONF or REST interfaces over SNMP. Such devices would be at certain disadvantage…

You can implement these YANG modules however you like. There is no
required dependency on SNMP. I am fine accepting your standpoint, but
I do not buy the implementation complexity arguments etc.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Aug 2012 10:24:45 -0700

> I do not buy the implementation complexity arguments etc.

But we are supposed to buy these arguments to justify NETCONF Light?
Vendors will end up ignoring what this module says and augmenting
the interface list entry with counters in their own namespace.
Protocol performance and efficiency have always been a concern
of vendors and pretending it is not an issue won't work.

Andy

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Thu, 2 Aug 2012 17:27:38 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Andy Bierman
> Sent: Thursday, August 02, 2012 1:25 PM
> To: Juergen Schoenwaelder; Patrick Gili (pgili); Andy Bierman;
> [email-masked]
> >> There are already "constrained devices" on the market that have made the
> choice, and they have decided to go with NETCONF or REST interfaces over
> SNMP. Such devices would be at certain disadvantage if they had to rely on
> YANG modules that were merely a translation of MIB modules.
> >

> Vendors will end up ignoring what this module says and augmenting the
> interface list entry with counters in their own namespace.

As a point of reference, this is exactly what I have done for the current system I am working on, as it does not have any SNMP support.

-Jeff

> Protocol performance and efficiency have always been a concern of vendors
> and pretending it is not an issue won't work.
> 
> >
> > /js
> 
> Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 03 Aug 2012 07:45:37 -0700 (PDT)

Andy Bierman <[email-masked]> wrote:
> in order to retrieve interface counters.

So which objects are we talking about?  For example, does it still
make sense to include both the 32-bit and 64-bit counters?  How do we
represent speed/highspeed?  Do we keep the ifCounterDiscontinuityTime,
defined in terms of sysUpTime?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 3 Aug 2012 08:08:35 -0700

> defined in terms of sysUpTime?

I would say just 64-bit counters and use a date-and-time object, not sysUpTime.

Andy

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Fri, 3 Aug 2012 15:09:51 +0000

Discontinuity time is still very important, independent of what we use for the epoch.

Patrick

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Friday, August 03, 2012 11:09 AM
To: Martin Bjorklund
Cc: [email-masked]; Patrick Gili (pgili); [email-masked]
Subject: Re: [netmod] comment on ietf-interfaces module

On Fri, Aug 3, 2012 at 7:45 AM, Martin Bjorklund <[email-masked]> wrote:
>> IMO, it is unacceptable to rely on the existence of IF-MIB in order 
>> to retrieve interface counters.
>

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 4 Aug 2012 10:21:24 -0700

> defined in terms of sysUpTime?

My 2 cents: 11 leafs:

   ifOperStatus
   ifLastChange
   ifHCInOctets
   ifHCInUcastPkts
   ifHCInMulticastPkts
   ifHCInBroadcastPkts
   ifHCOutOctets
   ifHCOutUcastPkts
   ifHCOutMulticastPkts
   ifHCOutBroadcastPkts
   ifCounterDiscontinuityTime

Change timeticks to date-and-time.

Andy

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Sat, 4 Aug 2012 17:30:10 +0000

Why not error and discard counters?

Patrick

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Saturday, August 04, 2012 1:21 PM
To: Martin Bjorklund
Cc: [email-masked]; Patrick Gili (pgili); [email-masked]
Subject: Re: [netmod] comment on ietf-interfaces module

My 2 cents: 11 leafs:

   ifOperStatus
   ifLastChange
   ifHCInOctets
   ifHCInUcastPkts
   ifHCInMulticastPkts
   ifHCInBroadcastPkts
   ifHCOutOctets
   ifHCOutUcastPkts
   ifHCOutMulticastPkts
   ifHCOutBroadcastPkts

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 4 Aug 2012 10:36:16 -0700

> Why not error and discard counters?

OK -- must have missed them because I skipped the 32 bit counters.
Change them to 64 bit, and of course change all the names to
something readable.

Andy

---

From: Carl Moberg <[email-masked]>
Date: Sun, 5 Aug 2012 00:04:02 +0200

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Aug 2012 11:00:40 +0200

On Tue, Jul 31, 2012 at 09:02:57AM -0700, Martin Bjorklund wrote:
> Hi,
> 
> "Patrick Gili (pgili)" <[email-masked]> wrote:
> > Also, it is convenient to traverse interface stacks bottom-up, rather than
> > top-down. This is the reason why RFC 2864 came about.
> 
> Does this mean that you suggest we add something like:
> 
>   list interface {
>     ...
>     leaf-list superior-if {
>       type interface-ref;
>       config false;
>     }
>   }        
> 
> or would you like to see both:
> 

The interfaces MIB calls these higher-layer and lower-layer
interfaces.  (It actually uses the terms "higher sub-layer" and "lower
sub-layer", probably because sometimes a single network protocol layer
may actually have a stack of interfaces.) Unless these terms are
broken, I would rather stick to them since this might reduce
confusion.

/js

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Mon, 6 Aug 2012 10:04:25 +0000

Hi Juergen,

I think these names are broken. If you read section 3.1.1 of RFC 2863, you'll find the formal definitions of superior and subordinate interfaces.

Patrick

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, August 06, 2012 5:01 AM
To: Martin Bjorklund
Cc: Patrick Gili (pgili); [email-masked]
Subject: Re: [netmod] comment on ietf-interfaces module

On Tue, Jul 31, 2012 at 09:02:57AM -0700, Martin Bjorklund wrote:
> > Also, it is convenient to traverse interface stacks bottom-up, 
> > rather than top-down. This is the reason why RFC 2864 came about.
> 

The interfaces MIB calls these higher-layer and lower-layer interfaces.  (It actually uses the terms "higher sub-layer" and "lower sub-layer", probably because sometimes a single network protocol layer may actually have a stack of interfaces.) Unless these terms are broken, I would rather stick to them since this might reduce confusion.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Aug 2012 12:37:03 +0200

> I think these names are broken. If you read section 3.1.1 of RFC 2863, you'll find the formal definitions of superior and subordinate interfaces.

Formal definitions? I find these words only in quotes. Not sure what
that suggests. I am worried if we name things differently in YANG
models and SMIv2 models.

/js

---

From: t.petch <[email-masked]>
Date: Tue, 7 Aug 2012 10:27:37 +0100

---- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, August 04, 2012 6:21 PM
> Change timeticks to date-and-time.

The logic of timeticks was that every box had a timer that popped every
few mS or more often, but not all boxes, perhaps not many boxes, had a
date-and-time facility (something I am reminded of every power cut when
I have to reinput day of week to my answerphone which can do very clever
things but never knows what date it is).
I do not know how current hubs, switches etc stack up on this.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Tue, 7 Aug 2012 10:33:50 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Patrick Gili (pgili)" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 06, 2012 11:37 AM
> > I think these names are broken. If you read section 3.1.1 of RFC
2863, you'll find the formal definitions of superior and subordinate
interfaces.
> that suggests. I am worried if we name things differently in YANG

I agree.  Where the names have been long established and the semantics
are the same, then we should resist the temptation to 'improve' the
names; of course we can, but we do our users a disservice by doing so.

Tom Petch