YANG over BGP

1.1. Design Goals

• Distribution like routes: objects reach routers through the existing BGP peerings and topology; no per-router login is required.¶
• Receiver autonomy: each router decides, per peer, object type and object name, what it accepts (Section 11). The default is deny.¶
• Persistence: applied objects stay in the configuration when a session goes down; they are removed only by an explicit tombstone (Sections 7 and 8).¶
• Deterministic convergence: all speakers settle on the same version of an object regardless of arrival order or propagation path (Section 6).¶
• Openness: any YANG module can be distributed, and vendors can add their own data without a new specification (Section 13).¶

1.2. Benefits

• Independent implementability. YoBGP builds only on published specifications: BGP and its multiprotocol extensions, and YANG with its JSON encoding. It does not wait for the standardization of anything else, and an implementer can support any YANG module it already has. Mechanisms that define policy semantics inside BGP need new BGP elements whenever the policy language grows; YoBGP does not.¶
• Diversity. YoBGP prescribes no single data model and ties a network neither to the schema of one vendor nor to the schema of one standards body. Any YANG module can be distributed, including vendor-specific ones, so a multi-vendor network can use the models its platforms support, and models can evolve without changes to this document.¶
• Fewer configuration errors. An object is defined once, as YANG data, and each router maps it to its own configuration. This reduces the errors that come from rendering the same object in different syntaxes for different platforms, and removes the need to maintain one template per platform.¶

1.3. Non-Goals

• Feedback to the originator. As with routes, the originator does not learn whether, or when, an object was applied. Monitoring is done out of band (Section 14).¶
• Atomic multi-object commit or rollback orchestration. Each object is versioned and applied individually; dependencies between objects are handled locally by the receiver (Section 12).¶
• Origin authentication of objects beyond what the BGP session provides (Section 15).¶

1.4. Relationship to Other Mechanisms

YoBGP distributes configuration objects that routers keep. It is not the first use of BGP to carry policy-related or filter-like information, and this section states how it differs from the closest mechanisms.¶

Routing Policy Distribution (RPD) [I-D.ietf-idr-rpd] also uses a new AFI/SAFI to deliver routing policy from a controller, normally through a route reflector, to routers. The two solve different problems:¶

• Purpose. RPD distributes dynamic policies that adjust traffic by changing or suppressing the IP routes a router sends to its peers, for example by changing the MED, adding to the AS_PATH, or not advertising a route. YoBGP distributes the stable objects that a router's configuration refers to: prefix sets, community sets, AS-path sets, access control lists, and the routing policies themselves.¶
• Semantics. RPD defines in the BGP specification what a policy can match and what it can do, and encodes it in BGP Wide Community [I-D.ietf-idr-wide-bgp-communities], a separate draft that has not been published as an RFC. Each new match condition or action needs a new element defined for BGP. YoBGP defines no policy semantics. The meaning of an object comes from its YANG module, so new kinds of objects need no change to this document.¶
• Lifecycle. RPD policies are held as BGP routes for as long as the controller's session lets them be, helped by graceful restart. YoBGP objects are configuration: they persist independently of any session, carry versions, and are removed only by an explicit tombstone.¶
• Where applied. A router applies RPD policies after its other policies, as a separate source of policy. YoBGP objects become part of the router's own configuration, where its other configuration can refer to them.¶
• Admission. RPD relies on the trust placed in the controller's BGP session. YoBGP adds a per-peer import filter that decides, by object type and name, what a peer may create, modify or delete (Section 11).¶

The two mechanisms can coexist. A deployment can use YoBGP to keep stable sets and policies identical on all routers and RPD for short-lived traffic adjustments. YoBGP does not replace RPD and does not carry the dynamic policy actions that RPD defines. RPD in turn does not provide persistent, versioned, schema-driven objects.¶

YoBGP is also related to Outbound Route Filtering [RFC5291], which sends a filter to a peer to be applied to what that peer advertises, and to Flow Specification [RFC8955], which distributes traffic filtering rules. Neither carries configuration objects that the receiver stores.¶

Finally, YoBGP complements management protocols such as NETCONF [RFC6241] and does not replace them. It suits objects that must be identical on many routers and be distributed along the BGP topology without a management session to each router. It is not a general management interface.¶

1.5. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

5.1. Format

