Inter-Domain Routing (idr) Internet Drafts

      
 BGP Bestpath Selection Criteria Enhancement
 
 draft-ietf-idr-bgp-bestpath-selection-criteria-13.txt
 Date: 14/09/2026
 Authors: Rajiv Asati
 Working Group: Inter-Domain Routing (idr)
 BGP specification (RFC4271) prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and would desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane.
 BGP Flow-Spec Redirect-to-IP Action
 
 draft-ietf-idr-flowspec-redirect-ip-16.txt
 Date: 21/05/2026
 Authors: Jeff Haas, Wim Henderickx, Adam Simpson
 Working Group: Inter-Domain Routing (idr)
 Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications, but the primary one for many network operators is the distribution of traffic filtering actions for distributed denial of service (DDoS) mitigation. The flow-spec standard, RFC 8955, defines a redirect-to-VRF (Virtual Routing and Forwarding) action for policy- based forwarding. This mechanism can be difficult to use, particularly in networks without Layer 3 VPN infrastructure. This document defines a new redirect-to-IP flow-spec action that provides a simpler method of policy-based forwarding. The details of the action, including the IPv4 or IPv6 target address, are encoded in newly defined BGP extended communities [RFC4360].
 RT-Constrain Optimization in Hierarchical Route Reflection Scenarios
 
 draft-ietf-idr-rtc-hierarchical-rr-06.txt
 Date: 03/09/2026
 Authors: Jie Dong, Mach Chen, RASZUK Robert
 Working Group: Inter-Domain Routing (idr)
 The Route Target (RT) Constrain mechanism specified in RFC 4684 is used to build a route distribution graph in order to restrict the propagation of Virtual Private Network (VPN) routes. In network scenarios where hierarchical route reflection (RR) is used, the existing RT-Constrain mechanism cannot guarantee a correct route distribution graph. This document describes the problem scenario and proposes solutions to address the RT-Constrain issue in hierarchical RR scenarios.
 YANG Model for Border Gateway Protocol (BGP-4)
 
 draft-ietf-idr-bgp-model-21.txt
 Date: 14/08/2026
 Authors: Mahesh Jethanandani, Keyur Patel, Sue Hares, Jeff Haas
 Working Group: Inter-Domain Routing (idr)
 This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects, such as RIB, based on data center, carrier, and content provider operational requirements.
 BGP Dissemination of Flow Specification Rules for Tunneled Traffic
 
 draft-ietf-idr-flowspec-nvo3-24.txt
 Date: 03/06/2026
 Authors: Donald Eastlake, Hao Weiguo, Shunwan Zhuang, Zhenbin Li, Rong Gu
 Working Group: Inter-Domain Routing (idr)
 This draft specifies a Border Gateway Protocol (BGP) Network Layer Reachability Information (NLRI) encoding format for flow specifications (RFC 8955) that can match on a variety of tunneled traffic. In addition, flow specification components are specified for certain tunneling header fields.
 Flowspec Indirection-id Redirect
 
 draft-ietf-idr-flowspec-path-redirect-13.txt
 Date: 22/04/2026
 Authors: Gunter Van de Velde, Keyur Patel, Zhenbin Li
 Working Group: Inter-Domain Routing (idr)
 This document defines a new extended community known as "FlowSpec Redirect to indirection-id Extended Community". This extended community triggers advanced redirection capabilities to flowspec clients. When activated, this flowspec extended community is used by a flowspec client to retrieve the corresponding next-hop and encoding information within a localised indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the operation of the available paths.
 BGP-LS Extensions for Inter-AS Topology Retrieval
 
 draft-ietf-idr-bgpls-inter-as-topology-ext-44.txt
 Date: 13/09/2026
 Authors: Aijun Wang, Huaimo Chen, Ketan Talaulikar, Shunwan Zhuang, Changwang Lin
 Working Group: Inter-Domain Routing (idr)
 This document specifies the procedures for distributing Border Gateway Protocol-Link State (BGP-LS) key parameters for inter-domain links between two Autonomous Systems (ASes). It defines a new type within the BGP-LS Network Layer Reachability Information (NLRI) for an Inter-AS Link, along with three new Type-Length-Values (TLVs) descriptors for the BGP-LS Inter-AS Link. These extensions and procedures allow network operators to collect inter-domain interconnect information and automatically compute the inter-AS topology using information provided by the BGP-LS protocol.
 BGP BFD Strict-Mode
 
 draft-ietf-idr-bgp-bfd-strict-mode-19.txt
 Date: 26/08/2026
 Authors: Mercia Zheng, Acee Lindem, Jeff Haas, Albert Fu
 Working Group: Inter-Domain Routing (idr)
 This document specifies extensions to RFC4271 BGP-4 that enable a BGP speaker to negotiate additional Bidirectional Forwarding Detection (BFD) extensions using a BGP capability. This BFD Strict-Mode Capability enables a BGP speaker to prevent a BGP session from being established until a BFD session is established. This is referred to as BFD "strict-mode".
 SR Policy Extensions for Path Segment and Bidirectional Path
 
 draft-ietf-idr-sr-policy-path-segment-16.txt
 Date: 29/06/2026
 Authors: Cheng Li, Zhenbin Li, Yuanyang Yin, Weiqiang Cheng, Ketan Talaulikar
 Working Group: Inter-Domain Routing (idr)
 BGP SR Policy address-family is used for signaling of individual candidate paths of a Segment Routing Policy. This document specifies extensions for the signaling of a Path Segment Identifier associated with the Segment List(s) of a candidate path. It also specifies extensions for the signaling of the Segment List(s) in the reverse direction when Bidirectional SR Policies are used.
 SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS
 
 draft-ietf-idr-bgp-ls-sr-policy-path-segment-12.txt
 Date: 27/08/2026
 Authors: Cheng Li, Zhenbin Li, Yongqing Zhu, Weiqiang Cheng, Ketan Talaulikar
 Working Group: Inter-Domain Routing (idr)
 This document specifies the way of collecting configuration and states of SR policies carrying Path Segment and bidirectional path information by using BPG-LS. Such information can be used by external conponents for many use cases such as performance measurement, path re-optimization and end-to-end protection.
 Segment Routing Path MTU in BGP
 
 draft-ietf-idr-sr-policy-path-mtu-15.txt
 Date: 17/08/2026
 Authors: Cheng Li, Yongqing Zhu, Ahmed El Sawaf, Zhenbin Li, Guanming Zeng
 Working Group: Inter-Domain Routing (idr)
 Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR policy is a set of SR Policy candidate paths consisting of one or more segments with the appropriate SR path attributes. BGP distributes each SR Policy candidate path as combination of an prefix plus a the BGP Tunnel Encapsulation(Tunnel-Encaps) attribute containing an SR Policy Tunnel TLV with information on the SR Policy candidate path as a tunnel. However, the path maximum transmission unit (MTU) information for a segment list for SR path is not currently passed in the BGP Tunnel-Encaps attribute. . This document defines extensions to BGP to distribute path MTU information within SR policies.
 Signaling Maximum Transmission Unit (MTU) using BGP-LS
 
 draft-ietf-idr-bgp-ls-link-mtu-12.txt
 Date: 20/05/2026
 Authors: Yongqing Zhu, Zhibo Hu, Shuping Peng, Robbins Mwehair
 Working Group: Inter-Domain Routing (idr)
 Segment Routing (SR) leverages the source routing paradigm, which can be directly applied to the MPLS architecture and IPv6 architecture, with a new type of routing header. Since multiple labels or SRv6 SIDs are pushed in the packets, it is more likely that the packet size exceeds the path MTU of SR tunnel. However, SR uses the IGP as the routing protocol and does not support the negotiation of the Path MTU. BGP Link State (BGP-LS) describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This document specifies the extensions to BGP-LS to carry MTU information of link. The centralized controller (PCE/SDN) calculates the Path MTU while completing the service path calculation based on the information transmitted by the BGP-LS.
 BGP SR Policy Extensions to Enable IFIT
 
 draft-ietf-idr-sr-policy-ifit-12.txt
 Date: 17/04/2026
 Authors: Fengwei Qin, Hang Yuan, Shunxing Yang, Tianran Zhou, Giuseppe Fioccola
 Working Group: Inter-Domain Routing (idr)
 Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular the most popular are In-situ OAM (IOAM) and Alternate Marking. This document defines extensions to BGP to distribute SR policies carrying IFIT information. So that IFIT methods can be enabled automatically when the SR policy is applied.
 BGP Link-State Extensions for BGP-only Networks
 
 draft-ietf-idr-bgp-ls-bgp-only-fabric-07.txt
 Date: 19/08/2026
 Authors: Ketan Talaulikar, Aravind MahendraBabu, Clarence Filsfils, Krishnaswamy Ananthamurthy, Shawn Zandi, Gaurav Dawra, Muhammad Durrani
 Working Group: Inter-Domain Routing (idr)
 BGP is used as the only routing protocol in some networks today. In such networks, it is useful to get a detailed topology view similar to one available when using link state routing protocols. This document defines extensions to the BGP Link-state (BGP-LS) address- family and the procedures for advertisement of topology information in a BGP-only network.
 SD-WAN Edge and Underlay Tunnel Discovery Using BGP
 
 draft-ietf-idr-sdwan-edge-discovery-31.txt
 Date: 15/09/2026
 Authors: Linda Dunbar, Sue Hares, Kausik Majumdar, RASZUK Robert, Venkit Kasiviswanathan
 Working Group: Inter-Domain Routing (idr)
 This document specifies BGP mechanisms for SD-WAN (Software-Defined Wide Area Network) edge node attribute discovery. These mechanisms comprise a new tunnel type and associated Sub-TLVs for the BGP Tunnel Encapsulation Attribute, and a new Subsequent Address Family Identifier (SAFI) carrying a typed NLRI for advertising SD-WAN underlay tunnel information.
 BGP Flow Specification for SRv6
 
 draft-ietf-idr-flowspec-srv6-10.txt
 Date: 16/09/2026
 Authors: Zhenbin Li, Huaimo Chen, Christoph Loibl, Gyan Mishra, Yongqing Zhu, Shunwan Zhuang
 Working Group: Inter-Domain Routing (idr)
 This document specifies extensions to BGP Flow Specification (BGP-FS) to enable filtering of IPv6 packets based on the structural components of an SRv6 Segment Identifier (SID) present in the IPv6 Destination Address (representing the active segment of an SRv6 path).
 Applicability of Border Gateway Protocol - Link State (BGP-LS) with Multi-Topology (MT) for Segment Routing based Network Resource Partitions (NRPs)
 
 draft-ietf-idr-bgpls-sr-vtn-mt-14.txt
 Date: 16/10/2025
 Authors: Chongfeng Xie, Cong Li, Jie Dong, Zhenbin Li
 Working Group: Inter-Domain Routing (idr)
 When Segment Routing (SR) is used for building Network Resource Partitions (NRPs), each NRP can be allocated with a group of Segment Identifiers (SIDs) to identify the topology and resource attributes of network segments in the NRP. This document describes how BGP-Link State (BGP-LS) with Multi-Topology (MT) can be used to distribute the information of SR-based NRPs to a network controller in a specific context where each NRP is associated with a separate logical topology identified by a Multi-Topology ID (MT-ID). This document sets out the targeted scenarios for the approach suggested, and presents the scalability limitations that arise.
 Advertising p2mp policies in BGP
 
 draft-ietf-idr-sr-p2mp-policy-01.txt
 Date: 29/04/2026
 Authors: Hooman Bidgoli, Dan Voyer, Andrew Stone, Rishabh Parekh, Serge Krier, Swadesh Agrawal
 Working Group: Inter-Domain Routing (idr)
 SR P2MP policies are set of policies that enable architecture for P2MP service delivery. A P2MP policy consists of candidate paths (CPs) that connects the Root of the Tree to a set of Leaves. The P2MP policy is composed of replication segments [RFC9524]. A replication segment is a forwarding instruction for a candidate path which is downloaded to the Root, transit nodes and the leaves. This document specifies a new BGP SAFI with a new NLRI in order to advertise P2MP policy from a controller to a set of nodes. This document introduces three new route types within this NLRI, one for P2MP policy and its candidate paths that need to be programmed on the Root node, one for the replication segment incoming SID which uniquely will identify the replication state and another for each outgoing interface that the packets get replicated to. The last two route types are forwarding instructions that needs to be programmed on the Root, and optionally on Transit and Leaf nodes. It should be noted that this document does not specify how the Root and the Leaves are discovered on the controller, it only describes how the P2MP Policy and Replication Segments are programmed from the controller to the nodes.
 Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in BGP
 
 draft-ietf-idr-bgp-ifit-capabilities-09.txt
 Date: 17/04/2026
 Authors: Giuseppe Fioccola, Ran Pang, Subin Wang, Bruno Decraene, Shunwan Zhuang, Haibo Wang
 Working Group: Inter-Domain Routing (idr)
 In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines a new Characteristic to advertise the In-situ Flow Information Telemetry (IFIT) capabilities. Within an IFIT domain, the IFIT capabilities advertisement from the tail node to the head node assists the head node to determine whether a particular IFIT Option type can be encapsulated in data packets. Such advertisement helps mitigating the leakage threat and facilitating the deployment of IFIT measurements on a per-service and on-demand basis.
 Traffic Steering using BGP FlowSpec with SR Policy
 
 draft-ietf-idr-ts-flowspec-srv6-policy-18.txt
 Date: 05/09/2026
 Authors: Jiang Wenying, Yisong Liu, Shunwan Zhuang, Gyan Mishra, Shuanglong Chen
 Working Group: Inter-Domain Routing (idr)
 BGP Flow Specification (FlowSpec) provides mechanisms to distribute traffic filtering and steering rules across BGP networks. This document specifies BGP FlowSpec procedures to steer matching traffic flows into Segment Routing (SR) Policies. Specifically, it defines protocol mechanisms for combining FlowSpec NLRIs with specific BGP Extended Communities for transport policy steering (Mode 1) in SR- MPLS and SRv6 networks, and optionally with the BGP Prefix-SID Attribute when egress service action execution is required (Mode 2) in SRv6 networks.
 BGP Extension for 5G Edge Service Metadata
 
 draft-ietf-idr-5g-edge-service-metadata-33.txt
 Date: 29/05/2026
 Authors: Linda Dunbar, Kausik Majumdar, Cheng Li, Gyan Mishra, Zongpeng Du
 Working Group: Inter-Domain Routing (idr)
 This draft describes a new Edge Metadata Path Attribute and some Sub- TLVs for egress routers to advertise the Edge Metadata about the attached edge services (ES). The edge service Metadata can be used by the ingress routers in the 5G Local Data Network to make path selections not only based on the routing cost but also the running environment of the edge services. The goal is to improve latency and performance for 5G edge services. The extension enables an edge service at one specific location to be more preferred than the others with the same IP address (ANYCAST) to receive data flow from a specific source, like a specific User Equipment (UE).
 VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4
 
 draft-ietf-idr-vpn-prefix-orf-45.txt
 Date: 09/06/2026
 Authors: Wei Wang, Aijun Wang, Haibo Wang, Gyan Mishra, Jie Dong
 Working Group: Inter-Domain Routing (idr)
 This document defines an experimental specification for a new type of Outbound Route Filter (ORF), known as the Virtual Private Network (VPN) Prefix ORF. The VPN Prefix ORF mechanism is applicable when VPN routes from different Virtual Routing and Forwarding (VRF) instances are exchanged through a single shared Border Gateway Protocol (BGP) session. The purpose of the VPN Prefix ORF mechanism is to control the overload of VPN routes based on Route Distinguisher (RD), Route Target (RT) and other necessary routing information. This mechanism is applicable to intra-domain scenarios.
 Extended Communities Derived from Route Targets
 
 draft-ietf-idr-rt-derived-community-10.txt
 Date: 31/07/2026
 Authors: Zhaohui Zhang, Jeff Haas, Keyur Patel
 Working Group: Inter-Domain Routing (idr)
 This document specifies a way to derive an Extended Community from a Route Target and describes some example use cases.
 One Administrative Domain using BGP
 
 draft-uttaro-idr-bgp-oad-08.txt
 Date: 17/04/2026
 Authors: Jim Uttaro, Alvaro Retana, Pradosh Mohapatra, Keyur Patel, Bin Wen
 Working Group: Inter-Domain Routing (idr)
 This document defines a new External BGP (EBGP) peering type known as EBGP-OAD, which is used between two EBGP peers that belong to One Administrative Domain (OAD).
 BGP SR Policy Extensions for Network Resource Partition
 
 draft-ietf-idr-sr-policy-nrp-13.txt
 Date: 19/07/2026
 Authors: Jie Dong, Zhibo Hu, Ran Pang
 Working Group: Inter-Domain Routing (idr)
 Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. A Network Resource Partition (NRP) is a subset of network resources allocated in the underlay network which can be used to support one or a group of RFC 9543 network slice services. In networks where there are multiple NRPs, an SR Policy may be associated with a particular NRP. The association between SR Policy and NRP needs to be specified, so that for service traffic which is steered into the SR Policy, the header of the packets can be augmented with the information associated with the NRP. An SR Policy candidate path can be distributed using BGP SR Policy. This document defines the extensions to BGP SR Policy to specify the NRP which the SR Policy candidate path is associated with.
 BGP SR Policy Extensions for Segment List Identifier
 
 draft-ietf-idr-sr-policy-seglist-id-14.txt
 Date: 24/08/2026
 Authors: Changwang Lin, Weiqiang Cheng, Yao Liu, Ketan Talaulikar, Mengxiao Chen
 Working Group: Inter-Domain Routing (idr)
 Segment Routing (SR) is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. This document defines extensions to BGP SR Policy to specify the identifier of a segment list.
 BGP SR Policy Extensions for Metric
 
 draft-ietf-idr-sr-policy-metric-05.txt
 Date: 02/06/2026
 Authors: Zhenqiang Li, KaZhang, Jie Dong, Ketan Talaulikar, Rui Gu
 Working Group: Inter-Domain Routing (idr)
 An SR Policy consists of one or more Candidate Paths (CPs), each comprising one or more segment lists. BGP can be used to propogate SR Policy CPs to the SR Policy headend nodes in the network. After an SR Policy CP is installed on the headend node, packets can be steered into the SR Policy. For a particular BGP destination, if there are multiple BGP routes with different next-hops, BGP best path selection is performed and the IGP metric to the next-hop node may be used for tie-breaking to select the best path. When the path to the next-hop is resolved over an SR Policy, the IGP metric of the SR policy is needed for BGP path selection. This document defines the BGP extensions to carry the IGP metric of segment lists when BGP is used to propagate SR Policy CPs.
 MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement
 
 draft-ietf-idr-mpbgp-extension-4map6-06.txt
 Date: 07/06/2026
 Authors: Chongfeng Xie, Guozhen Dong, Xing Li, Guoliang Han, Zhongfeng Guo
 Working Group: Inter-Domain Routing (idr)
 This document defines MP-BGP extension and the procedures for IPv4 service delivery in multi-domain IPv6-only underlay networks. It defines a new TLV in the BGP Tunnel Encapsulation attribute, used in conjunction with a specific AFI/SAFI combination for advertising IPv4-over-IPv6 mapping rules. The behaviors of each type of network (IPv4 and IPv6) are also illustrated. In addition, this document provides the deployment and operation considerations when the extension is deployed.
 BGP MultiNexthop Attribute
 
 draft-ietf-idr-multinexthop-attribute-05.txt
 Date: 12/05/2026
 Authors: Kaliraj Vairavakkalai, Minto Jeyananth, Mohan Nanduri, Avinash Lingala
 Working Group: Inter-Domain Routing (idr)
 Today, a BGP speaker can advertise one nexthop for a set of NLRIs in an Update message. This nexthop can be encoded in either the top- level BGP-Nexthop attribute (code 3), or inside the MP_REACH_NLRI attribute (code 14). Forwarding information related to the nexthop is scattered across various attributes, extended communities or the NLRI field. This document defines a new optional non-transitive BGP attribute called "MultiNexthop (MNH)" with IANA code TBD. The MNH provides two things: it allows carrying the Nexthop and related forwarding information in one BGP attribute. The MNH also enables carrying an ordered set of multiple Nexthops in the same attribute, with forwarding information scoped on a per Nexthop basis.
 IANA Registrations for the BGP Finite State Machine (FSM)
 
 draft-ietf-idr-bgp-fsm-iana-02.txt
 Date: 26/06/2026
 Authors: Jeff Haas, Sue Hares, Keyur Patel
 Working Group: Inter-Domain Routing (idr)
 The Border Gateway Protocol, version 4 (BGP-4) finite state machine (FSM) is defined in RFC 4271. Over the years, various extensions to BGP have been authored that update the protocol's FSM. Some elements of the FSM are enumerated. Those elements are referred to across BGP extensions in their respective state machine changes, and may also be used for management purposes in things such as YANG (RFC 7950). To provide consistent naming and enumeration of these FSM elements, this document requests IANA to create and maintain registries for elements in the BGP FSM.
 Advertising SID Algorithm Information in BGP
 
 draft-ietf-idr-sr-te-policy-attr-05.txt
 Date: 18/05/2026
 Authors: Yao Liu, Shaofu Peng, Gyan Mishra
 Working Group: Inter-Domain Routing (idr)
 This document defines new Segment Types and proposes extensions for BGP to provide algorithm information for SR-MPLS Adjacency-SIDs when delivering SR Policy via BGP.
 SR Policies Extensions for Network Resource Partition in BGP-LS
 
 draft-ietf-idr-bgp-ls-sr-policy-nrp-03.txt
 Date: 07/07/2026
 Authors: Ran Chen, Jie Dong, Detao Zhao, Liyan Gong, Yongqing Zhu, Ran Pang
 Working Group: Inter-Domain Routing (idr)
 A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP ID is an important network resource attribute associated with the Segment Routing (SR) policy and needs to be reported to the external components. This document defines a new TLV which enables the headend to report the NRP which the SR Policy Candidate Path (CP) is associated with using Border Gateway Protocol Link-State (BGP-LS).
 BGP Flow Specification Version 2 - for Basic IP
 
 draft-ietf-idr-fsv2-ip-basic-07.txt
 Date: 06/07/2026
 Authors: Sue Hares, Donald Eastlake, Jie Dong, Chaitanya Yadlapalli, Sven Maduschke, Jeff Haas
 Working Group: Inter-Domain Routing (idr)
 BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117, describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. During the deployment of BGP FSv1 a number of issues were detected, so version 2 of the BGP flow specification (FSv2) protocol addresses these issues. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2. The IDR WG requires two implementation. Early feedback on implementations of FSv2 indicate that FSv2 has a correct design direction, but that breaking FSv2 into a progression of documents would aid deployment of the draft (basic, adding more filters, and adding more actions). This document specifies the basic FSv2 NLRI with user ordering of filters added to FSv1 IP Filters and FSv2 actions.
 Link-Local Next Hop Capability for BGP
 
 draft-ietf-idr-linklocal-capability-06.txt
 Date: 03/06/2026
 Authors: Russ White, Jeff Tantsura, Donatas Abraitis, Biswajit Sadhu
 Working Group: Inter-Domain Routing (idr)
 To support IPv6 [RFC4291] reachability, BGP [RFC4271] relies on the Multiprotocol Extensions as defined in [RFC4760]. [RFC2545] defines the structure of IPv6 next hops. These IPv6 next hops may contain a Global IPv6 address, and optionally can contain an IPv6 Link-Local address when the BGP peer is directly attached and shares a common subnet with the IPv6 Global address. This document updates [RFC2545] to clarify the encoding of the BGP next hop when the advertising system is directly attached and only an IPv6 Link-Local address is available. A new BGP Capability [RFC5492] is defined to signal support for this updated encoding. This clarification applies specifically to IPv6 Link-Local addresses and does not pertain to IPv4 Link-Local addresses as defined in [RFC3927].
 Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members
 
 draft-ietf-idr-bgp-ls-sr-epe-over-l2bundle-09.txt
 Date: 05/08/2026
 Authors: Changwang Lin, Zhenqiang Li, Ran Pang, Ketan Talaulikar, Ran Chen
 Working Group: Inter-Domain Routing (idr)
 This document specifies how to support Segment Routing BGP Egress Peer Engineering over Layer 2 bundle members. It updates RFC 9085 to allow the L2 Bundle Member Attributes TLV in the BGP-LS Attribute of the BGP-LS Link NLRI for a BGP peering link. For SR-MPLS, it updates RFC 9085 and RFC 9086 to allow the PeerAdj SID TLV as a sub-TLV of the L2 Bundle Member Attributes TLV.
 BGP Extended Communities Attribute
 
 draft-ietf-idr-rfc4360-bis-09.txt
 Date: 13/07/2026
 Authors: Srihari Sangli, Nat Kao
 Working Group: Inter-Domain Routing (idr)
 This document describes the "Extended Communities" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. This document obsoletes RFC 4360. This document also updates RFC 5701 by adding an "Operational Considerations" section.
 A Border Gateway Protocol 4 (BGP-4)
 
 draft-ietf-idr-bgp4-rfc4271bis-01.txt
 Date: 06/07/2026
 Authors: Yakov Rekhter, Tony Li, Sue Hares, John Scudder
 Working Group: Inter-Domain Routing (idr)
 This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP-speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 4271.
 BGP Next-next Hop Nodes
 
 draft-ietf-idr-next-next-hop-nodes-01.txt
 Date: 26/05/2026
 Authors: Kevin Wang, Jeff Haas, Changwang Lin, Jeff Tantsura
 Working Group: Inter-Domain Routing (idr)
 BGP speakers learn their next hop addresses for NLRI in RFC 4271 in the NEXT_HOP field and in RFC 4760 in the "Network Address of Next Hop" field. Under certain circumstances, it might be desirable for a BGP speaker to know both the next hops and the next-next hops of NLRI to make optimal forwarding decisions. One such example is global load balancing (GLB) in a Clos network. Draft-ietf-idr-nhc defines the "Next Hop Dependent Characteristics Attribute" (NHC) which allows a BGP speaker to signal the forwarding characteristics associated with a given next hop. This document defines a new NHC characteristic, the Next-next Hop Nodes (NNHN) characteristic, which can be used to advertise the next- next hop nodes associated with a given next hop.
 BGP Next Hop Dependent Characteristics Attribute
 
 draft-ietf-idr-nhc-07.txt
 Date: 04/06/2026
 Authors: Bruno Decraene, Kireeti Kompella, Serge Krier, MOHANTY Satya, John Scudder, Kevin Wang, Bin Wen
 Working Group: Inter-Domain Routing (idr)
 RFC 5492 allows a BGP speaker to advertise its capabilities to a peer. When a route is propagated beyond the immediate peer, it is useful to allow certain characteristics to be conveyed further. In particular, it is useful to advertise forwarding plane features. This specification defines a BGP transitive attribute to carry such information, the "Next Hop Dependent Characteristics Attribute," or NHC. Unlike the capabilities defined by RFC 5492, the characteristics conveyed in the NHC apply solely to the routes advertised by the BGP UPDATE that contains the particular NHC.
 BGP Entropy Label Characteristic
 
 draft-ietf-idr-elc-01.txt
 Date: 22/06/2026
 Authors: Bin Wen, Kevin Wang, John Scudder, MOHANTY Satya, Serge Krier, Kireeti Kompella, Bruno Decraene
 Working Group: Inter-Domain Routing (idr)
 The BGP Next Hop Dependent Characteristics Attribute (NHC) provides a way for a BGP speaker to advertise certain characteristics of routes. In particular, it is useful to advertise forwarding plane features. This specification defines an NHC characteristic that can be used to advertise the ability to process the MPLS Entropy Label as an egress LSR for all NLRI advertised in the BGP UPDATE. It updates RFC 6790 and RFC 7447 concerning this BGP signaling.
 BGP Extension for SR-MPLS Entropy Label Position
 
 draft-ietf-idr-bgp-sr-mpls-elp-01.txt
 Date: 10/05/2026
 Authors: Yao Liu, Shaofu Peng
 Working Group: Inter-Domain Routing (idr)
 This document proposes extensions for BGP to indicate the entropy label position in the SR-MPLS label stack when delivering SR Policy via BGP.
 Advertising Flexible Algorithm Extensions in BGP Link-State
 
 draft-ietf-idr-bgp-ls-flex-algo-ext-03.txt
 Date: 25/05/2026
 Authors: Shraddha Hegde, Aravind MahendraBabu, Ketan Talaulikar, Peter Psenak, Bruno Decraene
 Working Group: Inter-Domain Routing (idr)
 Flexible Algorithm is a solution that allows some routing protocols (IS-IS and OSPF) to compute paths over a network based on user- defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distributed manner using a Flexible Algorithm Definition. This Definition is provisioned on one or more routers and propagated through the network by IS-IS and OSPF flooding. BGP Link-State (BGP-LS) enables the collection of various topology information from the network. BGP-LS supports the advertisement of Flexible Algorithm Definition and other Flexible Algorithm related advertisements as a part of the topology information from the network. This document specifies the advertisement of further Flexible Algorithm related extensions in BGP-LS.
 BGP Attribute Escape
 
 draft-ietf-idr-bgp-attribute-escape-00.txt
 Date: 17/06/2026
 Authors: Jeff Haas
 Working Group: Inter-Domain Routing (idr)
 BGP-4 [RFC 4271] has been very successful in being extended over the years it has been deployed. A significant part of that success is due to its ability to incrementally add new features to its Path Attributes when they are marked "optional transitive". Implementations that are ignorant of a feature for an unknown Path Attribute that are so marked will propagate BGP routes with such attributes. Unfortunately, this blind propagation of unknown Path Attributes may happen for features that are intended to be used in a limited scope. When such Path Attributes inadvertently are carried beyond that scope, it can lead to things such as unintended disclosure of sensitive information, or cause improper routing. In their worst cases, such propagation may be for malformed Path Attributes and lead to BGP session resets or crashes. This document calls such inadvertent propagation of BGP Path Attributes, "attribute escape". This document further describes some of the scenarios that leads to this behavior and makes recommendations on practices that may limit its impact.
 BGP SR Policy Extensions for Administrative Flags
 
 draft-ietf-idr-sr-policy-admin-flags-00.txt
 Date: 18/07/2026
 Authors: Changwang Lin, Yisong Liu, Ran Chen, Amal Karboubi, Tiankui Zhang, Guanming Zeng
 Working Group: Inter-Domain Routing (idr)
 Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. This document defines an extension to the BGP SR Policy that sets the administrative state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy.
 Advertisement of SR Policy Operational States using BGP Link-State
 
 draft-ietf-idr-bgp-ls-sr-policy-admin-flags-00.txt
 Date: 18/07/2026
 Authors: Changwang Lin, Zafar Ali, Yisong Liu, Ran Chen, Amal Karboubi
 Working Group: Inter-Domain Routing (idr)
 This document defines the extension of BGP Link-State to advertise the operational state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy.
 Inter Domain considerations for Constrained Route distribution
 
 draft-ietf-idr-rtc-interas-00.txt
 Date: 17/08/2026
 Authors: Stephane Litkowski, Jeffrey Haas, Keyur Patel
 Working Group: Inter-Domain Routing (idr)
 RFC4684 defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information in order to limit the propagation of Virtual Private Networks (VPN) Network Layer Reachability Information (NLRI). RFC4684 addresses both intra domain and inter domain distributions. Operational deployment experience shows that the current distribution model defined in RFC4684 for inter domain may cause some issue in specific scenarios. This document proposes alternate route distribution rules for inter domain in order to address these specific scenarios.

