Move bridged TC off the node NIC so the DUT can own its qdisc

[Jafaral]

• Host-to-switch delay / rate / loss are applied on the switch, not the node NIC, so the DUT keeps its root qdisc.
• Switch to: N is traffic toward that node (node RX, switch egress). Switch from: N is traffic from that node (node TX, IFB on switch ingress). Use two entries for both directions.
• A node’s own delay still means that node’s TX (same pipe as from:). Network-root constraints still default to to: (RX). P2P is unchanged; warn if TC stays on the node.

Example Config

networks:
  - name: wan1
    connections:
      - to: r1
        delay: 2500
        rate: { rate: "15M", burst: 16384, limit: 131072 }
      - from: r1
        delay: 2500
        rate: { rate: "15M", burst: 16384, limit: 131072 }

[liambrady]

I like your changes to TC with the usage of IFBs. I think we need to revisit the to/from config syntax before that portion gets merged, though.

[liambrady]

Why does the usage of _tc_constraints() differ in the host-to-host and host-to-switch cases? Is merging required only in host-to-switch case?

[liambrady]

Never mind. I see that the behavior is corrected in the next commit. It is probably worth cleaning this up to ensure the history clean.

[liambrady]

While I like the idea of configuring egress/ingress link metrics from the same network, I don't think that the definition of a new from leaf is the way to go. Specifically, I would like to strictly adhere to standard YANG for new config, however, your usage of to and from as mutually exclusive key values cannot (to my knowledge) be modelled in YANG.

Furthermore, I don't see how the from can be extended to the config of ingress TC metrics for the typical node connections (which would be a suitable follow up feature). The presence of further config (e.g. hostintf, physical, ip, etc.) wouldn't quite make sense in the from context. (e.g. Why would I be configuring node A's interface from the context of node B?).

I think it makes more sense to wrap the TC metrics in new transmit/receive containers, to specify whether the metrics apply to local egress or ingress traffic. That would make both the direction of the rules clear and prevent conflicts with the usage of to as a key. (Note: the usage of the current TC metrics without the transmit/receive container would continue to have to be supported but should be labelled as deprecated under this approach.)

For example, my vision is:

|  |  +--rw connections* [to]
|  |     +--rw to                    string
|  |     +--rw name?                 string
|  |     +--rw remote-name?          string
|  |     +--rw transmit
|  |     | +--rw delay?                uint64
|  |     | +--rw jitter?               uint64
|  |     | +--rw jitter-correlation?   decimal64
|  |     | +--rw loss?                 uint64
|  |     | +--rw loss-correlation?     decimal64
|  |     | +--rw rate
|  |     |    +--rw rate?    number64
|  |     |    +--rw limit?   number64
|  |     |    +--rw burst?   number64
|  |     +--rw receive
|  |       +--rw delay?                uint64
|  |       +--rw jitter?               uint64
|  |       +--rw jitter-correlation?   decimal64
|  |       +--rw loss?                 uint64
|  |       +--rw loss-correlation?     decimal64
|  |       +--rw rate
|  |          +--rw rate?    number64
|  |          +--rw limit?   number64
|  |          +--rw burst?   number64