A YANG Data Model for BGP Communities

A YANG Data Model for BGP Communities RIPE NCC

NL mpels@ripe.net

This document defines a YANG data model for the structured specification of BGP communities. The model provides operators with a way to publish their locally defined BGP communities in a standardized format. Two YANG modules are defined in this document. The first is designed for stand-alone usage. The second is used to augment the "ietf-bgp" YANG module with BGP community annotations.

ISPs use BGP communities to add information to their prefix announcements or to let customers influence routing behaviour inside the network of the ISP. Each ISP defines for itself which BGP communities to support and how the structure of these communities should be interpreted. This document provides a YANG module for describing the structure and meaning of BGP communities, Extended BGP communities and Large BGP communities. ISPs can use this standardized format to publish their community definitions. elaborates on further advantages of using such a standardized format. and describe the base module. describes a module which augments the "ietf-bgp" YANG module with BGP community annotations.

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. The meaning of the symbols in tree diagrams are defined in .

ISPs may define various BGP communities that have local significance within their network. These communities could be used to add miscellaneous information to a prefix announcement. For example, a community "64501:1:528" may signify that the AS with ASN 64501 is originating a prefix from a point of presence in The Netherlands (ISO 3166-1 code 528). Communities could be used to allow customers of an ISP to control the routing behavior of their prefixes inside the ISP. For example, a community "64501:4:64498" attached to a prefix advertised to AS64501 by a customer may be interpreted by AS64501 to mean that this prefix must not be propagated to AS64498. For both use cases it is necessary for the ISP to communicate the meaning of their locally defined communities to others. Currently this is typically done by publishing a list of communities on a web page, or as a remark inside an "autnum" object in the Internet Routing Registry. This makes it cumbersome to determine whether and where an ISP publishes community information. The lack of a well-defined structure makes it hard to create a standardized publishing mechanism, and to develop tools for automatically parsing community information and eventually triggering configuration actions. The purpose of the YANG model defined in this document is to provide a standardized format for publishing community definitions. These definitions help applications to interpret the structure and purpose of BGP communities. For example, looking glasses may use the published definitions to parse communities seen in BGP announcements and display their meaning. Another potential use case is in generating routing policy configurations based on community definitions published by an upstream ASN. This could be achieved automatically using external tooling to generate router configurations, or inside a router's command-line interface by importing the definitions and providing the CLI-user with available choices for manual configuration. This document only describes a data model for the publishing format of community definitions. The publishing location and publishing mechanism used are outside the scope of this specification. The data model does not make any assumption about the protocol used to publish/retrieve formatted data following the model.

The following tree diagram provides an overview of the "ietf-bgp-communities" data model. module: ietf-bgp-communities +--ro bgp-communities +--ro serial? uint32 +--ro autonomous-system-id? inet:as-number +--ro uri? inet:uri +--ro description? string +--ro contact-url? inet:uri +--ro contact* [email-address] | +--ro email-address inet:email-address | +--ro name? string | +--ro role? string | +--ro organization? string | +--ro organizational-unit? string +--ro regular* [name] | +--ro name community-name | +--ro category? community-category | +--ro description? community-description | +--ro global-admin two-octet-as-number | +--ro local-admin | +--ro format? local-admin-format | +--ro field* [name] | +--ro name field-name | +--ro length? uint8 | +--ro pattern field-pattern | +--ro description? field-description +--ro extended* [name] | +--ro name community-name | +--ro category? community-category | +--ro description? community-description | +--ro type uint8 | +--ro subtype uint8 | +--ro (global-admin) | | +--:(asn) | | | +--ro asn? two-octet-as-number | | +--:(asn4) | | +--ro asn4? inet:as-number | +--ro local-admin | +--ro format? local-admin-format | +--ro field* [name] | +--ro name field-name | +--ro length? uint8 | +--ro pattern field-pattern | +--ro description? field-description +--ro large* [name] +--ro name community-name +--ro category? community-category +--ro description? community-description +--ro global-admin inet:as-number +--ro local-data-part-1 | +--ro format? local-admin-format | +--ro field* [name] | +--ro name field-name | +--ro length? uint8 | +--ro pattern field-pattern | +--ro description? field-description +--ro local-data-part-2 +--ro format? local-admin-format +--ro field* [name] +--ro name field-name +--ro length? uint8 +--ro pattern field-pattern +--ro description? field-description

