Re: [netmod] interface-cfg issues

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Apr 30, 2013 at 09:29:45AM +0200, Martin Bjorklund wrote:
> Hi,
> 
> The Routing Directorate review of
> draft-ietf-netmod-interfaces-cfg-10.txt
> brought up a couple of issues that I think the WG needs to dicsuss.
> 
> (The original mail is not in the list archive, but my reply is found
> here: 
> http://www.ietf.org/mail-archive/web/netmod/current/msg08031.html)
> 
> 
> 1)  The name "location"
> 
> > > >> 3. Interfaces Data Model
> > > >> …
> > > >>            +--rw location?                   string
> > > >> ...
> > > >> 3.1. The interface List
> > > >> …
> > > >>   The "location" leaf is a string.  It is optional in the data model,
> > > >>   but if the type represents a physical interface, it is mandatory.
> > > >>   The format of this string is device- and type-dependent.  The device
> > > >>   uses the location string to identify the physical or logical entity
> > > >>   that the configuration applies to.  For example, if a device has a
> > > >>   single array of 8 ethernet ports, the location can be one of the
> > > >>   strings "1" to "8".  As another example, if a device has N cards of M
> > > >>   ports, the location can be on the form "n/m", such as "1/0".
> > > >> 
> > > >> I think that "location" is a poorly chosen label, a misnomer. This
> > > >> seems to be
> > > >> closer to an identifier than a locator. For example, some devices
> > > >> number slots
> > > >> left to right, and some number slots right to left :-)
> > > > 
> > > > Correct, and we do not try to get into this at all.  Some
> > > > devices has 2 ports called A and B, and some have chassis of cards
> > > > with rows of ports...
> > > > 
> > > >> This does not answer
> > > >> "where" something is; I do not mean geo-location, but I strongly
> > > >> suggest
> > > >> getting more precision on how this leaf is called. For example,
> > > >> interface
> > > >> numbering, instance id, type identifier, etc.
> > > > 
> > > > The intention is really to be "where" the port is.  It is not intended
> > > > to be a virtual id.  If the operator plugs in a cable in a certain
> > > > port, he has to know how to configure this port so there must be
> > > > something in the config that connects to the physical port.  We use
> > > > the name "location" for this purpose.
> > > 
> > > Thanks for the explanation. While I appreciate (and I agree) that you
> > > do not get into interpreting or parsing the syntax of the field, I
> > > still think it is not a "location".
> > > 
> > > I believe there is still an underlying assumption that the language is
> > > defined for the physical world. If you have an Ethernet1/0, versus an
> > > Ethernet1/2, that identifies (not locates) which interface. Yes, you
> > > can use that to physically find them. But what if you have a
> > > "loopback123" vs "loopback112358 or a "Serial1/4:5.123"? I do not
> > > think we can "locate" the loopback, or the subinterface.
> > > 
> > > If the operator creates a "loopback", "Tunnel", or virtual interface,
> > > he or she does not need to physically locate it.
> > > 
> > > I believe that labeling the leaf as "location" can be harmful as it
> > > implies a specific meaning and shows assumptions.
> > 
> > Ok I think I understand your concern.  Personally, I think "location"
> > works also in this case, but we should pick a name that is as useful
> > as possible.  Let me bring this issue back to the WG.
> 
> 
> Any comments on this?
> 

My understanding is that location is primarily for physical network
interfaces. For logical interfaces, the location may not be defined.
This covers loopback, tunnel, and virtual interfaces. Perhaps all that
needs to be done is to state that for interfaces that do not have a
location like loopback interfaces, the location leaf will not exist.
 
> 2)  phys-address
> 
> >>         leaf phys-address {
> >>           type yang:phys-address;
> >>           config false;
> >>           description
> >>             "The interface's address at its protocol sub-layer.  For
> >>             example, for an 802.x interface, this object normally
> >>             contains a MAC address.  The interface's media-specific
> >>             modules must define the bit and byte ordering and the
> >>             format of the value of this object.  For interfaces that do
> >>             not have such an address (e.g., a serial line), this node
> >>             is not present.";
> >>           reference
> >>             "RFC 2863: The Interfaces Group MIB - ifPhysAddress";
> >>         }
> >> 
> >> Just by reading the description of this leaf, shouldn't this be
> >> part of an augmentation type-specific module? For example, for an
> >> Ethernet interface module, instead of the main YANG interface
> >> management top-level. Meaning: this specific leaf, by definition,
> >> cannot be generically specified to what it means for each type of
> >> interfaces. All the others can… if this cannot be specified outside
> >> a media-specific module, why define it here?
> 
> So the proposal from him is to remove this leaf.  I think it could
> stay, but we would probably not have added it if it wasn't part of
> ifTable...  Comments?

There are interfaces that do not have a physical address, e.g. the
loopback interface. For such interfaces, phys-address would not exist.
Are there interfaces that have a physical address that this object
can't represent properly? Sure, this object could be moved to
interface type specific data models. This provides the benefit of
coming up with more specific address types and representations at the
expense that there is no generic way to retrieve the physical address
of an arbitrary interface. Do we have any concrete experience that
ifPhysAddress does not work in the IF-MIB?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>