data-group-menu-data-url="/group/groupmenu.json">

Inter-Domain Routing (idr)

WG Name Inter-Domain Routing
Acronym idr
Area Routing Area (rtg)
State Active
Charter charter-ietf-idr-06 Approved
Status update Show Changed 2018-11-07
Document dependencies
Additional resources IDR GitHub Organization
IDR Wiki, Zulip stream
Personnel Chairs Jeffrey Haas, Keyur Patel, Susan Hares
Area Director Ketan Talaulikar
Secretary Jie Dong
Delegate Jie Dong
Mailing list Address [email protected]
To subscribe https://www.ietf.org/mailman/listinfo/idr
Archive https://mailarchive.ietf.org/arch/browse/idr/
Chat Room address https://zulip.ietf.org/#narrow/stream/idr

Charter for Working Group

The Border Gateway Protocol (BGP) (version 4) [RFC4271] was originally developed to support inter-domain IP routing over the Internet and other IP-based networks. The introduction of multiprotocol extensions [RFC4760] enabled BGP to support multiple address families, significantly broadening its applicability to a wide range of routing features and deployment scenarios.

The primary objective (and priority) of the Inter-Domain Routing (IDR) Working Group (WG) is to develop and maintain BGP as the standard inter-domain routing protocol deployed for IPv4 and IPv6 over the Internet.

