Quantcom, a.s.

zbynek.pospichal@quantcom.cz

Routing Inter-Domain Routing BGP YANG configuration This document defines YANG over BGP (YoBGP), an extension of BGP for distributing network configuration objects (for example routing policies, prefix sets, community sets, and access control lists) modeled in YANG. Objects are carried in a dedicated Address Family (AFI/SAFI) and spread between routers the way routes do: they are advertised to peers, carry a version, are filtered on receipt, and are optionally re-advertised. Received objects are subject to a per-peer inbound filtering framework, persist in the receiving node's configuration independently of the state of the BGP session, and are removed only by an explicit, versioned tombstone. Its goal is effortless synchronization of selected configuration settings across a large number of BGP speakers. The framework is schema-agnostic: any YANG module, including vendor-specific ones, can be distributed.

Introduction The main goal of YoBGP is effortless synchronization of selected configuration settings across a large number of BGP speakers. Operators of large networks need selected configuration objects (routing policies, prefix sets, community sets, AS-path sets, access control lists) to be identical on many routers. This is usually achieved with automation engines (Ansible, NETCONF clients, SSH scripting) that open an administrative session to every router. Such engines hold credentials with elevated privileges for the whole fleet, and managing that access is itself an operational and security burden. This document defines YANG over BGP (YoBGP), which extends BGP with a new address family for distributing configuration objects modeled in YANG. A YoBGP object is distributed the way a route is: it is originated by one or more routers, optionally propagated through the BGP topology (including through route reflectors), and received by routers that decide locally, per peer, whether and how to apply it. No management session and no additional credentials are introduced; the existing BGP peering is the only channel. YoBGP is a transport framework. It is decoupled from the schemas it distributes, such as , and the BGP YANG model , and is open to any other YANG module, including vendor-specific ones (Section ).

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 ). 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 and ).
• Deterministic convergence: all speakers settle on the same version of an object regardless of arrival order or propagation path (Section ).
• Openness: any YANG module can be distributed, and vendors can add their own data without a new specification (Section ).

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.

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 ).
• Atomic multi-object commit or rollback orchestration. Each object is versioned and applied individually; dependencies between objects are handled locally by the receiver (Section ).
• Origin authentication of objects beyond what the BGP session provides (Section ).

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) 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 , 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 ).

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 , which sends a filter to a peer to be applied to what that peer advertises, and to Flow Specification , which distributes traffic filtering rules. Neither carries configuration objects that the receiver stores. Finally, YoBGP complements management protocols such as NETCONF 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.

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 when, and only when, they appear in all capitals, as shown here.

Terminology

• YoBGP object: an instance of a YANG schema node (typically a list entry), for example one prefix set or one policy definition.
• Object key: the tuple (Object Type, Object Name) carried in the NLRI. It identifies a YoBGP object.
• Version: a 64-bit unsigned integer ordering the successive states of one object (Section ).
• Originator: a speaker that places an object into its YoBGP-RIB from its own configuration instead of receiving it from a peer (Section ).
• Tombstone: an object with zero fragments (Fragment Count 0). It removes the object from the managed configuration (Section ).
• YoBGP-RIB: the volatile store with one entry per object key, holding the current admitted object (Section ). It corresponds to a RIB.
• YoBGP-CIB: the Configuration Information Base: the objects that YoBGP has applied, which are part of the node's own persistent configuration. It carries no state of its own. It corresponds to a FIB: the YoBGP-RIB holds what is current, the YoBGP-CIB holds what is installed; unlike a FIB, it survives restarts (Sections and ).
• Active configuration: the configuration currently in effect on the node.
• Applying: handing an object's payload to the node's configuration parser for validation and injection into the active configuration.

Overview of Operation A YoBGP UPDATE carries exactly one fragment of an object (Section ). A receiving speaker validates and filters each fragment (steps 1 and 2), reassembles the object, and then processes the complete object as it would process a route (steps 3 to 5):

