Justification for BIER on Standards Track
draft-shepherd-bier-standards-track-00

Abstract

This document is intended to provide justification for re-chartering the BIER Working Group as Standards Track, and to move all BIER WG previously published documents to Standards Track.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on June 24, 2018.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 2. IP Multicast Challenges
• 3. Benefits of BIER
• 4. Trade Offs
• 5. Impact of BIER on the Forwarding Plane
• 6. Conclusion
• 7. Acknowledgements
• 8. IANA Considerations
• 9. Security Considerations
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Authors' Addresses

1. Introduction

IER(Bit Index Explicit Replication) is an alternative method of multicast forwarding. It does not require any multicast-specific trees, and hence does not require any multicast-specific tree building protocols. Due to the particular sensitivity of adding new significant functionality into the data-plane, the BIER work began progress as Experimental. The current status of the experiment is documented in this draft and is intended to provide justification for re-charting the BIER Working Group (WG) as Standards Track and to move all published documents of the BIER WG to Standards Track. This document will detail the benefits, problems, and trade-offs for using BIER instead of traditional multicast forwarding mechanisms, as required by the BIER WG Charter charter-ietf-bier-01

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

2. IP Multicast Challenges

Current IP Multicast solutions require a tree-building control plane to build and maintain end-to-end tree state per flow, impacting router state capacity and network convergence times. Multi-point tree building protocols are often considered complex to deploy and debug and may include mechanics from legacy use-cases and/or assumptions which no longer apply to the current use-cases. When multicast services are transiting a provider network through an overlay, the core network has a choice to either aggregate customer state into a minimum set of core states resulting in flooding traffic to unwanted network end-points, or to map per-customer, per-flow tree state directly into the provider core state amplifying the network-wide state problem. Though the value proposition of network replication is high, the cost of deploying IP Multicast is often considered too high to justify deployment.

3. Benefits of BIER

BIER is a radical simplification of IP Multicast. BIER has no tree-building protocol. BIER has no end-to-end tree/flow state. BIER has no RPF requirements. BIER packets follow the same path to a destination as a unicast packet would take to the same destination. BIER provides deterministic convergence times regardless of how many (S,G)s are being transported through the BIER network. BIER can be deployed in SDN-driven deployment models, that minimize protocols required in a network as well by eliminating multicast protocols and relying on IGP infrastructure or direct SDN programmability.

4. Trade Offs

BIER is intended to carry IP Multicast packets - though not explicitly restricted to this - across an overlay. Therefore, BIER is not end-to-end like IP Multicast. This isn't an inherent tradeoff, but it does focus the scope of the solution and the discussion. The lack of (S,G) state often comes up as a perceived limitation. But considering IP Unicast does not have active flow state in the Forwarding Information Base (FIB) of each node, the expectation that Multicast needs flow state for debugging purposes is more of an artifact of legacy solutions rather than a requirement. Debugging individual flows in BIER will require unicast techniques such as flow export tools rather than forwarding state entries of IP Multicast. BIER's primary limitation is the size of the bitmask. The BIER architecture requires 256 bit mask support, but can accommodate larger and smaller masks. As the masks get larger (+1024 bits) transport tax begins to exceed what is reasonable. 256 to 1024 end nodes of a BIER domain could then be considered a limitation. Larger numbers of end nodes can be addressed with the use of BIER Sets or via multiple BIER domains.

Because BIER is a forwarding plane feature significantly different from IP Unicast or Multicast, not all routers today can be programmed to support BIER. Transition mechanisms have already been introduced to facility migration to an expanding BIER domain.

5. Impact of BIER on the Forwarding Plane

Bitmask forwarding techniques have been used in embedded systems and software communication for decades. BIER is the first time the mechanism has been extended to address distributed forwarding and replication across a network. Though the BIER forwarding rules are different than IP forwarding, it is significantly simpler than IP Multicast forwarding. Detailed description of BIER forwarding is documented in RFC8279. The BIER forwarding logic is simple, and the state requirements minimal enough, that some existing micro-codable forwarding hardware is programmable to support BIER today. It is expected that dedicated BIER forwarding hardware will be developed to extend the solution beyond micro-codable forwarding hardware - that is expected to then further reduce hardware costs. Multiple router vendors and chip vendors either have plans to support BIER or will be announcing new products with BIER support very soon. In addition, multiple operators are now actively evaluating and planning the deployment of BIER for multicast delivery in their networks. This validates BIER as next generation technology for multicast delivery.

6. Conclusion

The overall benefits of BIER over traditional IP Multicast are quite significant, and the value of network replication is so well understood, that operator and vendor engagement and support for BIER was strong from the beginning and has only grown over time. It is expected that BIER adoption will begin to take over as the dominant network replication transport in all networks where traditional IP Multicast is used today. It is our recommendation that the BIER work and all existing BIER published RFCs be moved from the Experimental track to the Standards track.

7. Acknowledgements

TBD

8. IANA Considerations

This memo includes no request to IANA.

9. Security Considerations

This draft is Informational and has no impact on security.

10. References

10.1. Normative References

10.2. Informative References

Authors' Addresses