1. BGP Over QUIC
1.1 BGP Over QUIC
Publication URL: https://datatracker.ietf.org/doc/html/draft-chen-idr-bgp-over-quic
BGP uses TCP to implement reliable and orderly transmission of information. Similar to TCP, QUIC is a UDP-based, byte-stream-based reliable data transmission service. In addition, by integrating with TLS 1.3, QUIC also supports functions such as establishing connections with minimum latency and providing confidentiality and integrity protection for the transmitted data, and multi-stream multiplexing. Taking use of QUIC for BGP can achieve the possible advantages. This document defines the mechanism of BGP over QUIC to and corresponding procedures.
1.2 Use of Streams in BGP over QUIC
Publication URL: https://datatracker.ietf.org/doc/html/draft-retana-idr-bgp-quic-stream
This document specifies the use of QUIC Streams to support multiple BGP sessions over one connection in order to achieve high resiliency.
BGP over QUIC demo: Github: RustyBGP over QUIC
1.1 Dynamic Flooding on Dense Graphs
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding
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
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
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.1 Use of BGP for Routing in Large-Scale Data Centers
Publication URL: https://datatracker.ietf.org/doc/html/rfc7938
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
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
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.1 RIFT: Routing in Fat Trees
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-rift-rift
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.
1.1 BGP Monitoring Protocol (BMP)
Publication URL: https://datatracker.ietf.org/doc/html/rfc7854
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
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 BGP Route Policy and Attribute Trace Using BMP
Publication URL: https://datatracker.ietf.org/doc/html/draft-xu-grow-bmp-route-policy-attr-trace
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.4 VPN Traffic Engineering Using BMP
Publication URL: https://datatracker.ietf.org/doc/html/draft-gu-grow-bmp-vpn-te
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.5 VPN Label Monitoring Using BMP
Publication URL: https://datatracker.ietf.org/doc/html/draft-gu-grow-bmp-vpn-label
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.6 Monitoring BGP Capabilities Using BMP
Publication URL: https://datatracker.ietf.org/doc/html/draft-zhuang-grow-monitoring-bgp-capabilities
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.
1.7 TLV support for BMP Route Monitoring and Peer Down Messages
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv
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.8 BMP Extension for Path Status TLV
Publication URL: https://datatracker.ietf.org/doc/html/draft-cppy-grow-bmp-path-marking-tlv
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 BGP path before and after being processed by the BGP best-path selection algorithm. This extension makes use of the TLV mechanims described in draft-ietf-grow-bmp-tlv [I-D.ietf-grow-bmp-tlv] and draft-lucente-grow-bmp-tlv-ebit [I-D.lucente-grow-bmp-tlv-ebit].
1.9 Support for Enterprise-specific TLVs in the BGP Monitoring Protocol
Publication URL: https://datatracker.ietf.org/doc/html/draft-lucente-grow-bmp-tlv-ebit
Message types defined by the BGP Monitoring Protocol (BMP) do provision for optional trailing data in TLV - Type, Length, Value - format; 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. With this document we want to introduce an Enterprise Bit, or E-bit, for such purpose.
2.1 Network Monitoring Protocol (NMP)
Publication URL: https://datatracker.ietf.org/doc/html/draft-gu-network-monitoring-protocol
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
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
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.1 Protocol Assisted Protocol (PASP)
Publication URL: https://datatracker.ietf.org/doc/html/draft-li-rtgwg-protocol-assisted-protocol
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.
1.1 A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience
Publication URL: https://datatracker.ietf.org/doc/html/rfc5210
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.
1.2 Source Address Validation: Use Cases and Gap Analysis
Publication URL: https://datatracker.ietf.org/doc/html/draft-li-sav-gap-analysis
This document identifies the importance and use cases of source address validation (SAV) at both intra-AS level and inter-AS level (see RFC5210). However, existing intra-AS and inter-AS SAV mechanisms, either Ingress ACL filtering RFC2827, unicast Reverse Path Forwarding (uRPF) RFC3704, or Enhanced Feasible-Path uRPF (EFP-uRPF) RFC8704 has limitations in scalability or accuracy. This document provides the gap analysis of the existing SAV mechanisms followed with some design considerations.
1.3 Distributed Source Address Validation (DSAV) Framework
Publication URL: https://datatracker.ietf.org/doc/html/draft-li-dsav-framework
This document provides an overall framework of Distributed Source Address Validation (DSAV) including both intra-AS and inter-AS levels. It also describes related considerations.
1.4 Control Plane of Inter-Domain Source Address Validation Architecture
Publication URL: https://datatracker.ietf.org/doc/html/draft-xu-savax-control
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 machine to generate consistent tags. When communicating between two end hosts at different ADs of 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.
1.5 Data Plane of Inter-Domain Source Address Validation Architecture
Publication URL: https://datatracker.ietf.org/doc/html/draft-xu-savax-data
This memo focus on the data plane of the SAVA-X mechanism.
1.6 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
This memo focus on the packet formats and processing flow of the SAVA-X mechanism.
2.1 Source Address Validation Improvement (SAVI) Framework
Publication URL: https://datatracker.ietf.org/doc/html/rfc7039
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
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
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
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
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.