Aligned with this priority, the IDR WG will develop and maintain BGP features, extensions, and mechanisms that are address-family independent and are considered core to the protocol’s operation. These are:

  • Protocol-level aspects such as message encoding and processing (PDUs), support for different transports specific to BGP, session management, neighbor finite state machine (FSM), path selection, and associated procedures.
  • BGP attributes used to convey information relevant to Network Layer Reachability Information (NLRIs), next-hop resolution, metrics, and other data integral to BGP operation.
  • Capability advertisement mechanisms [RFC5492] used during session establishment to signal support for optional protocol features.
  • Extended Communities [RFC4360], including support for Large and Wide Communities, for carrying metadata and policy-related information.
  • Outbound Route Filtering (ORF) mechanisms [RFC5291][RFC5292] for policy-based control of route advertisement.
  • Route constraint mechanisms such as Route Target Constraints [RFC4684] for limiting route propagation.
  • Advertisement of tunnel encapsulation information [RFC9012] to support data plane flexibility.
  • Advertisement of Segment Routing information via Prefix SID Attribute [RFC8669].
  • Operation and optimization of Route Reflectors [RFC4456] and Confederations [RFC5065] for scalable iBGP deployments.
  • Graceful Restart procedures [RFC4724] [RFC9494] for improving BGP session resiliency and convergence during restarts or failures.
  • BGPsec [RFC8205] and BGP security-related extensions other than the Resource Public Key Infrastructure (RPKI) related work undertaken in SIDROPS WG.