The YoBGP attribute (type code TBA3) is an optional, non-transitive BGP path attribute (cf. [RFC9552]). It MUST be present in every MP_REACH_NLRI UPDATE for this AFI/SAFI.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Version (octets 0-3)                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Version (octets 4-7)                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Source Router ID                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Fragment Count        |       Payload (variable)      ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Version (64 bits): see Section 6.1. The value 0 is invalid.¶
• Source Router ID (32 bits): the BGP Identifier of the speaker that originated this version. It is copied unchanged when the object is propagated and is not the ORIGINATOR_ID attribute of [RFC4456].¶
• Fragment Count (16 bits): the number N of fragments of the object, or 0 for a tombstone (Section 5.4).¶
• Payload: one piece of the serialized object (Section 5.4). It extends to the end of the attribute. A tombstone has an empty payload, and any octets after the Fragment Count are ignored.¶

5.2. Error Handling for Malformed Objects

[RFC7606] requires a document that defines new BGP elements to say what is an error and how it is handled. For YoBGP the treatment depends on whether the NLRI field of MP_REACH_NLRI can still be parsed.¶

Treat-as-withdraw. The NLRI field can be parsed, but the YoBGP attribute is missing or malformed (wrong attribute flags, an invalid Version, an attribute shorter than its fixed part of 14 octets, a Fragment Number greater than the Fragment Count, a Fragment Number 0 with a Fragment Count other than 0 or the reverse, or a fragment with an empty payload), the UPDATE carries more than one NLRI, or the inner fields of an NLRI are inconsistent with its NLRI Length. The advertisement is handled as treat-as-withdraw [RFC7606]: it is discarded and SHOULD be logged with the neighbor address and, if known, the object key. Because a withdrawal has no effect on stored state or on the active configuration (Section 6.4), such an advertisement changes nothing. The BGP session is not reset.¶

NLRI field cannot be parsed. An NLRI Length exceeds the data that remains in MP_REACH_NLRI, or the Length of Next Hop Network Address is not 0. The NLRI field cannot then be located reliably, and treat-as-withdraw cannot be used [RFC7606]. The speaker SHOULD use the AFI/SAFI disable approach of [RFC4760] and [RFC7606], that is, ignore all subsequent YoBGP routes received over the session. Session reset is the other approach that [RFC7606] allows, but it is not RECOMMENDED because it also drops every other address family. Objects already applied are not affected by either approach.¶

5.3. Payload Structure

The payload, which is the byte string that results from reassembly (Section 5.4), is JSON text [RFC7951] in UTF-8. It is a complete data tree that contains exactly one object. It consists of the top-level data node named by the first component of the Object Type and, below it, the chain of descendants on the path to the object. Each list on the path appears with exactly one entry, which holds its keys. The object itself appears with its complete content. The payload contains nothing else.¶

The identity of the object in the payload, that is, the names on the path, including their modules, and the key values, MUST match the Object Type and the Object Name of the NLRI. A mismatch is a configuration payload error (Section 12.2).¶

When the object is applied, the receiver replaces the object in its configuration with the one in the payload as a whole, and creates the ancestors on the path if they do not exist. It MUST NOT change any other data.¶

5.4. Transfer of Objects in Fragments

Every object is transferred in the same way, as a sequence of N fragments. N is 1 for an object that fits in one UPDATE, larger for a bigger object, and 0 for a tombstone. There is no separate encoding for small and large objects.¶

The payload of the object is serialized as one byte string with the structure of Section 5.3 and cut into N pieces of any sizes that fit the peer. Each fragment is one UPDATE. Its NLRI is the object key together with the Fragment Number k, from 1 to N (Section 4). Its attribute has the Version and the Source Router ID of the object, the Fragment Count N and, as its payload, piece k. All fragments of an object carry the same Version, Source Router ID and Fragment Count.¶

A tombstone is a single UPDATE with Fragment Number 0, Fragment Count 0 and an empty payload.¶

Fragmentation applies to each hop separately. A speaker that advertises an object to a peer cuts it for that peer into as many fragments as the maximum BGP message size negotiated with that peer requires, and fragment boundaries are not preserved from one hop to the next. An UPDATE MUST NOT exceed that size. Implementations SHOULD support Extended Message [RFC8654] and SHOULD advertise it, so that fewer fragments are needed. A speaker SHOULD send the fragments in numerical order.¶

