openconfig
Add support for PBLQ per-interface capabilities
Physical/channelized interfaces could support a variety of Generator or Reflector capabilities. An optional field is added to each capability to report a list of supported interfaces. Should this field not be set, it is assumed that all interfaces are supported for the capability reported.
Pull Request Test Coverage Report for Build 12280713436
Details
- 0 of 20 (0.0%) changed or added relevant lines in 1 file are covered.
- No unchanged relevant lines lost coverage.
- Overall coverage decreased (-0.002%) to 1.14%
| Changes Missing Coverage | Covered Lines | Changed/Added Lines | % |
|---|---|---|---|
| packet_link_qualification/packet_link_qualification.pb.go | 0 | 20 | 0.0% |
| <!-- | Total: | 0 | 20 |
| Totals | |
|---|---|
| Change from base Build 12267172196: | -0.002% |
| Covered Lines: | 166 |
| Relevant Lines: | 14562 |
💛 - Coveralls
While I agree that a system-wide capabilities response is not always sufficient (I raised some of the questoins/issues in #149); I'm not a huge fan of per-interface approach. Typically in HW capabilities are defined per ASIC; I'd suggest considering a per-ASIC capabilities response format instead.
While I agree that a system-wide capabilities response is not always sufficient (I raised some of the questoins/issues in #149); I'm not a huge fan of per-interface approach. Typically in HW capabilities are defined per ASIC; I'd suggest considering a per-ASIC capabilities response format instead.
Since this API deals with "links" (e.g. interfaces), the dimension of an ASIC seems that it would unfold into needing yet another method to resolve what the ASIC -> interface relationship is (either within this API or a dependency on another API)
We also have a use-cases that aren't distinguishable by an ASIC alone but rather configuration attributes of an interface that cascades towards separate capablities "per interface"
We also have a use-cases that aren't distinguishable by an ASIC alone but rather configuration attributes of an interface that cascades towards separate capablities "per interface"
Can you please elaborate on this part?
Since this API deals with "links" (e.g. interfaces), the dimension of an ASIC seems that it would unfold into needing yet another method to resolve what the ASIC -> interface relationship is (either within this API or a dependency on another API)
That is a fair point. gNMI/OC can be used to establish that relationship if necessary via the components tree. Today we already have indirect dependencies on another API - e.g. PLQ clients have to know what interfaces are available in the system, interface speeds, etc. Unless the objective of your PR is to eliminate all of that, I don't see much of a problem with extending this approach to asic-to-interface mappings.
We also have a use-cases that aren't distinguishable by an ASIC alone but rather configuration attributes of an interface that cascades towards separate capablities "per interface"
Can you please elaborate on this part?
One example could be the modes set on an interface (e.g. channelization) - if we get into implementation detail, there could be a variety of reasons that capabilities can then change for the full intent of these APIs. We don't have this level of granularity in the API definition today to signal any differences as there is a system wide assumption.
Since this API deals with "links" (e.g. interfaces), the dimension of an ASIC seems that it would unfold into needing yet another method to resolve what the ASIC -> interface relationship is (either within this API or a dependency on another API)
That is a fair point. gNMI/OC can be used to establish that relationship if necessary via the components tree. Today we already have indirect dependencies on another API - e.g. PLQ clients have to know what interfaces are available in the system, interface speeds, etc. Unless the objective of your PR is to eliminate all of that, I don't see much of a problem with extending this approach to asic-to-interface mappings.
Personally, I think this is also something that is not well understood or prescribed from an overarching OC umbrella architectural standpoint. It is often where intent or data is duplicated amongst APIs or relationships that are constructed that assume OC YANG schemas for what could (possibly should?) be schema agnostic APIs. It isn't until a workflow is really dissected before realizing that there may need to be a dependence on another interface to access pre-requisite data. In this case, I had also thought we could convey such capabilities in a YANG state subtree somewhere as well so it begs the overall question, should you be able to fulfill PBLQ related intent solely w/ the APIs defined within this scope? To your point, we already have a dependence on an alternate API here for prior context (likely gNMI subscribe/get but also not limited to depending)
The objective of this PR is primarily to provide a mechanism to signal potentially different capabilities per "link" and a client handling this prior to further RPC execution. How that is accomplished is best suited for the most optimal workflow - I don't feel strongly whether it should exist in this API or elsewhere tbh...
cc: @dplore @robshakir @anshkhanna-ggl for additional thoughts on some of the discussion here
One example could be the modes set on an interface (e.g. channelization) - if we get into implementation detail, there could be a variety of reasons that capabilities can then change for the full intent of these APIs.
Can you provide specific examples (what capabilities are expected to have per-intf granularity)? I'm not sure if I'm following.
Thanks!
My comment could be bit overreaching but neverthless I will share my toughts.
- The capabilities, whatever garnularity they are, are static. Just attribute of a platform The granularaity finer then node are needed, sure. And this can be adressed either by extending PLQ API or by storing it in OC and make accessible by gMNI. But IMHO, we have bigger fish to fry
Every platform has limitations. The PacketGenerators has rate limit per ASIC or ASIC-slice. There are limits for concurrent reflectors per system/LC/asic. For packetInjector there is limited rate packet can be injected, etc. Worst, this limits will varry between platform generations, and vandors. Even between software releases.
- I think we shall rather extend gnoi.PLQ API by runtime port feasibility. The request will list ONE port and responce will provide information what could be requested and system (gnoi.plq server) has free resouces to run at this point in time. This way we would cover main problem - if system has enough free resources to run qualification. And obviously if port do not have some capability, it would never reporte feasibility. So 2 birds w/ one stone.
