Re: [savnet] A variation of DSAV as a BGP extension

Very interesting, thanks Igor!

Jari

> On 22. Mar 2022, at 5.15, Lubashev, Igor <ilubashe=40akamai.com@dmarc.ietf.org> wrote:
> 
> I am glad to see some renewed attention paid to SAV.
> 
> Here is a quick proposal I've made on the topic @ IETF-101.
> https://datatracker.ietf.org/meeting/101/materials/slides-101-rtgwg-sessb-ingress-filtering-for-asymmetric-routing-01
> 
> The quick summary of the above:
> 
> 1. We have a problem today, because we use the same BGP reachability advertisements for two separate purposes: advertising reachability and SAV.
> 
> 2. The proposal is a creation of a new "SAV Allow" SAFI. Advertisements with "SAV Allow" SAFI are never used for forwarding and can only be used for SAV.
> 2a. The advertisements are secured against spoofing by all the usual means that BGP advertisements are secured.
> 2b. "SAV Allow" SAFI advertisements are transitive, unless a route (a regular or "SAV Allow") with the same or a shorter prefix is advertised to a peer. This is because the advertised route already serves "SAV Allow" purpose.
> 2c. Only routers that support "SAV Allow" SAFI get these advertisements.
> 
> 3. The upside is that this seems like it would solve SAV problem and use just a simple BGP extension for it. The downside is that incremental deployment can only start with the routers that are originating the routes -- upgrading an intermediary router does no good, unless all routers between the path originator and itself have been upgraded.
> 3a. Compared to RFC8704, RFC8704 does not solve SAV completely, but it allows for a much looser increment deployment to be useful.
> 
> Happy to discuss this more, of course.
> 
> - Igor
> 
> -- 
> savnet mailing list
> savnet@ietf.org
> https://www.ietf.org/mailman/listinfo/savnet