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

Multiple Spanning Tree Protocol (MSTP) HLD #1298

Closed
wants to merge 15 commits into from

Conversation

hamnarauf
Copy link
Collaborator

@hamnarauf hamnarauf commented Mar 21, 2023

This document describes the design details for IEEE 802.1s - Multiple Spanning Tree Protocol (MSTP) support in SONiC.

@hamnarauf hamnarauf force-pushed the mstp_hld branch 3 times, most recently from 5321c1e to 7d5eb3e Compare March 22, 2023 07:25
@ridahanif96
Copy link
Collaborator

@zhangyanzhao can you please assign this HLD to @hamnarauf Thanks!

@adyeung adyeung assigned hamnarauf and unassigned ridahanif96 Jun 21, 2023
@zhangyanzhao
Copy link
Collaborator

||SAI_SWITCH_ATTR_MAX_STP_INSTANCE|

## New SAI Attributes
MSTP design requires one new attribute `SAI_HOSTIF_TRAP_TYPE_MSTP` for control trap packets which will be defined in saihostif.h.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Please explain why SAI_HOSTIF_TRAP_TYPE_STP is not sufficient. The DMAC and LLC fields are identical for STP and MSTP.  Creating separate trap types for STP and MSTP would required the hardware to parse/match the BPDU protocol identifier.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We can discuss this in coming SAI meeting. For reference, please see this PR Add hostif trap for MSTP

@ridahanif96
Copy link
Collaborator

ridahanif96 commented Jul 11, 2023

@lguohan , Please find following are unmerged PRs of PVST, that needs to merged for MSTP:
SWSS: sonic-net/sonic-swss#1058
Utilities: sonic-net/sonic-utilities#648
Buildimage: sonic-net/sonic-buildimage#3463

@ridahanif96
Copy link
Collaborator

@zhangyanzhao pls add @wajahatrazi as assignee for this HLD.

@zhangyanzhao
Copy link
Collaborator

@hamnarauf can you please help to add the code PR list in this HLD? Thanks.

@ridahanif96
Copy link
Collaborator

ridahanif96 commented Oct 7, 2023

@hamnarauf can you please help to add the code PR list in this HLD? Thanks.

Hi @zhangyanzhao , Hamna is no longer assignee on this feature. Please consider @Wajahat as assignee on this from now onward. We are working on MSTP code and waiting for @adyeung help in unmereged code PR of PVST. Thanks!

@zhangyanzhao
Copy link
Collaborator

@ridahanif96 can you please help to add the code PRs to this HLD by referring to #806 ? Thanks!

@ridahanif96
Copy link
Collaborator

@divyachandralekha Hi Divya,can you please review this HLD!

The table holds the state of a port i.e forwarding, learning, blocking with respect to each instance.
#### STP_VLAN_INSTANCE_TABLE
The table holds the VLAN to instance mapping.
#### STP_FASTAGEING_FLUSH_TABLE

Choose a reason for hiding this comment

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

A per-VLAN flush may trigger a lot of churn, especially considering the possibility of 4K VLANs mapped to one MST instance. Here, only one flush is necessary. You may need to consider optimisation in this scenario.

Copy link
Collaborator

@ridahanif96 ridahanif96 Mar 21, 2024

Choose a reason for hiding this comment

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

Yes, it might be cumber-sum to flush for each VLAN. We will consider one FDB Flush for every MSTI for optimization.

# Sequence Diagrams
## MSTP global enable

Only the VLANs that are currently present will be mapped to IST instance. A VLAN cannot be mapped to an instance if it has not been created yet.

Choose a reason for hiding this comment

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

When we have this limitation , managing the IST configuration becomes more complex. Especially in environments where VLANs are frequently added or removed. Administrators must continuously update the IST configuration to reflect changes in VLAN membership.
Creating a VLAN and then adding it to the Internal Spanning Tree (IST) configuration can potentially create convergence churn and disturb the existing network.
You may need to consider pre-configuring VLAN-to-instance mapping before actually creating the VLAN.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Agreed, we will consider pre-configuring VLAN-to instance mapping to avoid convergence churn.

Below commands allow configuring on region basis:

- **config spanning_tree region name \<region-name\>**
- Edit the name of region

Choose a reason for hiding this comment

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

Do you support empty region name ?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Name is an empty string it could have 0 value by default for region name

- **config spanning_tree instance (add|del) \<instance-id\>**
- Creation or deletion of an instance.
- instance-id: Default: 0, range: 1-63
- Instance can not be deleted if VLAN(s) are associated with it.

Choose a reason for hiding this comment

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

What is the reason behind this restriction?

Copy link
Collaborator

Choose a reason for hiding this comment

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

The restriction here on an MSTP instance when VLANs are associated with it serves to prevent accidental deletions that could lead to network inconsistencies and loops in VLAN topologies. This approach aligns with industry standards followed by Cisco, Huawei, and SONiC, ensuring consistency and clarity for users familiar with these platforms. Additionally, in SONiC, an interface associated with a VLAN also prevents the deletion of that VLAN, maintaining the integrity of the network configuration.

@ridahanif96
Copy link
Collaborator

Hi @divyachandralekha , do you have more suggestions on the design? if no can you please help approve this PR. Also we can discuss offline for PVST code PRs and our workflows for bringing STP/PVST/MSTP to SONiC

@adyeung adyeung closed this Apr 3, 2024
@adyeung adyeung reopened this Apr 3, 2024
@adyeung
Copy link
Collaborator

adyeung commented Apr 3, 2024

