Semantics and format of Component Location

[dplore]

In order to get some consistency for the leaf /components/component/state/location, I propose that we constrain it's meaning to be relevant to the parent component. For example, a port's location would be a reference to the position in a CHASSIS (fixed-form factor) or LINECARD (modular form factor). A value "5" for a PORT location would for example mean the 5th port on the parent LINECARD.

Today we see inconsistencies where some devices concatenate the linecard slot (CHASSIS position) and and linecard port (LINECARD position) together with some separator (ie: 1/5 or 1/5-port) while others use only the parent location (ie: 5)

public/release/models/platform/openconfig-platform.yang

Lines 404 to 412 in 6fd1f5d

	leaf location {
	type string;
	description
	"System-supplied description of the location of the
	component within the system. This could be a bay position,
	slot number, socket location, etc. For component types that
	have an explicit slot-id attribute, such as linecards, the
	system should populate the more specific slot-id.";
	}

[earies]

Few comments/questions:

• Components can be SW or HW components - the way this is written seems to imply its HW component specific
• Since component names must be unique across the system, the encoding of the name really should indicate much of this data. One technique is to encode the hierarchy in the name to maintain uniqueness e.g. CHASSIS0:LINECARD0:PORT0
• A value "5" for a PORT location would for example mean the 5th port on the parent LINECARD - nit/thought: depends on what is meant to be conveyed here - on a zero-based numbering scheme, that could be the "5th port" but on port "4"
• We have a loose definition here indicating the presence of this leaf could vary depending on the component type. This loose contract would need to be outlined as to what a client is to expect/not-expect
• This is of a string type but could represent integers as strings? Are you proposing changing the type to an integer?
• Is this node even necessary? Can we paint out the use-cases where you have a name (that should encode enough information), slot-id and this? Considering models growing infinitely, scale is going to become more and more of a concern so think we're probably due to assess how and when nodes are added, nice-to-haves vs. must-haves esp. where there is some level of overlap in meaning between alternate nodes

[dplore]

Thanks for the comment @earies.

The operational use case we would like to solve for is:
As a hardware replacement technician, I want to receive an indication of the location of a replaceable component within some network device physical package (chassis, shelf, linecard, etc) . A subset of the components could include a chassis, fan , fabric, powersupply , linecard module or transceiver module. The indication from a software service should match or be mappable to some physical label or display on the hardware.

I am in favor of a model which is more tightly defined than we have now so we can reliably meet the above use case across multiple implementations without deviations.

For this use case, we commonly see a parent-component has 1 or more positions or indices that sub-components may reside in. We can meet the unique component name requirement by relying on that the parent and sub component names are unique. This proposal is a component has a parent-position or 'parent-index' which indicates the component's installation location within its parent.

For example,

• component/name = "linecard0" has 8 ports

• component[name="Ethernet0/1"]/parent = "Linecard0"

• component[name="Ethernet0/1"]/parent-position = "1" (new leaf here which perhaps obsoletes the current location leaf)

This indicates that a component named "Ethernet0/1" is installed in position "1" of component "Linecard0".

Regarding 0 based or 1 based location, we observe there are cases where the parent-position is an alphanumeric string. ie: "1N" or "2S". Linecard slots could be slot 'A' and slot 'B' for example. (This appears more commonly in optical equipment). So the parent-position is proposed to be a string. And due to this there is no sequence or notion of start or end of a list.

[SydneyCaulfeild]

Hi @dplore, I have a question about what will happen to the existing state/location path. I agree that with the new /parent-position and existing state/parent path, the existing state/location will be redundant in most (all?) cases.

In the example you gave, if a component named "Ethernet0/1" has /parent-position of "1" and a state/parent of "Linecard0", and this Linecard component has a parent-position of "0" (since within the parent Chassis it is in slot 0), I don't think we will ever need the port's path state/location of "0/1".

Out of curiosity, why was the decision made to add a new parent-position path instead of constraining the current state/location path and asking vendors to update this value? Would this not help to limit duplicate/unnecessary locations being stored? Or do you still think there will be a need for state/location even with parent-position, perhaps if a component doesn't have a parent but still has a location?

Also, just to clarify, this new parent-position path will be under components/component[name]/state/ as well, correct?

[dplore]

I am proposing a new leaf to make it clear that there is new functionality required versus a change in the description for an existing leaf. We could also deprecate the current location leaf and remove it altogether in a future release. In practice I also observe it is redundant.

[SydneyCaulfeild]

Sounds good! If the plan is to eventually deprecate the current location leaf, should we add to the description of the new parent-position that it should be present whenever state/location is present to help with this transition?

[dplore]

Sounds good! If the plan is to eventually deprecate the current location leaf, should we add to the description of the new parent-position that it should be present whenever state/location is present to help with this transition?

Yes we can do this. I'll open a PR shortly.