Re: [bmwg] Fwd: Re: WG Adoption Call for draft-vassilev-bmwg-network-interconnect-tester-06

[Vladimir Vassilev <[e-mail]>]

On 16/09/2021 18.45, Jürgen Schönwälder wrote:
> On Thu, Sep 16, 2021 at 04:24:02PM +0200, Vladimir Vassilev wrote:
>> On 16/09/2021 15.09, Jürgen Schönwälder wrote:
>>> On Thu, Sep 16, 2021 at 02:20:04PM +0200, Vladimir Vassilev wrote:
>>>> On 16/09/2021 11.59, Jürgen Schönwälder wrote:
>>>>> I am not sure I have time to read this but just skimming through it,
>>>>> I already have some questions:
>>>>>
>>>>> - The draft defines a model for a traffic generator and a traffic
>>>>>      analyzer. Should the title not be "A YANG Data Model for Traffic
>>>>>      Generators and Traffic Analyzers"? It seems I should be able to
>>>>>      run generators and analyzers on pretty much anything
>>>> The terms "network interconnect" and "tester" are used in RFC2544. In sec. 6
>>>> it is shown a "tester" can be split into "sender" and "receiver" but no
>>>> further references to that private case are made further in the draft.
>>>>
>>>> IMO with the current title the draft is using terminology in use in the
>>>> BMWG. It is just defining a YANG model for management of this device
>>>> abstractions that so far have only had proprietary management interfaces in
>>>> the industry.
>>>>
>>> You may want to pick a title that is broadly well understood and not
>>> just by people deeply involved in BMWG. And my proposal was putting
>>> emphasis on the function and not on some devices that may implement
>>> them.
>>>
>>>>> - Why would a WG work on this and then publish the result as
>>>>>      Informational and not Standards Track?
>>>> I agree.
>>>>
>>>>
>>>>> - Since I worked on LMAP some years ago, it could be nice if trafffic
>>>>>      generators or analyzers could be controlled (scheduled) via LMAP.
>>>> Point taken.
>>>>
>>>>
>>>>> - Figure 1 (would be nice to have a number and caption) seems to
>>>>>      indicate that traffic is flowing from e0.egress to the DUT and from
>>>>>      the DUT to e1.ingress. The model seems to say that the ingress
>>>>>      generates traffic? I am likely confused about egress/ingress,
>>>>>      perhaps source and sink would help?
>>>> The model has .../traffic-generator with the expected egress/source
>>>> direction. In addition some devices support the more exotic
>>>> .../traffic-generator-ingress  generator found on devices that can generate
>>>> their own ingress/sink traffic.
>>>>
>>>> Same goes for the traffic-analyzer and traffic-analyzer-egress containers.
>>>>
>>> I am still not sure what the purpose of an ingress generator is and
>>> why the arraow in the figure points to it, perhaps I do not understand
>>> what the arrows mean in the first place...
>>
>> I double-checked but there is no ingress traffic generator in the figure.
>> The figure shows usecase with egress traffic generator and ingress traffic
>> analyzer.
>>
>>                      +----------------+
>>            e0.egress |                | e1.ingress
>>         +------------| TG  tester  TA |<-------------+
>>         |            |                |              |
>>         |            +----------------+              |
>>         |                                            |
>>         |              +------------+                |
>>         |              |            |                |
>>         +------------->|    DUT     |----------------+
>>                        |            |
>>                        +------------+
> OK. I did not read the figure carefully. That cleared up, how does a
> figure with both an ingress and egress generator look like? Why do I
> need both and how are they different?
>   
>> There is no figure in the current version where ingress traffic generator and egress traffic analyzer are used. Those do not make sense for dedicated testers but for network devices that forward packets and are instrumented with such test functionality.
>>
>> In those devices an ingress traffic generator can be used to generate predefined ingress traffic without changing the topology in order to physically connect dedicated traffic generator devices.
>>
> It may help to have this well defined somewhere, perhaps it is and I
> did not spot while skimming/searching the text. Is the following
> correct?
>
>                  |      ^
>    egress TG --->+      |
>                  v      |
>                +-----------+
>                | interface |
>                +-----------+
>                  |      ^
>                  |      +<--- ingress TG
>                  V      |
>
> Or is the egress TG "below" the interface as well?


Yes.


> Are the interface
> counters expected to see and count the generated egress (ingress)
> traffic?


Yes.


>   Where would be the ingress / egress TAs be placed?


                 |      ^

          TG --->+      |
                 |      |
   egress TA <---+      |
                 v      |
               +-----------+
               | interface |
               +-----------+
                 |      ^
                 |      +---> TA
                 |      |
                 |      +<--- ingress TG
                 V      |
>
>> There are many devices that provide the network administrator with the option of configuring such ingress traffic in order to test a network setup. That is why the ingress traffic generator feature is added.
>>
> OK. But in the model, is replcating all definitions the best way to
> describe this? Or would a simple attribute describing how a TG is
> attached to an interface be a simpler solution and perhaps also be
> more extensible? I am just asking questions about alternatives to
> consider, BMWG will eventually have to determine the answers.


Yes. Having this starting point the group can make changes in making 
this concept more extensible or go in the opposite direction and remove 
the ingress traffic generator and egress traffic analyzer.


/Vladimir


>
> /js
>