In addition, the WG will develop and maintain BGP features, extensions, and mechanisms for the following BGP address families for their respective deployments within operator networks (including but not limited to service provider, enterprise, and data center environments):

Track 1) Infrastructure (Underlay) Routing: These address families support the routing of infrastructure prefixes, commonly referred to as underlay routing:

  • IPv4 and IPv6 unicast address families for networks outside of the public Internet.
  • MPLS Labeled Unicast address family [RFC8277].
  • Address families related to intent-aware underlay routing specified by the WG.

Track 2) Routing-Adjacent Information Dissemination: These address families enable BGP to carry information related to, or adjacent to, routing functionality:

The IDR WG charter lists work areas as opposed to specific deliverables, reflecting the ongoing work, the extensible nature of the BGP, and the WG’s operational model. Milestones are added for specific deliverables as corresponding documents are adopted by the WG. These are tracked as they progress through WGLC. The WG maintains a long-standing policy that any protocol specification (excluding YANG modules) must have at least two independent implementations prior to advancing to publication.

The following work areas define the scope of activities for the WG, limited to the context of the BGP address families and core protocol extensions outlined above:

  • Advancement of BGP specifications, including but not limited to [RFC4271], toward Internet Standard status, where appropriate.
  • Resolution of protocol issues and incorporation of improvements based on operational experience and feedback from the operator community. This includes enhancements related to security, performance, scalability, protocol correctness, robustness, and operational simplicity.
  • Development of YANG data models scoped to the WG's chartered BGP features and extensions to support the management of these features and extensions, with a focus on device models and capturing operational considerations, as appropriate.
  • Definition of BGP protocol extensions to meet new requirements and use cases originating in other IETF working groups.
  • Enhancements to BGP's path selection and forwarding behavior to support advanced load-balancing capabilities beyond Equal-Cost Multi-Path (ECMP), including unequal and weighted load-balancing based on parameters such as bandwidth.
  • Protocol improvements and extensions to support BGP deployments in IPv6 networks, including IPv6-only environments and mechanisms that facilitate the transition from IPv4 to IPv6 and coexistence.

