Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update description for forwarding-viable #1032

Merged
merged 27 commits into from
Feb 22, 2024
Merged
Changes from 10 commits
Commits
Show all changes
27 commits
Select commit Hold shift + click to select a range
4da5f50
Update openconfig-if-sdn-ext.yang
sachendras Jan 5, 2024
f088fa2
Update openconfig-if-sdn-ext.yang
sachendras Jan 5, 2024
5f89788
Update openconfig-if-sdn-ext.yang
sachendras Jan 5, 2024
6bc879b
Update openconfig-if-sdn-ext.yang
sachendras Jan 5, 2024
f4099cf
Update openconfig-if-sdn-ext.yang
sachendras Jan 5, 2024
9026779
Update openconfig-if-sdn-ext.yang
sachendras Jan 7, 2024
d2a6ac2
Update openconfig-if-sdn-ext.yang
sachendras Jan 16, 2024
634c496
Update openconfig-if-sdn-ext.yang
sachendras Jan 16, 2024
7e01727
Merge branch 'master' into patch-3
sachendras Jan 16, 2024
7e7c400
Update release/models/interfaces/openconfig-if-sdn-ext.yang
sachendras Jan 17, 2024
2101a8d
Update release/models/interfaces/openconfig-if-sdn-ext.yang
sachendras Jan 17, 2024
156d0a5
Merge branch 'master' into patch-3
sachendras Feb 3, 2024
bad52da
Update openconfig-if-sdn-ext.yang
sachendras Feb 3, 2024
e65449a
Update openconfig-if-sdn-ext.yang
sachendras Feb 3, 2024
208eac1
Update release/models/interfaces/openconfig-if-sdn-ext.yang
sachendras Feb 3, 2024
9a2b1b3
Update openconfig-if-sdn-ext.yang
sachendras Feb 3, 2024
0f1575a
Update release/models/interfaces/openconfig-if-sdn-ext.yang
sachendras Feb 12, 2024
367f4a7
Update release/models/interfaces/openconfig-if-sdn-ext.yang
sachendras Feb 12, 2024
097052f
Update openconfig-if-sdn-ext.yang
sachendras Feb 12, 2024
846cee7
Update openconfig-if-sdn-ext.yang
sachendras Feb 12, 2024
422f81e
Merge branch 'master' into patch-3
sachendras Feb 13, 2024
2d5eb06
Update openconfig-if-sdn-ext.yang
sachendras Feb 13, 2024
0679609
Update openconfig-if-sdn-ext.yang
sachendras Feb 13, 2024
30f5332
Update release/models/interfaces/openconfig-if-sdn-ext.yang
sachendras Feb 21, 2024
1f577dd
Merge branch 'master' into patch-3
sachendras Feb 21, 2024
af90d27
Update openconfig-if-sdn-ext.yang
sachendras Feb 21, 2024
856d272
Update openconfig-if-sdn-ext.yang
sachendras Feb 21, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 20 additions & 5 deletions release/models/interfaces/openconfig-if-sdn-ext.yang
Original file line number Diff line number Diff line change
Expand Up @@ -47,11 +47,26 @@ module openconfig-if-sdn-ext {
This is used by an external programming entity to disable an interface
(usually part of an aggregate) for the purposes of forwarding
traffic. This allows a logical aggregate to continue to be
used with partial capacity, for example. Note that setting
`forwarding-viable = false` is not equivalent to
administratively disabling the interface -- in particular, the
interface is expected to participate in L2 protocols such as
LLDP or LACP even if it blocked from forwarding traffic.";
used with partial capacity. Setting `forwarding-viable = false` is not
equivalent to administratively disabling the interface.
Some rules to follow when a port/bundle is set for
Forwarding-viable=False:
1. Given that L2 protocols like LACP should be allowed to be
transmitted and received on such ports, a device mustn't consider
such ports in the calculation for minimum number of links required
for an aggregate bundle when such a configuration exists on the box.
Hence, the device mustn't disable the bundle because the minimum
number of member links requirement is not met for the bundle.
2. L2 protocols like LLDP, LACP must be allowed for transmit and
receive on such ports/bundles, IS-IS should be handled as per the
requirements for L3 packets below.
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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

  1. 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated as per the internal doc, ptal.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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,

  1. Stop L3 transmit for both control and data-plane packets.
  2. 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nachikethas I have updated rule#3 to include other use cases, ptal

4. An implementation should follow rule#3 even when the subject
port/bundle is the last resort of communication for the device.";
}
}

Expand Down
Loading