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

From: "MORTON JR., AL" <[email-masked]>
Date: Wed, 8 Sep 2021 13:35:34 +0000

BMWG:

A WG Adoption Call for the Internet-Draft on

      A YANG Data Model for Network Interconnect Tester Management
           draft-vassilev-bmwg-network-interconnect-tester-06

will be open from 8 September through 6 October, 2021.

Please weigh-in on this topic by providing:
 
+ whether or not you believe the working group should adopt this Internet-Draft 
as a work item, for eventual publication as an Informational RFC. 
+ your current comments on the draft from your adoption call review 
(recent comments on the list should be referenced).
+ whether or not you are willing to review new versions of the draft during 
development. 

Send your comments to this list @[email-masked]

A URL for this Internet-Draft is [0]

Al
bmwg co-chair

[0] https://datatracker.ietf.org/doc/html/draft-vassilev-bmwg-network-interconnect-tester-06.txt

---

From: tom petch <[email-masked]>
Date: Thu, 9 Sep 2021 10:05:01 +0000

From: bmwg <[email-masked]> on behalf of MORTON JR., AL <[email-masked]>
Sent: 08 September 2021 14:35

BMWG:

<tp>
Oppose

I commented in January and some of my comments have been addressed, some have not.

The one I regard as most significant is that this uses two character prefix for the YANG modules.  Prefix must be unique across the entire IETF, everything from every WG, everything not from a WG, so while brevity is attractive, I see them as belonging with modules that will be widely used, widely known - interfaces comes to mind. I do not see this in this category,

I have yet to see a YANG doctor approve of a two-character prefix but I have seen opposition.

The author's response was to do it later n the process, that it would mean changing code.  Well the later in the process the more code there will be to change, more work, more mistakes from anyone involved..

There are other glitches in the  YANG module but I see this as the one to fix before considering any other.

Tom Petch 

Al
bmwg co-chair

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

---

From: Vladimir Vassilev <[email-masked]>
Date: Fri, 10 Sep 2021 09:43:04 +0200

> I have yet to see a YANG doctor approve of a two-character prefix but I have seen opposition.

There is no problem to add longer prefixes. "tg:" -> "nttg:", "ta:" -> 
"ntta:" where "nt" stands for network test.

The intention with this draft is to provide "widely used, widely known" 
modules. The equivalent of ping and tcpdump functionality in YANG terms 
but also very deterministic and precise method for specification of test 
traffic for the dataplane. If the IETF and the authors manage to pull 
this off these modules will be the base modules augmented by vendors of 
network test equipment and very likely regular networking equipment will 
have implementation for verification and troubleshooting purposes.

There is reference code that implements RFC2544 as a simple python 
script using the model specified in the draft - 
https://github.com/vlvassilev/litenc/blob/master/tntapi/example/ietf-network-interconnect-tester/rfc2544.py 

and a reference device side implementation with open-source and 
open-hardware design  - 
https://www.hackster.io/lightside-instruments/network-programmability-kit-for-ultra96-07435c

significant part of this work was done at IETF Hackathon events.

/Vladimir

---

From: tom petch <[email-masked]>
Date: Fri, 10 Sep 2021 08:45:31 +0000

From: Vladimir Vassilev <[email-masked]>
Sent: 10 September 2021 08:43

<tp>

If there will be other BMWG YANG modules in the future, then there would be 
a case for grouping them together with a prefix that starts the same, something more generic than 'nt'.  'bmwg' is long IMHO and the 'wg' does not really belong there.  The best I could come up with would be 'bm' which did not seem very good so I did not mention it before.  WG like PIM and LDP have the advantage of us here.  The current list of prefix, some good, can be seen in iana under 'YANG Module Names'

Tom Petch

/Vladimir

---

From: Vladimir Vassilev <[email-masked]>
Date: Fri, 17 Sep 2021 10:01:05 +0200

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