Update description for forwarding-viable #1032
Conversation
Add more clarity/rules for the forwarding-viable leaf and how an implementation should implement it.
|
No major YANG version changes in commit 856d272 |
Co-authored-by: rszarecki <46606165+rszarecki@users.noreply.github.com>
Co-authored-by: rszarecki <46606165+rszarecki@users.noreply.github.com>
| 3. L3 packets, control-plane as well as data-plane must be received | ||
| but not transmitted on such ports/bundles. By doing so, expectation | ||
| is that the other end of the connection ceases to use its respective | ||
| ports for transmit and receive when either the dead-timer or the | ||
| hold-down timer of its L3 protocol expires. |
There was a problem hiding this comment.
We should define what the expectation is for received L3 packets. I would guess the device is supposed to forward L3 packets, right? If yes, then stating something like the following might make this more clear?
- Received L3 packets should be evaluated by the data plane as usual. For example, when a dataplane packet is received, a lookup should be performed and the packet forwarded as usual. If an L3 control plane packet is received, it should be processed as usual.
There was a problem hiding this comment.
updated as per the internal doc, ptal.
There was a problem hiding this comment.
Hi Sach, this statement appears tailored for a protocol like IS-IS. The peer does not have to stop sending traffic to this device on the non-viable ports based on a timeout even if all the trunk members are not-viable. So, can we modify the statement to talk only about DUT and not enforce expectations on the peer? Specifically,
- Stop L3 transmit for both control and data-plane packets.
- L3 forwarding should work as usual on Rx without any timeout considerations. The peer can choose to continue sending this packets here indefinitely.
If you prefer, you can call out IS-IS as an example, where the timeout will happen.
There was a problem hiding this comment.
@nachikethas I have updated rule#3 to include other use cases, ptal
Co-authored-by: Darren Loher <dloher@google.com>
Co-authored-by: Darren Loher <dloher@google.com>
Co-authored-by: Darren Loher <dloher@google.com>
|
/gcbrun |
Co-authored-by: Darren Loher <dloher@google.com>
|
/gcbrun |
|
/gcbrun |
1 similar comment
|
/gcbrun |
|
/gcbrun |
…it. (openconfig#1032) * Update openconfig-if-sdn-ext.yang Clarify the forwarding-viable leaf and how an implementation should implement it. --------- Co-authored-by: rszarecki <46606165+rszarecki@users.noreply.github.com> Co-authored-by: Darren Loher <dloher@google.com>
Add more clarity/rules for the forwarding-viable leaf.
a. This requirement can be easily be achieved by an implementation if they follow the rule that, when a port/bundle is set to forwarding-viable=false, do not transmit L3 packets. This is true for both control-plane or data-plane packets. As a result, it would be a graceful transition for L3 traffic on that connection because, the other end of the connection will have its L3 protocol's dead-interval/hold-down timer expired leading for it to migrate away from the connection eventually.
I feel minimum-link calculation for aggregate bundle should be ignored for member ports whose forwarding-viable=false. Minimum-Links add unnecessary complications on the controller end. Also, that will result in an implementation to disable a bundle if the min-links requirement is not met and that is not the expectation. Expectation is that, the implementation must continue to Receive and Transmit L2 and only Receive L3 packets on such ports.
Finally, in order to remove confusions around IS-IS, the pull calls out that IS-IS should be treated as L3 protocols from this leaf's perspective.
More details in go/forwarding_viable_expected_behavior