eclist matching question

[Alexander Shikov]

On Tue, Jul 07, 2020 at 16:08:02 +0200, Ondrej Zajicek wrote:
> On Wed, Jul 01, 2020 at 03:06:30PM +0300, Alexander Shikov wrote:
> > On Tue, Jun 30, 2020 at 22:27:54 +0200, Ondrej Zajicek wrote:
> > Hello!
> > 
> > bird> show route 109.68.40.0/21 all
> > BIRD 1.6.8 ready.
> > 109.68.40.0/21     via 193.25.180.17 on bge0 [ITCONS 2020-07-01 15:02:20] * (100) [AS25372i]
> >         Type: BGP unicast univ
> >         BGP.origin: IGP
> >         BGP.as_path: 25372
> >         BGP.next_hop: 193.25.180.17
> >         BGP.local_pref: 100
> >         BGP.community: (25372,3) (65005,10804) (31210,31210)
> >         BGP.ext_community: (rt, 65001, 28773) (rt, 31210, 31210)
> > 
> > bird> show route 109.68.40.0/21 all where (rt,65001,28773) ~ bgp_ext_community
> > - output is empty, matching failed.
> 
> After investigating, it seems to be caused by ambiguity in extended
> communities. There is basic two-octet AS form, which has 2 bytes for ASN
> and 4 bytes for local value, and there is extended four-octet AS form
> (RFC 5668), which has 4 bytes for ASN and 2 bytes for local value.
> 
> The received community is in the later form, although it has 2B ASN.
> While expression '(rt, 65001, 28773)' defines the former form. So they
> are two different communities (8B sequences), and do not match.
> 
> We should fix it by having different textual representation for such case
> (2B ASN in 4B-ASN form), so it is distinguished from the canonical
> represntation.

Dear Ondrej,

thank you for investigation and explanation.
Just a suggestion, you may consider JunOS representation:
target:65001L:28773 vs. target:65001:28773

-- 
Alexander Shikov
Technical Staff, Digital Telecom IX
Tel.: +380 44 201 14 07
Mob.: +380 50 410 30 57
http://dtel-ix.net/