This section contains the base YANG module for BGP community definitions. Several elements in this module use data types from . These data types are represented with the prefix "inet". file "ietf-bgp-communities@2025-08-26.yang" module ietf-bgp-communities { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bgp-communities"; prefix bgp-comm; import ietf-inet-types { prefix inet; reference "draft-ietf-netmod-rfc6991-bis-18: Common YANG Data Types"; } organization "IETF GROW Working Group"; contact "WG Web: WG List: Author: Martin Pels "; description "This module describes a structure for BGP Communities Copyright (c) 2025 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC YYYY; see the RFC itself for full legal notices. 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; // RFC-EDITOR: please update YYYY with this RFC ID revision 2025-08-26 { description "Initial revision."; reference "RFC YYYY: A YANG Data Model for BGP Communities RFC-EDITOR: please update YYYY with this RFC ID"; } typedef two-octet-as-number { type uint16; description "This type represents autonomous system numbers, which identify an Autonomous System (AS). Autonomous system numbers were originally limited to 16 bits. BGP extensions have enlarged the autonomous system number space to 32 bits. The two-octet-as-number type uses an uint16 base type for use cases where the enlarged number space is not supported."; reference "RFC 1930: Guidelines for creation, selection, and registration of an Autonomous System (AS)"; } typedef community-name { type string { length "1..255"; pattern '[^\s]+'; } description "This type restricts values for the name of a BGP community."; reference "RFC YYYY: A YANG Data Model for BGP Communities RFC-EDITOR: please update YYYY with this RFC ID"; } typedef community-category { type enumeration { enum informational { value 0; description "Informational community"; } enum action { value 1; description "Action community"; } } description "This type restricts values for the category of a BGP community."; reference "RFC 8195: Use of BGP Large Communities"; } typedef community-description { type string { length "1..65535"; } description "This type restricts values for the description of a BGP community."; reference "RFC YYYY: A YANG Data Model for BGP Communities RFC-EDITOR: please update YYYY with this RFC ID"; } typedef local-admin-format { type enumeration { enum decimal { value 0; description "Decimal number string"; } enum binary { value 1; description "Bit string"; } } description "This type defines the format options for a BGP community Local Administrator/Local Data field encoding"; reference "RFC YYYY: A YANG Data Model for BGP Communities RFC-EDITOR: please update YYYY with this RFC ID"; } typedef field-name { type string { length "1..255"; pattern '[^\s]+'; } description "This type restricts values for the name leaf of a BGP community Local Administrator/Local Data field."; reference "RFC YYYY: A YANG Data Model for BGP Communities RFC-EDITOR: please update YYYY with this RFC ID"; } typedef field-pattern { type string { length "1..4095"; pattern '[-0-9.,*?^$+|(){}\[\]]+'; } description "This type restricts values for the pattern leaf of a BGP community Local Administrator/Local Data field. Patterns are described as POSIX Extended Regular Expressions"; reference "IEEE 1003.2-1992: Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)"; } typedef field-description { type string { length "1..65535"; pattern '(\*)|([^*]+)'; } description "This type restricts values for the description leaf of a BGP community Local Administrator/Local Data field. The string containing a single asterisk '*' indicates that the value of the field should be used as description."; reference "RFC YYYY: A YANG Data Model for BGP Communities RFC-EDITOR: please update YYYY with this RFC ID"; } grouping local-admin-fields { description "A group of subfields inside the Local Administrator/Local Data section of a BGP Community"; list field { key "name"; ordered-by user; description "Ordered list of fields with their meanings"; leaf name { type field-name; description "The name of the field"; } leaf length { type uint8; description "Length of the field. If local-admin-format is 'decimal', this is a number of digits. In case local-admin-format is 'binary', it is a number of bits. Parsers use the field length to determine how many decimals or bits from the Local Administrator part of the community are used by this field. If this leaf is not defined, the length is assumed to be the maximum allowed length of the entire field list. In this case the field list MUST NOT contain more than one element."; } leaf pattern { type field-pattern; mandatory true; description "Used by parsers to match on the content of the field. This could be a single value or a regular expression pattern matching multiple values."; } leaf description { type field-description; description "A text description of the field pattern. This description can be used to provide meaning to specific values for a field."; } } } grouping maintainer-contact { description "A maintainer contact entry"; leaf email-address { type inet:email-address; description "Maintainer contact e-mail address"; } leaf name { type string { length "1..255"; } description "Maintainer contact name"; } leaf role { type string { length "1..255"; } description "Maintainer contact role"; } leaf organization { type string { length "1..255"; } description "Maintainer contact organization"; } leaf organizational-unit { type string { length "1..255"; } description "Maintainer contact organizational unit"; } } grouping regular-community { description "A Regular BGP community definition"; leaf name { type community-name; description "Community name"; } leaf category { type community-category; description "Category of the community"; } leaf description { type community-description; description "Description for the community"; } leaf global-admin { type two-octet-as-number; mandatory true; description "Global Administrator field"; } container local-admin { description "Local Administrator Field"; leaf format { type local-admin-format; default "decimal"; description "Format used for parsing Local Administrator subfields"; } uses local-admin-fields; } reference "RFC 1997: BGP Communities Attribute"; } grouping extended-community { description "An Extended BGP community definition"; leaf name { type community-name; description "Community name"; } leaf category { type community-category; description "Category of the community"; } leaf description { type community-description; description "Description for the community"; } leaf type { type uint8 { range "0|2|64|66"; } mandatory true; description "High-order Type of the community. Supported values are 0 (0x00) for Transitive Two-Octet AS-Specific Extended Communities, 2 (0x02) for Transitive Four-Octet AS-Specific Extended Communities, 64 (0x40) for Non-Transitive Two-Octet AS-Specific Extended Communities and 66 (0x42) for Non-Transitive Four-Octet AS-Specific Extended Communities."; } leaf subtype { type uint8; mandatory true; description "Low-order Sub-Type of the community"; } choice global-admin { mandatory true; description "Global Administrator Field"; case asn { leaf asn { type two-octet-as-number; must "../type = 0 or ../type = 64" { error-message "../type must match Two-Octet AS-Specific Community"; } description "Two-Octet AS"; } } case asn4 { leaf asn4 { type inet:as-number; must "../type = 2 or ../type = 66" { error-message "../type must match Four-Octet AS-Specific Community"; } description "Four-Octet AS"; } } } container local-admin { description "Local Administrator Field"; leaf format { type local-admin-format; default "decimal"; description "Format used for parsing Local Administrator subfields"; } uses local-admin-fields; } reference "RFC 4360: BGP Extended Communities Attribute"; } grouping large-community { description "A Large BGP community definition"; leaf name { type community-name; description "Community name"; } leaf category { type community-category; description "Category of the community"; } leaf description { type community-description; description "Description for the community"; } leaf global-admin { type inet:as-number; mandatory true; description "Global Administrator field"; } container local-data-part-1 { description "Local Data Part 1 Field"; leaf format { type local-admin-format; default "decimal"; description "Format used for parsing Local Data Part 1 subfields"; } uses local-admin-fields; } container local-data-part-2 { description "Local Data Part 2 Field"; leaf format { type local-admin-format; default "decimal"; description "Format used for parsing Local Data Part 2 subfields"; } uses local-admin-fields; } reference "RFC 8092: BGP Large Communities Attribute"; } container bgp-communities { config false; description "A community set"; leaf serial { type uint32; must ". > 0" { error-message "serial must not be 0"; } description "Version number of the community set. This value wraps and should be compared using sequence space arithmetic. Publishing implementations are free to decide how to generate this value. One example method is to use the YYYYMMDDnn syntax as commonly used inside the DNS."; reference "RFC 1912: Common DNS Operational and Configuration Errors"; } leaf autonomous-system-id { type inet:as-number; description "Autonomous System authoritative for the community set"; } leaf uri { type inet:uri; description "Publication point for the community set"; } leaf description { type string { length "1..65535"; } description "A description for the community set"; } leaf contact-url { type inet:uri; description "A reference to a webpage with maintainer contact information"; } list contact { key "email-address"; description "A list of contacts for the community set maintainer(s)"; uses maintainer-contact; } list regular { must "(./global-admin = ../autonomous-system-id) or (./global-admin >= 64512 and ./global-admin <= 65534)" { error-message "global-admin must be private ASN or match autonomous-system-id"; } key "name"; ordered-by user; description "A list of objects describing RFC 1997 BGP Communities"; uses regular-community; } list extended { must "(./asn = ../autonomous-system-id) or (./asn4 = ../autonomous-system-id) or (./asn >= 64512 and ./asn <= 65534) or (./asn4 >= 4200000000 and ./asn4 <= 4294967294)" { error-message "global-admin must be private ASN or match autonomous-system-id"; } key "name"; ordered-by user; description "A list of objects describing RFC 4360 Extended BGP Communities. Two-Octet and Four-Octet AS Specific communities are supported by this model."; uses extended-community; } list large { must "(./global-admin = ../autonomous-system-id) or (./global-admin >= 64512 and ./global-admin <= 65534) or (./global-admin >= 4200000000 and ./global-admin <= 4294967294)" { error-message "global-admin must be private ASN or match autonomous-system-id"; } key "name"; ordered-by user; description "A list of objects describing RFC 8092 Large BGP Communities"; uses large-community; } } }

]]>



    
      
        This section contains a YANG module defining augmentations for the "ietf-bgp" YANG module.
        It can be used to annotate BGP communities in a BGP RIB.
      
      
 file "ietf-bgp-communities-annotate@2025-08-26.yang"

