[Sidrops] Re: Call for Adoption of draft-li-sidrops-bicone-sav-04

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

>Lancheng: Can we add these special prefixes (that would not be used as a source IP address) into the blocklist

It is not just the special purpose prefixes. Think about how you would add to your blocklist all the prefixes corresponding to the unallocated & unrouted (and allocated & unrouted) IPv6 address space. Relatively only a little IPv6 is allocated & routed currently. So, there may be a minimum on the order of 2^32 = 4 Billion unallocated/unrouted /32 IPv6 prefixes. Or, there may be a maximum on the order of 2^48 = 256 * Trillion unallocated/unrouted /48 IPv6 prefixes.  In any case, if one is able estimate and list them all (keep in mind it is quite dynamical), the number is many orders of magnitude larger compared to the number of prefixes in Loc-RIB (which is about a million at present).
>> So, in the end, it is an allowlist SAV (not blocklist). It is essentially the loose uRPF method with some prefixes removed. IMO, there is no concept of "blocklist" that can work as a SAV method.
>Lancheng: I do not think I understand this. According to the definition in [1], I think bicone sav uses a blocklist instead of an allowlist.
Does the above help in understanding?
Sriram

From: Lancheng <[e-mail]>
Sent: Thursday, September 19, 2024 1:53 AM
To: Sriram, Kotikalapudi (Fed) <[e-mail]>
Cc: Lubashev, Igor <[e-mail]>; IETF SIDRops <[e-mail]>; [e-mail]
Subject: Re: Re: Call for Adoption of draft-li-sidrops-bicone-sav-04

Hi Sriram,
Thank you for the comments.
> Because it currently admits all special purpose prefixes (https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml ), unallocated prefixes, and allocated but unannounced prefixes (not intended to be announced; having no ROAs).  For fixing this issue, bicone must be modified to use the approach of allowing all prefixes that are in the Loc-RIB [RFC 4271] minus the list of prefixes that can be perceived to originate *only* from the provider cone.
Lancheng: Can we add these special prefixes (that would not be used as a source IP address) into the blocklist?
> So, in the end, it is an allowlist SAV (not blocklist). It is essentially the loose uRPF method with some prefixes removed. IMO, there is no concept of "blocklist" that can work as a SAV method.
Lancheng: I do not think I understand this. According to the definition in [1], I think bicone sav uses a blocklist instead of an allowlist.
> Even after doing the above, bicone still has no real directionality property to speak of.  It is only marginally better than loose uRPF.  It will still have improper blocking - in some multihoming scenarios with prefixes that are invisible in the CC.
Lancheng: IMO, the primary goal of SAV is avoiding improper blocks and then reducing improper admits. In terms of avoiding improper blocks, bicone sav would be better than existing allowlist-based SAV. In terms of reducing improper admits, bicone sav is better than loose uRPF. We are improving the current design of bicone sav to further eliminate improper blocks.
[1] https://datatracker.ietf.org/doc/draft-huang-savnet-sav-table/
Best,
Lancheng




-----Original Messages-----
From: "Sriram, Kotikalapudi (Fed)" <[e-mail]<mailto:[e-mail]>>
Send time: Thursday, 09/19/2024 06:25:19
To: Lancheng <[e-mail]<mailto:[e-mail]>>, "Lubashev, Igor" <[e-mail]<mailto:[e-mail]>>
Cc: "IETF SIDRops" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: Call for Adoption of draft-li-sidrops-bicone-sav-04
Hi Lancheng and coauthors,

[Igor wrote:] "... The "cost" is an improper admit of all prefixes originated solely by the AS's customers and peers as well as an improper admit of all unannounced prefixes (although the latter can be easily fixed)."

In the process of fixing this, you'll see that bicone SAV turns into an "allowlist" proposal as well.  To me it feels incorrect to position bicone as a "blocklist" SAV.  Because it currently admits all special purpose prefixes (https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml ), unallocated prefixes, and allocated but unannounced prefixes (not intended to be announced; having no ROAs).  For fixing this issue, bicone must be modified to use the approach of allowing all prefixes that are in the Loc-RIB [RFC 4271] minus the list of prefixes that can be perceived to originate *only* from the provider cone.  So, in the end, it is an allowlist SAV (not blocklist). It is essentially the loose uRPF method with some prefixes removed. IMO, there is no concept of "blocklist" that can work as a SAV method.

Even after doing the above, bicone still has no real directionality property to speak of.  It is only marginally better than loose uRPF.  It will still have improper blocking - in some multihoming scenarios with prefixes that are invisible in the CC.  OTOH, I think no improper blocking can be achieved in BAR-SAV through appropriate recommendations, certainly for ASes doing SAV that are one to two levels above the stubs where SAV is most effective.  We'll provide details in the next version of the BAR-SAV draft.

Thanks.

Sriram