Subject: [bmwg] Minutes from IETF-109 Session

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 6 Jan 2021 19:58:27 +0000

BMWG,

Minutes of our virtual time together (in the middle of the night for me) are now available [0].

Thanks again to Bill Cerveny for taking the minutes in a meeting with many active discussions and action items (some of the items are for all of us)!

I hope your new year is going well so far!

Al
bmwg co-chair

[0] https://datatracker.ietf.org/meeting/109/materials/minutes-109-bmwg-00

---

From: tom petch <[email-masked]>
Date: Fri, 8 Jan 2021 10:21:24 +0000

From: bmwg <[email-masked]> on behalf of MORTON, ALFRED C (AL) <[email-masked]>
Sent: 06 January 2021 19:58

BMWG,

<tp>

'  Proposals:

    A YANG Data Model for Network Interconnect Tester Management
    https://tools.ietf.org/html/draft-vassilev-bmwg-network-interconnect-tester-04
    status:
        Draft updated Sept 9, added mechanism for real time synchronization of traffic generation
        open-source/hardware implementation of generator/analyzer at the hackathon.

No one raised hand that they have read above draft. '

That is because the word 'yang' does not appear in the title!  No matter, 

NMDA support or lack thereof needs a mention in the Introduction

There are about twenty Normative References missing such as 

IEEE 802-2014
IEEE 802.1Q
IEEE 802.1p
RFC6991
RFC8343
RFC7224

while all features should have a YANG Reference clause according to a recent YANG doctor review - I agree!

Why is data type 'string'?  Why not binary or hex-string?  I note that 'burst-data' is couched in terms of octets

YANG 'augment' are usually constrained by 'when' clause. Here every YANG interface on the box will be augmented.

YANG prefix must be unique across the entire spectrum of IETF work and ideally beyond that as well.  I find 'ta' and 'tg' too brief and think that they should have another two or three characters. 't(raffic)' embraces a lot of concepts!

'The proposed model splits the design into 3 modules - 1) Traffic
   Generator module (TG), 2) Traffic Analyzer module (TA).  '
That would be one and two and ???

MAC-address implies, well MAC address only; seems a bit limiting or worth a mention in the Abstract/Introduction

'statistics' would be better IMHO in a container of their own for this application rather than alongside every other interface statistic.

vlan id has been defined by IEEE and it is different!

     when "ta:type = 'ta:ethernet'";
is fragile - derived from or self is a more robust concept

Security Considerations must conform to YANG Guidelines

What language is used for Appendix A.1?

Tom Petch

Al
bmwg co-chair

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

---

From: Vladimir Vassilev <[email-masked]>
Date: Tue, 12 Jan 2021 21:46:09 +0100

Hi Tom,

Thanks for keeping an eye on the draft.

On 08/01/2021 11.21, tom petch wrote:
> That is because the word 'yang' does not appear in the title!

What do you mean? The title is "A YANG Data Model for Network 
Interconnect Tester Management".

>   No matter,

There are a few counters defined under 
/if:interfaces-state/interface/statistics (which make the draft 
dependent on a deprecated container as of RFC8343). My intention is to 
remove them in the next version and copy the RFC8407 "NMDA support" 
boilerplate text.

> There are about twenty Normative References missing such as

OK. These 6 references will be added to the next version.

> while all features should have a YANG Reference clause according to a recent YANG doctor review - I agree!

OK but what would be the reference for the "multi-stream" feature for 
example or the rest of the features specified in the draft that do not 
need external reference?

> Why is data type 'string'?  Why not binary or hex-string?

Both 'binary' and 'hex-string' are alternatives that can work. With 
binary one looses the human readable representation on the wire and the 
ability to edit the configuration without specialized tools for a 1/3 
compression gain. While hex-string adds 1/3 extra data in form of 
columns separating each byte "01:02:03" which works fine for MAC 
addresses but is standing a bit in the way for longer strings - frame 
header specification etc.

can make this change once at a more mature point so I do not need to 
change all the tools (here an example of a tool generating an RFC2544 
testframe that can be directly reused with the configuration of the 
generator):

  ./traffic-generator-make-testframe --frame-size=64 
--dst-mac-address="12:34:56:78:9A:BC" 
--src-mac-address="DE:F0:12:34:56:78" --src-ipv4-address="192.0.2.1" 
--ipv4-ttl=10 --src-ipv4-udp-port=49184 --dst-ipv4-address="192.0.2.2" 
--dst-ipv4-udp-port=7
  123456789ABCDEF01234567808004500002E000000000A112CBCC0000201C0000202C0200007001A0000000102030405060708090A0B0C0D0E0F10119CD50E0F