module ietf-bgp-communities-annotate {
  yang-version 1.1;
  namespace
    "urn:ietf:params:xml:ns:yang:ietf-bgp-communities-annotate";
  prefix bgp-comm-an;

  import ietf-bgp-communities {
    prefix bgp-comm;
    reference
      "draft-ietf-grow-yang-bgp-communities-07: A YANG Data
       Model for BGP Communities";
  }
  import ietf-routing {
    prefix rt;
    reference
      "RFC 8349: A YANG Data Model for Routing Management
       (NMDA Version).";
  }
  import ietf-bgp {
    prefix bgp;
    reference
      "draft-ietf-idr-bgp-model-18: YANG Model for Border
       Gateway Protocol (BGP-4)";
  }

  organization
    "IETF GROW Working Group";
  contact
    "WG Web:   
     WG List:  

     Author:   Martin Pels
       ";
  description
    "This module augments the ietf-bgp module with support for
     community annotations.

     Copyright (c) 2025 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC YYYY; see
     the RFC itself for full legal notices.

     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 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.";

  // RFC-EDITOR: please update YYYY with this RFC ID

  revision 2025-08-26 {
    description
      "Initial revision.";
    reference
      "RFC YYYY: A YANG Data Model for BGP Communities
       RFC-EDITOR: please update YYYY with this RFC ID";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bgp:bgp/bgp:rib/"
        + "bgp:communities/bgp:community" {
    description
      "Augments a Regular BGP community from the
       ietf-bgp module with an optional annotation.";
    container annotation {
      presence "true";
      description
        "The presence of this container indicates
         that a community definition is available";
      uses bgp-comm:regular-community;
    }
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bgp:bgp/bgp:rib/"
        + "bgp:ext-communities/bgp:ext-community" {
    description
      "Augments an Extended BGP community from the
       ietf-bgp module with an optional annotation.";
    container annotation {
      presence "true";
      description
        "The presence of this container indicates
         that a community definition is available";
      uses bgp-comm:extended-community;
    }
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bgp:bgp/bgp:rib/"
        + "bgp:large-communities/bgp:large-community" {
    description
      "Augments a Large BGP community from the
       ietf-bgp module with an optional annotation.";
    container annotation {
      presence "true";
      description
        "The presence of this container indicates
         that a community definition is available";
      uses bgp-comm:large-community;
    }
  }
}

]]>
      

    


    

      
        
