There are already >60 BGP SAFI being specified: https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml
Many people told me that New SAFI would requires changes to RR. But to use RR to relay SD-WAN end point properties to the authorized peers, RR has to be enhanced. For normal IPsec, edge nodes have to be provisioned with policies on which peers the edge nodes can establish IPsec SA. For large SD-WAN deployment, it becomes N square problem, as Ali described at the BESS session today. It scales much better if the SD-WAN CPE offload the Security Association Policy work to RR, by just advertising its properties to its corresponding RR: - RR can authenticate if the Peer is authorized to receive the Advertisement. - CPE and RR has to establish a secure channel first (such as TLS or DTLS) before CPE can propagate its end points properties to its RR - IPsec SA needs to re-key periodically, there will be many messages for the same tunnel, but with different IPsec SA subTLV. Having a new SAFI makes RR implementation so much cleaner & simpler. Really appreciate anyone can elaborate what are the problems to anticipate with new SD-WAN SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext ? Thank you Linda Dunbar
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