The primary focus of the WG will remain on the development of Standards Track BGP specifications. Adoption of experimental specifications may be done as an exception in consultation with the Responsible AD. The WG will not seek to publish documents focused on use cases, frameworks, or architectural definitions. As an exception, the WG may produce Informational documents capturing deployment experience or best practices for BGP features developed within the WG with the exception of those related to global Internet routing and BGP security that are covered by the GROW and SIDROPS WGs.

The WG may take up work on BGP protocol extensions to support the work happening in other IETF WGs following consultation with the relevant WG Chairs and Responsible ADs without the need for a recharter. The WG shall coordinate closely with the originating WG(s) that is responsible for the overall base framework, architecture, and requirements. Progression of such work in IDR WG shall follow the maturity (specifically, the adoption and WGLC milestones) of the corresponding base work in those WGs. Relevant WGs include, but are not limited to, CATS, SAVNET, SPRING, and, TEAS, and, in the context of BGP-LS, LSR.

The IDR WG may consider adopting work related to new BGP address families, feature extensions, or work areas not explicitly listed above. However, adoption of such work will require demonstrated interest and sufficient expertise within the WG, and will be subject to a WG rechartering process (i.e., IDR will not become the WG that automatically adopts any BGP-related work).

Given the broad use of BGP across various WGs in the IETF, the IDR WG will provide advice and collaborate closely with other WGs developing or relying on BGP extensions and their BGP-related YANG models. This includes BESS (VPN service-related BGP features), GROW (operational practices and monitoring via BMP), LSVR (BGP-SPF extensions), and SIDROPS (RPKI-related). The IDR WG will seek input from GROW and SIDROPS as appropriate, particularly with respect to operational and security considerations during the development of new BGP specifications. Likewise, the WG will seek review from V6OPS and 6MAN for IPv6-related extensions and from SRV6OPS for Segment Routing operational aspects.