The receiver reassembles every object before it enters the YoBGP-RIB. Fragments are not entries of the YoBGP-RIB. For each object it receives, the receiver keeps a reassembly buffer for the session on which the fragments arrive, and never combines fragments received from different peers, because their boundaries can differ.¶

Steps 1 and 2 of Section 3 (validation and import filter) are applied to each fragment as it arrives, using the object key and the Fragment Count, and before any memory is allocated for reassembly, so that a rejected object is never buffered. A state that does not supersede the entry of the object in the YoBGP-RIB (Section 6.3) is discarded without being buffered.¶

When the buffer holds, for every number from 1 to N, a fragment with the same Version, Source Router ID and Fragment Count, the receiver concatenates the pieces in the order of their numbers, takes the result as the payload of the object, and handles the object from step 3 of Section 3 as if it had been received in one UPDATE. The buffer is then released. A tombstone is complete on arrival. Fragments that carry the same Version and Source Router ID but disagree in Fragment Count are discarded together with the buffered fragments of that Version, and the event SHOULD be logged. Until an object is complete, nothing of it is in the YoBGP-RIB and the state that was there before remains in effect.¶

A new version of an object can have fewer or more fragments than the previous one, for example 2 fragments after a version that had 3. Fragments of different states are never combined, because reassembly requires the same Version, Source Router ID and Fragment Count. The receiver MUST discard the reassembly state of an object, so that no orphaned fragment of a lower state remains for its object key, when it receives a newer state of that object from the same peer, when an entry that supersedes the buffered state is installed in the YoBGP-RIB, whichever peer it came from, when the session is lost, and when the limit on memory for reassembly is reached. Late fragments of a lower state are discarded on arrival, as described above. A speaker SHOULD limit the memory for reassembly per peer (Section 15.7).¶

6.1. Version

Version is a 64-bit unsigned integer, scoped to one object key. Zero is invalid. Versions are compared as plain unsigned integers; no wraparound arithmetic is used. A 64-bit Version does not wrap in practice: one new Version per microsecond would take more than half a million years to exhaust it. Serial number arithmetic [RFC1982] would not help an originator that restarts with lower Versions either, because it also orders Version 1 before Version 1500. An originator MUST assign strictly increasing versions to successive states of an object (including its tombstone) and MUST NOT advertise two different contents with the same Version and Source Router ID. Implementations SHOULD choose versions that survive a restart of the originator, for example from a persisted counter or from a clock. An originator MUST provide an administrative means to set the version to be used next for an object, to any non-zero value. An originator MAY also provide an administrative setting, a version offset, that adds a configured constant to every Version it assigns. It lets an originator that has lost its Version counter resume above the Versions already in the network. The constant should only be raised, because lowering it can make new Versions lower than those already issued.¶

6.2. YoBGP-RIB

Each speaker keeps one YoBGP-RIB. It holds at most one entry per object key, the current entry, independent of which peer supplied it and of the state of that peer's session. An entry records the Version, Source Router ID, Payload, the peer from which it was received (or local, for an originated object), and its application status (applied, pending, rejected, or, in no-apply mode, not applied). Tombstones are entries too. The YoBGP-RIB is volatile (Section 8); what has been applied is part of the node's configuration (the YoBGP-CIB).¶

6.3. Update Procedure

State S1 of an object supersedes state S2 if S1 has a higher Version, or the same Version and a lower Source Router ID. This order is the same on every speaker. The BGP decision process is not used for this AFI/SAFI. For a valid received object that the import filter admits (Section 11):¶

1. If the YoBGP-RIB holds an entry for the object key: if the received state supersedes the stored one, the entry is replaced. If both states are the same (same Version and Source Router ID), the received object is a duplicate and is discarded; if its content differs from the stored content, the speaker SHOULD log a version conflict and keep the stored entry. If the stored state supersedes the received one, the received object is discarded.¶
2. If the YoBGP-RIB holds no entry for the object key, an entry is created.¶
3. When an entry is created or replaced, it is scheduled for propagation (Section 10) and for application (Section 12).¶

6.4. MP_UNREACH_NLRI

