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

Thank Igor for sharing the slides. I've read through it.

DSAV can be realized either as a new protocol or as a new SAFI in BGP.
Actually we also think extending BGP may be easier for deployment
consideration.

In our current design, we mainly pay attention on two aspects. 

1) Where to send the SAV notification message? In our current design, each
AS sends the notification along the "real" data-plane forwarding path (AS
path).
2) How to improve the scalability of the protocol by sending as few
notification messages as possible? We use several ways to combine the
protocol messages, which will be described in our BoF meeting on Thursday.

Incentive and incremental deployment require more discussions.

Best,
Dan

-----邮件原件-----
发件人: savnet-bounces@ietf.org <savnet-bounces@ietf.org> 代表 Lubashev,
Igor
发送时间: 2022年3月22日 12:15
收件人: savnet@ietf.org
主题: [savnet] A variation of DSAV as a BGP extension

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-in
gress-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