Honestly I am not sure if adding a new BGP MESSAGE will provide sufficient separation from BGP.
My take is that if existing RFC8955 does not provide a sufficient placeholder to propagate SAV data it should be transported outside of BGP entirely. Best, R. On Fri, May 6, 2022 at 2:23 PM <[email protected]> wrote: > > > "When the next hop to a destination node changes, the node will > > generate a triggered notification message. The triggered notification > > message will update SAV tables and SAV graphs in nodes along the new > > path. > > IMHO -- if you're going to put more information into BGP, do so as a new > message type, rather than as yet another AF ... BGP is already heavily > overloaded. Anything that adds to the churn of updates/etc. in BGP could > potentially degrade the entire routing system. If you're using BGP merely > as transport, add a new message type so the code and functionality can be > largely separated from existing BGP mechanisms. > > > " Just like packet loss from temporal loop during routing update cannot > > be completely avoided." > > In link-state protocols this is true. In path-vector protocols (like BGP) > and distance-vector protocols, you generally end up temporarily dropping > traffic rather than looping it during convergence events. > > Note that if you're relying on BGP, there are several known conditions > where BGP will not converge--ever--and will experience serious churn. This > is bound to happen with protocols that manage multiple metrics; all such > protocols will be multi-stable in some way or another. During these > "non-convergence events," you might well experience both dropping and > looping traffic. > > /r > > -- > savnet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/savnet >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