A speaker MAY send MP_UNREACH_NLRI for this AFI/SAFI, for example when its outbound policy changes. Receiving it has no effect on the YoBGP-RIB or on the active configuration. Deleting an object is expressed only by a tombstone (Section 7).¶

6.5. Administrative Override at the Receiver

A speaker MUST provide an administrative means to discard the YoBGP-RIB entry of an object, or to set the Version of that entry, so that an erroneously high version can be corrected (Section 15.6). Discarding the entry does not remove the applied object from the active configuration; it removes only the ordering state, so that the next received state of the object is accepted whatever its Version. A speaker MAY offer a configurable limit on how far a received Version may exceed the stored one. Appendix A.3 shows hypothetical commands.¶

9.1. The advertise Statement

The operator names an object type and an object name pattern, using the pattern syntax of Section 11.1. Naming one object exactly is a pattern without a wildcard, and "*" covers all objects of the type. The speaker originates every object of that type whose name matches and that is found in its configuration, and follows later additions, changes and removals automatically.¶

9.2. Scope

A statement configured for the address family applies to all peers. A statement configured for one peer applies only to that peer. An originated object is advertised to the peers that the statements cover, subject to the mode and outbound policy of Section 10. A peer covered by overlapping statements receives the object once.¶

9.3. Common Rules

• Origin. An originated entry carries the speaker's own BGP Identifier as Source Router ID, unless another value is configured, and is marked in the YoBGP-RIB as local. Originated entries are not subject to the import filter.¶
• Payload. The speaker exports the object as YANG data of a module it implements. An object that cannot be expressed in this way MUST NOT be originated.¶
• Names. An implementation MAY translate object names on export. How it does so is not specified.¶
• Versions. The speaker assigns a Version as in Section 6.1 whenever the exported data of an object change, and MUST NOT assign a new Version when they do not. The data are compared by value, not by their serialization.¶
• Deleted objects. When an originated object is deleted from the configuration, the speaker originates a tombstone for it with a higher Version (Section 7). Removing the advertise statement, or an object ceasing to match it, only stops the origination: nothing is deleted at the receivers, and the entry is removed from the YoBGP-RIB of the originator (MP_UNREACH_NLRI, Section 6.4, may be sent).¶
• Dependencies. The speaker SHOULD originate referenced objects before the objects that reference them (Section 12.1).¶
• Restart. Originated entries are rebuilt from the configuration. Versions should survive the restart (Section 6.1). A clock-based Version gives unchanged objects a new Version after a restart, which is harmless but makes receivers apply them again.¶

10.1. Modes

Support for propagating received objects is OPTIONAL. A speaker that supports it MUST allow configuring it per peer. The default is non-transitive.¶

• Non-transitive: the speaker MUST NOT advertise received entries to any peer. It MAY advertise objects it originates itself.¶
• Transitive: the speaker advertises received entries following the normal BGP advertisement rules for the session type, including route reflection [RFC4456]. Loops end by themselves: an entry that returns is a duplicate under Section 6.3 and is not propagated again, so loop prevention by AS_PATH or CLUSTER_LIST is not required, although an implementation may still apply it.¶

Only entries admitted into the YoBGP-RIB are propagated; an object rejected by the import filter is not. An admitted entry that cannot be applied on this node (status pending or rejected) is still propagated, because its applicability here says nothing about other nodes.¶

A speaker MAY offer a no-apply mode, per AFI/SAFI, in which entries are admitted, stored and propagated but never handed to the configuration parser. It lets a route reflector reflect objects without applying them. In no-apply mode update-only is treated as permit.¶

Transitive mode needs increased attention. A faulty or compromised speaker in transitive mode reaches every speaker downstream of it. Objects persist (Section 8), so a faulty object is removed only by a tombstone, and the retention of tombstones is limited (Section 7). Transitive mode should be enabled only on a small number of well-controlled speakers (Section 14).¶

10.2. Outbound Policy

A speaker that supports transitive mode MUST support outbound filtering. The outbound policy defaults to permit. It matches on the same attributes as the import filter (Section 11.1) and decides only whether an entry is advertised to a peer.¶

10.3. Initial Advertisement and Refresh

When a session for this AFI/SAFI is established, the speaker advertises all entries of its YoBGP-RIB that its mode and outbound policy allow, retained tombstones included, each object as fragments (Section 5.4). The same procedure is followed when a ROUTE-REFRESH message [RFC2918] for this AFI/SAFI is received.¶

