Conversation
Signed-off-by: philo <philo@micasnetworks.com>
Signed-off-by: philo <philo@micasnetworks.com>
Signed-off-by: philo <philo@micasnetworks.com>
| IP multicast is a network communication technique that allows a single sender to send packets to multiple destinations without having to send packets separately for each destination. This method greatly saves bandwidth resources and improves the efficiency of the network. For different Multicast group members, Multicast service models can be divided into ASM(Any-Source multicast) and SSM(Source-Specific multicast) service models. To ensure efficient transmission of multicast data, IP multicast uses the RPF (Reverse Path Forwarding) mechanism. | ||
|
|
||
| Routers dynamically establish forwarding tables through protocols (such as IGMP, PIM, MSDP, etc.) and maintain a multicast forwarding table, recording the membership of the multicast group and the corresponding outbound interface. | ||
|
|
There was a problem hiding this comment.
Can you request a slot to review this HLD in Routing WG? FYI. @eddieruan-alibaba
Few questions from the community meeting today.
- Why didnt we explore fpmsyncd path for programming the multicast routes? we came to know pimd is directly programming the kernel, what if we have the bgp ipv4 multicast configuration, wont there be any MRTM (part of Zebra) to consolidate multicast routes from different protocols(e.g pimd, bgp and static..etc)? we need to discuss with FRR folks and decide.
There was a problem hiding this comment.
Can you describe your use case as well?
I am second on @venkatmahalingam 's comment. It is better to explore fpmsyncd approach to program mroutes directly from pimd instead of via Linux kernel for the following two reasons.
- Scale and performance
- feature velocity
Both of these two considerations are related to your use case and roadmap.
There was a problem hiding this comment.
No problem, next we will try to request Routing WG review of the HLD. As for choosing between fpmsyncd or kernel, both solutions have their own significant advantages, so it's hard for me to decide :) Let's leave this discussion for after communicating with Routing WG and see what their feedback is
| In ECMP routing, there is already a very elegant nexthop group design and implementation, so for IP multicast routing reference this design uses mgmanager to manage the ipmc group and rpf group. | ||
|
|
||
| The following diagram summarizes the key structure of IPMC functionality in SONiC: | ||
|
|
There was a problem hiding this comment.
The Linux kernel notifies multicast interface creation or deletion using RTM_NEWNETCONF and RTM_DELNETCONF messages.
Given this, can the same path used for mroute updates also be applied for multicast-enabled interfaces?
There was a problem hiding this comment.
The Linux kernel notifies multicast interface creation or deletion using RTM_NEWNETCONF and RTM_DELNETCONF messages. Given this, can the same path used for mroute updates also be applied for multicast-enabled interfaces?
Since the current interface configurations are all passed through config DB, separating multicast-enabled to be read by the kernel doesn't seem to be necessary
| ```text | ||
| RTM_NEWROUTE | ||
| RTM_DELROUTE | ||
| ``` |
There was a problem hiding this comment.
Pls update netlink messages used for multicast enabled interfaces.
|
@philo-micas can you please help to add the code PRs by referring to #806 ? Thanks. |
The code PR is not ready yet |
|
Community review recording on 9/17/2024. PR is not merged and move to backlog. |
Signed-off-by: philo <philo@micasnetworks.com>
|
/azp run |
|
No pipelines are associated with this pull request. |
Ignores all multicast protocol types
|
/azp run |
|
No pipelines are associated with this pull request. |
The HLD introduce IPMC dataplane implement in SONiC, include database change, Linux Multicast route listening and handling, orchagent ipmc support.