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

"liumingxing (E)" <liumingxing7@huawei.com> Tue, 12 December 2023 09:42 UTC

From: "liumingxing (E)" <liumingxing7@huawei.com>
To: Kotikalapudi Sriram <sriram.ietf@gmail.com>
CC: "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: [Sidrops] I-D Action: draft-ietf-sidrops-bar-sav-02.txt
Thread-Index: AQHaK2IcQnYFx0/aPESU1qQf45/yPLClYing
Date: Tue, 12 Dec 2023 09:41:54 +0000
Message-ID: <87c2fe2ef538498188af590702cccde4@huawei.com>
References: <CAKqPU27msOvsidHepzWwL_ToXVOcsjZp8d=ozBwxdY-EEEosWQ@mail.gmail.com>
In-Reply-To: <CAKqPU27msOvsidHepzWwL_ToXVOcsjZp8d=ozBwxdY-EEEosWQ@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
Content-Type: multipart/related; boundary="_004_87c2fe2ef538498188af590702cccde4huaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/wj6mMOD521ADgbv7fB-J-YuyPho>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-bar-sav-02.txt
Precedence: list

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.
[cid:image001.png@01DA2D22.7D688230]

I think this scenario should be reasonable.

Best,
Mingxing Liu

From: Kotikalapudi Sriram <sriram.ietf@gmail.com>
Sent: Sunday, December 10, 2023 8:12 PM
To: liumingxing (E) <liumingxing7@huawei.com>
Cc: sidrops@ietf.org; draft-ietf-sidrops-bar-sav@ietf.org
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)" <liumingxing7@huawei.com<mailto:liumingxing7@huawei.com>>

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.

Attachment: image001.png

[Sidrops] I-D Action: draft-ietf-sidrops-bar-sav-… internet-drafts
Re: [Sidrops] I-D Action: draft-ietf-sidrops-bar-… liumingxing (E)
Re: [Sidrops] I-D Action: draft-ietf-sidrops-bar-… Kotikalapudi Sriram
Re: [Sidrops] I-D Action: draft-ietf-sidrops-bar-… liumingxing (E)
Re: [Sidrops] I-D Action: draft-ietf-sidrops-bar-… Kotikalapudi Sriram

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

Attachment: image001.png