11.1. Actions and Matching

A filter is an ordered list of rules and can be defined once and applied to several peers. A rule matches on an object type and one or more object name patterns, and has one of three actions:¶

• permit: the object is admitted. It may be instantiated if absent, modified if present, and deleted by a tombstone.¶
• update-only: the object is admitted only if it already exists in the active configuration under the same name and type (whether created locally or by YoBGP), and only if the received state is not a tombstone. Existence is checked when the object arrives.¶
• deny: the object is not admitted.¶

The object type is matched against the Object Type of the NLRI. Implementations MUST allow naming the object types of the models they support in their native terminology (for example prefix-list, community-list, as-path-list, route-policy, access-list), MUST at minimum cover prefix sets, community sets, AS-path sets, routing policies and access control lists (Appendix A.4), and MAY support a catch-all token "any". An object name pattern is matched against the whole Object Name as it is encoded in the NLRI (Section 4), case-sensitively, so a "/" inside a key value is matched as %2F. The character "*" matches any sequence of characters, including none, and the character "?" matches exactly one character. Both also match the separators "/" and ",", and a %-escape counts as three characters. No other wildcard is defined, and there is no escape for "*" or "?". For example, "CUST_A_*" matches every name that begins with CUST_A_, "*-V6" every name that ends in -V6, "*XYZ*" every name that contains XYZ, "SRV-???-IN" every name that consists of SRV-, exactly three characters and -IN, and "*" every name. Rules are evaluated in configured order and the first matching rule applies.¶

Because the first match wins, a filter can be structured. It can hold any number of rules for each object type, and a narrow rule (a deny for legacy names, an update-only for one critical policy) placed before a broader permit makes an exception to it. Different peers can use different filters, for example one controller that may create and delete objects and another that may only modify what already exists.¶

11.2. Effect of Each Action

"Rejected" means the object is discarded on arrival: it is not stored, not propagated and not applied. The speaker SHOULD log a rejection by update-only with the neighbor address, the object key and the reason. "Instantiate", "overwrite" and "delete" describe an admitted object, which is stored, propagated and applied subject to Section 12.¶

11.3. Default Behavior

If no rule matches an object, the action is deny (implicit deny). A peer with no import filter therefore has no objects admitted.¶

11.4. Filter Changes and Refresh

A change of an import filter affects objects received afterwards. It does not remove entries from the YoBGP-RIB or objects from the active configuration: changing a filter never deletes anything that was admitted or applied.¶

Rejected objects are not retained. After a filter has been changed, or after an object has been created locally that an update-only rule is meant to maintain, the speaker requests the objects again with a ROUTE-REFRESH message [RFC2918]. Speakers MUST support Route Refresh for this AFI/SAFI. A speaker MAY instead keep unfiltered copies of received objects, comparable to soft reconfiguration inbound, and re-evaluate them locally; such copies are not part of the YoBGP-RIB and are neither propagated nor applied. They also allow an operator to inspect what a peer has sent before the import filter, which helps when looking for a problem.¶

12.1. Dependencies

Objects can reference other objects (a policy references prefix sets and community sets). A sender SHOULD advertise an object only after the objects it references have been advertised, but delivery order is not guaranteed, so the receiver enforces consistency:¶

• An admitted object MUST NOT be applied while an object it references does not exist in the active configuration. It stays in the YoBGP-RIB with status pending, a syslog warning SHOULD be generated, and the speaker MUST retry whenever the active configuration changes.¶
• A tombstone MUST NOT be applied while another object in the active configuration still references the object to be deleted. It stays pending, a syslog error SHOULD be generated, and it is retried when the references change.¶

12.2. Configuration Payload Errors

If an admitted payload has unsupported attributes, unrecognized conditions, an unknown module, syntax errors, or an identity that does not match the object key (Section 5.3), the node:¶

1. MUST NOT apply the object and MUST NOT change the active configuration;¶
2. MUST NOT reset the BGP session;¶
3. keeps the entry in the YoBGP-RIB with status rejected; the entry remains eligible for propagation (Section 10.1), because its validity for this node says nothing about other nodes;¶
4. SHOULD generate a syslog error containing the sending neighbor, the object key and a description of the error.¶

12.3. The YoBGP-CIB

