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

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]