Inter-Domain Routing (idr) Internet Drafts


      
 BGP Link Bandwidth Extended Community
 
 draft-ietf-idr-link-bandwidth-09.txt
 Date: 17/09/2024
 Authors: Prodosh Mohapatra, Rex Fernando, Reshma Das, MOHANTY Satya, Mankamana Mishra, Rafal Szarecki
 Working Group: Inter-Domain Routing (idr)
This document describes an application of BGP extended communities that allows a router to perform unequal cost load balancing.
 BGP Flow-Spec Redirect-to-IP Action
 
 draft-ietf-idr-flowspec-redirect-ip-03.txt
 Date: 08/09/2024
 Authors: Jim Uttaro, Jeffrey Haas, akarch@cisco.com, Saikat Ray, Prodosh Mohapatra, Wim Henderickx, Adam Simpson, Matthieu Texier
 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 [RFC5575] defines a redirect-to-VRF action for policy-based forwarding. This mechanism can be difficult to use, particularly in networks without L3 VPN infrastructure. This draft 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.
 Performance-based BGP Routing Mechanism
 
 draft-ietf-idr-performance-routing-04.txt
 Date: 27/08/2024
 Authors: Xiaohu Xu, Shraddha Hegde, Ketan Talaulikar, Mohamed Boucadair, Christian Jacquenet
 Working Group: Inter-Domain Routing (idr)
The current BGP specification doesn't use network performance metrics (e.g., network latency) in the route selection decision process. This document describes a performance-based BGP routing mechanism in which network latency metric is taken as one of the route selection criteria. This routing mechanism is useful for those server providers with global reach to deliver low-latency network connectivity services to their customers.
 BGP Dissemination of L2 Flow Specification Rules
 
 draft-ietf-idr-flowspec-l2vpn-23.txt
 Date: 15/04/2024
 Authors: Hao Weiguo, Donald Eastlake, Stephane Litkowski, Shunwan Zhuang
 Working Group: Inter-Domain Routing (idr)
This document defines a Border Gateway Protocol (BGP) Flow Specification (flowspec) extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with L3 flowspecs. AFI/ SAFI 6/133 and 25/134 are used for these purposes. New component types and two extended communities are also defined.
 BGP Dissemination of Flow Specification Rules for Tunneled Traffic
 
 draft-ietf-idr-flowspec-nvo3-20.txt
 Date: 16/06/2024
 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.
 BGP-LS Extension for Inter-AS Topology Retrieval
 
 draft-ietf-idr-bgpls-inter-as-topology-ext-16.txt
 Date: 02/06/2024
 Authors: Aijun Wang, Huaimo Chen, Ketan Talaulikar, Shunwan Zhuang, Changwang Lin
 Working Group: Inter-Domain Routing (idr)
This document describes the process to distribute Border Gateway Protocol- Link State (BGP-LS) key parameters for inter-domain links between two Autonomous Systems. This document defines a new type within the BGP-LS NLRI for a Stub Link and three new type-length- values (TLVs) for BGP-LS Link descriptor. These additions to BGP-LS let Software Definition Network (SDN) controllers retrieve the network topology automatically under various inter-AS environments. Such extension and process can enable the network operator to collect the interconnect information between different domains and then calculate the overall network topology automatically based on the information provided by BGP-LS protocol.
 Deprecation of AS_SET and AS_CONFED_SET in BGP
 
 draft-ietf-idr-deprecate-as-set-confed-set-16.txt
 Date: 27/08/2024
 Authors: Warren Kumari, Kotikalapudi Sriram, Lilia Hannachi, Jeffrey Haas
 Working Group: Inter-Domain Routing (idr)
BCP 172 (i.e., RFC 6472) recommends not using AS_SET and AS_CONFED_SET AS_PATH segment types in the Border Gateway Protocol (BGP). This document advances that recommendation to a standards requirement in BGP; it prohibits the use of the AS_SET and AS_CONFED_SET path segment types in the AS_PATH. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a BGP route clearer. This will also simplify the design, implementation, and deployment of various BGP security mechanisms. This document updates RFC 4271 by deprecating the origination of BGP routes with AS_SET (Type 1 AS_PATH segment) and updates RFC 5065 by deprecating the origination of BGP routes with AS_CONFED_SET (Type 4 AS_PATH segment). Finally, it obsoletes RFC 6472.
 BGP BFD Strict-Mode
 
 draft-ietf-idr-bgp-bfd-strict-mode-13.txt
 Date: 05/07/2024
 Authors: Mercia Zheng, Acee Lindem, Jeffrey 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-12.txt
 Date: 02/09/2024
 Authors: Cheng Li, Zhenbin Li, Yuanyang Yin, Weiqiang Cheng, Ketan Talaulikar
 Working Group: Inter-Domain Routing (idr)
A Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists with necessary path attributes. For each SR path, it may also have its own path attributes, and Path Segment is one of them. A Path Segment is defined to identify an SR path, which can be used for performance measurement, path correlation, and end-2-end path protection. Path Segment can be also used to correlate two unidirectional SR paths into a bidirectional SR path which is required in some scenarios, for example, mobile backhaul transport network. This document defines extensions to BGP to distribute SR policies carrying Path Segment and bidirectional path information.
 BGP Extensions for Routing Policy Distribution (RPD)
 
 draft-ietf-idr-rpd-19.txt
 Date: 28/03/2024
 Authors: Zhenbin Li, Liang Ou, Yujia Luo, Gyan Mishra, Huaimo Chen, Haibo Wang
 Working Group: Inter-Domain Routing (idr)
It is hard to adjust traffic in a traditional IP network from time to time through manual configurations. It is desirable to have a mechanism for setting up routing policies, which adjusts traffic automatically. This document describes BGP Extensions for Routing Policy Distribution (BGP RPD) to support this with a controller.
 SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS
 
 draft-ietf-idr-bgp-ls-sr-policy-path-segment-07.txt
 Date: 28/08/2024
 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-10.txt
 Date: 24/09/2024
 Authors: Cheng Li, Yongqing Zhu, Ahmed El Sawaf, Zhenbin Li
 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-08.txt
 Date: 17/09/2024
 Authors: Yongqing Zhu, Zhibo Hu, Shuping Peng, Robbins Mwehair
 Working Group: Inter-Domain Routing (idr)
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. The centralized controller (PCE/SDN) completes the service path calculation based on the information transmitted by the BGP-LS and delivers the result to the Path Computation Client (PCC) through the PCEP or BGP protocol. This document specifies the extensions to BGP Link State (BGP-LS) to carry maximum transmission unit (MTU) messages of link. The 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-08.txt
 Date: 19/04/2024
 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 UPDATE for SD-WAN Edge Discovery
 
 draft-ietf-idr-sdwan-edge-discovery-16.txt
 Date: 10/09/2024
 Authors: Linda Dunbar, Kausik Majumdar, Susan Hares, Robert Raszuk, Venkit Kasiviswanathan
 Working Group: Inter-Domain Routing (idr)
The document describes the encoding of BGP UPDATE messages for the SD-WAN edge node property discovery. In the context of this document, BGP Route Reflector (RR) is the component of the SD-WAN Controller that receives the BGP UPDATE from SD-WAN edges and in turns propagates the information to the intended peers that are authorized to communicate via the SD-WAN overlay network.
 BGP Flow Specification for SRv6
 
 draft-ietf-idr-flowspec-srv6-05.txt
 Date: 29/03/2024
 Authors: Zhenbin Li, Lei Li, Huaimo Chen, Christoph Loibl, Gyan Mishra, Yanhe Fan, Yongqing Zhu, Lei Liu, Xufeng Liu
 Working Group: Inter-Domain Routing (idr)
This document proposes extensions to BGP Flow Specification for SRv6 for filtering packets with a SRv6 SID that matches a sequence of conditions.
 Applicability of BGP-LS with Multi-Topology (MT) for Segment Routing based Network Resource Partitions (NRP)
 
 draft-ietf-idr-bgpls-sr-vtn-mt-06.txt
 Date: 06/09/2024
 Authors: Chongfeng Xie, Cong Li, Jie Dong, Zhenbin Li
 Working Group: Inter-Domain Routing (idr)
