Internet DRAFT - draft-shepherd-bier-standards-track
draft-shepherd-bier-standards-track
Internet Engineering Task Force G. Shepherd, Ed.
Internet-Draft Cisco
Intended status: Informational A. Dolganow
Expires: June 23, 2018 Nokia
December 20, 2017
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 23, 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.
Shepherd & Dolganow Expires June 23, 2018 [Page 1]
Internet-Draft Justification for BIER on Standards Track December 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. IP Multicast Challenges . . . . . . . . . . . . . . . . . . . 2
3. Benefits of BIER . . . . . . . . . . . . . . . . . . . . . . 3
4. Trade Offs . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Impact of BIER on the Forwarding Plane . . . . . . . . . . . 4
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
9. Security Considerations . . . . . . . . . . . . . . . . . . . 4
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
10.1. Normative References . . . . . . . . . . . . . . . . . . 5
10.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
IER [RFC8279](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 [RFC2119].
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
Shepherd & Dolganow Expires June 23, 2018 [Page 2]
Internet-Draft Justification for BIER on Standards Track December 2017
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.
Shepherd & Dolganow Expires June 23, 2018 [Page 3]
Internet-Draft Justification for BIER on Standards Track December 2017
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.
Shepherd & Dolganow Expires June 23, 2018 [Page 4]
Internet-Draft Justification for BIER on Standards Track December 2017
10. References
10.1. Normative References
[min_ref] authSurName, authInitials., "Minimal Reference", 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<https://www.rfc-editor.org/info/rfc2629>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
Authors' Addresses
Greg Shepherd (editor)
Cisco
San Jose
US
Email: gjshep@gmail.com
Shepherd & Dolganow Expires June 23, 2018 [Page 5]
Internet-Draft Justification for BIER on Standards Track December 2017
Anrew Dolganow
Nokia
438B Alexandra Road 08-07/10, Alexandra Technopark
119968
Singapore
Email: andrew.dolganow@nokia.com
Shepherd & Dolganow Expires June 23, 2018 [Page 6]