The IDR WG is expected to review BGP-related work in other WGs that is specifically impacting core BGP protocol aspects and provide timely feedback during (but not limited to) WG adoption and WGLCs in those respective WGs. This feedback has no additional standing beyond any other community review.

Milestones

Date Milestone Associated documents
Dec 2027 Complete WGLC for MP-BGP Extension for IPv4/IPv6 Mapping Advertisement as a Proposed Standard draft-ietf-idr-mpbgp-extension-4map6
Dec 2027 Complete WGLC for BGP Extensions for Routing Policy Distribution as a Proposed Standard draft-ietf-idr-rpd
Dec 2027 Complete WGLC for Advertising SR P2MP Policies in BGP as a Proposed Standard draft-ietf-idr-sr-p2mp-policy
Dec 2027 Complete WGLC for BGP CT Adaptation for SRv6 as an Experimental draft-ietf-idr-bgp-ct-srv6
Nov 2027 Complete WGLC on Multisession BGP as a Proposed Standard draft-ietf-idr-bgp-multisession
Jul 2027 Complete WGLC for BGP SR Policy Extensions for Entropy Label Position as a Proposed Standard draft-ietf-idr-bgp-sr-mpls-elp
Jul 2027 Complete WGLC for BGP SR Policy Extensions for Path MTU as a Proposed Standard draft-ietf-idr-sr-policy-path-mtu
Jul 2027 Complete WGLC for BGP Extension for 5G Edge Service Metadata as a Proposed Standard draft-ietf-idr-5g-edge-service-metadata
Jul 2027 Complete WGLC for BGP-LS Extensions for SR Policy NRP as a Proposed Standard draft-ietf-idr-bgp-ls-sr-policy-nrp
Jul 2027 Complete WGLC for BGP for SD-WAN Edge Discovery as a Proposed Standard draft-ietf-idr-sdwan-edge-discovery
Jul 2027 Complete WGLC for BGP-LS Extensions for IS-IS Flood Reflection as a Proposed Standard draft-ietf-idr-bgp-ls-isis-flood-reflection
May 2027 Submit Base BGP specification (RFC 4271) to IESG as an Internet Standard draft-ietf-idr-bgp4-rfc4271bis
Mar 2027 Complete WGLC for ASpath ORF as a Proposed Standard draft-ietf-idr-aspath-orf
Dec 2026 Complete WGLC for BGP SR Policy Extensions for Advertising SID Algorithm as Experimental draft-ietf-idr-sr-te-policy-attr
Dec 2026 Complete WGLC for IANA Registrations for the BGP FSM as a Proposed Standard draft-ietf-idr-bgp-fsm-iana
Dec 2026 Complete WGLC for BGP Flow Specification Version 2 - for Basic IP as a Proposed Standard draft-ietf-idr-fsv2-ip-basic
Dec 2026 Complete WGLC for BGP BFD Strict-Mode as a Proposed Standard draft-ietf-idr-bgp-bfd-strict-mode
Dec 2026 Complete WGLC for BGP-LS Extensions for SR Policy Path Segment as a Proposed Standard draft-ietf-idr-bgp-ls-sr-policy-path-segment
Dec 2026 Complete WGLC for BGP SR Policy Extensions for Path Segment as a Proposed Standard draft-ietf-idr-sr-policy-path-segment
Dec 2026 Complete WGLC for Dynamic Capability for BGP-4 draft-ietf-idr-dynamic-cap
Nov 2026 Complete WGLC for Registered Wide BGP Community Values as a Proposed Standard draft-ietf-idr-registered-wide-bgp-communities
Nov 2026 Complete WGLC for BGP SR Policy Extensions for Metric as a Proposed Standard draft-ietf-idr-sr-policy-metric
Nov 2026 Complete WGLC for BGP FlowSpec Extensions for SRv6 Policy as a Proposed Standard draft-ietf-idr-ts-flowspec-srv6-policy
Nov 2026 Complete WGLC for BGP FlowSpec Extensions for Path Redirection as a Proposed Standard draft-ietf-idr-flowspec-path-redirect
Nov 2026 Complete WGLC for BGP Community Container Attribute as a Proposed Standard draft-ietf-idr-wide-bgp-communities
Nov 2026 Complete WGLC for BGP FlowSpec Extensions for Indirection to Interface-set as a Proposed Standard draft-ietf-idr-flowspec-interfaceset
Nov 2026 Complete WGLC for BGP FlowSpec Extensions for SRv6 as a Proposed Standard draft-ietf-idr-flowspec-srv6
Nov 2026 Complete WGLC for BGP-LS SR EPE over L2 Bundle Members as a Proposed Standard draft-ietf-idr-sr-epe-over-l2bundle
Jul 2026 Complete WGLC for BGP-LS Extension for Inter-AS Topology Retrieval as a Proposed Standard draft-ietf-idr-bgpls-inter-as-topology-ext
Jul 2026 Complete WGLC for Extended Communities Derived from Route Targets as a Proposed Standard draft-ietf-idr-rt-derived-community
Jul 2026 Submit Yang BGP Modules to IESG as Proposed Standard draft-ietf-idr-bgp-model
Jul 2026 Submit BGP Extended Communities Attribute rfc4360bis to IESG as a Proposed Standard draft-ietf-idr-rfc4360-bis
Jul 2026 Complete WGLC for Link-Local Next Hop Capability for BGP as a Proposed Standard draft-ietf-idr-linklocal-capability
Jul 2026 Complete WGLC for BGP SR Policy Extensions for Segment List Identifier as a Proposed Standard draft-ietf-idr-sr-policy-seglist-id