Enhanced VPNs aim to deliver VPN services with enhanced characteristics to customers who have specific requirements on their connectivity, such as guaranteed resources, latency, or jitter. Enhanced VPNs require integration between the overlay VPN connectivity and the characteristics provided by the underlay network. 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 could be used as the underlay to support one or a group of enhanced VPN services. When Segment Routing is used as the data plane of 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. The association between the network topology, the network resource attributes and the SR SIDs may need to be distributed to a centralized network controller. In some network scenarios, each NRP can be associated with a unique logical network topology. This document describes a mechanism to distribute the information of SR based NRPs using BGP-Link State (BGP-LS) with Multi-Topology (MT).
 BGP Flow Specification Version 2
 
 draft-ietf-idr-flowspec-v2-04.txt
 Date: 28/04/2024
 Authors: Susan Hares, Donald Eastlake, Chaitanya Yadlapalli, Sven Maduschke
 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. Multiple applications have used BGP FSv1 to distribute traffic filter policy. These applications include the following: mitigation of denial of service (DoS), enabling traffic filtering in BGP/MPLS VPNs, centralized traffic control of router firewall functions, and SFC traffic insertion. During the deployment of BGP FSv1 a number of issues were detected due to lack of consistent TLV encoding for rules for flow specifications, lack of user ordering of filter rules and/or actions, and lack of clear definition of interaction with BGP peers not supporting FSv1. Version 2 of the BGP flow specification (FSv2) protocol addresses these features. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2.
 BGP for BIER-TE Path
 
 draft-ietf-idr-bier-te-path-04.txt
 Date: 29/03/2024
 Authors: Huaimo Chen, Mike McBride, Ran Chen, Gyan Mishra, Aijun Wang, Yisong Liu, Yanhe Fan, Boris Khasanov, Lei Liu, Xufeng Liu
 Working Group: Inter-Domain Routing (idr)
This document describes extensions to Border Gateway Protocol (BGP) for distributing a Bit Index Explicit Replication Traffic/Tree Engineering (BIER-TE) path. A new Tunnel Type for BIER-TE path is defined to encode the information about a BIER-TE path.
 Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in BGP
 
 draft-ietf-idr-bgp-ifit-capabilities-05.txt
 Date: 05/07/2024
 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 BGP Router Capability Code to advertise the In-situ Flow Information Telemetry (IFIT) capabilities. Within an IFIT domain, IFIT-capability 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.
 BGP Color-Aware Routing (CAR)
 
 draft-ietf-idr-bgp-car-10.txt
 Date: 26/04/2024
 Authors: Dhananjaya Rao, Swadesh Agrawal, Co-authors
 Working Group: Inter-Domain Routing (idr)
This document describes a BGP based routing solution to establish end-to-end intent-aware paths across a multi-domain transport network. The transport network can span multiple service provider and customer network domains. The BGP intent-aware paths can be used to steer traffic flows for service routes that need a specific intent. This solution is called BGP Color-Aware Routing (BGP CAR). This document describes the routing framework and BGP extensions to enable intent-aware routing using the BGP CAR solution. The solution defines two new BGP SAFIs (BGP CAR SAFI and BGP VPN CAR SAFI) for IPv4 and IPv6. It also defines an extensible NLRI model for both SAFIs that allow multiple NLRI types to be defined for different use cases. Each type of NLRI contains key and TLV based non-key fields for efficient encoding of different per-prefix information. This specification defines two NLRI types, Color-Aware Route NLRI and IP Prefix NLRI. It defines non-key TLV types for MPLS label stack, Label Index and SRv6 SIDs. This solution also defines a new Local Color Mapping (LCM) Extended Community.
 BGP Classful Transport Planes
 
 draft-ietf-idr-bgp-ct-33.txt
 Date: 26/04/2024
 Authors: Kaliraj Vairavakkalai, Natrajan Venkataraman
 Working Group: Inter-Domain Routing (idr)
This document specifies a mechanism referred to as "Intent Driven Service Mapping". The mechanism uses BGP to express intent based association of overlay routes with underlay routes having specific Traffic Engineering (TE) characteristics satisfying a certain Service Level Agreement (SLA). This is achieved by defining new constructs to group underlay routes with sufficiently similar TE characteristics into identifiable classes (called "Transport Classes"), that overlay routes use as an ordered set to resolve reachability (Resolution Schemes) towards service endpoints. These constructs can be used, for example, to realize the "IETF Network Slice" defined in TEAS Network Slices framework. Additionally, this document specifies protocol procedures for BGP that enable dissemination of service mapping information in a network that may span multiple cooperating administrative domains. These domains may be administered either by the same provider or by closely coordinating providers. A new BGP address family that leverages RFC 4364 procedures and follows RFC 8277 NLRI encoding is defined to advertise underlay routes with its identified class. This new address family is called "BGP Classful Transport", a.k.a., BGP CT.
 Traffic Steering using BGP FlowSpec with SR Policy
 
 draft-ietf-idr-ts-flowspec-srv6-policy-04.txt
 Date: 15/08/2024
 Authors: Jiang Wenying, Yisong Liu, Shunwan Zhuang, Gyan Mishra, Shuanglong Chen
 Working Group: Inter-Domain Routing (idr)
