Re: [netmod] interface-cfg issues

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Apr 30, 2013 at 10:12:13AM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder <[e-mail]> wrote:
> > 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.
> 
> So we should probably say that it is used *only* for physical
> interfaces, not "primarily" - or is there a situation where it could
> be used also for logical/virtual interfaces?  For example, for
> loopbacks, you could theoretically use a plain number as the
> location.  If we limit location to physical interfaces, you would have
> to define a "number" leaf for loopbacks (in some other module).  But
> it might be ok,

I fail to see why I now suddenly need a number for the location of my
loopback interface. It simply does not have a location, no? A VLAN
interface on top of an Ethernet trunk does not need a physical
location since the lower layer interface has one but I also do not
mind to have an implementation support a location in that case.
Perhaps I do not see the problem yet.
 
> > > 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?
> 
> I don't think this was his concern.  I think the concern was that this
> leaf sticks out - why do we have an object that doesn't apply to all
> interface types in this module?  Maybe there are other such objects
> that we should include...

We went through discussions like this and the WG finally agreed on
what we have in the I-D. I personally do not like to restart this
discussion. We need to ship things, additional leafs can always be
added later in revisions. So I only see the option we ship what we
have agreed to before or we take out phys-address and we are willing
to wait for interface type specific data models to provide something
similar. Unless ifPhysAddress has proven broken, I prefer to keep what
we have on the table right now.

/js

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