          Operators SHOULD only publish BGP community definitions for networks they control.
          This may include communities where the Global Administrator field contains a private ASN, if this community has a local meaning inside the network of the publisher.
        
        
          When publishing community definitions with overlapping field patterns, these definitions MUST be ordered from most to least preferred.
          This ensures parsers can perform deterministic matching (see ).
          For example, a definition for a single community "64500:123" needs to be specified before a definition that matches a covering range of communities "64500:*".
        
      

      
        
          A published BGP community definition can be used by parsers to display information about a received community.
          If a received community matches multiple published community definitions, the first matching definition in the published order takes precedence.
        
        
          Parsers that use published community definitions from multiple operators SHOULD NOT attempt to match received communities where the Global Administrator field contains a private ASN, unless they have some method to determine which published definition is the authoritative one.
        
        
          By default, communities are compared using the decimal representation of the fields. If "format" for a Local Administrator or Local Data Part is set to "binary", the fields in the received community are converted to strings of zeros and ones before comparison.
        
        
          See  for security considerations when parsing community definitions.
        
      

    

    

      
        
          This document registers the following XML namespace URN in the "IETF
          XML Registry", following the format defined in :
        
        
URI: urn:ietf:params:xml:ns:yang:ietf-bgp-communities
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
        
      

      
        
