Re: [bmwg] matters arising Re: Minutes from IETF-109 Session

[Vladimir Vassilev <[e-mail]>]

Hi Tom,

Thanks for keeping an eye on the draft.

On 08/01/2021 11.21, tom petch wrote:
> <tp>
>
> '  Proposals:
>
>      A YANG Data Model for Network Interconnect Tester Management
>      https://tools.ietf.org/html/draft-vassilev-bmwg-network-interconnect-tester-04
>      status:
>          Draft updated Sept 9, added mechanism for real time synchronization of traffic generation
>          open-source/hardware implementation of generator/analyzer at the hackathon.
>
> No one raised hand that they have read above draft. '
>
> That is because the word 'yang' does not appear in the title!


What do you mean? The title is "A YANG Data Model for Network 
Interconnect Tester Management".


>   No matter,
>
> NMDA support or lack thereof needs a mention in the Introduction


There are a few counters defined under 
/if:interfaces-state/interface/statistics (which make the draft 
dependent on a deprecated container as of RFC8343). My intention is to 
remove them in the next version and copy the RFC8407 "NMDA support" 
boilerplate text.


> There are about twenty Normative References missing such as
>
> IEEE 802-2014
> IEEE 802.1Q
> IEEE 802.1p
> RFC6991
> RFC8343
> RFC7224


OK. These 6 references will be added to the next version.


> while all features should have a YANG Reference clause according to a recent YANG doctor review - I agree!


OK but what would be the reference for the "multi-stream" feature for 
example or the rest of the features specified in the draft that do not 
need external reference?


> Why is data type 'string'?  Why not binary or hex-string?

Both 'binary' and 'hex-string' are alternatives that can work. With 
binary one looses the human readable representation on the wire and the 
ability to edit the configuration without specialized tools for a 1/3 
compression gain. While hex-string adds 1/3 extra data in form of 
columns separating each byte "01:02:03" which works fine for MAC 
addresses but is standing a bit in the way for longer strings - frame 
header specification etc.

can make this change once at a more mature point so I do not need to 
change all the tools (here an example of a tool generating an RFC2544 
testframe that can be directly reused with the configuration of the 
generator):

  ./traffic-generator-make-testframe --frame-size=64 
--dst-mac-address="12:34:56:78:9A:BC" 
--src-mac-address="DE:F0:12:34:56:78" --src-ipv4-address="192.0.2.1" 
--ipv4-ttl=10 --src-ipv4-udp-port=49184 --dst-ipv4-address="192.0.2.2" 
--dst-ipv4-udp-port=7
  123456789ABCDEF01234567808004500002E000000000A112CBCC0000201C0000202C0200007001A0000000102030405060708090A0B0C0D0E0F10119CD50E0F


> I note that 'burst-data' is couched in terms of octets


Correct. The interframe-,interburst- and interstream- gaps are expressed 
in octets.


> YANG 'augment' are usually constrained by 'when' clause. Here every YANG interface on the box will be augmented.


IMO this is the case when the augment only applies to a certain set of 
interface types. However in the case of a generator/analyzer modules 
that aim to be universal and applicable for all interfaces that send and 
receive packets I do not see how we can do this.


> YANG prefix must be unique across the entire spectrum of IETF work and ideally beyond that as well.  I find 'ta' and 'tg' too brief and think that they should have another two or three characters. 't(raffic)' embraces a lot of concepts!


While I am OK with changing the prefixes to a different/longer strings I 
think we can do it later in the process. For me the cost will be going 
through some working code in order to modify these particular bits. 
Formally there is no requirement in RFC8407 for avoiding too short prefixes.


> 'The proposed model splits the design into 3 modules - 1) Traffic
>     Generator module (TG), 2) Traffic Analyzer module (TA).  '
> That would be one and two and ???


I will fix that.


> MAC-address implies, well MAC address only; seems a bit limiting or worth a mention in the Abstract/Introduction


I am lost here. Do you refer to the ethernet feature which enables 
specification of parameters like src-mac-address, dst-mac-address 
vlan-id etc.?


> 'statistics' would be better IMHO in a container of their own for this application rather than alongside every other interface statistic.


The original argument for placing some of the statistic counter 
definitions ( e.g. tg:generated-pkts, tg:generated-octets) in the same 
container as the rest of the generic interface counters 
{if:out-unicast-pkts, if:out-broadcast-pkts, if:out-multicast-pkts} was 
the strict synchronization requirements for the counters of such 
instruments and  some anticipated complications associated with the 
synchronization of separate containers.

I would like to keep this point open for discussion for now.


> vlan id has been defined by IEEE and it is different!

Correct. This is not a precedent for IETF (yang:mac-address is also 
different). That said I am considering removing the VLAN fields from the 
traffic-generator module all together. I find myself using the raw 
frame-data leaf for specifying advanced testframe headers (that includes 
VLAN tagged frames, alternative ipv4(udp) and ipv6(udp) header options).


>       when "ta:type = 'ta:ethernet'";
> is fragile - derived from or self is a more robust concepthea


OK. I can't see any disadvantage in that.


> Security Considerations must conform to YANG GuidelinOK.


OK. I will add the RFC8407 boilerplate text and a few lines informing 
the reader that a stateless traffic generator is controlled with the 
model and the potential risks when used outside of test environments.


> her
>
> What language is used for Appendix A.1?

This should be considered pseudo code but is actually python which uses 
command line syntax (based on the YANG modules) that expands to NETCONF 
protocol PDUs to orchestrate the test network in the example. The 
intention is to demonstrate how the generator can be programmed along 
with the DUTs.


/Vladimir


>
> Tom Petch