Subject: [netmod] interface-cfg issues

From: Martin Bjorklund <[email-masked]>
Date: Tue, 30 Apr 2013 09:29:45 +0200 (CEST)

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?

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?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Apr 2013 09:49:30 +0200

> > as possible.  Let me bring this issue back to the WG.

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.
 
> stay, but we would probably not have added it if it wasn't part of

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: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 30 Apr 2013 10:12:13 +0200 (CEST)

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

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

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 30 Apr 2013 10:29:58 +0200 (CEST)

> to define a "number" leaf for loopbacks (in some other module).  But

Hmm, for loopback you don't need anything more than the unique name
(and the type).  No location or number is needed...

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Apr 2013 10:42:07 +0200

> to define a "number" leaf for loopbacks (in some other module).  But

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 30 Apr 2013 11:51:21 +0200

>> as possible.  Let me bring this issue back to the WG.

Let me just throw in my earlier proposal of using "local-name" instead of "location". I believe the former makes sense on every platform, which is not the case for the latter.

> stay, but we would probably not have added it if it wasn't part of

I think the reviewer is right that physical address is always defined by a particular technology, so it might really be appropriate to remove this leaf. We have the type "yang:phys-address" in 6021bis, so it is not a big deal to add it where it makes sense.

Lada

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

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