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

Hi Validimir, 

Thank you for the follow-up and for the detailed note on IFG. 


> > 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.
> >

My recommendation here is to pick a new name and add a note that is a digest of the explanation you provided below. In doing so, we don't endorse the overloading practice but in the main time we explain how existing practice can be mapped to the specification.

I don't have a preference for the name to use, though.

Cheers,
Med

> -----Message d'origine-----
> De : Vladimir Vassilev <[email protected]>
> Envoyé : mercredi 29 avril 2026 12:30
> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>;
> [email protected]
> Cc : bmwg <[email protected]>; ippm <[email protected]>
> Objet : 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> git
> >> hub.com%2Fboucadair%2FIETF-Drafts-
> Reviews%2Fblob%2Fmaster%2F2026%2Fdr
> >> aft-ietf-bmwg-network-tester-cfg-10-
> rev%2520Med.pdf&data=05%7C02%7Cmo
> >>
> hamed.boucadair%40orange.com%7C9510e60889c44d2b3ad208dea5da4ddc%7C
> 90c
> >>
> 7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639130554182694917%7CUnkno
> wn%
> >>
> 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX
> aW4
> >>
> zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FEB9DvJlk
> 1DO
> >> HQGylzMAS5bwSeVunkoy2pnVkX2jb2Y%3D&reserved=0
> >>   * doc:
> >>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> git
> >> hub.com%2Fboucadair%2FIETF-Drafts-
> Reviews%2Fblob%2Fmaster%2F2026%2Fdr
> >> aft-ietf-bmwg-network-tester-cfg-10-
> rev%2520Med.doc&data=05%7C02%7Cmo
> >>
> hamed.boucadair%40orange.com%7C9510e60889c44d2b3ad208dea5da4ddc%7C
> 90c
> >>
> 7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639130554182733323%7CUnkno
> wn%
> >>
> 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX
> aW4
> >>
> zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Eb4pej7eZ
> hJ%
> >> 2FBUO6G%2BpCQ%2B8Ymv0GCJqBy3mqnqHvevo%3D&reserved=0
> >>
> >>
> >> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.
> > xenanetworks.com%2Fwp-content%2Fuploads%2F2020%2F01%2FTesting-
> minimum-
> >
> IFG.pdf&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9510e60889
> c44d
> >
> 2b3ad208dea5da4ddc%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63
> 9130
> >
> 554182752631%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO
> iIwL
> >
> jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C
> %7C%
> >
> 7C&sdata=UTPT4PjUTQoqSvweHbKDYiP73fCk6VctEDtHgifrL7Y%3D&reserved=0
> >
> > 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
> >>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

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