Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.txt

[Andy Bierman <[e-mail]>]

Hi,

I think we should publish what we have, which is more aligned with
existing implementations and SNMP.  The enhancements you
describe could be added in the future with augments or a module update.
An identity in addition to an IANA enum is OK.


Andy


On Mon, Jun 17, 2013 at 5:49 AM, Ladislav Lhotka <[e-mail]> wrote:

> Hi,
>
> the discussion below doesn't seem to have reached any conclusion. But
> whatever the answer to Juergen's question might be, I think we should
> consider the "type" leaf again, because:
>
> 1. The "type" leaf is useful in YANG for restricting some configuration
> parameters for use only with a certain interface type. The existing values
> in the "iana-if-type" enumeration, such as "ethernetCsmacd" or "tunnel",
> don't seem very effective in this respect. What we need is the type
> information that's often encoded in (platform-specific) interface names,
> for example TenGigabitEthernet0/1, gr-0/0/0 or ppp0.
>
> 2. We actually need a *hierarchy* of interface types, whereas
> "iana-if-type" is flat. For instance, take the Ethernet example in Appendix
> A: The "when" condition
>
>        when "if:type = 'ethernetCsmacd'";
>
> causes the generic Ethernet parameters to apply only to this particular
> type, but not to any specialized Ethernet type, say "ieee-802.11bgn" (if
> this was ever registered by IANA).
>
> 3. The set of permitted types should be easily extensible, without the
> need to go to IANA first.
>
> In my opinion, YANG identity is a much better choice for the type of
> "type" because it satisfies all three requirements. No extra registry is
> needed for identities because they will be registered indirectly through
> the module where they are defined.
>
> It is possible that a simple hierarchy of interface types won't be enough
> for representing the variety of real-world interfaces with all their
> properties and features. But then additional (type-specific) parameters
> could be introduced and used along with "type" for conditional augments.
>
> Lada
>
> Juergen Schoenwaelder <[e-mail]> writes:
>
> > On Wed, May 29, 2013 at 05:53:19PM +0000, Lange, Jeffrey K (GE Energy
> Management) wrote:
> >> Martin asked that I provide my $0.02 on this draft as we've created
> >> an implementation against the -08 version. So here we go...
> >>
> >> In general I like having the interface-state separate from the
> >> interface configuration, it provides an easy way for a user to see
> >> what devices are currently in the system and are available for
> >> configuration.  In our -08 implementation we created a
> >> /interfaces/physical-interfaces table that would be pre-populated by
> >> the factory with the interfaces that are available for that
> >> particular product.  Note that our product is not customer
> >> expandable, so the interfaces that ship with the unit are the only
> >> ones that the customer can configure (ignoring logical interfaces).
> >> By having this config false list of interfaces we could achieve the
> >> same thing in a more standard way.
> >
> > This is _very_ welcome feedback. Implementation experience is always
> > very welcome - if others implement things as well, please consider to
> > share your experiences. This helps a lot.
> >
> >> We have many proprietary interface types (primarily different types
> >> of in-house radio interfaces) that do not fit into the categories
> >> defined by iana-if-type.  Sure you could use the argument "well then
> >> get them added via iana".  But that will never happen.
> >
> > I have to ask this so I do better understand. Why will this never
> > happen?
> >
> > - Is the procedure to register your interface type too complex?
> >
> > - Is the interface type kind of secret and hence you do not want to
> >   have it registered somewhere?
> >
> > - Is it that developers simply would not know how to register a new
> >   interface type and choose a random value anyway?
> >
> > - Something else?
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> > Fax:   [phone]         <http://www.jacobs-university.de/>
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>