BGP Flow Specification (FlowSpec) [RFC8955] and [RFC8956] has been proposed to distribute BGP [RFC4271] FlowSpec NLRI to FlowSpec clients to mitigate (distributed) denial-of-service attacks, and to provide traffic filtering in the context of a BGP/MPLS VPN service. Recently, traffic steering applications in the context of SR-MPLS and SRv6 using FlowSpec also attract attention. This document introduces the usage of BGP FlowSpec to steer packets into an SR Policy.
 BGP Next Hop Dependent Characteristics Attribute
 
 draft-ietf-idr-entropy-label-15.txt
 Date: 20/09/2024
 Authors: Bruno Decraene, John Scudder, Wim Henderickx, Kireeti Kompella, MOHANTY Satya, Jim Uttaro, Bin Wen
 Working Group: Inter-Domain Routing (idr)
RFC 5492 allows a BGP speaker to advertise its capabilities to its 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. This specification also 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 5G Edge Service Metadata
 
 draft-ietf-idr-5g-edge-service-metadata-23.txt
 Date: 14/08/2024
 Authors: Linda Dunbar, Kausik Majumdar, Cheng Li, Gyan Mishra, Zongpeng Du
 Working Group: Inter-Domain Routing (idr)
This draft describes a new Metadata Path Attribute and some Sub-TLVs for egress routers to advertise the 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-08.txt
 Date: 22/09/2024
 Authors: Wei Wang, Aijun Wang, Haibo Wang, Gyan Mishra, Jie Dong
 Working Group: Inter-Domain Routing (idr)
This draft defines a new type of Outbound Route Filter (ORF), known as the VPN Prefix ORF. The VPN Prefix ORF mechanism is applicable when VPN routes from different VRFs are exchanged through a single shared BGP session.
 Extended Communities Derived from Route Targets
 
 draft-ietf-idr-rt-derived-community-02.txt
 Date: 23/07/2024
 Authors: Zhaohui Zhang, Jeffrey 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.
 Advertisement of Segment Routing Policies using BGP Link-State
 
 draft-ietf-idr-bgp-ls-sr-policy-05.txt
 Date: 22/07/2024
 Authors: Stefano Previdi, Ketan Talaulikar, Jie Dong, Hannes Gredler, Jeff Tantsura
 Working Group: Inter-Domain Routing (idr)
This document describes a mechanism to collect the Segment Routing Policy information that is locally available in a node and advertise it into BGP Link-State (BGP-LS) updates. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc.
 Border Gateway Protocol 4 (BGP-4) Send Hold Timer
 
 draft-ietf-idr-bgp-sendholdtimer-15.txt
 Date: 06/08/2024
 Authors: Job Snijders, Ben Cartwright-Cox, Yingzhen Qu
 Working Group: Inter-Domain Routing (idr)
This document defines the SendHoldtimer, along with the SendHoldTimer_Expires event, for the Border Gateway Protocol (BGP) Finite State Machine (FSM). Implementation of the SendHoldTimer helps overcome situations where a BGP connection is not terminated after the local system detects that the remote system is not processing BGP messages. This document specifies that the local system should close the BGP connection and not solely rely on the remote system for connection closure when the SendHoldTimer expires. This document updates RFC4271.
 Segment Routing Segment Types Extensions for BGP SR Policy
 
 draft-ietf-idr-bgp-sr-segtypes-ext-04.txt
 Date: 30/07/2024
 Authors: Ketan Talaulikar, Clarence Filsfils, Stefano Previdi, Paul Mattes, Dhanendra Jain
 Working Group: Inter-Domain Routing (idr)
