Subject: [netmod] ietf-interfaces & vendor specific types

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Thu, 26 Jul 2012 14:20:15 +0000

I've run into a bit of a snag when trying to implement the ietf-interfaces model on our products, we have some vendor specific interface types that are not covered by the iana enumeration, yet we need to be able to convey the interface type in the data model..  I propose that a new leaf be added that allows for an identity-ref for a type when the iana iftype is 'other'  I've tested this in my environment, and it works well.

In ietf-interfaces:
  identity interface-type {
    description
      "Base identity from which vendor specific interface types are
       derived.";
  }

...

    leaf type {
        type ianaift:iana-if-type;
         ...
      }
      leaf other-type {
        type identityref {
          base interface-type;
        }
       when "../type='other'";
        description
          "When an interface type is not specified by the iana-if-type
           enumeration, this leaf may be populated with a vendor-
           specific interface type";
      }

Then in my vendor-specific data model I can define the following:

  identity cellular-lte {
    base if:interface-type;
    description
      "A 4G LTE cellular radio";
  }

Does anyone else see merit in this approach?  I think it would make vendor specific extensions much easier to handle in a standard way.

-Jeff

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Thu, 26 Jul 2012 14:38:42 +0000

Historically, I have had no difficulties using the web page IANA makes available to register new interface types.

However, it brings up a relevant point. Wouldn't an identityref better represent the notion of "interface type", thereby allowing vendors to have vendor-specific interface types? It would somewhat simplify the administrative of interface types, as the IANA interface types have been littered throughout the ages with interfaces types that were ultimately vendor specific in nature.

Patrick Gili

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lange, Jeffrey K (GE Energy)
Sent: Thursday, July 26, 2012 10:20 AM
To: [email-masked]
Subject: [netmod] ietf-interfaces & vendor specific types

In ietf-interfaces:

