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

[Vladimir Vassilev <[e-mail]>]

Hi Alfred,

On 16/11/2019 13.27, MORTON, ALFRED C (AL) wrote:
> 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 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


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


OK


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


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


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


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.


>
> ....
>
>      |  |  +--:(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?


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.


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


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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bmwg