> I note that 'burst-data' is couched in terms of octets

Correct. The interframe-,interburst- and interstream- gaps are expressed 
in octets.

> YANG 'augment' are usually constrained by 'when' clause. Here every YANG interface on the box will be augmented.

IMO this is the case when the augment only applies to a certain set of 
interface types. However in the case of a generator/analyzer modules 
that aim to be universal and applicable for all interfaces that send and 
receive packets I do not see how we can do this.

> YANG prefix must be unique across the entire spectrum of IETF work and ideally beyond that as well.  I find 'ta' and 'tg' too brief and think that they should have another two or three characters.…

While I am OK with changing the prefixes to a different/longer strings I 
think we can do it later in the process. For me the cost will be going 
through some working code in order to modify these particular bits. 
Formally there is no requirement in RFC8407 for avoiding too short prefixes.

> That would be one and two and ???

I will fix that.

> MAC-address implies, well MAC address only; seems a bit limiting or worth a mention in the Abstract/Introduction

I am lost here. Do you refer to the ethernet feature which enables 
specification of parameters like src-mac-address, dst-mac-address 
vlan-id etc.?

> 'statistics' would be better IMHO in a container of their own for this application rather than alongside every other interface statistic.

The original argument for placing some of the statistic counter 
definitions ( e.g. tg:generated-pkts, tg:generated-octets) in the same 
container as the rest of the generic interface counters 
{if:out-unicast-pkts, if:out-broadcast-pkts, if:out-multicast-pkts} was 
the strict synchronization requirements for the counters of such 
instruments and  some anticipated complications associated with the 
synchronization of separate containers.

I would like to keep this point open for discussion for now.

> vlan id has been defined by IEEE and it is different!

Correct. This is not a precedent for IETF (yang:mac-address is also 
different). That said I am considering removing the VLAN fields from the 
traffic-generator module all together. I find myself using the raw 
frame-data leaf for specifying advanced testframe headers (that includes 
VLAN tagged frames, alternative ipv4(udp) and ipv6(udp) header options).

> is fragile - derived from or self is a more robust concepthea

OK. I can't see any disadvantage in that.

> Security Considerations must conform to YANG GuidelinOK.

OK. I will add the RFC8407 boilerplate text and a few lines informing 
the reader that a stateless traffic generator is controlled with the 
model and the potential risks when used outside of test environments.

> her

This should be considered pseudo code but is actually python which uses 
command line syntax (based on the YANG modules) that expands to NETCONF 
protocol PDUs to orchestrate the test network in the example. The 
intention is to demonstrate how the generator can be programmed along 
with the DUTs.

/Vladimir

---

From: tom petch <[email-masked]>
Date: Wed, 13 Jan 2021 09:58:03 +0000

From: Vladimir Vassilev <[email-masked]>
Sent: 12 January 2021 20:46

<tp>
inline which gets a bit messy:-(

Hi Tom,

<tp>
sloppy wording on my part - I meant the filename which is what shows up more readily in the I-D announcements; I used to be able to search the body of the announcements but my ISP stopped that   Not worth changing now I know.

OK. These 6 references will be added to the next version.
<tp>
I think that there are more than that for example from the required Security Guidelines:-)

<tp>
Well when the YANG module is floating free in cyberspace, then there is nothing else, no draft, no RFC so if the I-D is the best reference, then that should be the reference in the form of RFC XXXX

<tp>
ok

<tp>
just a followup to my comment about string/hexstring so no need to change anything

<tp>
right but below you do seem to constrain the use to Ethernet so it is not all interfaces - there are other protocols in the world!  I would add a comment to the effect that all interfaces are augmented so it is clear that this is intentional

I will fix that.

<tp>
And section 7 which has loads of 'three's

<tp>
I am unclear whether or not this applies to interfaces which run a protocol other than Ethernet, of which there are hundreds.  I think that this needs spelling out more clearly as part of the applicability

<tp>
ok

<tp>
I recall an AD objecting to the redefinition of this term, especially as the IETF definition lost some of the semantics which the IEEE had taken care to specify - I have notes on it somewhere, I think that it was to do with the valid values of the range

<tp>
again this comes from a YANG Doctor review of another I-D

<tp>
Worth spelling out, the language that is,  as Python or pseudo-python or ..  Examples do get copied into running code by those who know no better.  

Tom Petch

/Vladimir