Conversation
Signed-off-by: Jing Zhang <zhangjing@microsoft.com>
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
lolyu
left a comment
lolyu
left a comment
There was a problem hiding this comment.
Review: #2403
Clear, conservative, well-structured HLD. I read the full document and verified its load-bearing claims against source rather than taking them on faith:
- ✅ The
MUX_CABLEschema already carriesserver_ipv6/soc_ipv6(confirmed in sonic-swssmuxorch.cpp), so "no new Config DB fields" holds. - ✅ Loopback2 = prober source / Loopback3 = GUID source matches the actual linkmgrd source (
MuxManager.h,LinkProberBase.cpp,DbInterface.cpp) and the companion PR #344. - ✅ Companion linkmgrd #344 exists, same author, and its IPv4-first/IPv6-fallback logic matches this doc's Component Requirements.
The design accurately describes the feature its companion PRs implement. Nothing blocks. Two substantive suggestions inline (independent server-vs-soc family selection; missing-loopback error handling); the rest is polish.
One structural point that doesn't anchor to a single line — the server-vs-soc family cross-product. server_* (linkmgrd probing) and soc_* (ycabled gRPC) are selected independently per-field, so a port with server_ipv4 present but only soc_ipv6 would probe over IPv4 while doing gRPC over IPv6. Is that mixed-family case intended and supported? The Compatibility matrix only varies the soc_* axis and doesn't show the server×soc cross-product. Recommend either stating explicitly that family is selected independently per endpoint (and confirming mixed is valid), or adding a constraint that a port's server and soc endpoints must share a family. That's the one genuine spec gap — see inline #1.
Minor (polish): the <ul><li> HTML inside the Component Requirements table renders on GitHub but may not on the SONiC doc site's static generator or other markdown processors — worth checking whether the repo's other HLDs use raw HTML in tables or prefer sub-sections.
Signed-off-by: Jing Zhang <zhangjing@microsoft.com>
|
/azp run |
|
No pipelines are associated with this pull request. |
|
Hi @lolyu - addressed the comment, please help review again |
3 participants
[dualtor]: Add IPv6 only active-active control plane design
Add a SONiC-level design document for IPv6-only active-active DualToR control-plane support. The document describes the intended behavior for config generation, linkmgrd, ycabled, compatibility, error handling, and sonic-mgmt validation without implementation-specific details.
The design is intentionally conservative: existing IPv4-only and dual-stack deployments continue to use IPv4, and IPv6 is selected only when the corresponding IPv4 field is missing.
sign-off: Jing Zhang zhangjing@microsoft.com