Subject: [netmod] comment on ietf-interfaces module

From: Andy Bierman <[email-masked]>
Date: Mon, 30 Jul 2012 13:59:39 -0700

Hi,

I re-read this draft and I do not understand why there is no generic
equivalent to the ifStackTable.  There is no way to describe that
1 interface is layering above or below another interface.
There is an example in Appendix B for ethernet bonding.

I understand that different interface types may want to augment
the interface entry with specific fields.  This is not an adequate
replacement for a data structure that describes the general interface layering.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 30 Jul 2012 23:14:14 +0200

> replacement for a data structure that describes the general interface layering.

The document focuses on configuration. It seems the way to configure
bondings etc. is technology specific. Are you asking for addition of
operational state (config false) objects to report the layering?  Or
are you asking for a generic mechanism to configure interface
layering?

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 30 Jul 2012 14:23:14 -0700

I think there is value in knowing that 1 interface is conceptually
layered on top of another 1.  Focusing on configuration
is near-sighted if actual operational deployment requires
that some basic information be retrievable in order to
properly modify a device configuration.

If you are arguing that the ifStackTable has no value and
therefore there is no reason to use something like it in NETCONF, that
is one thing, but config=true vs. config=false is an artificial
distinction.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 30 Jul 2012 14:03:37 -0700 (PDT)

> replacement for a data structure that describes the general interface

Do you mean a config false data structure, in order to view the
layering?  This goes back to the question how much non-config stuff do
we put in this module, when it is available in IF-MIB.

/martin

---

From: Chris Elliott <[email-masked]>
Date: Mon, 30 Jul 2012 14:23:41 -0700

> are you asking for a generic mechanism to configure interface

Without knowledge of layering, it will be rather difficult to correctly
configure interfaces, so I question the usefulness of a model that
basically requires you to use another channel (SNMP, screen scraping) to
gather the information you need to use the model.

Chris.

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

-- 
Chris Elliott
[email-masked]

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Mon, 30 Jul 2012 21:32:20 +0000

If you're going to use that argument, then why do we allow the creation/destruction of interfaces through this model? The IF-MIB doesn't allow the creation/destruction of interfaces, as the authors of that MIB thought the process of creating and destroying interfaces was technology-specific.

Patrick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Monday, July 30, 2012 5:14 PM
To: Andy Bierman
Cc: [email-masked]
Subject: Re: [netmod] comment on ietf-interfaces module

On Mon, Jul 30, 2012 at 01:59:39PM -0700, Andy Bierman wrote:
> I understand that different interface types may want to augment the 
> interface entry with specific fields.  This is not an adequate 

The document focuses on configuration. It seems the way to configure bondings etc. is technology specific. Are you asking for addition of operational state (config false) objects to report the layering?  Or are you asking for a generic mechanism to configure interface layering?

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 30 Jul 2012 14:38:01 -0700

I was asking for config=false objects.
I think configuration of layering will probably require
augmenting the interface entry with some interface type specific fields.

E.g., if I enable an interface that is layered on top
of a disabled interface, then it would be useful to know
that when wondering why enabling the interface didn't
seem to do anything wrt/ device behavior.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 30 Jul 2012 23:43:11 +0200

> is one thing, but config=true vs. config=false is an artificial

I really wonder how you read "ifStackTable has no value" out of my
message. Anyway, I conclude that your answer to my two questions is
this:

Are you asking for addition of operational state (config false)
objects to report the layering? No.

Or are you asking for a generic mechanism to configure interface
layering? yes

I will ignore the rest.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 30 Jul 2012 14:44:58 -0700 (PDT)

> gather the information you need to use the model.

I don't think anyone suggested you'd have to use SNMP.  One option is
to apply RFC 6643 and read the data over NETCONF.  I agree that this
is not optimal, but the alternative of copy&paste all counters etc
from the MIBs into new YANG modules does not seem very attractive
either.  Maybe it has to be done on a case-by-case basis - and maybe
this is one such case.

/martin

---

From: Chris Elliott <[email-masked]>
Date: Mon, 30 Jul 2012 14:53:31 -0700

> either.  Maybe it has to be done on a case-by-case basis - and maybe

It seems to me, with my limited experience with YANG, that it can do a much
better job of modeling interface layering than ifStackMIB, and that using
6643 for this instance will not end well.

That said, I haven't tried Juergen's tool for applying such a conversion to
said MIB yet...I'll give it a shot.

