Add set_mtu to packet_link_qualification

[dplore]

To avoid issues where the L2 interface MTU may be smaller than the packet_size requested for a packet link qualification test, a new field is added to ensure the interface mtu is set to the packet_size.

Instead of updating the description of the current packet_size field which would be a breaking change for plaforms that do not already do this, a new field is introduced.

For the reflector (asic loopback mode), a packet_size field is also added for the same purpose.

[coveralls]

Pull Request Test Coverage Report for Build 16943467466

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 0.0%

---

Totals
Change from base Build 16924193294:	0.0%
Covered Lines:	0
Relevant Lines:	12442

---

💛 - Coveralls

[LimeHat]

While I appreciate the spirit of this PR, I'm concerned about the fact that it introduces yet another mechanism of config (or state) changes without clear rules.

• how this operation is supposed to work?
• does it update the config (which, for example, is reflected in gnmi)?
• does it update the state?
• what are the rules of interaction with bootz datastores/namespaces (boot specifically, which is supposedly "immutable")?
• there's also gSII..
• what happens if a control module switchover occurs during the test?
  and so on and so forth..

I'd suggest leaving interface config aspects to the config management system.

[LimeHat]

Ensure how?

[rszarecki]

gnoi service == device.

Checking what is programmed on dataplane/port and programming port on ASIC if needed.

[dplore]

While I appreciate the spirit of this PR, I'm concerned about the fact that it introduces yet another mechanism of config (or state) changes without clear rules.

• how this operation is supposed to work?
• does it update the config (which, for example, is reflected in gnmi)?
• does it update the state?
• what are the rules of interaction with bootz datastores/namespaces (boot specifically, which is supposedly "immutable")?
• there's also gSII..
• what happens if a control module switchover occurs during the test?
  and so on and so forth..

I'd suggest leaving interface config aspects to the config management system.

Hi, thanks for the feedback. This PR is intentionally provoking this kind of feedback. 😄

Here's the operational use case:
An aggregate interface is configured with MTU 8000, but the individual member port MTU is not configured. gNOI link-qual with packet_size 8000 is invoked on a member of the aggregate. The link qualification fails because the member interface is put into TESTING mode and removed from the aggregate. Since it was removed from the aggregate, that individual interface has no MTU.

The operational goal of link qualification is that it can be used as a 'one shot' RPC action that takes care of everything needed to perform the link qualification. This includes taking the interface "out of service", doing the setup, generation and restoration of service. Packet-link-qual is an ephemeral state of operational intent. Operationally we want to avoid "temporary" configuration state (1).

So a few options are:

1. gNOI "takes care of setting the MTU to a value that accommodates the requested packet_size for the test.
2. The individual member interfaces are each configured with the desired MTU.
3. The operator adds in configuration of the MTU to the target interface(s) as part of a workflow.

Options 1 and 2 seem viable and don't violate the goal of avoiding 'temporary, ephemeral configuration state'. Option 3 violates the operational goal.

More feedback from operators and vendors is appreciated. :)

(1) gSII proposes a generalized way to formalize temporary or ephemeral configuration.

[LimeHat]

Ah, this also involves LAG.. which makes it even more interesting and vendor-specific! :-)

The link qualification fails

... in some implementations. Have you tried Nokia? :-)

removed from the aggregate. Since it was removed from the aggregate, that individual interface has no MTU.

• "removed from aggregate" in this case is not a strongly defined action.
  • It is removed from the data plane point of view (the interface cannot be used for hashing/traffic forwarding in this LAG), and from the control plane perspective (LACP signaling is blocked).
  • It doesn't mean that the interface loses all other properties inherited from the LAG (such as MTU).
• IMO there's no such thing as "no MTU" - even if we assume that a vendor implementation completely removes the interface from the LAG, with all associated properties - the interface should have a default MTU.
  • the only issue in your scenario would be if the default on that NOS is 1500 instead of 9k+ and it cannot be configured system-wide
  • bonus option to resolve this: add a configurable /system/mtu/config/default-interface-mtu leaf to openconfig :-)

To keep it vendor-neutral and help you (and the vendor in question) achieve the operational goal, may I suggest the following:

• indicate that this is an optional field that should be supported by vendors that do not retain MTU configuration when an interface is in testing mode
• specify that this option modifies only the state

[rszarecki]

Please add min_mtu, max_mtu to message AsicLoopbackCapabilities.
We shall know what system is capable for, befor requesting any configuration.

[rszarecki]

For consistency, can we also have 'set-MTU' Boolean?

It will be bit redundant but IMHO more intuitive.

Also it is optional file,right? Can we declare default 1500B?

[rszarecki]

gnoi service == device.

Checking what is programmed on dataplane/port and programming port on ASIC if needed.