1. The NLRI and the YoBGP attribute are validated (Sections and ).
2. The import filter of the receiving peer decides whether the object is admitted (Section ). An object that is not admitted is discarded; it is neither stored nor propagated.
3. An admitted object is compared by version with the current entry for the same object key in the YoBGP-RIB; a newer version replaces the entry (Section ).
4. A new or replaced entry is eligible for propagation to other peers (Section ), whether or not it can be applied on this node.
5. The entry is checked for dependencies and handed to the configuration parser (Section ). On success the object is part of the node's configuration, that is, of the YoBGP-CIB (Section ). The outcome sets the status of the entry; it does not remove the entry from the YoBGP-RIB.

YoBGP-NLRI The YoBGP-NLRI is carried in MP_REACH_NLRI and MP_UNREACH_NLRI under AFI=TBA1 and SAFI=TBA2. The NLRI carries the object key and the number of one fragment of the object (Section ). Version and content are carried in the YoBGP attribute (Section ). As with Flow Specification , the Length of Next Hop Network Address field in MP_REACH_NLRI MUST be 0 and receivers MUST ignore any next hop. An UPDATE for this AFI/SAFI MUST carry exactly one NLRI in MP_REACH_NLRI, because the path attributes that follow describe that one fragment. An UPDATE with more than one NLRI is handled as an attribute error (Section ).

• NLRI Type (8 bits): 1 = YANG Object. A receiver MUST skip, using NLRI Length, any NLRI of an unknown type and SHOULD log it, as requires for typed NLRI. This leaves room for future NLRI formats.
• NLRI Length (16 bits): number of octets that follow.
• Fragment Number (16 bits): the number k of the fragment, from 1 to the Fragment Count N, or 0 in a tombstone (Section ).
• Object Type Length (16 bits) and Object Type: the path of data node names, separated by "/", from the top-level data node to the schema node of the object, as a UTF-8 string. Each name is written as an RFC 7951 member name: it is qualified with its module name at the top-level node and wherever the namespace differs from that of its parent, and unqualified otherwise. The module that defines the object is the module of the last name on the path. Example: "ietf-routing-policy:routing-policy/defined-sets/prefix-sets/prefix-set".
• Object Name Length (16 bits) and Object Name: a UTF-8 string that identifies the instance of the object. It has one segment for each list on the path from the top-level data node to the object, including the object itself if it is a list entry, in path order and separated by "/". A segment holds the key values of that list entry in the order of the list's key statement, each in the canonical form of and separated by ",". Within a key value, the characters "%", "/" and "," are written as %25, %2F and %2C. An entry named main of a list that is nested in the entry named 192.0.2.1 of another list has the Object Name 192.0.2.1/main. An object that is not a list entry and has no list on its path has an empty Object Name.

The key is built entirely from identifiers in clear text, so a speaker can filter, store and propagate an object without parsing its payload, and can name an unsupported module in a log message.

YoBGP Attribute

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

• Version (64 bits): see Section . 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 .
• Fragment Count (16 bits): the number N of fragments of the object, or 0 for a tombstone (Section ).
• Payload: one piece of the serialized object (Section ). It extends to the end of the attribute. A tombstone has an empty payload, and any octets after the Fragment Count are ignored.

Error Handling for Malformed Objects 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 : 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 ), 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 . The speaker SHOULD use the AFI/SAFI disable approach of and , that is, ignore all subsequent YoBGP routes received over the session. Session reset is the other approach that allows, but it is not RECOMMENDED because it also drops every other address family. Objects already applied are not affected by either approach.

Payload Structure The payload, which is the byte string that results from reassembly (Section ), is JSON text 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 ). 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.

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 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 ). 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 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 (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 ) 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 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 ).

Object Versioning and the YoBGP-RIB

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 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.

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 ); what has been applied is part of the node's configuration (the YoBGP-CIB).

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 ):

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 ) and for application (Section ).

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 ).

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 ). 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 shows hypothetical commands.

Tombstones An object is removed from the managed configuration only by a tombstone: a regular advertisement (MP_REACH_NLRI) with Fragment Count 0 (Section ), the same object key, and a Version higher than that of the state being removed. A tombstone is ordered by Version like any other state, so a delayed older advertisement cannot bring a deleted object back while the tombstone is retained, and a late tombstone can never delete a newer object.

