On Wed, Nov 16, 2022 at 02:43:40PM +0100, Claudio Jeker wrote:
> On Wed, Nov 16, 2022 at 12:18:14PM +0000, Job Snijders wrote:
> > On Wed, Nov 16, 2022 at 12:47:46PM +0100, Claudio Jeker wrote:
> > > A aspa-set is defined like this:
> > > aspa-set {
> > > source-as 1 transit-as { 5 }
> > > source-as 2 expires 1668181648 transit-as { 3 4 }
> > > source-as 5 transit-as { 1 2 allow inet 7 allow inet6 }
> > > }
> >
> > bikeshed.com
> >
> > I'd argue s/source-as/customer-as/ and s/transit-as/provider-as/
> > because bgpd.conf(5)'s transit-as already has a defined meaning: any ASN
> > left of the origin AS in the AS_PATH. In ASPA the customer-as and
> > provider-as are adjacent (if I understand the voodoo correctly).
>
> I do not want to create too many tokens in the parser since they may
> conflict with user defined strings in the config. Maybe less of an
> issue with customer-as and provider-as but still something to
> consider.
>
> I my opinion source-as is close enough to customer-as.
ok
> transit-as is a bit more of a stretch. Similar the 'allow inet' bit is
> a bit of a stretch but AFI specific ASPA entries are dumb anyway.
'transit-as' currently means "all but the rightmost AS number", however
in the ASPA context it really means something different. The new token
only is valid in context of aspa-set { ... } so I imagine it shouldn't
cause too much of a pain to make it 'provider-as'; and perhaps
'provider-as' as a token is useful in the normal FILTER as well? :-)
Kind regards,
Job
