IETF-Announce List
![[Feed]](feedicon16.png) New RFCs
New and Revived Drafts
- Split Horizon Considerations in Border Gateway Protocol (BGP) Fast ReRoute (FRR) (draft-anup-idr-bgp-frr-splithorizon)
By Anup T, 2017-05-23 TXT HTML PDF
Abstract: This document describes the problems in certain types of BGP FRR deployments. It also suggests a solution in such scenarios. The described problem and solution are applicable to any distance vector routing protocol attempting FRR
- Secure BFD Sequence Numbers (draft-ietf-bfd-secure-sequence-numbers)
By Mahesh Jethanandani, Sonal Agarwal, Ashesh Mishra, Ankur Saxena, Alan DeKok, 2017-05-23 TXT HTML PDF
Abstract: This document describes a security enhancements for the BFD packet's sequence number.
Updated Drafts
- TFRC-based Congestion Control for Saratoga (draft-eddy-tsvwg-saratoga-tfrc)
By Wesley Eddy, lloyd.wood@yahoo.co.uk, Will Ivancic, 2017-05-23 TXT HTML PDF
Abstract: This document specifies the use of TCP-Friendly Rate Control (TFRC) with the Saratoga data transfer protocol. The necessary conventions that a Saratoga sender and receiver implementation must follow if they wish to enable the use of TFRC are described.
- Media Types for Sensor Measurement Lists (SenML) (draft-ietf-core-senml)
By Cullen Jennings, Zach Shelby, Jari Arkko, Ari Keranen, Carsten Bormann, 2017-05-23 TXT HTML PDF
Abstract: This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), eXtensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use this media type in protocols such as HTTP or CoAP to transport the measurements of the sensor or to be configured.
- The BGP Tunnel Encapsulation Attribute (draft-ietf-idr-tunnel-encaps)
By Eric Rosen, Keyur Patel, Gunter Van de Velde, 2017-05-23 TXT HTML PDF
Abstract: RFC 5512 defines a BGP Path Attribute known as the "Tunnel Encapsulation Attribute". This attribute allows one to specify a set of tunnels. For each such tunnel, the attribute can provide the information needed to create the tunnel and the corresponding encapsulation header. The attribute can also provide information that aids in choosing whether a particular packet is to be sent through a particular tunnel. RFC 5512 states that the attribute is only carried in BGP UPDATEs that have the "Encapsulation Subsequent Address Family (Encapsulation SAFI)". This document deprecates the Encapsulation SAFI (which has never been used), and specifies semantics for the attribute when it is carried in UPDATEs of certain other SAFIs. This document adds support for additional tunnel types, and allows a remote tunnel endpoint address to be specified for each tunnel. This document also provides support for specifying fields of any inner or outer encapsulations that may be used by a particular tunnel.
- A YANG Data Model for L2VPN Service Delivery (draft-ietf-l2sm-l2vpn-service-model)
By Bin Wen, Giuseppe Fioccola, Chongfeng Xie, Luay Jalil, 2017-05-23 TXT HTML PDF
Abstract: This document defines a YANG data model that can be used to configure a Layer 2 Provider Provisioned VPN service.
- OSPF Extensions for Segment Routing (draft-ietf-ospf-segment-routing-extensions)
By Peter Psenak, Stefano Previdi, Clarence Filsfils, Hannes Gredler, Rob Shakir, Wim Henderickx, Jeff Tantsura, 2017-05-23 TXT HTML PDF
Abstract: Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).
- Link State protocols SPF trigger and delay algorithm impact on IGP micro-loops (draft-ietf-rtgwg-spf-uloop-pb-statement)
By Stephane Litkowski, Bruno Decraene, Martin Horneffer, 2017-05-23 TXT HTML PDF
Abstract: A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm.
- Resiliency use cases in SPRING networks (draft-ietf-spring-resiliency-use-cases)
By Clarence Filsfils, Stefano Previdi, Bruno Decraene, Rob Shakir, 2017-05-23 TXT HTML PDF
Abstract: This document identifies and describes the requirements for a set of use cases related to network resiliency on Segment Routing (SPRING) networks.
- TRILL Multilevel Using Unique Nicknames (draft-ietf-trill-multilevel-unique-nickname)
By Mingui Zhang, Donald Eastlake, Radia Perlman, Margaret Cullen, Hongjun Zhai, Dongxin Liu, 2017-05-23 TXT HTML PDF
Abstract: TRILL routing can be extended to support multiple levels by building on the multilevel feature of IS-IS routing. Depending on how nicknames are managed, there are two primary alternatives to realize TRILL multilevel: the unique nickname approach and the aggregated nickname approach as discussed in [MultiL]. This document specifies a unique nickname approach. This approach gives unique nicknames to all TRILL switches across the multilevel TRILL campus.
- Tunnel Congestion Feedback (draft-ietf-tsvwg-tunnel-congestion-feedback)
By Xinpeng Wei, Lei Zhu, Lingli Deng, 2017-05-22 TXT HTML PDF
Abstract: This document describes a method to measure congestion on a tunnel segment based on recommendations from RFC 6040, "Tunneling of Explicit Congestion Notification", and to use IPFIX to communicate the congestion measurements from the tunnel's egress to a controller which can respond by modifying the traffic control policies at the tunnel's ingress.
- AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption (draft-irtf-cfrg-gcmsiv)
By Shay Gueron, Adam Langley, Yehuda Lindell, 2017-05-23 TXT HTML PDF
Abstract: This memo specifies two authenticated encryption algorithms that are nonce misuse-resistant - that is that they do not fail catastrophically if a nonce is repeated.
- BANdwidth Aggregation for interNet Access (BANANA) Discard Timer Features for Bonding Tunnel Method (draft-leymann-banana-discard-timer)
By Nicolai Leymann, Cornelius Heidemann, Jun Shen, 4c 67, Lihao Chen, Mingui Zhang, Margaret Cullen, 2017-05-23 TXT HTML PDF
Abstract: Various tunnel based methods have been developed to realize BANdwidth Aggregation for interNet Access (BANANA). At the egress point of bonding tunnels, packets that have been delivered through different tunnels are reordered in a bonding reordering buffer. Along each tunnel, network devices may set aside buffers, which are referred as tunnel buffers, to cache packets as well. This document exposes that a time boundary, which is referred as "Discard Timer", imposed on tunnel buffers could improve the throughput and reliability of the bonding tunnels.
- IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST (draft-murchison-imap-list-myrights)
By Ken Murchison, Bron Gondwana, 2017-05-23 TXT HTML PDF
Abstract: This document defines an extension to the to IMAP LIST command that allows the client to request the set of rights that the logged-in user has been granted on mailboxes, along with other information typically returned by the LIST command.
- OSPF LLS Extensions for Local Interface ID Advertisement (draft-ppsenak-ospf-lls-interface-id)
By Peter Psenak, Ketan Talaulikar, Wim Henderickx, Padma Pillay-Esnault, 2017-05-23 TXT HTML PDF
Abstract: This draft describes the extensions to OSPF link-local signaling to advertise Local Interface Identifier.
- CBOR Object Signing and Encryption (COSE): Headers for carrying and referencing X.509 certificates (draft-schaad-cose-x509)
By Jim Schaad, 2017-05-23 TXT HTML PDF
Abstract: This document defines the headers and usage for referring to and transporting X.509 certificates in the CBOR Encoded Message (COSE) Syntax.
- Asymmetric Extended Route Optimization (AERO) (draft-templin-aerolink)
By Fred Templin, 2017-05-23 TXT HTML PDF
Abstract: This document specifies the operation of IP over tunnel virtual links using Asymmetric Extended Route Optimization (AERO). Nodes attached to AERO links can exchange packets via trusted intermediate routers that provide forwarding services to reach off-link destinations and redirection services for route optimization. AERO provides an IPv6 link-local address format that supports operation of the IPv6 Neighbor Discovery (ND) protocol and links IPv6 ND to IP forwarding. Admission control and address/prefix provisioning are supported by the Dynamic Host Configuration Protocol for IPv6 (DHCPv6), while mobility management and route optimization are naturally supported through dynamic neighbor cache updates. Although DHCPv6 and IPv6 ND messaging are used in the control plane, both IPv4 and IPv6 are supported in the data plane. AERO is a widely-applicable tunneling solution especially well suited to mobile Virtual Private Networks (VPNs) and other applications as described in this document.
- Location Source Parameter for the SIP Geolocation Header Field (draft-winterbottom-sipcore-locparam)
By James Winterbottom, Roland Jesske, Bruno Chatras, Andrew Hutton, 2017-05-23 TXT HTML PDF
Abstract: There are some circumstances where a geolocation header field may contain more than one location value. Knowing the identity of the node adding the location value allows the recipient more freedom in selecting the value to look at first rather than relying solely on the order of the location values.
- Saratoga: A Scalable Data Transfer Protocol (draft-wood-tsvwg-saratoga)
By lloyd.wood@yahoo.co.uk, Wesley Eddy, Charles Smith, Will Ivancic, Chris Jackson, 2017-05-23 TXT HTML PDF
Abstract: This document specifies the Saratoga transfer protocol. Saratoga was originally developed to transfer remote-sensing imagery efficiently from a low-Earth-orbiting satellite constellation, but is useful in many other scenarios, including ad-hoc peer-to-peer communications, large-scale scientific sensing, and grid computing. Saratoga is a simple, lightweight, content dissemination protocol that builds on UDP, and optionally uses UDP-Lite. Saratoga is intended for use when moving files or streaming data between peers which may have permanent, sporadic or intermittent connectivity, and is capable of transferring very large amounts of data reliably under adverse conditions. The Saratoga protocol is designed to cope with highly asymmetric link or path capacity between peers, and can support fully-unidirectional data transfer if required. Saratoga can also cope with very large files for exascale computing. In scenarios with dedicated links, Saratoga focuses on high link utilization to make the most of limited connectivity times, while standard congestion control mechanisms can be implemented for operation over shared links. Loss recovery is implemented via a simple negative-ack ARQ mechanism. The protocol specified in this document is considered to be appropriate for experimental use on private IP networks.
- Congestion control for the Saratoga protocol (draft-wood-tsvwg-saratoga-congestion-control)
By lloyd.wood@yahoo.co.uk, Wesley Eddy, Will Ivancic, 2017-05-23 TXT HTML PDF
Abstract: Saratoga is a data transfer protocol designed to carry potentially large volumes of data over difficult network paths, often including only a single high-rate link and only one application flow. As the requirements for use vary across deployment environments, the base Saratoga specification only assumes that an implementation will be able to clock packets out at a configurable rate, and beyond this specifies no inherent or particular congestion-control behaviour. The design of Saratoga deliberately supports the integration of congestion-control algorithms without modification to the base protocol. This document describes how congestion control can be supported in the Saratoga transfer protocol. Saratoga is intended for use in private networks, where its use is engineered as a single flow to fill a link. However, as Saratoga is implemented over UDP, it can be multiplexed, and can be run across the public Internet, in which case congestion control in accordance with the UDP Guidelines becomes necessary.
Expired Drafts
- Discussion beyond English on IETF mailing lists (draft-wood-discussion-beyond-english)
By lloyd.wood@yahoo.co.uk, 2016-11-19 TXT HTML PDF
Abstract: The IETF requires English for technical discussion in working groups, in working group documents and in anything considered for publication. Use of English simplifies overhead and makes for clear discussion of a single document in a single language, but disadvantages those who lack fluency and comfort in English.
|
Drafts Sent to IESG
IESG Progress
- Data Center Benchmarking Terminology (draft-ietf-bmwg-dcbench-terminology): Publication Requested » AD Evaluation
By Lucien Avramov, jhrapp@gmail.com, 2017-05-11 TXT HTML PDF
Abstract: The purpose of this informational document is to establish definitions, discussion and measurement techniques for data center benchmarking. Also, it is to introduce new terminologies applicable to data center performance evaluations. The purpose of this document is not to define the test methodology, but rather establish the important concepts when one is interested in benchmarking network switches and routers in the data center.
- Unique IPv6 Prefix Per Host (draft-ietf-v6ops-unique-ipv6-prefix-per-host): AD Evaluation » In Last Call
By John Brzozowski, Gunter Van de Velde, 2017-05-17 TXT HTML PDF
Abstract: In some IPv6 environments, the need has arisen for hosts to be able to utilize a unique IPv6 prefix, even though the link or media may be shared. Typically hosts (subscribers) on a shared network, either wired or wireless, such as Ethernet, WiFi, etc., will acquire unique IPv6 addresses from a common IPv6 prefix that is allocated or assigned for use on a specific link.
Drafts Sent to RFC Editor
- Internet Protocol, Version 6 (IPv6) Specification (draft-ietf-6man-rfc2460bis): Approved-announcement sent » RFC Ed Queue
By Steve Deering, Robert Hinden, 2017-05-19 TXT HTML PDF
Abstract: This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC2460
- Multi-Cost ALTO (draft-ietf-alto-multi-cost): Approved-announcement sent » RFC Ed Queue
By Sabine Randriamasy, Wendy Roome, Nico Schwan, 2017-04-27 TXT HTML PDF
Abstract: The ALTO (Application Layer-Traffic Optimization) Protocol ([RFC7285]) defines several services that return various metrics describing the costs between network endpoints.
Other Status Changes
- Secure BFD Sequence Numbers (draft-sonal-bfd-secure-sequence-numbers): Active » Replaced by draft-ietf-bfd-secure-sequence-numbers
By Mahesh Jethanandani, Sonal Agarwal, Ashesh Mishra, Ankur Saxena, Alan DeKok, 2017-02-22 TXT HTML PDF
Abstract: This document describes a security enhancements for the BFD packet's sequence number.
RFC Editor Status Changes
- TRILL: Edge Directory Assist Mechanisms (draft-ietf-trill-directory-assist-mechanisms): » AUTH48
By Donald Eastlake, Linda Dunbar, Radia Perlman, Li Yizhou, 2017-03-02 TXT HTML PDF
Abstract: This document describes mechanisms for providing directory service to TRILL (Transparent Interconnection of Lots of Links) edge switches. The directory information provided can be used in reducing multi- destination traffic, particularly ARP/ND and unknown unicast flooding. It can also be used to detect traffic with forged source addresses.
IPR Disclosures
IESG/IAB/IAOC/Trust Minutes
Liaison Statements
Classified Ads
|
WGs marked with an 