• A tombstone that the import filter admits is stored in the YoBGP-RIB and propagated like any other entry.
• If the import filter admits the tombstone (action permit), the node deletes the object from the active configuration, including an object that was created locally, subject to the dependency rule in Section . Under update-only and deny the tombstone is not admitted (Section ).
• A later advertisement whose state supersedes the tombstone's re-creates the object.
• A tombstone is retained in the YoBGP-RIB for a configurable time, 3600 seconds by default, counted from the moment it became the current entry. When the time expires, the entry is discarded together with the ordering state it carries. A tombstone that is still pending (Section ) is not aged until it has been applied. Implementations MUST allow the time to be configured and SHOULD allow aging to be disabled.

Tombstones exist only in the YoBGP-RIB, which is volatile, so a restart discards them. Two things can follow from the expiry or loss of a tombstone. A node that was disconnected for longer than the retention time misses the deletion and keeps the object until it receives a tombstone again or an operator removes it. In transitive mode, a node that still holds an older state of the object can advertise it to peers that no longer hold the tombstone, and so bring the object back. A non-transitive node does not advertise received entries, so this cannot spread from it. Transitive mode therefore needs increased attention (Section ). The retention time should exceed the longest outage after which a node can be expected to rejoin. Peers that still retain the tombstone advertise it when the session is established (Section ).

Persistence The YoBGP-CIB is persistent: the objects that YoBGP has applied are stored with the node's persistent configuration and MUST survive a restart of the node. Loss of the BGP session, expiry of the Hold Timer and withdrawal by MP_UNREACH_NLRI MUST NOT remove objects from the YoBGP-CIB or from the active configuration. This is a deliberate difference from the treatment of ordinary routes, which are removed with the session. The YoBGP-RIB is not persistent and SHOULD NOT be written to persistent storage. It is empty after a restart and is filled again by the peers (Section ). Entries remain in the YoBGP-RIB when a session is lost, until the router restarts, so that the speaker can still advertise them to other peers. After a restart the ordering of states is rebuilt from the peers: the first state received for an object is accepted, and later states supersede it as usual (Section ). An implementation MAY provide, per peer, a purge-on-session-loss option, disabled by default. When enabled, on loss of the session the entries received from that peer are removed from the YoBGP-RIB, and the objects that those entries applied are removed from the node's configuration, as if by tombstone and subject to Section . Objects applied before a restart are not tracked by this option, because the YoBGP-RIB is empty after a restart.

Originating Objects A speaker originates an object when it places the object into its YoBGP-RIB from its own configuration instead of receiving it from a peer. Origination is configured with an advertise statement, modeled on the way routes are originated. Appendix shows examples.

The advertise Statement The operator names an object type and an object name pattern, using the pattern syntax of Section . 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.

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 . A peer covered by overlapping statements receives the object once.

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 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 ). 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 , may be sent).
• Dependencies. The speaker SHOULD originate referenced objects before the objects that reference them (Section ).
• Restart. Originated entries are rebuilt from the configuration. Versions should survive the restart (Section ). A clock-based Version gives unchanged objects a new Version after a restart, which is harmless but makes receivers apply them again.

Transitivity and Propagation

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 . Loops end by themselves: an entry that returns is a duplicate under Section 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 ), so a faulty object is removed only by a tombstone, and the retention of tombstones is limited (Section ). Transitive mode should be enabled only on a small number of well-controlled speakers (Section ).

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 ) and decides only whether an entry is advertised to a peer.

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 ). The same procedure is followed when a ROUTE-REFRESH message for this AFI/SAFI is received.

Inbound Object Filtering Every peer has an import filter that decides which received objects are admitted into the YoBGP-RIB, and thereby applied to the active configuration. It works as inbound policy does for routes: it is evaluated on arrival, before the YoBGP-RIB is updated, and an object it does not admit is discarded. The filter uses the object key and the Fragment Count (0 marks a tombstone), so it does not require parsing the payload.

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 ), 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 ), 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.

Effect of Each Action Effect of each action

Action	Object absent in active configuration	Object exists in active configuration	Tombstone
permit	instantiate	overwrite	delete
update-only	rejected	overwrite	rejected
deny	rejected	rejected	rejected

"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 .

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.

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 . 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.

Applying Objects

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.

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 ), 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 ), 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.

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 and ) becomes an object of the YoBGP-CIB. An object deleted by a tombstone, or removed by the purge-on-session-loss option (Section ), 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 ) 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.