The YoBGP-CIB is the set of objects that YoBGP has applied to the node's configuration. It is a thin, logical layer between the YoBGP-RIB and the configuration, like the FIB between the RIB and the forwarding plane in ordinary routing. An entry of the YoBGP-RIB that the import filter admits and that is applied successfully (Sections 11 and 12) becomes an object of the YoBGP-CIB. An object deleted by a tombstone, or removed by the purge-on-session-loss option (Section 8), ceases to be one.¶

The YoBGP-CIB has no state of its own, and in particular no version or ordering information, which lives in the YoBGP-RIB. Its objects are ordinary configuration: they are stored with the node's persistent configuration (Section 8) and the operator can view and change them with the usual configuration tools. An implementation MAY mark such objects to tell them apart from locally created ones; this document does not require it.¶

15.1. Reduced Attack Surface

YoBGP runs inside an existing BGP session. No automation engine holds credentials for the fleet, no management interface is opened, and the router accepts no inbound configuration connection beyond its BGP peering.¶

15.2. Inbound Admission Isolation

The import filter limits what each peer can do, independently of session type: permit, update-only and deny, evaluated with an implicit deny. An operator can restrict a peer to modifying pre-existing objects only, which prevents it from injecting new ones.¶

15.3. Limits of the Filter

The filter judges names and types, not content. A peer allowed to update a route policy can change what the policy does. Operators SHOULD grant permit or update-only only to peers they trust to that degree, narrowly by name pattern. Permitting object types that create BGP sessions or change routing policy deserves particular care. Access to the same YANG data through NETCONF is governed by [RFC8341]; YoBGP's filter is a separate mechanism and should be aligned with it in deployment.¶

15.4. Session and Transport Security

The BGP session is the only security boundary. Deployments SHOULD protect it with TCP-AO [RFC5925] and, for directly connected peers, GTSM [RFC5082]. This document does not depend on a particular transport; further improvements in the security of BGP sessions, which can be expected, benefit YoBGP directly.¶

15.5. Transit Trust

In transitive mode, intermediate speakers can alter or inject objects, as in any BGP propagation; there is no object-level signature. Transitive mode SHOULD NOT be used across administrative boundaries, and outbound filters SHOULD be used to limit what a speaker passes on. The non-transitive default prevents leaking configuration beyond the intended peers.¶

15.6. Version Manipulation

A peer permitted to supply an object can send a very high Version, after which lower versions from the legitimate originator are discarded. The administrative override (Section 6.5) restores control, and the optional limit on version jumps can prevent the situation. Equal-version conflicts are settled by Source Router ID, which is not authenticated; see Section 15.5.¶

15.7. Resource Exhaustion

A peer can fill the YoBGP-RIB with entries that the import filter admits. Because rejected objects are not stored, the implicit deny already limits this to what the operator has permitted. Implementations SHOULD nevertheless support a configurable limit on the number of entries per peer, comparable to a maximum-prefix limit; retained tombstones count toward it until they expire. On reaching the limit the speaker SHOULD log and stop accepting new entries from that peer; it MAY also reset the session. Reassembly buffers (Section 5.4) need a similar limit. A peer cannot make a speaker allocate memory for an object that the import filter rejects, because the filter is applied before a reassembly buffer is created. Memory is allocated as fragments arrive and not in advance from the Fragment Count, which is not trusted.¶

15.8. Parser Exposure

Payloads are parsed only for admitted objects, and transit speakers need not parse them at all. Parsers handling YANG JSON from the network SHOULD enforce limits on size and nesting depth and run with minimal privilege.¶

A.1. Conceptual Cisco IOS XR Style Configuration

yobgp-filter CONTROLLER_A_IN
 ! First matching rule wins; narrow rules go before broad ones.
 10 deny prefix-list CUST_A_LEGACY_*
 20 permit prefix-list CUST_A_* CUST_B_*
 30 permit community-list CUST_*
 40 update-only as-path-list TRANSIT_ASNS_*
 50 permit route-policy CUST_*_IN CUST_*_OUT
 60 update-only route-policy GLOBAL_TRANSIT_POLICY
 70 permit access-list EDGE_PROTECT_*
 ! Anything else: implicit deny.
