draft-ietf-bier-architecture-01.txt   draft-ietf-bier-architecture-02.txt 
Internet Engineering Task Force IJ. Wijnands, Ed. Internet Engineering Task Force IJ. Wijnands, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track E. Rosen, Ed. Intended status: Standards Track E. Rosen, Ed.
Expires: December 27, 2015 Juniper Networks, Inc. Expires: January 30, 2016 Juniper Networks, Inc.
A. Dolganow A. Dolganow
Alcatel-Lucent Alcatel-Lucent
T. Przygienda T. Przygienda
Ericsson Ericsson
S. Aldrin S. Aldrin
Google, Inc. Google, Inc.
June 25, 2015 July 29, 2015
Multicast using Bit Index Explicit Replication Multicast using Bit Index Explicit Replication
draft-ietf-bier-architecture-01 draft-ietf-bier-architecture-02
Abstract Abstract
This document specifies a new architecture for the forwarding of This document specifies a new architecture for the forwarding of
multicast data packets. It provides optimal forwarding of multicast multicast data packets. It provides optimal forwarding of multicast
packets through a "multicast domain". However, it does not require a packets through a "multicast domain". However, it does not require a
protocol for explicitly building multicast distribution trees, nor protocol for explicitly building multicast distribution trees, nor
does it require intermediate nodes to maintain any per-flow state. does it require intermediate nodes to maintain any per-flow state.
This architecture is known as "Bit Index Explicit Replication" This architecture is known as "Bit Index Explicit Replication"
(BIER). When a multicast data packet enters the domain, the ingress (BIER). When a multicast data packet enters the domain, the ingress
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 27, 2015. This Internet-Draft will expire on January 30, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 47 skipping to change at page 2, line 47
6.6. Examples of BIER Forwarding . . . . . . . . . . . . . . . 18 6.6. Examples of BIER Forwarding . . . . . . . . . . . . . . . 18
6.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 19 6.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 19
6.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 20 6.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 20
6.7. Equal Cost Multi-path Forwarding . . . . . . . . . . . . 22 6.7. Equal Cost Multi-path Forwarding . . . . . . . . . . . . 22
6.7.1. Non-deterministic ECMP . . . . . . . . . . . . . . . 22 6.7.1. Non-deterministic ECMP . . . . . . . . . . . . . . . 22
6.7.2. Deterministic ECMP . . . . . . . . . . . . . . . . . 23 6.7.2. Deterministic ECMP . . . . . . . . . . . . . . . . . 23
6.8. Prevention of Loops and Duplicates . . . . . . . . . . . 25 6.8. Prevention of Loops and Duplicates . . . . . . . . . . . 25
6.9. When Some Nodes do not Support BIER . . . . . . . . . . . 26 6.9. When Some Nodes do not Support BIER . . . . . . . . . . . 26
6.10. Use of Different BitStringLengths within a Domain . . . . 28 6.10. Use of Different BitStringLengths within a Domain . . . . 28
6.10.1. BitStringLength Compatibility Check . . . . . . . . 29 6.10.1. BitStringLength Compatibility Check . . . . . . . . 29
6.10.2. Handling BitStringLength Mismatches . . . . . . . . 30 6.10.2. Handling BitStringLength Mismatches . . . . . . . . 31
6.10.3. Transitioning from One BitStringLength to Another . 31 6.10.3. Transitioning from One BitStringLength to Another . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 32 10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.1. Normative References . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . 34
11.2. Informative References . . . . . . . . . . . . . . . . . 34 11.2. Informative References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
This document specifies a new architecture for the forwarding of This document specifies a new architecture for the forwarding of
multicast data packets. It provides optimal forwarding of multicast multicast data packets. It provides optimal forwarding of multicast
data packets through a "multicast domain". However, it does not data packets through a "multicast domain". However, it does not
require the use of a protocol for explicitly building multicast require the use of a protocol for explicitly building multicast
distribution trees, and it does not require intermediate nodes to distribution trees, and it does not require intermediate nodes to
maintain any per-flow state. This architecture is known as "Bit maintain any per-flow state. This architecture is known as "Bit
Index Explicit Replication" (BIER). Index Explicit Replication" (BIER).
skipping to change at page 27, line 38 skipping to change at page 27, line 38
that node from the tree. All BFERs that are reached through that that node from the tree. All BFERs that are reached through that
child node are then re-parented on the tree, so that BFR B now child node are then re-parented on the tree, so that BFR B now
becomes their parent. becomes their parent.
This variant is simpler because the set of BFERs that are reached This variant is simpler because the set of BFERs that are reached
through a particular child node of B can be determined from the F-BM through a particular child node of B can be determined from the F-BM
in the BIFT. However, if this variant is used, the results are less in the BIFT. However, if this variant is used, the results are less
optimal, because packets will be unicast directly from B to the BFERs optimal, because packets will be unicast directly from B to the BFERs
that are reachable through the non-BIER child node. that are reachable through the non-BIER child node.
When using a unicast MPLS tunnel to get a packet to a BFR-NBR, it may When using a unicast MPLS tunnel to get a packet to a BFR-NBR:
be advantageous to (a) set the TTL of the MPLS label entry
representing the "tunnel" to a large value, rather than copying the o the TTL of the MPLS label entry representing the "tunnel" SHOULD
TTL value from the BIER-MPLS label, and (b) when the tunnel labels be set to a large value, rather than being copied from the TTL
are popped off, to avoid copying the TTL from the tunnel labels to value from the BIER-MPLS label, and
the BIER-MPLS label. That way, the TTL of the BIER-MPLS label would
only control the number of "BFR hops" that the packet may traverse. o when the tunnel labels are popped off, the TTL from the tunnel
labels SHOULD NOT be copied to the BIER-MPLS label.
In other words, the TTL processing for the tunnel SHOULD be as
specified in [RFC3443] for "Pipe Model" and "Short Pipe Model" LSPs.
That way, the TTL of the BIER-MPLS label constrains only the number
of BFRs that the packet may traverse, not the total number of hops.
The material in this section presupposes that a given node is either The material in this section presupposes that a given node is either
a BFR or not, and that a BFR supports BIER on all its interfaces. It a BFR or not, and that a BFR supports BIER on all its interfaces. It
is however possible that a router will have some line cards that is however possible that a router will have some line cards that
support BIER and some that do not. In such a case, one can think of support BIER and some that do not. In such a case, one can think of
the router as a "partial-BFR", that supports BIER only on some of its the router as a "partial-BFR", that supports BIER only on some of its
interfaces. If it is desired to deploy such partial-BFRs, one can interfaces. If it is desired to deploy such partial-BFRs, one can
use the multi-topology features of the IGP to set up a BIER-specific use the multi-topology features of the IGP to set up a BIER-specific
topology. This topology would exclude all the non-BIER-capable topology. This topology would exclude all the non-BIER-capable
interfaces that attach to BFRs. BIER would then have to be run in a interfaces that attach to BFRs. BIER would then have to be run in a
skipping to change at page 33, line 49 skipping to change at page 34, line 13
San Jose, CA 95134 San Jose, CA 95134
United States United States
Email: jeff.tantsura@ericsson.com Email: jeff.tantsura@ericsson.com
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
in Multi-Protocol Label Switching (MPLS) Networks",
RFC 3443, DOI 10.17487/RFC3443, January 2003,
<http://www.rfc-editor.org/info/rfc3443>.
11.2. Informative References 11.2. Informative References
[Boivie_Feldman] [Boivie_Feldman]
Boivie, R. and N. Feldman, "Small Group Multicast", Boivie, R. and N. Feldman, "Small Group Multicast",
(expired) draft-boivie-sgm-02.txt, February 2001. (expired) draft-boivie-sgm-02.txt, February 2001.
[ISIS_BIER_EXTENSIONS] [ISIS_BIER_EXTENSIONS]
Ginsberg, L., Przygienda, T., Aldrin, S., and J. Zhang, Ginsberg, L., Przygienda, T., Aldrin, S., and J. Zhang,
"BIER Support via ISIS", internet-draft draft-ietf-bier- "BIER Support via ISIS", internet-draft draft-ietf-bier-
isis-ranges-00.txt, April 2015. isis-extensions-00.txt, April 2015.
[MPLS_BIER_ENCAPS] [MPLS_BIER_ENCAPS]
Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J., and Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J., and
S. Aldrin, "Encapsulation for Bit Index Explicit S. Aldrin, "Encapsulation for Bit Index Explicit
Replication in MPLS Networks", internet-draft draft-ietf- Replication in MPLS Networks", internet-draft draft-ietf-
bier-mpls-encapsulation-00.txt, April 2015. bier-mpls-encapsulation-01.txt, June 2015.
[OSPF_BIER_EXTENSIONS] [OSPF_BIER_EXTENSIONS]
Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A.,
Przygienda, T., and J. Zhang, "OSPF Extensions for Bit Przygienda, T., and J. Zhang, "OSPF Extensions for Bit
Index Explicit Replication", internet-draft draft-ietf- Index Explicit Replication", internet-draft draft-ietf-
ospf-bier-extensions-00.txt, April 2015. ospf-bier-extensions-00.txt, April 2015.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
VPNs", RFC 6513, February 2012. BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012. VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>.
Authors' Addresses Authors' Addresses
IJsbrand Wijnands (editor) IJsbrand Wijnands (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Email: ice@cisco.com Email: ice@cisco.com
 End of changes. 14 change blocks. 
23 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/