[ippm] Re: AD Review of draft-ietf-bmwg-network-tester-cfg

On 4/8/26 2:59 PM, [email protected] wrote:
>
> Overall, the document reads well. The structure of the modules are 
> well articulated, but there is lack of details about the intended use 
> of the modules and specific parameters.
>
> There is no narrative text that helps readers walk through the 
> modules, which is not compliant with RFC 9907. I suggest that you add 
> some text about the intended use of the modules, without seeking to be 
> exhaustive, in a dedicated Operational Considerations sections. For 
> example, it is not clear to me how egress/ingress interfaces can be 
> connected to provide the example in Appendix A.
>
> BTW, the rationale for the goals should be better explained to help 
> digest why these requirements are set as design goals. The explanation 
> does not need to be verbose. A reference to a dedicated section in in 
> RFC2544 (or other authoritative sources) would suffice for some of them.
>
> There are some issues with the classification of the references, 
> references not used, and also the misalignment with RFC9907 templates. 
> I flagged the much I can in my review and proposed fixes, but please 
> double check on your side as well.
>
> You can find my detailed AD review:
>
>   * pdf:
>     https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2026/draft-ietf-bmwg-network-tester-cfg-10-rev%20Med.pdf
>   * doc:
>     https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2026/draft-ietf-bmwg-network-tester-cfg-10-rev%20Med.doc
>
>
> Let me know if any clarification is needed.
>

While steadily working my way through the editorial nits I have reached 
an issue that requires a change that I consider important enough to be 
brought up for discussion on the mailing list.

The relevant issues brought up in the review are:

[MB18] Inter-frame-gap would be better

[MB26] Where Idle octets is defined?

[MB30] To be consistent with "Section 3.7 of RFC1242"

The problem at hand is that the specification of the traffic to be 
generated needs a parameter that specifies the gap between frames and 
includes all of the L1 specific mandatory gap octets (like the 1- octet 
start of frame delimeter + 7-octet preamble + 12 octet in the specific 
case of IEEE 802.3 Ethernet frame or other) and the additional amount of 
"idle octets" the operator wants. Unfortunately the semantics of the 
natural choice of name "interframe gap" (IEEE 802.3) or "inter frame 
gap" (RFC1242) both exclude the L1 (physical interface specific to 
Ethernet octets 8 octets (the 7-octet preamble and 1-octet start of 
frame delimeter)) but includes the mandatory gap of 12 octets (physical 
interface specific to Ethernet) which are not idle octets on the data 
plane that can be utilized for frame data.

A traffic generator management model that aims to be independent of the 
physical interface can not deal with physical interface specific octets 
like the Ethernet preamble and start of frame delimeter.

So the people designing such models have often overloaded inter frame 
gap (IFG) definition by adding all the physical layer specific octets to 
that parameter. Here is an example of Teledyne/Xena application note 
using that approach 
https://www.xenanetworks.com/wp-content/uploads/2020/01/Testing-minimum-IFG.pdf

By doing this the minimum IFG becomes 20 and not 8 octets which would be 
the case when the term is used according to Section 3.7 of RFC1242 
or IEEE 802.3.

Until we come up with a name for this parameter we are using the 
overloaded interframe-gap definition as others in the industry have 
done. But I was expecting the issue to be raised and maybe it is time to 
chose a new name that does not conflict with  the RFC1242 definition.

/V





> Cheers,
>
> Med
>

_______________________________________________
ippm mailing list -- [email protected]
To unsubscribe send an email to [email protected]