@ridahanif96 The earlier PVST code PRs will be updated and reposted in the next community release

@ridahanif96
Copy link
Collaborator

@ridahanif96 The earlier PVST code PRs will be updated and reposted in the next community release

@adyeung thanks Adam!, till then it would be great if we also finalize this design and merge this.

@ridahanif96
Copy link
Collaborator

@rck-innovium Hi Ravi, can you please help review this design. As per suggestion earlier in SAI community we had updated SAI Modification for MSTP control packets.

@adyeung adyeung self-assigned this Apr 17, 2024
ridahanif96 and others added 2 commits April 25, 2024 16:47
Update CONFIG/APP DB and yang model
Copy link

linux-foundation-easycla bot commented May 6, 2024

CLA Signed

The committers listed above are authorized under a signed CLA.

2. Assigning VLAN to instance via SAI STP API and SAI VLAN API.
3. Creation of STP Port and assigning port state with respect to each instance via SAI STP API.
4. Flushing FDB entries via SAI FDB API.

Choose a reason for hiding this comment

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

BPDU guard functionality requires link-state control, maybe we need to add SAI api that control link state here as well.

Choose a reason for hiding this comment

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

PortOrch already has link state control SAI attributes. STP notifies OrchAgent of any link state changes, which are then managed accordingly.

- Configure an interface as a bpdu_guard.

Interface level CLI configurations of root guard, BPDU guard will also be supported for spanning-tree mode `mstp`.

Choose a reason for hiding this comment

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

I see STP can be enabled on "portchannel" as well, so im assuming we may need to add CLI restrictions to ensure that when STP is enabled on a portchannel, the portchannel group cannot be deleted/modified.

If thats true, please ensure its captured here or a different section of HLD

Choose a reason for hiding this comment

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

Design will handle Portchannel modification/deletion automatically , so we don't plan to add any restrictions to prevent these operation on a STP enabled PortChannel.

Responsible for all MST protocol related calculations. BPDUs are sent and received in STPd and states are updated accordingly.

### STPSync
A process running as a part of STPD. Responsible for updating all the MSTP states in APP DB.

Choose a reason for hiding this comment

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

Couple of questions here,

  1. is "stpSync" process forked within "STPd".
  2. Is "STPd" taken from a open-source implementation for instance https://github.com/sonic-net/sonic-stp ?

Assuming the answer to the above is 'yes', would be it cleaner to have "STPsync" implemented outside of "STPd" and then have IPCs to communicate port-states, fdb flush & link state events.

Doing this will ensure "STPd" repo has minimal integration changes and syncing it later to open-source repo would be easier.

Choose a reason for hiding this comment

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

stpsync is not a process. STPSync is a component integrated within STPd responsible for managing and updating all operational STP data to APP DB.

We will update the same in HLD.

### STPSync
A process running as a part of STPD. Responsible for updating all the MSTP states in APP DB.

The BPDU rx/tx, BPDU processing, handling of timers, handling of changes related to port or LAG using netlink events and STP port state sync to Linux Kernel will function the same as PVST.

Choose a reason for hiding this comment

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

If the port state programming fails, how to handle the use-case. Can you please provide your thought process on the same

Copy link
Collaborator

@ridahanif96 ridahanif96 Jun 11, 2024

Choose a reason for hiding this comment

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

if port state programming we will keep trying to set it until succeeds.

}
default 128;
description
"The manageable component of the Port Identifier,

Choose a reason for hiding this comment

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

Can you please add the information that priority values should be increments of 16 in the description?

Choose a reason for hiding this comment

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

We will update the HLD

- Specify configuring the port level priority for root bridge in seconds.
Default: 128, range 0-240
- **config spanning_tree mst cost \<cost-value\>**
- Specify configuring the port level priority for root bridge in seconds.

Choose a reason for hiding this comment

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

Does this description needs an update to match the command? And path cost configuration should be supported only per interface or global?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Path cost works for both cases per interface and global. These are two separate set of commands for each case.

- **config spanning_tree interface \<ifname\> bpdu_guard {enable|disable}**
- Configure an interface as a bpdu_guard.

- **config spanning_tree interface \<ifname\> guard {root|bpdu}**

Choose a reason for hiding this comment

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

Is this CLI command a condensed version of the above two seperate bpdu and root guard configuration commands?

Copy link
Collaborator

Choose a reason for hiding this comment

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

We will update HLD with reference to this point

@TafkaMax
Copy link

TafkaMax commented Jun 9, 2024

Is the plan to merge the code for both PVST and MSTP together for the community sonic or would one be merged before?

Copy link

@praveenraja1 praveenraja1 left a comment

Choose a reason for hiding this comment

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

Looks good

@ridahanif96
Copy link
Collaborator

Is the plan to merge the code for both PVST and MSTP together for the community sonic or would one be merged before?

No, As discussed in PENS WG , we will only provide MSTP for the community in this release ,we will not be looking into PVST code merged.

@ridahanif96
Copy link
Collaborator

@madhupalu , @praveenraja1 , @sutharsansr @adyeung @zhangyanzhao ,
As per our Discussion in PENS WG, New Updated Design is ready for review. Please consider Multiple Spanning Tree Protocol (MSTP) Updated HLD from onwards. Please help review the new design.

This PR will be closed to avoid confusion.

@adyeung adyeung closed this Aug 2, 2024
@adyeung
Copy link
Collaborator

adyeung commented Aug 2, 2024

Closing this PR, revised HLD in the following submission

#1761

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: DeferredForNextRelease
Development

Successfully merging this pull request may close these issues.

10 participants