Extensibility YoBGP distributes any YANG data that can be named by an Object Type. A vendor or operator can distribute data from its own module simply by naming it in the Object Type; no registration is needed. A speaker that meets an unsupported module stores, and in transitive mode propagates, the object, and treats it as a payload error when it would otherwise apply it (Section ). New kinds of objects need no extension of the protocol, because they are YANG data. New NLRI types are registered in the registry of Section . Objects with far-reaching effects, such as a new BGP neighbor definition for a route reflector taken from the BGP YANG model , need no special mechanism. They are distributed as any other object and, being subject to implicit deny, are applied only where an operator permits them explicitly.

Operational Considerations

• There is no feedback. Implementations SHOULD expose the YoBGP-RIB, with version, source peer and application status for each entry, so operators can compare nodes and find drift.
• Where more than one originator can advertise the same object, operators should coordinate object names, or accept that the highest version wins and that equal versions are settled by Source Router ID.
• Applied objects persist after a controller is decommissioned. Remove them with tombstones.
• An originator that restarts without its Version counter issues Versions that are lower than those the receivers already hold, and the receivers ignore them without any signal. To prevent this, derive Versions from a clock or keep the counter in persistent storage (Section ). If it happens, raise the version offset or set the Version to be used next on the originator above the highest Version in the network, or discard the entries at the receivers (Section and Appendix ).
• Rejected objects are not retained. After changing a filter, or after creating locally an object that an update-only rule should maintain, request a refresh from the peer (Section ).
• Tombstones age out (Section ). A node that was disconnected for longer than the retention time and still holds an object that has since been deleted can bring it back when it rejoins; such nodes should be checked after long outages.
• Transitive mode needs increased attention (Sections and ). Enable it only on a small number of well-controlled speakers and keep the default elsewhere.
• Because transitivity is off by default and filters deny by default, a rollout can start with one originator, one peer and a narrow permit rule.

One possible deployment uses a single server that originates the objects. The server peers with the route reflectors or route servers, where transitive mode is enabled with great care, and from there the objects reach all other routers, which keep the default non-transitive mode. In specific cases transitive mode can also be enabled on a speaker that serves customers, to distribute objects to the customer-edge devices of large customers.

Security Considerations

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.

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.

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 ; YoBGP's filter is a separate mechanism and should be aligned with it in deployment.

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

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.

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 ) 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 .

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 ) 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.

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.

IANA Considerations This document requests the following. Registration policies are named as in .

• Address Family Numbers registry: AFI = TBA1 (YoBGP Configuration).
• SAFI Values registry: SAFI = TBA2 (YoBGP Service).
• BGP Path Attributes registry: type code TBA3, YoBGP Attribute (optional, non-transitive).
• New registry "YoBGP NLRI Types": 0 Reserved; 1 YANG Object; 2-239 IETF Review; 240-254 Experimental Use; 255 Reserved.

The AFI/SAFI pair is requested as a new pair, and not as a SAFI under AFI 1 or 2, because configuration objects are not addresses and tying the service to an IP address family would be arbitrary. The BGP-LS service is the precedent: it carries data that is not address information under its own AFI and SAFIs.

References Normative References Informative References

Informative Material

Conceptual Cisco IOS XR Style Configuration

Conceptual Juniper Junos Style Configuration 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 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.

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. 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]]>

Minimum Object Types The minimum object types of Section 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 ; access control lists of ; community sets, AS-path sets and extended community sets of the BGP YANG model .

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.

Open Issues This section is to be removed before publishing as an RFC.

1. Attribute type code; whether a SAFI under an existing AFI is enough instead of a new AFI.
2. Positioning relative to RPD (Section ) and the current status of that draft, to be checked with the IDR chairs and the authors of that draft.
3. Revision numbers and dates of the draft references (RPD, Wide Community, BGP YANG model) to be refreshed when this draft is submitted.

Use of AI Assistance This document was written with the assistance of an AI system. Using the keys of : mode is ai-originated, because the text of this version was generated by the AI from the design decisions of the author and from an earlier draft supplied by the author, and then revised repeatedly at the author's direction; model is Claude, with several versions used and not recorded; provider is Anthropic; and reviewed-by is the author. The design is the author's. The AI also proposed details of the text and of the protocol, which the author reviewed, changed or accepted, and the author is responsible for the whole document.