...

    leaf type {

  identity cellular-lte {
    base if:interface-type;
    description

-Jeff

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 Jul 2012 08:07:07 -0700

On Thu, Jul 26, 2012 at 7:38 AM, Patrick Gili (pgili) <[email-masked]> wrote:
> Historically, I have had no difficulties using the web page IANA makes
> available to register new interface types.
>
>
>
> However, it brings up a relevant point. Wouldn’t an identityref better
> represent the notion of “interface type”, thereby allowing vendors to have
> vendor-specific interface types? It would somewhat simplify the
> administrative of interface types, as the IANA interface types have been
> littered throughout the ages with interfaces types that were ultimately
> vendor specific in nature.
>
>

I think there is more standards value if the interface types are assigned from a
single naming authority.  Otherwise, we will end up will
vendor-specific versions
of the IANA registered types.  I think a separate leaf for this purpose would
be better.

> Patrick Gili

Andy

> I’ve run into a bit of a snag when trying to implement the ietf-interfaces
> model on our products, we have some vendor specific interface types that are
> not covered by the iana enumeration, yet we need to be able to convey the
> interface type in the data model..  I propose that a new leaf be added that
> allows for an identity-ref for a type when the iana iftype is ‘other’  I’ve
> tested this in my environment, and it works well.
>
>
>
> In ietf-interfaces:
>
> …
>          …
> Does anyone else see merit in this approach?  I think it would make vendor
> specific extensions much easier to handle in a standard way.
>
>
>
> -Jeff
>
>
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Jul 2012 17:47:31 +0200

> However, it brings up a relevant point. Wouldn't an identityref better represent the notion of "interface type", thereby allowing vendors to have vendor-specific interface types? It would somewhat…

This has already been discussed:

http://www.ietf.org/mail-archive/web/netmod/current/msg05913.html

In short: We need support for YANG identities in XPath expressions, otherwise the migration from enumerations to identities makes little sense.

To this end, an XPath extension function (derived-from()) is already waiting in the pipe, but unfortunately this requires an update to the YANG spec.

Lada

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

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Thu, 26 Jul 2012 17:10:36 +0000

> > However, it brings up a relevant point. Wouldn't an identityref better
> represent the notion of "interface type", thereby allowing vendors to have
> littered throughout the ages with interfaces types that were ultimately vendor
> specific in nature.
> 
> In short: We need support for YANG identities in XPath expressions,
> otherwise the migration from enumerations to identities makes little sense.
> 
> To this end, an XPath extension function (derived-from()) is already waiting in
> the pipe, but unfortunately this requires an update to the YANG spec.
> 

I agree that having the derived-from would be a cleaner approach, but what I'm suggesting is 1) possible today, and 2) creates a standard way to deal with the already defined "other" iana-iftype enum value.  I clearly could augment the interfaces model to add this capability in my own vendor specific extensions, but I think that this is something that other people would also benefit from.  And I would like to try to keep my models as close to the standards as possible for obvious reasons.

And I don't think that asking IANA to add a truly vendor specific interface type, that no other manufacturer in the world would be using,  to the public enumeration is a very good idea either.

-Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Jul 2012 21:07:51 +0200

> However, it brings up a relevant point. Wouldn't an identityref better represent the notion of "interface type", thereby allowing vendors to have vendor-specific interface types? It would somewhat…

I think we had this discussion before. The last time we went through
this, I believe the WG favored a controlled central registry for
interface types since this promotes interoperability. Is it really
useful if every vendor comes up with his own interface types for say
LTE interfaces?

/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: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Thu, 26 Jul 2012 19:21:07 +0000

> I think we had this discussion before. The last time we went through this, I
> believe the WG favored a controlled central registry for interface types since
> this promotes interoperability. Is it really useful if every vendor comes up with
> his own interface types for say LTE interfaces?
> 

Yes, I agree that things like LTE should be maintained by a central registry, however we have many proprietary radio interfaces on our products that would make absolutely no sense to have maintained by a central registry.   I contend that this is the purpose of the "other" value in the iftypes enum.

-Jeff

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 27 Jul 2012 06:29:35 +0200

This is exactly why the 'other' value in the ifTypes enum occupies one
and only one value. As advisor for IANA for the ifType registry I
believe that defining vendor specific interfaces should remain the sole
responsibility of vendors. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Lange, Jeffrey K (GE Energy)
> Sent: Thursday, July 26, 2012 10:21 PM
> To: Juergen Schoenwaelder; PatrickGili (pgili)
> Cc: [email-masked]
> Subject: Re: [netmod] ietf-interfaces & vendor specific types
> 
> Yes, I agree that things like LTE should be maintained by a central
> registry, however we have many proprietary radio interfaces on our
> products that would make absolutely no sense to have maintained by a
> central registry.   I contend that this is the purpose of the "other"
> value in the iftypes enum.
> 
> -Jeff
> 
> > /js
> >
> > --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Jul 2012 07:26:04 +0200

> responsibility of vendors. 

But then we have rather recent additions of interface types such as
vmwareNicTeam or vmwareVirtualNic. ;-)

My concern is that many vendors might believe they have rather vendor
specific interface types while this for some interfaces might just not
be true. Like in the early days, people thought that an Ethernet
interface running at different speeds needs to have different ifTypes
values (and that got fixed in RFC 3635). I guess one of the problems
with the IANA ifType registry is that the definition of what those
allocated interface types are is somewhat lacking (usually just an
expansion of the allocated name with some other acronyms in the
comments). For me, a vendor specific interface is one that will never
ever communicate with something built by a different vendor.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 27 Jul 2012 07:46:06 +0200

To get a new ifType assignment a vendor needs to show a specification
that describes the layering model and the specific and presumably unique
characteristics of the interface type, as well as the meaningful filling
of the ifTable objects as per RFC 2863. 

Dan

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Friday, July 27, 2012 8:26 AM
> To: Romascanu, Dan (Dan)
> Cc: Lange, Jeffrey K (GE Energy); PatrickGili (pgili); [email-masked]
> > believe that defining vendor specific interfaces should remain the
> > sole responsibility of vendors.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Jul 2012 08:33:39 +0200

> of the ifTable objects as per RFC 2863. 

This is good but unfortunately this useful information does not seem
to be recorded in the IANA registry. (This comment applies to many
allocations, whether initiated by a vendor or not - and allocated by a
vendor may not be the same as vendor-specific allocation.)

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 27 Jul 2012 15:44:20 +0200

On Jul 26, 2012, at 7:10 PM, Lange, Jeffrey K (GE Energy) wrote:

> I agree that having the derived-from would be a cleaner approach, but what I'm suggesting is 1) possible today, and 2) creates a standard way to deal with the already defined "other" iana-iftype enum value.  I clearly could

Well, I guess the absence of derived-from() XPath function will have the same consequences, e.g., if you wanted to add some nodes that are valid only for certain if-types: qualified identity names won't work and the derivation relations cannot be used.

Lada 

> augment the interfaces model to add this capability in my own vendor specific extensions, but I think that this is something that other people would also benefit from.  And I would like to try to keep my models as close to the standards as possible for obvious reasons.
>

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Fri, 27 Jul 2012 13:49:25 +0000

Well after much debate on this topic I guess I'll retreat and just implement  this in a vendor-specific model. =)

-Jeff

> From: Ladislav Lhotka [mailto:[email-masked]]
> Sent: Friday, July 27, 2012 9:44 AM
> To: Lange, Jeffrey K (GE Energy)
> Cc: [email-masked]
> >> represent the notion of "interface type", thereby allowing vendors to
> >> have vendor-specific interface types? It would somewhat simplify the
> >> administrative of interface types, as the IANA interface types have
> >> been littered throughout the ages with interfaces types that were
> >> ultimately vendor specific in nature.
> >>
> >> To this end, an XPath extension function (derived-from()) is already
> >> waiting in the pipe, but unfortunately this requires an update to the YANG
> spec.
> >>
> >
> >
> > I agree that having the derived-from would be a cleaner approach, but
> > what I'm suggesting is 1) possible today, and 2) creates a standard
> > way to deal with the already defined "other" iana-iftype enum value.
> > I clearly could
> 
> Well, I guess the absence of derived-from() XPath function will have the same
> consequences, e.g., if you wanted to add some nodes that are valid only for
> certain if-types: qualified identity names won't work and the derivation
> relations cannot be used.
> 
> Lada
> 
> > augment the interfaces model to add this capability in my own vendor
> specific extensions, but I think that this is something that other people would
> also benefit from.  And I would like to try to keep my models as close to the
> standards as possible for obvious reasons.
> >
> > And I don't think that asking IANA to add a truly vendor specific interface
> type, that no other manufacturer in the world would be using,  to the public
> enumeration is a very good idea either.
> >
> > -Jeff
> >
> >> Lada
> >>
> >>>
> >>> Patrick Gili
> >>>
> 
> --

---

From: Andy Bierman <[email-masked]>
Date: Fri, 27 Jul 2012 06:54:39 -0700

> Well, I guess the absence of derived-from() XPath function will have the same consequences, e.g., if you wanted to add some nodes that are valid only for certain if-types: qualified identity names…

I'm not sure about the details of this new 'derived-from' function,
but adding that feature to a server is new code no matter how it is done.
For example, Yuma XPath knows about identityrefs and accepts local-name
or YANG-prefix:local-name for an identityref leaf value.  YANG-prefixes are
the same for all QNodes specified in a must or when expr.  This approach
seems easier than creating new XPath functions.  (BTW, not in a hurry
to make any changes to YANG).

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 27 Jul 2012 16:06:34 +0200

> to make any changes to YANG).