          This document registers the following YANG module in the "YANG Module Names" registry :
        
        
Name: ietf-bgp-communities
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-bgp-communities
Prefix: bgp-comm
Reference: RFC YYYY
RFC-EDITOR: please update YYYY with this RFC ID
        
      

      
        
          This document registers the following entry in the "IETF YANG SID" registry :
        
        
SID range entry point: TBD
SID range size: 100
YANG module name: ietf-bgp-communities
Reference: RFC YYYY
RFC-EDITOR: please update YYYY with this RFC ID
        
      

    

    

      
        RFC-EDITOR: Please remove this section and the accompanying reference(s) before publication.
      

     
       This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in .
       The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs.
       Please note that the listing of any individual implementation here does not imply endorsement by the IETF.
       Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors.
       This is not intended as, and must not be construed to be, a catalog of available implementations or their features.
       Readers are advised to note that other implementations may exist.
     

     
       According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.
       It is up to the individual working groups to use this information as they see fit".
     

      

        
          The following networks are known to publish BGP community definitions according to this specification.
        

        Publishing implementations
          
          
            
              ASN
              Publication URI
              YANG model revision
            
          
          
            
              197000
              as197000.json
              2025-08-26
            
            
              25152
              as25152.json
              2025-08-26
            
          
        

      

      

        
          The following known parser implementations exist.
        

        Parser implementations
          
          
            
              Name
              YANG model revision
            
          
          
            
              NLNOG Looking Glass
              2025-07-04
            
          
        

      

    
    
    

      

        
          This section is modeled after the template described in Section 3.7 of .
        
        
          The "ietf-bgp-communities" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF  and RESTCONF .
          These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH , TLS , and QUIC ) and (2) have to use mutual authentication.
        
        
          The Network Configuration Access Control Model (NACM)  provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
        
        
          There are no data nodes defined in this YANG module that are writable/creatable/deletable.
        
        
          Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments.
          Specifically, the following subtrees and data nodes have particular sensitivities/vulnerabilities:
        
        
         bgp-communities/contact/email-address
         bgp-communities/contact/name
        
        
          Disclosing this information may be misused, e.g., for tracking and data correlation.
          Publishers MUST NOT populate these elements with Personally Identifiable Information (PII).
          For example, these elements may be set with information that refers to generic contact information, not pointing to specific individuals.
        

      

      

        
          The YANG module described in this document may be used to specify BGP community definitions in different serialization formats, such as XML, JSON or CBOR.
          Applications that parse these community definitions SHOULD reject objects that do not conform to the YANG model.
          Furthermore, parsers SHOULD check that the sum of the specified Local Administrator or Local Data Part field lengths in each community definition does not exceed the local part size of the specified community type.
          For example, a Regular BGP community definition with format "decimal" containing a field of length 4 and a field of length 2 would be illegal, as the Local Administrator field has a maximum length of 65535 (5 digits).
        
        
          The "bgp-communities/contact-url" element may contain a link to an untrusted webpage.
          Parsers MAY opt to render the URL as plain text rather than a clickable link, to prevent inadvertent exposure of information by users of the rendered output.
        
        
          Several elements with the "string" data type may be used to display information in a web page or application.
          Parsers should take care that the appropriate escaping is performed to protect against cross-site scripting attacks.

ASN	Publication URI	YANG model revision
197000	as197000.json	2025-08-26
25152	as25152.json	2025-08-26

