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

["MORTON, ALFRED C (AL)" <[e-mail]>]

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.