But it also means that Yuma XPath is not XPath anymore, and different YANG implementations can give different results. In contrast, extension functions are a well-established concept in XPath (and YANG already uses one - current()), so I think it is a much cleaner approach. For one, new functions make the deviation from standard XPath explicit.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 27 Jul 2012 07:53:16 -0700

> But it also means that Yuma XPath is not XPath anymore, and different YANG implementations can give different results. In contrast, extension functions are a well-established concept in XPath (and…

You are probably right, but the common thing to do is just use the local-name
and reference an identity defined in the module.  So the QName version
is not used very often. (Also yuma treats XPath prefixes in YANG stmts
as module prefixes but the XPath select parameter always uses XML prefixes.

Don't we need more than an XPath function?
What about comparing nodes (when "/foo/idref1 = /foo/idref2";)
We want 'foo:bar1' and 'bar1' to compare equal (bar1 defined in the foo module).
(e.g., when "idref(/foo/bar1) = idref(/foo/bar2)";)

The nodeset may not be derived from a simple path-expr like this.
It may not be possible to always wrap an idref value in this special
XPath function.  Either the XPath parser knows it is dealing with
an identityref, or some times these nodes will be compared as simple
strings.  The values come from the internal database, not the XPath expr.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 27 Jul 2012 18:58:24 +0200

> Sent: Friday, July 27, 2012 9:34 AM
> To: Romascanu, Dan (Dan)
> > that describes the layering model and the specific and presumably
> > unique characteristics of the interface type, as well as the
> > meaningful filling of the ifTable objects as per RFC 2863.
> 
to
> be recorded in the IANA registry. (This comment applies to many

Well, the IANA registry is actually a MIB module containing the TC with
the enumeration, as you know. We can ask IANA to record as comments or
separately a pointer to the specification and/or contact information to
the owners

Dan

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 27 Jul 2012 20:26:06 +0200

> separately a pointer to the specification and/or contact information to

I don't know about ifType but I found out that IANA-ADDRESS-FAMILY-NUMBERS-MIB is not kept in sync with the list published on IANA web:

http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xml

So I assume the web list is the authoritative resource.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 28 Jul 2012 00:15:53 +0200

> separately a pointer to the specification and/or contact information to

My understanding is that the IANA registry is here

http://www.iana.org/assignments/smi-numbers

(you have to scroll a bit) and the MIB module is a machine readable
serialization of it (and the YANG module would be another
serialization). While IANA seems to maintain data internally in an XML
format these days, there is no automated generation of derived
serializations, at least this was true when we talked to IANA. At that
time (some IETFs ago), IANA said updates are rare enough that
automating things is not necessary.

The registry actually contains a pointer who requested the entry. But
that is all, no additional information seems to be linked (except
allocations described in RFCs).

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 29 Jul 2012 02:36:22 +0200

> Sent: Saturday, July 28, 2012 1:16 AM
> To: Romascanu, Dan (Dan)
> > > allocations, whether initiated by a vendor or not - and allocated
by
> > > a vendor may not be the same as vendor-specific allocation.)
> > >
> > > /js
> > >
> > >
> >
> > Well, the IANA registry is actually a MIB module containing the TC
> > with the enumeration, as you know. We can ask IANA to record as
> > comments or separately a pointer to the specification and/or contact
> > information to the owners
> 
automating
> things is not necessary.
[[DR]] 

Right, this changed with the introduction of the XML format. Actually
all latest entries include either a [contact] or a [reference] field, in
many cases both. We could easily automate the generation of comments
that would include the information with the MIB and YANG generated
modules. 

Dan