During email discussion in 2023, there were worries that placing a SNAC stub router in a network (with its default configurations) would disturb / harm the existing network / AIL. For example due to the advertising of extra prefixes, or advertising particular (deviating?) values of bits, routes or time-durations in the RA.
One proposed solution was to provide a taxonomy (e.g. an appendix) that explains which particular topologies/configurations a SNAC stub router can work, and in which ones it doesn't work, and in which ones it can cause malfunctions (if any).
Some examples:
stub router doesn't work in a network that has RA-guard
in a network without RA guard, and where no suitable prefix is advertised on AIL, stub router can "disrupt" by advertising its ULA prefix. In this case we assume the ULA prefix is not intended by the admin. (Maybe the admin and/or network users should know better here, but anyhow it's a possibility.)
Having a better overview of success/fail cases also helps reviewers of the document to judge the risk.
darrendukes
commented
1 month ago
During email discussion in 2023, there were worries that placing a SNAC stub router in a network (with its default configurations) would disturb / harm the existing network / AIL. For example due to the advertising of extra prefixes, or advertising particular (deviating?) values of bits, routes or time-durations in the RA.
One proposed solution was to provide a taxonomy (e.g. an appendix) that explains which particular topologies/configurations a SNAC stub router can work, and in which ones it doesn't work, and in which ones it can cause malfunctions (if any).
Some examples:
Having a better overview of success/fail cases also helps reviewers of the document to judge the risk.
FYI here's a pointer to one of the messages in the thread of 2023 that summarizes some cases and how it could be documented: https://mailarchive.ietf.org/arch/msg/snac/q5hZdvzX_s4iCjoKjgg2B0eD8MQ/