openconfig
Introduce LINECARD_MODULE identity for hardware component type
- (M) release/models/platform/openconfig-platform-types.yang
- Add LINECARD_MODULE identity as valid hardware component type
This proposal adds the LINECARD_MODULE hardware component type to represent modular
interface and services modules generally used as a child of LINECARD and
parent of PORT or ASIC
References:
- https://www.cisco.com/c/en/us/products/interfaces-modules/index.html
- https://infocenter.nokia.com/public/7750SR140R4/index.jsp?topic=%2Fcom.sr.interface%2Fhtml%2Finterfaces.html
- https://www.juniper.net/documentation/en_US/release-independent/junos/topics/concept/pic-overview-nog.html
@rgwilton @rolandphung for any comments. The use case is for enumerating, optional, pluggable/replacable modules that are contained within a linecard.
This will be presented to the openconfig operators on May 3, 2022. Barring any objections, this should merge that day.
I suggest we leave the name as "MODULE" because if the module is a child of a LINECARD it is obviously a LINECARD_MODULE, etc. As was stated above in the thread, this issue is with other component types as well so if passed then are we inviting every component type to also have a MODULE type. What about the case where a MODULE within a slot of a CHASSIS contains additional CPU and STORAGE subcomponents? By keeping the component name generic (e.g. MODULE) this use case is addressed but not if the name is LINECARD_MODULE.
I suggest we leave the name as "MODULE" because if the module is a child of a LINECARD it is obviously a LINECARD_MODULE, etc. As was stated above in the thread, this issue is with other component types as well so if passed then are we inviting every component type to also have a MODULE type. What about the case where a MODULE within a slot of a CHASSIS contains additional CPU and STORAGE subcomponents? By keeping the component name generic (e.g. MODULE) this use case is addressed but not if the name is LINECARD_MODULE.
Thx @cfyo - This comes at a perfect time since what you raise is already a concern and we have some design decisions to take into account
The approach you mention (and what was initially proposed here) is fairly loose which means it
- Can be abused
- Can be ambiguous to the client
Essentially, we already have this today with the FRU type. It is looked at as a catch-all and does not truly cover the case for a component that cannot be represented in the system that is actually not "removable". When we have catch-all types then we run the risk of not being able to categorize or filter correctly based off the component type and since the component name is vendor proprietary, we now lose some preciseness (e.g. filter all components of type=MODULE may return a large list that then needs to be broken down further based off proprietary criteria conveyed in another leaf or key) - the same holds true for FRU
I was considering another PR for additional module types infact (in addition to the potential removal of type FRU as the FRU portion itself can be conveyed by way of the removable boolean leaf) as a given system may have upwards of 25, 30, 35+ "types" of components that then need to be represented and overloaded into a small defined abstract subset.
When there is abstraction, you lose preciseness so the question is how precise do we want to get in this classification w/o creating an ever expanding list of identities
Hi @earies - IETF has general hardware_classes like OC such as chassis, fan, power-supply, sensor, etc. and module but no linecard_module. They do have sub-module and sub-module-[L2/3/...] that may be an option to discuss. The component's name, description, location and other state information will also provide information as to its type without adding dozens of new specific component types to this list. The benefit of OC is generalization and abstraction so it can be used across multiple vendors.
My experience here is that over the years that has been quite a lot of flexibility as to what linecard modules look like. E.g., if I am remembering my hardware properly, then there have been cases where linecards are split into two separate parts (i.e., the forwarding engine separate to the port carrying PLIM part), as one type of PLIM we had a card carrying up to 6 separate SPAs. So logically, all of these components can be independently added/removed and they all represent some kind of FRU, that you could call a module, but they also all look quite different as to what they are, and what function they provide.
Hence, I think that this discussion comes down to:
Does a "LINECARD_MODULE" have any common associated data nodes (beyond that which is available for all hardware modules)? If it does then I agree that having a specific "LINECARD_MODULE" identity makes sense, alongside defining the associated container definition.
However, if this identity is only intended to be a slightly more meaningful generic name, with the only intent of helping to describe the physical structure then a name like "MODULE" is arguably better because it is more generic. Here, it is really just acting as a better description than "FRU".
The proposed description of "LINECARD_MODULE" leaf in this PR constrains this leaf to be a child of "LINECARD" component. The english words chosen are meant to align with this constraint. This leaf has a more strictly defined use case than what might be implied by "MODULE" or "FRU".
The use case of a child of a LINECARD_MODULE (such as a "SPA") could only be met by defining another leaf such as "LINECARD_SUBMODULE" or other, perhaps more clever name, which carried a constraint that it must be a child of a "LINECARD_MODULE".
The schema already allows arbitrary nesting of components. These types are essentially adjectives for components. I think we need some better adjective than 'MODULE'. This is meant to be a vendor neutral name for Juniper's physical interface card (PIC). However PIC is used for more than just physical interfaces. Rather than use a term which we overload, perhaps we can take this as an opportunity to clarify. (and perhaps use multiple types/adjectives as appropriate)
One approach is to not describe the function at all, but rather the physical packaging. Linecard Sub Module (LSM) or similar.
Another would be add types which attempt to summarize the functionality of such modules. ie: subcomponent of a linecard which packages physical ports. Linecard Interface Submodule (LIS). Linecard Packet Processing SubModule (LPPS), etc.
On Fri, Apr 22, 2022 at 3:03 PM Ebben Aries @.***> wrote:
@.**** commented on this pull request.
In release/models/platform/openconfig-platform-types.yang https://github.com/openconfig/public/pull/612#discussion_r856598798:
@@ -299,6 +305,14 @@ module openconfig-platform-types { "Linecard component, typically inserted into a chassis slot"; }
- identity MODULE {
yep - completely open to suggestions here as I pondered the same for something to generically represent this type of FRU. How about LINECARD_MODULE to at least reel this back to representing an FRU that is a child of LINECARD so that MODULE doesn't get abused as you mention?
— Reply to this email directly, view it on GitHub https://github.com/openconfig/public/pull/612#discussion_r856598798, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMCGM3WQPLXB6RJIZTJ4KDVGMO2XANCNFSM5SCGBGHQ . You are receiving this because you commented.Message ID: @.***>