|
|
| |
| Controller Based BGP Multicast Signaling |
|
|
This document specifies a way that one or more centralized controllers can use BGP to set up multicast distribution trees (identified by either IP source/destination address pair, or mLDP FEC) in a network. Since the controllers calculate the trees, they can use sophisticated algorithms and constraints to achieve traffic engineering. The controllers directly signal dynamic replication state to tree nodes, leading to very simple multicast control plane on the tree nodes, as if they were using static routes. This can be used for both underlay and overlay multicast trees, including replacing BGP-MVPN signaling. |
| OSPF YANG Model Augmentations for Additional Features - Version 1 |
|
|
This document defines YANG data modules augmenting the IETF OSPF YANG model to provide support for Traffic Engineering Extensions to OSPF Version 3 as defined in RF 5329, OSPF Two-Part Metric as defined in RFC 8042, OSPF Graceful Link Shutdown as defined in RFC 8379, OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement as defined in RFC 8510, OSPF MSD as defined in RFC 8476, OSPF Application-Specific Link Attributes as defined in RFC 8920, and OSPF Flexible Algorithm. |
| Framework for Rule-based International Cyberspace Governance |
|
| draft-hanliu-ricg-01.txt |
| Date: |
30/12/2023 |
| Authors: |
Han Liu, Jilong Wang, Chengyuan Zhang, Pardis Tehrani, Ji Ma |
| Working Group: |
Individual Submissions (none) |
|
Cyberspace involves politics, economy, culture, and technology; it engages governments, international organizations, Internet companies, technology communities, civil society, and citizens, forming an integrated, organic body. In a word, cyberspace is the online version of a community with a shared future for mankind. This memo tries to outline a new framework for rule-based international cyberspace governance regime in the context of IPv6 application, which looks into the future international cooperation of cyberspace governance. |
|
|
| |
| Equal-Cost Multipath Considerations for BGP |
|
|
BGP (Border Gateway Protocol) [RFC4271] employs tie-breaking logic to select a single best path among multiple paths available, known as BGP best path selection. At the same time, it has become a common practice to allow for "equal-cost multipath" (ECMP) selection and programming of multiple next-hops in routing tables. This document summarizes some common considerations for the ECMP logic when BGP is used as the routing protocol, with the intent of providing common reference for otherwise unstandardized set of features. |
| Lzip Compressed Format and the 'application/lzip' Media Type |
|
|
Lzip is a lossless compressed data format designed for data sharing, long-term archiving, and parallel compression/decompression. Lzip uses LZMA compression and can achieve higher compression ratios than gzip. Lzip provides accurate and robust 3-factor integrity checking. This document describes the lzip format and registers a media type, a content coding, and a structured syntax suffix to be used when transporting lzip-compressed content via MIME or HTTP. |
| Ethernet over HTTPS Protocol |
|
|
This document defines a protocol for encapsulating Ethernet frames over HTTPS, allowing secure communication between a client and internal web servers. The protocol includes authentication using strong API keys encrypted with the server's public key. The communication is secured using TLS for privacy and integrity. |
|
|
| |
| Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP |
|
|
The purpose of this document is to guide the design of congestion notification in any lower layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Following these guidelines should assure interworking among IP layer and lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. This document is included in BCP 89 and updates the single paragraph of advice to subnetwork designers about ECN in Section 13 of RFC 3819, by replacing it with a reference to the whole of this document. |
| Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim |
|
|
RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of ECN consistent for all forms of IP in IP tunnel. This specification updates RFC 6040 to clarify that its scope includes tunnels where two IP headers are separated by at least one shim header that is not sufficient on its own for wide area packet forwarding. It surveys widely deployed IP tunnelling protocols that use such shim header(s) and updates the specifications of those that do not mention ECN propagation (that is RFC 2661, RFC 3931, RFC 2784, RFC 4380 and RFC 7450, which respectively specify L2TPv2, L2TPv3, GRE, Teredo and AMT). This specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe. |