This document specifies the signaling of additional Segment Routing Segment Types for BGP SR Policy SAFI.
 BGP CT - Adaptation to SRv6 dataplane
 
 draft-ietf-idr-bgp-ct-srv6-05.txt
 Date: 25/04/2024
 Authors: Kaliraj Vairavakkalai, Natrajan Venkataraman
 Working Group: Inter-Domain Routing (idr)
This document specifies how the mechanisms for "Intent Driven Service Mapping" defined in [BGP-CT] are applied to SRv6 dataplane. The extensions needed for SRv6 dataplane operations are specified. Base procedures of BGP CT are followed unaltered. Illustration of how BGP CT procedures work in SRv6 dataplane is provided in this document.
 BGP SR Policy Extensions for Network Resource Partition
 
 draft-ietf-idr-sr-policy-nrp-01.txt
 Date: 28/06/2024
 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-02.txt
 Date: 15/08/2024
 Authors: Changwang Lin, Weiqiang Cheng, Yao Liu, Ketan Talaulikar, Mengxiao Chen
 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 extensions to BGP SR Policy to specify the identifier of segment list.
 BGP Colored Prefix Routing (CPR) for SRv6 based Services
 
 draft-ietf-idr-cpr-04.txt
 Date: 30/06/2024
 Authors: Haibo Wang, Jie Dong, Ketan Talaulikar, hantao, Ran Chen
 Working Group: Inter-Domain Routing (idr)
This document describes a mechanism to advertise IPv6 prefixes in BGP which are associated with Color Extended Communities to establish end-to-end intent-aware paths for Segment Routing over IPv6 (SRv6) services. Such IPv6 prefixes are called "Colored Prefixes", and this mechanism is called Colored Prefix Routing (CPR). In SRv6 networks, the Colored prefixes are the SRv6 locators associated with different intent. SRv6 services (e.g. SRv6 VPN services) with specific intent could be assigned with SRv6 Segment Identifiers (SIDs) under the corresponding SRv6 locators, which are advertised as Colored prefixes. This operational methodology allows the SRv6 service traffic to be steered into end-to-end intent-aware paths simply based on the longest prefix matching of SRv6 Service SIDs to the Colored prefixes. The existing IPv6 Address Family and Color Extended Community are reused for the advertisement of IPv6 Colored prefixes without new BGP extensions, thus this mechanism is easy to interoperate and can be deployed incrementally in multi-domain networks.
 BGP SR Policy Extensions for metric
 
 draft-ietf-idr-sr-policy-metric-01.txt
 Date: 16/06/2024
 Authors: KaZhang, Jie Dong, Ketan Talaulikar
 Working Group: Inter-Domain Routing (idr)
SR Policy candidate paths can be represented in BGP UPDATE messages. BGP can then be used to propagate the SR Policy candidate paths to the headend nodes in the network. After SR Policy is installed on the ingress node, the packets can be steered into SR Policy through route selection. Therefore, route selection may be performed on the ingress node of the SR Policy. If there are multiple routes to the same destination, the route selection node can select routes based on the local policy. The local policy may use the IGP metric of the selected path, which is the IGP Metric of the SR Policy. Thus the BGP UPDATE message needs to carry the metric of each segment list of the SR Policy Candidate Path, which can be used in path selection of routing.
 Advertising Segment Routing Policies in BGP
 
 draft-ietf-idr-sr-policy-safi-06.txt
 Date: 26/07/2024
 Authors: Stefano Previdi, Clarence Filsfils, Ketan Talaulikar, Paul Mattes, Dhanendra Jain
 Working Group: Inter-Domain Routing (idr)
A Segment Routing (SR) Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. An SR Policy consists of one or more candidate paths, each consisting of one or more segment lists. A headend may be provisioned with candidate paths for an SR Policy via several different mechanisms, e.g., CLI, NETCONF, PCEP, or BGP. This document specifies how BGP may be used to distribute SR Policy candidate paths. It introduces a BGP SAFI to advertise a candidate path of a Segment Routing (SR) Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute for signaling information about these candidate paths. This documents updates RFC9012 with extensions to the Color Extended Community to support additional steering modes over SR Policy.
 BGP Route Reflector with Next Hop Self
 
 draft-ietf-idr-bgp-fwd-rr-03.txt
 Date: 17/09/2024
 Authors: Kaliraj Vairavakkalai, Natrajan Venkataraman
 Working Group: Inter-Domain Routing (idr)
The procedures in BGP Route Reflection (RR) spec RFC4456 primarily deal with scenarios where the RR is reflecting BGP routes with next hop unchanged. In some deployments like Inter-AS Option C (Section 10, RFC4364), the ABRs may perform RR functionality with nexthop set to self. If adequate precautions are not taken, the RFC4456 procedures can result in traffic forwarding loop in such deployments. This document illustrates one such looping scenario, and specifies approaches to minimize possiblity of traffic forwarding loop in such deployments. An example with Inter-AS Option C (Section 10, RFC4364) deployment is used, where RR with next hop self is used at redundant ABRs when they re-advertise BGP transport family routes between multiple IGP domains.
 MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement
 
 draft-ietf-idr-mpbgp-extension-4map6-02.txt
 Date: 28/04/2024
 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 to be used in conjunction with the specific AFI/SAFI for IPv4 and IPv6. 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-03.txt
 Date: 21/09/2024
 Authors: Kaliraj Vairavakkalai, Jeyananth Jeganathan, 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-00.txt
 Date: 31/05/2024
 Authors: Jeffrey Haas, Susan 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-00.txt
 Date: 12/08/2024
 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-00.txt
 Date: 14/08/2024
 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-00.txt
 Date: 15/08/2024
 Authors: Susan Hares, Donald Eastlake, Chaitanya Yadlapalli, Sven Maduschke
 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 features. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2. The IDR WG requires two implementation Implementers feedback on FSv2 was that FSv2 has a correct design, but that breaking FSv2 into a progression of documents would aid deployment of the draft. The IDR WG requires two implementation so This document is the first of the series of documents indicating the basic FSv2 with user ordering of filters added to FSv1 IP Filters and IP actions.
 Accumulated Metric in NHC attribute
 
 draft-ietf-idr-bgp-generic-metric-00.txt
 Date: 30/08/2024
 Authors: Srihari Sangli, Shraddha Hegde, Reshma Das, Bruno Decraene, Bin Wen, Marcin Kozak, Jie Dong, Luay Jalil, Ketan Talaulikar
 Working Group: Inter-Domain Routing (idr)
RFC7311 describes mechanism for carrying accumulated IGP cost across BGP domains however it limits to IGP-metric only. There is a need to accumulate and propagate different types of metrics as it will aid in intent-based end-to-end path across BGP domains. This document defines BGP extensions for Generic Metric sub-types that enable different types of metrics to be accumulated and carried in BGP. This is applicable when multiple domains exchange BGP routing information.
 Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members
 
 draft-ietf-idr-sr-epe-over-l2bundle-00.txt
 Date: 02/09/2024
 Authors: Changwang Lin, Zhenqiang Li, Ran Pang, Ketan Talaulikar, Mengxiao Chen
 Working Group: Inter-Domain Routing (idr)
There are deployments where the Layer 3 interface on which a BGP peer session is established is a Layer 2 interface bundle. In order to allow BGP-EPE to control traffic flows on individual member links of the underlying Layer 2 bundle, BGP Peering SIDs need to be allocated to individual bundle member links, and advertisement of such BGP Peering SIDs in BGP-LS is required. This document describes how to support Segment Routing BGP Egress Peer Engineering over Layer 2 bundle members. This document updates [RFC9085] to allow the L2 Bundle Member Attributes TLV to be added to the BGP-LS Attribute associated with the Link NLRI of BGP peering link. This document updates [RFC9085] and [RFC9086] to allow the PeerAdj SID TLV to be included as a sub-TLV of the L2 Bundle Member Attributes TLV.


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

Skip to main content

Inter-Domain Routing (idr)

WG Name Inter-Domain Routing
Acronym idr
Area Routing Area (rtg)
State Active
Charter charter-ietf-idr-05 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 John Scudder
Secretary Jie Dong
Mailing list Address idr@ietf.org
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 Inter-Domain Routing Working Group is chartered to standardize,
develop, and support the Border Gateway Protocol Version 4 (BGP-4)
[RFC 4271] capable of supporting policy based routing for TCP/IP
internets.

The main objective of the working group is to support the use of
BGP-4 by IP version 4 and IP version 6 networks. The working group
will also continue to work on improving the robustness and
scalability of BGP.

IDR will review extensions made to BGP in other working groups at least
at WG document adoption and during working group last calls. The IDR
working group will also provide advice and guidance on BGP to other
working groups as requested.

Work Items:

The IDR working group will work on correctness, robustness and
scalability of the BGP protocol, as well as clarity and accuracy of the
BGP document set. The group will also work on extensions beyond these
areas when specifically added to the charter. The current additional
work items are:

  • Relax the definition of BGP identifiers to only require AS-wide
    uniqueness. This change must be made in a backward compatible way.

  • Specify a means to non-disruptively introduce new BGP Capabilities
    to an existing BGP session.

  • Upgrade of the base BGP specification to Full Standard

  • Define AS_PATH based Outbound Route Filtering.

  • MIB v2 for BGP-4

  • Augment the BGP multiprotocol extensions to support the use of
    multiple concurrent sessions between a given pair of BGP speakers.
    Each session is used to transport routes related by some session-
    based attribute such as AFI/SAFI. This will provide an alternative
    to the MP-BGP approach of multiplexing all routes onto a single
    connection.

  • Support for four-octet AS Numbers in BGP.

  • Revisions to the BGP 'Minimum Route Advertisement Interval'
    deprecating the previously recommended values and allowing for
    withdrawals to be exempted from the MRAI.

  • Advertisement of multiple paths for the same address prefix without
    the new paths implicitly replacing any previous ones. Each path is
    identified by a path identifier in addition to the address prefix.

  • Revised error handling rules for optional transitive BGP attributes
    so that a BGP speaker is no longer required to reset the session
    over which a malformed attribute is received. Provide guidelines
    for authors of documents that define new optional transitive
    attributes, and re-assess procedures for existing optional
    transitive attributes

  • Specify Link Bandwidth Extended Community for use in unequal cost
    load balancing.

  • The definition of an "Accumulated IGP Metric" attribute for BGP
    to report the sum of the metric of each link along the path.
    This attribute is for use in a restricted environment where:

  • all ASes are subject to the administrative control
  • some form of tunneling is used to deliver a packet to its next
    BGP hop
  • where the path for a route leads outside the AS to which the
    BGP speaker adding the attribute belongs.

  • Advertisement of the best external route in BGP to assist with
    resolution of the next hop in the chosen data plane.

Milestones

Date Milestone Associated documents
Apr 2016 Solicit work items for scalability improvements
Apr 2016 Progress base BGP specification (RFC 4271) as Full Standard
Feb 2016 Submit ASpath ORF draft to IESG as a Proposed Standard
Feb 2016 Submit Yang BGP Modules to IESG as Proposed Standard
Jan 2016 Revise WG charter
Dec 2015 Submit Dynamic Capability for BGP-4 to IESG as a Proposed Standard
Nov 2015 Submit MIB v2 for BGP-4 to IESG as a Proposed Standard
Nov 2015 Submit Multisession BGP to IESG as a Proposed Standard
Jun 2015 Submit Advertisement of Multiple Paths in BGP to IESG as a Proposed Standard
Jun 2015 Submit BGP Link Bandwidth Extended Community to IESG as a Proposed Standard
Mar 2015 Submit ASpath ORF to IESG as a Proposed Standard

Done milestones

Date Milestone Associated documents
Done Submit Error Handling for Optional Transitive BGP Attributes to IESG as a Proposed Standard
Done Submit The Accumulated IGP Metric Attribute for BGP to IESG as a Proposed Standard
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
Done Submit AS-wide Unique BGP Identifier for BGP-4 to IESG as a Proposed Standard
Done Prefix and ASpath ORF draft to IESG as a Proposed Standard
Done Submit Outbound Route Filter, Prefix and ASpath ORF draft to IESG as a Proposed Standard
Done Submit 4-byte AS ID to IESG as a Proposed Standard
Done Submit Subcodes for BGP Cease Notification Message to IESG as a Proposed Standard
Done Submit BGP Graceful Restart to IESG as a Proposed Standard
Done Submit Extended Communities draft to IESG as a Proposed Standard
Done Submit revised text on Multi-Protocol BGP (rfc2858bis) to IESG as a Draft Standard
Done Submit BGP4 document to IESG as a Draft Standard
Done Submit BGP Security Vulnerabilities Analysis to IESG as an Informational
Done Submit BGP4 MIB to IESG as a Proposed Standard
Done Submit to BGP Capability Advertisement to the IESG