!
yobgp-filter CONTROLLER_B_IN
 ! This controller may only modify what already exists.
 10 update-only prefix-list *
 20 update-only community-list *
!
router bgp 65000
 neighbor 192.0.2.1
  address-family yobgp
   import-filter CONTROLLER_A_IN
  !
 !
 neighbor 192.0.2.2
  address-family yobgp
   import-filter CONTROLLER_B_IN
  !
 !
!

A.2. Conceptual Juniper Junos Style Configuration

policy-options {
    yobgp-filter CONTROLLER_A_IN {
        /* First matching term wins. */
        term legacy-block {
            from {
                object-type prefix-list;
                name CUST_A_LEGACY_*;
            }
            then deny;
        }
        term customer-sets {
            from {
                object-type prefix-list;
                name [ CUST_A_* CUST_B_* ];
            }
            then permit;
        }
        term transit-asns {
            from {
                object-type as-path;
                name TRANSIT_ASNS_*;
            }
            then update-only;
        }
        term main-policy {
            from {
                object-type policy-statement;
                name GLOBAL_TRANSIT_POLICY;
            }
            then update-only;
        }
        /* Anything else: implicit deny. */
    }
}
protocols {
    bgp {
        group YO-BGP-PEERS {
            neighbor 192.0.2.1 {
                family yobgp {
                    import-filter CONTROLLER_A_IN;
                }
            }
        }
    }
}

The two examples use different native terms for the same object types (route-policy and policy-statement, as-path-list and as-path). The syntax is illustrative only and is not part of the specification; Section 11 defines the semantics. Both show a filter as a structured, reusable policy: ordered rules over several object types, a narrow deny before a broad permit, update-only rules for critical objects, and different filters for different peers.¶

A.3. Conceptual Administrative Commands

The first block is in the style of IOS XR, the second in the style of Junos. Neither is part of the specification.¶

! Receiver: discard the YoBGP-RIB entry of one object. The
! applied object stays.
clear yobgp prefix-list CUST_A_PL1

! Receiver: set the version of the stored entry of an object.
yobgp set-version prefix-list CUST_A_PL1 1000

! Originator: version to be used for the next change.
yobgp set-next-version prefix-list CUST_A_PL1 1000

router bgp 65000
 address-family yobgp
  ! Originator: add a constant to every Version it assigns.
  adjust-version 1500
 !
 neighbor 192.0.2.1
  address-family yobgp
   ! Receiver: limit how far a received version may exceed the
   ! stored one.
   version-jump-limit 100000
  !
 !
!

user@router> clear yobgp prefix-list CUST_A_PL1

user@router> request yobgp set-version prefix-list CUST_A_PL1
             1000

user@router> request yobgp set-next-version prefix-list
             CUST_A_PL1 1000

[edit protocols bgp]
user@router# set family yobgp adjust-version 1500

[edit protocols bgp group YO-BGP-PEERS neighbor 192.0.2.1]
user@router# set family yobgp version-jump-limit 100000

A.4. Minimum Object Types

The minimum object types of Section 11.1 correspond to the following YANG nodes. This mapping is informative and the paths must be checked against the published modules: prefix sets, neighbor sets, tag sets and policy definitions of [RFC9067]; access control lists of [RFC8519]; community sets, AS-path sets and extended community sets of the BGP YANG model [I-D.ietf-idr-bgp-model].¶

A.5. Conceptual Origination Configuration

The first block is in the style of IOS XR, the second in the style of Junos. Neither is part of the specification. The advertise statement names an object type and a name pattern. It can be configured for all peers or for one peer.¶

router bgp 65000
 address-family yobgp
  ! For all peers:
  advertise route-policy GLOBAL_TRANSIT_POLICY
  advertise community-list *
  advertise as-path-list TRANSIT_ASNS_*
 !
 neighbor 192.0.2.1
  address-family yobgp
   ! Only for this peer:
   advertise prefix-list CUST_A_*
  !
 !
!

protocols {
    bgp {
        family yobgp {
            advertise {
                policy-statement GLOBAL_TRANSIT_POLICY;
                community *;
                as-path TRANSIT_ASNS_*;
            }
        }
        group YO-BGP-PEERS {
            neighbor 192.0.2.1 {
                family yobgp {
                    advertise {
                        prefix-list CUST_A_*;
                    }
                }
            }
        }
    }
}