Re: [Sidrops] I-D Action: draft-ietf-sidrops-bar-sav-02.txt

[Kotikalapudi Sriram <[e-mail]>]

Hi Mingxing,

I think aggregation (without AS_SET) does not pose a problem for BAR-SAV.

Consider AS1 and AS2 announce p1/24 and p2/24, respectively, to their
transit provider AS3.

AS3 aggregates p1/24 and p2/24 with its own p3/23 and announces p/22
to its transit provider AS4.

(p1/24 + p2/24 + p3/23 = p/22)

In this case, AS4 will include p/22 in its SAV table (allow list) for
the customer interface

with AS3 (based on BGP updates alone).

There will be no improper block of addresses in p1/24 or p2/24 or
p3/23 (the aggregation components)

at AS4 in this scenario. Let me know if I am missing something?

Sriram

=================================================

From: "liumingxing (E)" <[e-mail]>

BGP route aggregation will lose the origin AS information of the
prefix. The as-set is configured by the operator and may not be
generated. As a result, An AS may receive such a prefix which is
advertised by the provider AS and contains the sub-prefix that has
been allocated to the customer AS. So, only BGP update and ASPA cannot
generate a complete allowlist on the customer interface. Only when all
customer ASes register all prefix in RKPI, BAR-SAV is accurate.
Therefore, the deployment of BAR-SAV should be a process that starts
at the edge of the Internet.

I suggest that section 5 should add the analysis of BGP route
aggregation and section 6.5 should add some related guidelines.