Name	YANG model revision
NLNOG Looking Glass	2025-07-04



  

    

      &I-D.ietf-idr-bgp-model;
      &I-D.ietf-netmod-rfc6991-bis;
      &RFC1930;
      &RFC1997;
      &RFC4360;
      &RFC7950;
      &RFC8092;
      &RFC8341;
      &RFC8349;
      &RFC9595;

    

    

      &I-D.ietf-netmod-rfc8407bis;
      &IEEE.1003-2.1992;
      &RFC1912;
      &RFC2119;
      &RFC3688;
      &RFC4252;
      &RFC4384;
      &RFC6020;
      &RFC6241;
      &RFC7942;
      &RFC7951;
      &RFC8040;
      &RFC8174;
      &RFC8195;
      &RFC8340;
      &RFC8446;
      &RFC8792;
      &RFC9000;

    

    

      
        This section shows example use cases for the YANG module defined in this document, using JSON encoding (see ).
        The examples contain long lines that may be folded, as described in .
      

      
        
          A JSON definition for the example Large BGP community described in , Section 4.1.1 looks as follows.
        
        
=============== NOTE: '\' line wrapping per RFC 8792 ================

{
  "ietf-bgp-communities:bgp-communities": {
    "autonomous-system-id": 64497,
    "serial": 2023080101,
    "uri": "http://example.net/peering/communities",
    "description": "BGP Community example for ASN-Based Selective \
NO_EXPORT",
    "contact": [
      {
        "email-address": "noc@example.net",
        "name": "Example.net contact",
        "role": "Administrative contact",
        "organization": "Example.net",
        "organizational-unit": "NOC"
      }
    ],
    "large": [
      {
        "name": "RFC8195-NOEXPORT-ASN",
        "category": "action",
        "description": "Do not export route to ASN",
        "global-admin": 64497,
        "local-data-part-1": {
          "field": [
            {
              "name": "Function",
              "pattern": "4",
              "description": "ASN-No-Export"
            }
          ]
        },
        "local-data-part-2": {
          "field": [
            {
              "name": "ASN",
              "pattern": ".*",
              "description": "*"
            }
          ]
        }
      }
    ]
  }
}
        
      

      
        
          A JSON definition for the example Regular and Extended BGP communities described in , Section 4 looks as follows.
        
        
=============== NOTE: '\' line wrapping per RFC 8792 ================

{
  "ietf-bgp-communities:bgp-communities": {
    "autonomous-system-id": 10876,
    "serial": 2023080101,
    "uri": "http://example.net/peering/communities",
    "description": "BGP Community example for Data Collection",
    "contact-url": "https://example.net/contact",
    "regular": [
      {
        "name": "RFC4384-REGULAR-ORIGIN-OC/FJ",
        "description": "A national route over a terrestrial link \
from the Fiji Islands",
        "global-admin": 10876,
        "local-admin": {
          "format": "binary",
          "field": [
            {
              "name": "Region",
              "length": 5,
              "pattern": "00010",
              "description": "OC"
            },
            {
              "name": "Satellite",
              "length": 1,
              "pattern": "0",
              "description": "*"
            },
            {
              "name": "Country",
              "length": 10,
              "pattern": "0011110010",
              "description": "FJ"
            }
          ]
        }
      }
    ],
    "extended": [
      {
        "name": "RFC4384-EXTENDED-ORIGIN-OC/FJ",
        "description": "A national route over a terrestrial link \
from the Fiji Islands",
        "type": 0,
        "subtype": 8,
        "asn": 10876,
        "local-admin": {
          "format": "binary",
          "field": [
            {
              "name": "Reserved",
              "length": 16,
              "pattern": "0000000000000000"
            },
            {
              "name": "Region",
              "length": 5,
              "pattern": "00010",
              "description": "OC"
            },
            {
              "name": "Satellite",
              "length": 1,
              "pattern": "0",
              "description": "*"
            },
            {
              "name": "Country",
              "length": 10,
              "pattern": "0011110010",
              "description": "FJ"
            }
          ]
        }
      }
    ]
  }
}
        
      

    

    

      
        The author would like to thank Jeffrey Haas, Luuk Hendriks, Jasper den Hertog, Teun Vink, Tom Petch, Dale Carder, Mohamed Boucadair and Ladislav Lhotka for contributing ideas and feedback to this document.