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

[Kotikalapudi Sriram <[e-mail]>]

Sure, I agree that your scenario is useful to further highlight the benefit
of BAR-SAV (i.e., its complementary use of BGP, ASPA, and ROA data). We
will consider mentioning the scenario in the draft and will also plan to
include it in the BAR-SAV tutorial slides.

Thank you.

Sriram

On Tue, Dec 12, 2023 at 3:12 PM liumingxing (E) <[e-mail]>
wrote:

> Consider that aggregation occurs at the provider AS.
>
>
>
> As shown in the following figure, AS3 has enabled BAR-SAV. AS1 announce
> prefix p1 to AS2 and AS2 announce prefix p1 and p2 to AS4.
>
> AS4 may aggregate p1 and p2 and generate a shorter prefix p4 (p4 = p1+p2).
> If AS4 announce p4 to AS3 without AS_SET, AS3 do not know that a part of p4
> belongs to AS1.  ROA that contains p1 and AS1 can help AS3 generate an
> accurate allowlist.
>
>
>
> I think this scenario should be reasonable.
>
>
>
> Best,
>
> Mingxing Liu
>
>
>
> *From:* Kotikalapudi Sriram <[e-mail]>
> *Sent:* Sunday, December 10, 2023 8:12 PM
> *To:* liumingxing (E) <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [Sidrops] I-D Action: draft-ietf-sidrops-bar-sav-02.txt
>
>
>
> 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.
>
>