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

Maybe specify the layer of the frame you are refering to, e.g. L2-inter-frame gap for the 20 octets outside an ethernet L2 frame?

On April 29, 2026 12:30:10 PM GMT+02:00, Vladimir Vassilev <[email protected]> wrote:
>
>On 4/29/26 12:26 PM, Vladimir Vassilev wrote:
>> 
>> 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.
>
>Correction "By doing this the minimum IFG becomes 20 and not 12 octets"
>
>/V
>
>
>> 
>> 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]

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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