Subject: [bmwg] Comments on: draft-vassilev-bmwg-network-interconnect-tester-02

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 16 Nov 2019 12:27:18 +0000

Hi Vladimir,

Thanks for your demo of the YANG control model today.

I have the following comments on your draft.

Al
(As a Participant)

BMWG,

Vladimir has transported equipment to the IETF-106 Hackathon.
He will be available to demo the implementation of his draft

on Sunday, before 1400 local time, and again

at the Hack Demo Happy Hour, on Monday beginning at 1810.

Both locations are the Moor/Morrison Room.

Hope to see you there,
Al
bmwg co-chair

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1.3.  Solution

   The proposed model splits the design into 3 modules - 1) Traffic
   Generator module (TG), 2) Traffic Analyzer module (TA). 
[acm]
Where's the third module?

   The modules
   are implemented as augmentations of the ietf-interfaces module adding
   configuration and state data that models the functionality of a
   tester.  The TA and TG modules concept is illustrated with the
   following diagram of a tester with two interfaces (named e0 and e1)
   conected in a loop with single DUT:
[acm]
run a spell check  s/conected/connected/

2.  Using the network interconnect tester model

   Basic example of how the model can be used in transactional network
   test API to control the testers part of a network and report countrer
   statistics and timing measurement data is presented in Appendix A.
   One of the examples demonstrates the use of the [RFC2544] defined
   testframe packet.
[acm]
It would be good to mention that the cases below assume that the 
search algorithm logic operates to control the generator and analyzer
for each trial  ->> unless they have an automated capability.

3.  Traffic Generator Module Tree Diagram

module: ietf-traffic-generator
  augment /if:interfaces/if:interface:
    +--rw traffic-generator {egress-direction}?
    |  +--rw (type)?
    |  |  +--:(single-stream)
    |  |  |  +--rw frame-size          uint32
[acm]
Frame size can be variable - RFC2544's authors did not include this 
possibility but it is widely used. See RFC 6985, where we tried to 
make this testing more repeatable.

...

    |  |  +--:(multi-stream)
    |  |     +--rw streams
    |  |        +--rw stream* [id]
    |  |           +--rw id                   uint32
    |  |           +--rw frame-size           uint32
    |  |           +--rw (frame-data-type)?
    |  |           |  +--:(raw-frame-data)
    |  |           |     +--rw frame-data?    string
    |  |           +--rw interframe-gap       uint32
    |  |           +--rw interburst-gap?      uint32
    |  |           +--rw frames-per-burst?    uint32
    |  |           +--rw frames-per-stream    uint32
    |  |           +--rw interstream-gap      uint32
    |  |           +--rw src-mac-address?     yang:mac-address {ethernet}?
    |  |           +--rw dst-mac-address?     yang:mac-address {ethernet}?
[acm]
How to control the range pf MAC addresses used for multi-frame?
Also, what about multiple IP-layer flows?

    |  |           +--rw ether-type?          uint16 {ethernet}?
    |  |           +--rw vlan {ethernet-vlan,ethernet}?
    |  |              +--rw id      uint16
    |  |              +--rw tpid?   uint16
    |  |              +--rw pcp?    uint8
    |  |              +--rw cfi?    uint8
[acm]
As discussed in-person, lists of frame sizes, number of flows, etc. work
well for the case of Automated test tools.

---

From: Vladimir Vassilev <[email-masked]>
Date: Sun, 17 Nov 2019 01:11:41 +0000

Hi Alfred,

> Both locations are the Moor/Morrison Room.

The third module was for management of internal interface loopback 
configuration  (present in 00-01 versions). It was removed in the latest 
(-02) version since similar functionality is being standardized in 
ietf-if-extensions.yang part of draft-ietf-netmod-intf-ext-yang-08. I 
will remove of the bogus reference to a third module. Those interested 
in contributing to the standardization of the loopback management 
functionality can do it in draft-ietf-netmod-intf-ext-yang-08. Here is 
thread discussing the latest state and open issues 
https://mailarchive.ietf.org/arch/msg/netmod/Q_itNBOran0K_EHMf4BD0iTKMNA

> run a spell check  s/conected/connected/

OK

> for each trial  ->> unless they have an automated capability.

Yes. A search algorithm would require multiple configuration 
transactions. I will add specific clarification.

> make this testing more repeatable.

The design of the module allows augmentation from external modules 
adding more flexible specification of the traffic generation. That said 
the current design allows for unlimited flexibility where each frame can 
be specified as individual stream. This is not practical if one wants 
random size frame generation or a sweep over a broad range of values but 
it is 100% deterministic.

> ....

Then one needs to specify multiple streams where each stream has frame 
specification with individual MAC or IP packet payload or augment the 
module adding more flexible templating options.

> well for the case of Automated test tools.

We can address these requirement by adding a template mechanism reusing 
the definition of a stream and specifying the logic of the generation of 
the payload of the frames. This is possible since none of the leafs 
(mac-address, frame-data etc.) are mandatory and the module can be 
augmented adding more flexible payload generation methods.

Vladimir

>
> _______________________________________________
> bmwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bmwg