Summary

VyOS already exposes two pieces of BGP config that, together, contain enough information to auto-generate a large chunk of a standard RFC 8195 ("Use of BGP Large Communities") tagging scheme without any extra operator-maintained community-lists:

1. local-role (RFC 9234) already declares the relationship (provider/customer/peer/rs/rs-client) per neighbor or peer-group.
2. Every neighbor/peer-group already has its remote-as on file.

We'd like VyOS to optionally derive and apply the RFC 8195 "relation to origin" community (Function 3) automatically from (1), and — as a larger, separate ask — optionally automate per-neighbor selective no-export/prepend (Functions 4/6) using (2), instead of requiring the operator to hand-build and maintain one large-community-list + route-map rule per neighbor for information that VyOS's config tree already fully determines.

Motivation / real-world use case

We're designing a BGP large-community scheme for our own AS (customer/peer/transit tagging, selective no-export, selective prepend) and deliberately chose to follow RFC 8195's conventions instead of inventing our own numbering, specifically so the tags are self-explanatory to any operator who knows the RFC. While doing this we noticed that most of the "relation to origin" tagging (RFC 8195 Function 3: <own-asn>:3:1/2/3/4 for internal/customer/peer/transit) is fully redundant with information we *already* had to configure for an unrelated reason (RFC 9234 role safety):

set protocols bgp peer-group upstream_myloc local-role customer
set protocols bgp peer-group upstream_openfactory local-role customer

local-role customer here means "we are the customer, the neighbor is our transit" — which is exactly RFC 8195's 3:4 ("route learned from a transit provider"). The mapping is mechanical:

(3:1, "originated internally", is out of scope for this — it applies to self-originated/aggregate routes, not neighbor relationships, and would need a different mechanism, e.g. tied to network/aggregate-address statements.)

Right now, achieving this tagging requires the operator to write, per neighbor:

set policy large-community-list AS<n>-REL-TRANSIT rule 10 action 'permit'
set policy large-community-list AS<n>-REL-TRANSIT rule 10 regex '<own-asn>:3:4'
set policy route-map rcs-AS<n>-IN rule 5 action 'permit'
set policy route-map rcs-AS<n>-IN rule 5 set large-community '<own-asn>:3:4'

even though local-role already told VyOS everything it needs to pick the right value.

What we actually want (core ask)

An option that, when enabled, makes VyOS automatically attach the RFC 8195 Function-3 community derived from the already-configured local-role, on import, without the operator building a separate community-list/route-map-set rule for it.

Requested syntax (example)

set protocols bgp peer-group upstream_myloc address-family ipv4-unicast large-community rfc8195-relation
set protocols bgp system-large-community-relation-asn '210198'

(exact leaf placement/naming is obviously up for the maintainers to decide — the point is the behavior, not this specific syntax.)

Behavior: on route import from that neighbor, VyOS/FRR would set large-community additive <system-asn>:3:<mapped-value> based on the neighbor's local-role, the same way local-role already drives the RFC 9234 OPEN capability today. No new community-list needed, no route-map edit needed when a new neighbor is added — the moment local-role is set (which is already recommended practice, see VyOS docs on RFC 9234), the tag follows automatically.

Second, larger ask: selective no-export / prepend (Functions 4/6) from remote-as

RFC 8195 also defines Function 4 (selective no-export, parameter = target neighbor ASN) and Function 6 (selective 1x prepend, parameter = target neighbor ASN). Since every route-map is already inherently tied to one specific neighbor (and that neighbor's remote-as is already known to VyOS), the same idea applies: a toggle that makes VyOS auto-generate the matching community-list (<own-asn>:4:<this-neighbors-remote-as> / <own-asn>:6:<this-neighbors-remote-as>) and reference it in that neighbor's own export route-map, rather than the operator hand-writing one community-list per neighbor.

To be precise about where the actual difficulty is: computing the community *value* itself needs no generated/invented identifier at all — it's plain substitution of scalars VyOS already has on file (the router's own ASN is a fixed constant, the neighbor's remote-as is already a per-neighbor config value). The real open question is purely *where/how* VyOS safely applies the resulting set large-community additive <value> action inside that neighbor's own export route-map without silently reordering or shadowing rules the operator already wrote there. That's the part we're flagging as a separate, harder problem — not expecting it bundled with the first (simpler, import-side-only) ask.

Requested syntax (example, second ask)

set protocols bgp neighbor <ip> address-family ipv4-unicast route-map export 'rcs-ASxxxxx-OUT'
set protocols bgp neighbor <ip> address-family ipv4-unicast large-community rfc8195-selective-no-export
set protocols bgp neighbor <ip> address-family ipv4-unicast large-community rfc8195-selective-prepend

with VyOS inserting the appropriate deny/set-as-path-prepend rule ahead of (or merged into) the user-specified export route-map at commit time.

Current workaround

Hand-write one large-community-list (and, for the second ask, one route-map rule) per neighbor, following a documented naming convention (e.g. AS210198-REL-<TYPE>, AS210198-NOEXPORT-TO-<peer-asn>). This is bundled into our own per-neighbor onboarding process (we already create a dedicated import/export route-map per neighbor for prefix/AS-path filtering, so this is "one more line" rather than wholly new process) — but it's still boilerplate that VyOS's existing config tree already has enough information to generate on its own.

Why this matters beyond our specific case

Any operator who (a) already sets local-role per RFC 9234 (which VyOS itself recommends) and (b) wants to follow RFC 8195's own convention for community tagging is, today, maintaining two separate, hand-written representations of the *same* underlying relationship (once for the BGP OPEN capability, once for the community that gets attached to routes) — with no automated link between them despite VyOS already holding all the necessary data.

See also

vyos-feature-request-config-derived-groups.md (T9160) proposes a related but distinct mechanism (apply-path) for populating groups/prefix-lists by *copying* a list of existing values from elsewhere in the config. This request is different in shape — it needs a *computed* value (own ASN + function number + a scalar looked up from local-role/remote-as), not a copied list — which is why it's filed separately rather than as an apply-path use case.

Environment

• VyOS 1.5.1 (circinus), FRR 10.5.2