Re: [Sidrops] Which 8210-bis error code should be used?

Hi all,

A little opposite opinion :)

I support " It is here but don't use it".
It can make the information more accurate for edge cases or some fake link hijacks.
All provider ASNs are listed (just like no afiLimit), and each provider AS is listed only once and is labeled with afiLimit  (just additional attribute information, if like).  Its values MUST be 0000 for ignored (not omitted), 0001 IPv4, 0002 IPv6.  If a customer-provider appears in IPv4 and IPv6 topology, no duplicated PDUs for IPv4 and IPv6, and no need to maintain two tables.
It is here. How to use (or not to use) it depends on uses (implementors, operators, etc). For example,  do not process afiLimit. But if users need this information, they can use them without protocol change.

Yangyang

> -----Original Message----
> From: sidrops-bounces@ietf.org [mailto:sidrops-bounces@ietf.org] On
> Behalf Of Hollyman, Michael
> Sent: 2023年6月2日 1:54
> To: sidrops@ietf.org
> Cc: draft-ietf-sidrops-aspa-verification@ietf.org
> Subject: Re: [Sidrops] Which 8210-bis error code should be used?
> 
> I tend to agree with Claudio and Martin here. I think the afiLimit should be
> removed from ASPA, if possible, or it will become just like max-length: "It is
> here but don't use it."  There shouldn't be any inference of intent in ASPA
> when one is published with an AFI and another without.
> 
> It appears to me that the spirit of ASPA is to simply list the provider ASes
> for a CAS. Keeping that simple and by AS, not by AFI, seems to be a logical
> choice.
> 
> Full path control is BGPSec. ASPA is an incremental step forward in
> preventing leaks and some hijacks.  Simplicity of ASPA should be the key in
> order to gain the most acceptance and usage.
> 
> Mike
> 
> On 5/24/23, 03:39, "Sidrops on behalf of Claudio Jeker" <sidrops-
> bounces@ietf.org <mailto:sidrops-bounces@ietf.org> on behalf of
> cjeker@diehard.n-r-g.com > <mailto:cjeker@diehard.n-r-g.com>> wrote:
> 
> 
> > I would love to remove the optional afiLimit from ASPA.
> > I brought this up a few times (well before there was any
> > implementation of any ASPA draft) and every time the answer of some of
> > the authors was no (without any particular reason).
> 
> 
> > As one of the developers of the first RP and only BGP implementation
> > handling ASPA I would enjoy to remove all the code required to handle
> > the afiLimit. We probably control most test deployments (RP and BGP
> > side) and are willing to make this change.
> 
> 
> > --
> > :wq Claudio
> 
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops