Fundamental Capabilities
1. BGP Over QUIC
Publication URL: https://datatracker.ietf.org/doc/html/draft-retana-idr-bgp-quic
Introduction:
This document specifies the use of QUIC Streams to support multiple BGP sessions over one connection in order to achieve high resiliency.
Reference
BGP over QUIC demo: Github: RustyBGP over QUIC
Scalability
1. IGP
1.1 Dynamic Flooding on Dense Graphs
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding
Introduction:
Routing with link state protocols in dense network topologies can result in sub-optimal convergence times due to the overhead associated with flooding. This can be addressed by decreasing the flooding topology so that it is less dense.
This document discusses the problem in some depth and an architectural solution. Specific protocol changes for IS-IS, OSPFv2, and OSPFv3 are described in this document.
1.2 Flooding Topology Computation Algorithm
Publication URL: https://datatracker.ietf.org/doc/html/draft-cc-lsr-flooding-reduction
Introduction:
This document proposes an algorithm for a node to compute a flooding topology, which is a subgraph of the complete topology per underline physical network. When every node in an area automatically calculates a flooding topology by using a same algorithm and floods the link states using the flooding topology, the amount of flooding traffic in the network is greatly reduced. This would reduce convergence time with a more stable and optimized routing environment.
1.3 Flooding Topology Minimum Degree Algorithm
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flooding-topo-min-degree
Introduction:
This document proposes an algorithm for a node to compute a flooding topology, which is a subgraph of the complete topology per underline physical network. When every node in an area automatically calculates a flooding topology by using a same algorithm and floods the link states using the flooding topology, the amount of flooding traffic in the network is greatly reduced. This would reduce convergence time with a more stable and optimized routing.
2. BGP
2.1 Use of BGP for Routing in Large-Scale Data Centers
Publication URL: https://datatracker.ietf.org/doc/html/rfc7938
Introduction:
Some network operators build and operate data centers that support over one hundred thousand servers. In this document, such data centers are referred to as “large-scale” to differentiate them from smaller infrastructures. Environments of this scale have a unique set of network requirements with an emphasis on operational simplicity and network stability. This document summarizes operational experience in designing and operating large-scale data centers using BGP as the only routing protocol. The intent is to report on a proven and stable routing design that could be leveraged by others in the industry.
2.2 BGP Link-State Shortest Path First (SPF) Routing
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-lsvr-bgp-spf
Introduction:
Many Massively Scaled Data Centers (MSDCs) have converged on simplified layer 3 routing. Furthermore, requirements for operational simplicity have led many of these MSDCs to converge on BGP as their single routing protocol for both their fabric routing and their Data Center Interconnect (DCI) routing. This document describes extensions to BGP to use BGP Link-State distribution and the Shortest Path First (SPF) algorithm used by Internal Gateway Protocols (IGPs) such as OSPF. In doing this, it allows BGP to be efficiently used as both the underlay protocol and the overlay protocol in MSDCs.
2.3 Requirements and Considerations in BGP Peer Auto-Configuration
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-autoconf-considerations
Introduction:
This draft is an exploration of the requirements, the alternatives, and trade-offs in BGP peer auto-discovery at various layers in the stack. It is based on discussions in the IDR Working Group BGP Autoconf Design Team. The current target environment is the datacenter.
This document is not intended to become an RFC.
3. RIFT
RIFT: Routing in Fat Trees
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-rift-rift
Introduction:
This document defines a specialized, dynamic routing protocol for Clos and fat-tree network topologies optimized towards minimization of control plane state as well as configuration and operational complexity.
Maintenability
1. BMP
1.1 BGP Monitoring Protocol (BMP)
Publication URL: https://datatracker.ietf.org/doc/html/rfc7854
Introduction:
This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol.
1.2 Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)
Publication URL: https://datatracker.ietf.org/doc/html/rfc8671
Introduction:
The BGP Monitoring Protocol (BMP) only defines access to the Adj-RIB-In Routing Information Bases (RIBs). This document updates BMP (RFC7854) by adding access to the Adj-RIB-Out RIBs. It also adds a new flag to the peer header to distinguish between Adj-RIB-In and Adj-RIB-Out.
1.3 TLV support for BMP Route Monitoring and Peer Down Messages
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv
Introduction:
Most of the message types defined by the BGP Monitoring Protocol (BMP) do provision for optional trailing data. However, Route Monitoring messages (to provide a snapshot of the monitored Routing Information Base) and Peer Down messages (to indicate that a peering session was terminated) do not. Supporting optional data in TLV format across all BMP message types allows for an homogeneous and extensible surface that would be useful for the most different use- cases that need to convey additional data to a BMP station. While it is not intended for this document to cover any specific utilization scenario, it defines a simple way to support optional TLV data in all message types.
1.4 BMP Extension for Path Status TLV
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-path-marking-tlv
Introduction:
The BGP Monitoring Protocol (BMP) provides an interface for obtaining BGP Path information. BGP Path Information is conveyed within BMP Route Monitoring (RM) messages. This document proposes an extension to BMP to convey the status of a path after being processed by the BGP process. This extension makes use of the TLV mechanims described in draft-ietf-grow-bmp-tlv [I-D.ietf-grow-bmp-tlv] and draft-ietf-grow-bmp-tlv-ebit [I-D.ietf-grow-bmp-tlv-ebit].
1.5 Support for Enterprise-specific TLVs in the BGP Monitoring Protocol
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-ebit
Introduction:
Message types defined by the BGP Monitoring Protocol (BMP) do provision for data in TLV - Type, Length, Value - format, either in the shape of a TLV message body, i.e., Route Mirroring and Stats Reports, or optional TLVs at the end of a BMP message, i.e., Peer Up and Peer Down. However the space for Type value is unique and governed by IANA. To allow the usage of vendor-specific TLVs, a mechanism to define per-vendor Type values is required. In this document we introduce an Enterprise Bit, or E-bit, for such purpose.
1.6 BGP Route Policy and Attribute Trace Using BMP
Publication URL: https://datatracker.ietf.org/doc/html/draft-xu-grow-bmp-route-policy-attr-trace
Introduction:
The generation of BGP adj-rib-in, local-rib or adj-rib-out comes from BGP route exchange and route policy processing. BGP Monitoring Protocol (BMP) provides the monitoring of BGP adj-rib-in (RFC7854), BGP local-rib [I-D.ietf-grow-bmp-local-rib] and BGP adj-rib-out [I-D.ietf-grow-bmp-adj-rib-out]. By monitoring these BGP RIB’s the full state of the network is visible, but how route-policies affect the route propagation or changes BGP attributes is still not. This document describes a method of using BMP to record the trace data on how BGP routes are (not) changed under the process of route policies.
1.7 VPN Traffic Engineering Using BMP
Publication URL: https://datatracker.ietf.org/doc/html/draft-gu-grow-bmp-vpn-te
Introduction:
The BGP Monitoring Protocol (BMP) is designed to monitor BGP running status, such as BGP peer relationship establishment and termination and route updates. This document provides a traffic engineering (TE) method in the VPN (Virtual Private Network) scenario using BMP.
1.8 VPN Label Monitoring Using BMP
Publication URL: https://datatracker.ietf.org/doc/html/draft-gu-grow-bmp-vpn-label
Introduction:
The BGP Monitoring Protocol (BMP) is designed to monitor BGP running status, such as BGP peer relationship establishment and termination and route updates. This document provides a method of collecting the VPN label using BMP, as well as an implementation example.
1.9 Monitoring BGP Capabilities Using BMP
Publication URL: https://datatracker.ietf.org/doc/html/draft-zhuang-grow-monitoring-bgp-capabilities
Introduction:
The BGP Monitoring Protocol (BMP) (RFC7854) is designed to monitor BGP (RFC4271) running status, such as BGP peer relationship establishment and termination and route updates. This document provides a use case that the BMP station can get all BGP capability information of the monitored network device via BMP.
2. NMP
2.1 Network Monitoring Protocol (NMP)
Publication URL: https://datatracker.ietf.org/doc/html/draft-gu-network-monitoring-protocol
Introduction:
To evolve towards automated network OAM (Operations, administration and management), the monitoring of control plane protocols is a fundamental necessity. In this document, a network monitoring protocol (NMP) is proposed to provision the running status information of control plane protocols, e.g., IGP (Interior Gateway Protocol) and other protocols. By collecting the protocol monitoring data and reporting it to the NMP monitoring server in real-time, NMP can facilitate network troubleshooting. In this document, NMP for IGP troubleshooting are illustrated to showcase the necessity of NMP. IS-IS is used as the demonstration protocol, and the case of OSPF (Open Shortest Path First) and other control protocols will be elaborated in the future versions. The operations of NMP are described, and the NMP message types and message formats are defined in the document.
2.2 Network-wide Protocol Monitoring (NPM): Use Cases
Publication URL: https://datatracker.ietf.org/doc/html/draft-chen-npm-use-cases
Introduction:
As networks continue to scale, we need a coordinated effort for diagnosing control plane health issues in heterogeneous environments. Traditionally, operators developed internal solutions to address the identification and remediation of control plane health issues, but as networks increase in size, speed and dynamicity, new methods and techniques will be required.
This document highlights key network health issues, as well as network planning requirements, identified by leading network operators. It also provides an overview of current art and techniques that are used, but highlights key deficiencies and areas for improvement.
This document proposes a unified management framework for coordinating diagnostics of control plane problems and optimization of network design. Furthermore, it outlines requirements for collecting, storing and analyzing control plane data, to minimise or negate control plane problems that may significantly affect overall network performance and to optimize path/peering/policy planning for meeting application-specific demands.
2.3 Network Monitoring For IGP
Publication URL: https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp
Introduction:
To evolve towards automated network OAM (Operations, administration and management), the monitoring of control plane protocols is a fundamental necessity. This document proposes network monitoring for IGP to facilitate troubleshooting by collecting the IGP monitoring data and reporting it to the network monitoring server in real-time. In this document, the operations of network monitoring for ISIS are described, and the corresponding network monitoring message types and message formats are defined.
3. PASP
Protocol Assisted Protocol (PASP)
Publication URL: https://datatracker.ietf.org/doc/html/draft-li-rtgwg-protocol-assisted-protocol
Introduction:
For routing protocol troubleshooting, different approaches exibit merits w.r.t. different situations. They can be generally divided into two categories, the distributive way and the centralized way. A very commonly used distributive approach is to log in possiblly all related devices one by one to check massive data via CLI. Such approach provides very detailed device information, however it requires operators with high NOC (Network Operation Center) experience and suffers from low troubleshooting efficiency and high cost. The centralized approach is realized by collecting data from devices via approaches, like the streaming Telemetry or BMP(BGP Monitoring Protocol) (RFC7854), for the centralized server to analyze all gathered data. Such approach allows a comprehensive view fo the whole network and facilitates automated troubleshooting, but is limited by the data collection boundary set by different management domains, as well as high network bandwidth and CPU computation costs.
This document proposes a semi-distributive and semi-centralized approach for fast routing protocol troubleshooting, localizing the target device and possibly the root cause, more precisely. It defines a new protocol, called the PAP (Protocol assisted Protocol), for devices to exchange protocol related information between each other in both active and on-demand manners. It allow devices to request specific information from other devices and receive replies to the requested data. It also allows actively transmission of information without request to inform other devices to better react w.r.t. network issues.
Security
1. SAVA
A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience
Publication URL: https://datatracker.ietf.org/doc/html/rfc5210
Introduction:
Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. In an effort to enhance the Internet with IP source address validation, a prototype implementation of the IP Source Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network. This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation.
2. SAVI
2.1 Source Address Validation Improvement (SAVI) Framework
Publication URL: https://datatracker.ietf.org/doc/html/rfc7039
Introduction:
Source Address Validation Improvement (SAVI) methods were developed to prevent nodes attached to the same IP link from spoofing each other’s IP addresses, so as to complement ingress filtering with finer-grained, standardized IP source address validation. This document is a framework document that describes and motivates the design of the SAVI methods. Particular SAVI methods are described in other documents.
2.2 Source Address Validation Improvement (SAVI) Solution for DHCP
Publication URL: https://datatracker.ietf.org/doc/html/rfc7513
Introduction:
This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source Address Validation Improvement (SAVI) device. The bindings set up by this procedure are used to filter packets with forged source IP addresses. This mechanism complements BCP 38 (RFC 2827) ingress filtering, providing finer-grained source IP address validation.
2.3 Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario
Publication URL: https://datatracker.ietf.org/doc/html/rfc8074
Introduction:
In networks that use multiple techniques for address assignment, the spoofing of addresses assigned by each technique can be prevented using the appropriate Source Address Validation Improvement (SAVI) methods. This document reviews how multiple SAVI methods can coexist in a single SAVI device and how collisions are resolved when the same binding entry is discovered by two or more methods.
2.4 A SAVI Solution for WLAN
Publication URL: https://datatracker.ietf.org/doc/html/draft-bi-savi-wlan
Introduction:
This document describes a source address validation solution for WLAN enabling 802.11i or other security mechanisms. This mechanism snoops NDP and DHCP packets to bind IP address to MAC address, and relies on the security of MAC address guaranteed by 802.11i or other mechanisms to filter IP spoofing packets. It can work in the special situations described in the charter of SAVI(Source Address Validation Improvements) workgroup, such as multiple MAC addresses on one interface. This document describes three different deployment scenarios, with solutions for migration of binding entries when hosts move from one access point to another.
2.5 Problems and Requirements of Source Address Spoofing in Integrated Space and Terrestrial Networks
Publication URL: https://datatracker.ietf.org/doc/html/draft-jliu-istn-savi-requirement
Introduction:
This document presents the detailed analysis about the problems and requirements of dealing with the threat of source address spoofing in Integrated Space and Terrestrial Networks (ISTN). First, characteristics of ISTN that cause DDos are identified. Secondly, it analyzes the major reasons why existing terrestrial source address validation mechanism does not fit well for ISTN. Then, it outlines the major requirements for improvement on source address validation mechanism for ISTN.
3. SAVNET
WG link: https://datatracker.ietf.org/wg/savnet/about/
Mail Archive: https://mailarchive.ietf.org/arch/browse/savnet/
To subscribe: https://www.ietf.org/mailman/listinfo/savnet/
3.1 Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-savnet-intra-domain-problem-statement/
Introduction:
This document provides the gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements.
3.2 Source Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and Requirements
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-savnet-inter-domain-problem-statement/
Introduction:
This document provides the gap analysis of existing inter-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements.
3.3 Intra-domain Source Address Validation (SAVNET) Architecture
Publication URL: https://datatracker.ietf.org/doc/html/draft-li-savnet-intra-domain-architecture/
Introduction:
This document proposes the intra-domain SAVNET architecture, which achieves accurate source address validation (SAV) in an intra-domain network by an automatic way. Compared with uRPF-like SAV mechanisms that only depend on routers’ local routing information, SAVNET routers generate SAV rules by using both local routing information and SAV-specific information exchanged among routers, resulting in more accurate SAV validation in asymmetric routing scenarios. Compared with ACL rules that require manual efforts to accommodate to network dynamics, SAVNET routers learn the SAV rules automatically in a distributed way.
3.4 Inter-domain Source Address Validation (SAVNET) Architecture
Publication URL: https://datatracker.ietf.org/doc/html/draft-wu-savnet-inter-domain-architecture/
Introduction:
This document introduces an inter-domain SAVNET architecture, providing a comprehensive framework for guiding the design of inter-domain SAV mechanisms. The proposed architecture empowers ASes to establish SAV rules by sharing SAV-specific Information between themselves. During the incremental or partial deployment of SAV-specific Information, it can rely on general information, such as routing information from the RIB, to construct the SAV table when SAV-specific Information for an AS’s prefixes is unavailable. Rather than delving into protocol extensions or implementations, this document primarily concentrates on proposing SAV-specific and general information and guiding how to utilize them to generate SAV rules. It also defines the architectural components and their relations.
3.5 General Source Address Validation Capabilities
Publication URL: https://datatracker.ietf.org/doc/html/draft-huang-savnet-sav-table/
Introduction:
The SAV rules of existing source address validation (SAV) mechanisms, are derived from other core data structures, e.g., FIB-based uRPF, which are not dedicatedly designed for source filtering. Therefore there are some limitations related to deployable scenarios and traffic handling policies.
To overcome these limitations, this document introduces the general SAV capabilitiies from data plane perspective. How to implement the capabilities and how to generate SAV rules are not in the scope of this document.
3.6 BGP Extensions for Source Address Validation Networks (BGP SAVNET)
Publication URL: https://datatracker.ietf.org/doc/html/draft-geng-idr-bgp-savnet/
Introduction:
Many source address validation (SAV) mechanisms have been proposed for preventing source address spoofing. However, existing SAV mechanisms are faced with the problems of inaccurate validation or high operational overhead in some scenarios. This document proposes BGP SAVNET by extending BGP protocol for SAV. This protocol can propagate SAV-related information through BGP messages. The propagated information will help edge/border routers automatically generate accurate SAV rules. These rules construct a validation boundary for the network and help check the validity of source addresses of arrival data packets.
SAVA-X
4.1 An RPKI and IPsec-based AS-to-AS Approach for Source Address Validation
Publication URL: https://datatracker.ietf.org/doc/html/draft-xu-risav/
Introduction:
This document presents RISAV, a protocol for establishing and using IPsec security between Autonomous Systems (ASes) using the RPKI identity system. In this protocol, the originating AS adds authenticating information to each outgoing packet at its Border Routers (ASBRs), and the receiving AS verifies and strips this information at its ASBRs. Packets that fail validation are dropped by the ASBR. RISAV achieves Source Address Validation among all participating ASes.
4.2 Control Plane of Inter-Domain Source Address Validation Architecture
Publication URL: https://datatracker.ietf.org/doc/html/draft-xu-savax-control/
Introduction:
Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. The inter-domain source address validation architecture is an effort to enhance the Internet by using state machines to generate consistent tags. When communicating between two end hosts at different ADs of the IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address.
This memo focus on the control plane of the SAVA-X mechanism.
4.3 Data Plane of Inter-Domain Source Address Validation Architecture
Publication URL: https://datatracker.ietf.org/doc/html/draft-xu-savax-data/
Introduction:
This memo focus on the data plane of the SAVA-X mechanism.
4.4 Communication Protocol Between the AD Control Server and the AD Edge Router of Inter-Domain Source Address Validation Architecture
Publication URL: https://datatracker.ietf.org/doc/html/draft-xu-savax-protocol/
Introduction:
This memo focus on the packet formats and processing flow of the SAVA-X mechanism.
Non-Routing Information Distribution
IETF 118 Non-Routing information distribution side meeting: https://wiki.ietf.org/en/meeting/118/sidemeetings
Publication URL: PDF - Non-Routing Information Distribution
Introduction:
There is continual increase in the amount of extra information that people are asking to carry in routing protocols. Some of the extra information is routing-related, but a lot of it is non-routing information that is used for operations or management. Carrying the non-routing information in routing protocols seem not to be a good use of routing protocols. This issue had been causing lots of concerns about the scalability and stability of routing protocols.
The side meeting in IETF 118 was to call the relevant experts together to have a discussion on the above issue. Around 30 people from operators, vendors, universities and other organizations paticipated the meeting onsite/remotely. In this meeting, some existing work was briefly reviewed (such as “RFC6823 IS-IS Generic Information”, “OSPF-GT” , “Transport Instance BGP”), some new proposals (DROID etc.), and some relevant outputs from the OPS area (e.g., “RFC8990 GRASP”).
Although there was argument that using BGP Transport Instance coupled with a dedicated TCP session should be enough to break the fate-sharing between routing and non-routing information distribution and processing, the overall tendency seemed to argue that expanding current BGP/IGP protocols might not be a good way for long-term sustainability due to the following reasons:
(1) Complexity: the expansion of various types of information options makes the routing protocols more and more complex, and development/maintenance costs are very high
(2) Limited expansion space: BGP/IGP can be expanded in a limited space, and it is not possible to expand indefinitely.
(2) Architectural vulnerability: the distribution of routing and non-routing information is bound to the same code space, protocol encapsulation, or even the same running instance, thus forming a “fate-sharing” at different degrees, creating “a loss of all losses” risk.