Chris.

-- 
Chris Elliott
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Mon, 30 Jul 2012 15:03:18 -0700

You got it backwards.
I think the monitoring info provided by interface layering is useful.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 Jul 2012 00:06:46 +0200

I give up.

/js

---

From: Chris Elliott <[email-masked]>
Date: Mon, 30 Jul 2012 16:53:41 -0700

On Mon, Jul 30, 2012 at 2:53 PM, Chris Elliott <[email-masked]> wrote:

> It seems to me, with my limited experience with YANG, that it can do a
> much better job of modeling interface layering than ifStackMIB, and that
> using 6643 for this instance will not end well.
>
> That said, I haven't tried Juergen's tool for applying such a conversion
> to said MIB yet...I'll give it a shot.
>

Juergen's tool's interpretation of the ifStackTable ends up with a module
that is not compatible with this YANG interface module:
...
  typedef InterfaceIndexOrZero {
    type int32 {
...
    list ifStackEntry {
      key "ifStackHigherLayer ifStackLowerLayer";
...
      leaf ifStackHigherLayer {
        type if-mib:InterfaceIndexOrZero;
...

vs. this YANG interfaces module:
...
  list interface {
         key "name";
         unique "type location";
...
    leaf if-index {
           if-feature snmp-if-mib;
           type int32 {
...

It seems to me that, if we want to represent stacking that's compatible
with the draft YANG interfaces module, then we should not use the ifIndex,
whatever it's called, to represent stacking, if it's to be useful. It seems
to me that the only things needed are to add is one new leaf, "slave-if",
to use the name from Appendix B of this YANG module. That seems much easier
to use than how it's done in SMI. Then, Appendix B could be modified to
show how "slave-if" could be constrained for Ethernet LAG interfaces
(ieee8023adLag),
for example.

I also think that these objects must be configurable. This YANG module
allows one to create interfaces, unless I don't understand the purpose of
this YANG module, which makes sense for virtual interfaces, for example,
that are often layered on other interfaces. Interface Eth0.1 can't be
successfully created without configuring that it's a sub-interface of Eth0.
I also think that layering of interfaces is this simple, and this model can
represent all cases of layering and we should not implement layering in the
interface type-specific modules.

This capability could be used to move a virtual interface  to another
physical interface, for example, instead of deleting and recreating the
interface or whole stack of interfaces. This seems to me to be a free and
rather interesting additional capability that could be useful in many
instances, and Appendix B shows an excellent example of the need for
this--binding multiple physical interfaces into one LAG.

Chris.

-- 
Chris Elliott
[email-masked]

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Tue, 31 Jul 2012 10:33:12 +0000

Hi Chris,

I like your idea, but have two nits:

-          Can we not invent new terminology? For decades we have used the terms "subordinate" and "superior", rather "slave" and "master".

-          This "slave-if" would need to be a leaf-list, as there exists the potential for an interface to sit atop more than one interface, such as the Ethernet LAG example or other forms of interface bonding.

Also, it is convenient to traverse interface stacks bottom-up, rather than top-down. This is the reason why RFC 2864 came about.

Patrick

From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Elliott
Sent: Monday, July 30, 2012 7:54 PM
To: Martin Bjorklund
Cc: [email-masked]
Subject: Re: [netmod] comment on ietf-interfaces module

On Mon, Jul 30, 2012 at 2:53 PM, Chris Elliott <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Jul 30, 2012 at 2:44 PM, Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:

It seems to me, with my limited experience with YANG, that it can do a much better job of modeling interface layering than ifStackMIB, and that using 6643 for this instance will not end well.

That said, I haven't tried Juergen's tool for applying such a conversion to said MIB yet...I'll give it a shot.

Juergen's tool's interpretation of the ifStackTable ends up with a module that is not compatible with this YANG interface module:
...

It seems to me that, if we want to represent stacking that's compatible with the draft YANG interfaces module, then we should not use the ifIndex, whatever it's called, to represent stacking, if it's to be useful. It seems to me that the only things needed are to add is one new leaf, "slave-if", to use the name from Appendix B of this YANG module. That seems much easier to use than how it's done in SMI. Then, Appendix B could be modified to show how "slave-if" could be constrained for Ethernet LAG interfaces (ieee8023adLag), for example.

I also think that these objects must be configurable. This YANG module allows one to create interfaces, unless I don't understand the purpose of this YANG module, which makes sense for virtual interfaces, for example, that are often layered on other interfaces. Interface Eth0.1 can't be successfully created without configuring that it's a sub-interface of Eth0. I also think that layering of interfaces is this simple, and this model can represent all cases of layering and we should not implement layering in the interface type-specific modules.

This capability could be used to move a virtual interface  to another physical interface, for example, instead of deleting and recreating the interface or whole stack of interfaces. This seems to me to be a free and rather interesting additional capability that could be useful in many instances, and Appendix B shows an excellent example of the need for this--binding multiple physical interfaces into one LAG.

Chris.

Chris.

/martin

--
Chris Elliott
[email-masked]<mailto:[email-masked]>

--
Chris Elliott
[email-masked]<mailto:[email-masked]>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 31 Jul 2012 08:56:41 -0700 (PDT)

Hi,

Chris Elliott <[email-masked]> wrote:

> whatever it's called, to represent stacking, if it's to be useful.

Ok.

It should be noted that the stacking information *is* available with
the current model; but not generically.  A generic stack table has the
advantage that a client can see the interface stack hierarchy without
understanding type-specific data models.  This *might* not be as
important with YANG as it was in SMIv2, since the augemented data is
provided "inline" - if you <get> the /interfaces list you will get the
generic stuff and the augmented type-specific stuff, which includes
the layering information.

> It seems
> I also think that these objects must be configurable.

Absolutely.  This is one of the requirements listed in section 2.

But note that a single leaf is not enough, since we need to support
1-over-N interfaces.  So it would have to be a leaf-list.  But in some
cases you might need more than just a set of interfaces; you might
need to specify additional information per interface.  As a simple
example you might need to assign a priority or a tag to each
underlying interface.  In order for the generic model to be
prepared for this, we cannot use a simple leaf-list; we'd have to use
a list (that can be augmented by type-specific modules).  And note
that if we do this generically, this list will be available for *all*
interface types, including interfaces that cannot be layered on top of
some other interfaces.  Of course, if you try to configure such an
invalid layering, you will get an error back.  But this constraint is
not captured in the data model.

So this is why I prefer to have type-specific layering configuration.
It makes the data model more "direct" and less confusing, and it
allows you to tailor the layering config for each type.

/martin

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Tue, 31 Jul 2012 16:02:45 +0000

Martin,

I don't agree with your statement below. It isn't always possible to determine the interface layering strictly from the type of an interface. For example, a PPP interface can sit atop any variety of interfaces, including DSL, cable, IP, L2TP, POS, DS3, etc, etc, etc. Interface stacking data is not only important for configuring bonded/aggregated interfaces, but also diagnosing any variety of problems.

Patrick Gili

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Tuesday, July 31, 2012 11:57 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netmod] comment on ietf-interfaces module

Hi,

Chris Elliott <[email-masked]> wrote:

> It seems to me that, if we want to represent stacking that's 
> compatible with the draft YANG interfaces module, then we should not 
> use the ifIndex, whatever it's called, to represent stacking, if it's to be useful.

Ok.

It should be noted that the stacking information *is* available with the current model; but not generically.  A generic stack table has the advantage that a client can see the interface stack hierarchy without understanding type-specific data models.  This *might* not be as important with YANG as it was in SMIv2, since the augemented data is provided "inline" - if you <get> the /interfaces list you will get the generic stuff and the augmented type-specific stuff, which includes the layering information.

> It seems
> to me that the only things needed are to add is one new leaf, 
> "slave-if", to use the name from Appendix B of this YANG module. That 
> seems much easier to use than how it's done in SMI. Then, Appendix B 
> could be modified to show how "slave-if" could be constrained for 
> Ethernet LAG interfaces (ieee8023adLag), for example.
> 

But note that a single leaf is not enough, since we need to support 1-over-N interfaces.  So it would have to be a leaf-list.  But in some cases you might need more than just a set of interfaces; you might need to specify additional information per interface.  As a simple example you might need to assign a priority or a tag to each underlying interface.  In order for the generic model to be prepared for this, we cannot use a simple leaf-list; we'd have to use a list (that can be augmented by type-specific modules).  And note that if we do this generically, this list will be available for *all* interface types, including interfaces that cannot be layered on top of some other interfaces.  Of course, if you try to configure such an invalid layering, you will get an error back.  But this constraint is not captured in the data model.

So this is why I prefer to have type-specific layering configuration.
It makes the data model more "direct" and less confusing, and it allows you to tailor the layering config for each type.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 31 Jul 2012 09:02:57 -0700 (PDT)

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:

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

/martin

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Tue, 31 Jul 2012 16:08:14 +0000

Hi Martin,

The later would be prove very useful.

The reason why both are useful is also for diagnosing faults or performing impact analysis. For example, if I have a broadband customer contact customer service with a problem, the technician dealing with the trouble ticket can identify the interface over which the customer's traffic is flowing and drill down through the interface stack, looking at status and statistics to determine whether there is a possible fault. Another example, if I know I'm going to take a particular physical interface offline, then I can perform a depth-first traversal of all interfaces dependent on the physical interface and send out the proper notifications.

Cheers,
Patrick

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Tuesday, July 31, 2012 12:03 PM
To: Patrick Gili (pgili)
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] comment on ietf-interfaces module

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.

  list interface {
    ...
    leaf-list superior-if {
      type interface-ref;
      config false;
    }
  }        

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 31 Jul 2012 09:09:26 -0700 (PDT)

"Patrick Gili (pgili)" <[email-masked]> wrote:
> Martin,
> 
> I don't agree with your statement below. It isn't always possible to determine
> the interface layering strictly from the type of an interface. For example, a
> PPP interface can sit atop any variety of interfaces, including DSL, cable,
> IP, L2TP, POS, DS3, etc, etc, etc.

I must have expresses myself badly.  I did not mean this.  I meant
that for a specific interface type, you can add objects (through
augmentation) that specifies how this particular interface type can be
layered on top of other interfaces.  Sometimes you can only layer an
interface of type A over type B, and sometimes you do not have such
restrictions.  Regardless of which, by expressing this specifically in
the data model for the interafce type, we can capture these
constraints in the data model.  This is not possible with a generic
config model for layering.

/martin

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Tue, 31 Jul 2012 16:17:05 +0000

Hi Martin,

The point you make below is true. SMIv2 was too generic in this regard and we should guard against simple translations of what was done for SNMP.

On the other hand, should we depend on developers defining YANG modules for each specific technology to do the right thing by augmenting the interface model to support this capability? If so, then I'm alright with this, as long as the RFC defining the ietf-interfaces model calls out best practices regarding interface layering.

I still think a generic, read-only capability is useful for diagnostics and impact analysis though.

Patrick

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Tuesday, July 31, 2012 12:09 PM
To: Patrick Gili (pgili)
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] comment on ietf-interfaces module

"Patrick Gili (pgili)" <[email-masked]> wrote:
> Martin,
> 
> I don't agree with your statement below. It isn't always possible to 
> determine the interface layering strictly from the type of an 
> interface. For example, a PPP interface can sit atop any variety of 
> interfaces, including DSL, cable, IP, L2TP, POS, DS3, etc, etc, etc.

I must have expresses myself badly.  I did not mean this.  I meant that for a specific interface type, you can add objects (through
augmentation) that specifies how this particular interface type can be layered on top of other interfaces.  Sometimes you can only layer an interface of type A over type B, and sometimes you do not have such restrictions.  Regardless of which, by expressing this specifically in the data model for the interafce type, we can capture these constraints in the data model.  This is not possible with a generic config model for layering.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 31 Jul 2012 09:23:33 -0700 (PDT)

"Patrick Gili (pgili)" <[email-masked]> wrote:
> Hi Martin,
> 
> The point you make below is true. SMIv2 was too generic in this regard and we
> should guard against simple translations of what was done for SNMP.
> 
> On the other hand, should we depend on developers defining YANG modules for
> each specific technology to do the right thing by augmenting the interface
> model to support this capability? If so, then I'm alright with this

Yes, this is a potential drawback.  But the question is, if we add
this layering thing as a generic config object, will that remove the
need for type-specific augmentations?  Not in general of course, but
for some (large enough) percentage of all interface types?

> , as long
> as the RFC defining the ietf-interfaces model calls out best practices
> regarding interface layering.

What do you have in mind for this?

> I still think a generic, read-only capability is useful for diagnostics and

Ok.  At this point it would be good to hear what others think about
this idea.  I think at least 4 persons agree with you, and so far
noone has objected.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 31 Jul 2012 09:46:12 -0700

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

Yes -- I think both leaf-lists should be added to the module.

Andy