Done milestones

Date Milestone Associated documents
Done Submit BGP Link Bandwidth Extended Community to IESG as a Proposed Standard rfc10005 (was draft-ietf-idr-link-bandwidth)
Done Submit Advertisement of Multiple Paths in BGP to IESG as a Proposed Standard rfc7911 (was draft-ietf-idr-add-paths)
Done Submit Error Handling for Optional Transitive BGP Attributes to IESG as a Proposed Standard rfc7606 (was draft-ietf-idr-error-handling)
Done Submit The Accumulated IGP Metric Attribute for BGP to IESG as a Proposed Standard rfc7311 (was draft-ietf-idr-aigp)
Done Submit Revisions to the BGP 'Minimum Route Advertisement Interval' to IESG as a Proposed Standard
Done Submit BGP Support for Four-octet AS Number Space (revised version) to IESG as a Proposed Standard rfc6793 (was draft-ietf-idr-rfc4893bis)
Done Submit AS-wide Unique BGP Identifier for BGP-4 to IESG as a Proposed Standard rfc6286 (was draft-ietf-idr-bgp-identifier)
Done Prefix ORF draft to IESG as a Proposed Standard rfc5292 (was draft-ietf-idr-bgp-prefix-orf)
Done Submit Outbound Route Filter draft to IESG as a Proposed Standard rfc5291 (was draft-ietf-idr-route-filter)
Done Submit Subcodes for BGP Cease Notification Message to IESG as a Proposed Standard rfc4486 (was draft-ietf-idr-cease-subcode)
Done Submit Extended Communities draft to IESG as a Proposed Standard rfc4360 (was draft-ietf-idr-bgp-ext-communities)
Done Submit BGP Graceful Restart to IESG as a Proposed Standard rfc4724 (was draft-ietf-idr-restart)
Done Submit revised text on Multi-Protocol BGP (rfc2858bis) to IESG as a Draft Standard rfc4760 (was draft-ietf-idr-rfc2858bis)
Done Submit BGP Security Vulnerabilities Analysis to IESG as an Informational rfc4272 (was draft-ietf-idr-bgp-vuln)
Done Submit BGP4 document to IESG as a Draft Standard rfc4271 (was draft-ietf-idr-bgp4)
Done Submit BGP4 MIB to IESG as a Proposed Standard rfc4273 (was draft-ietf-idr-bgp4-mib)
Done Submit to BGP Capability Advertisement to the IESG rfc3392 (was draft-ietf-idr-rfc2842bis)