BIER WG Zheng. Zhang Internet-Draft BenChong. Xu Intended status: Standards Track ZTE Corporation Expires: April 3, 2018 September 30, 2017 BIER Flooding Mechanism draft-zhang-bier-flooding-00.txt Abstract This document introduces a method to flood BIER information in hybrid network to build BIER forwarding plane. 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 April 3, 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. Zhang & Xu Expires April 3, 2018 [Page 1] Internet-Draft BIER Flooding September 2017 Table of Contents 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Scheduled Update . . . . . . . . . . . . . . . . . . . . 4 2.2. Triggered Update . . . . . . . . . . . . . . . . . . . . 4 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. PFM message . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. BIER information TLV . . . . . . . . . . . . . . . . . . 5 3.3. BIER MPLS Encapsulation sub-TLV . . . . . . . . . . . . . 6 3.4. Optional BIER sub-domain BSL conversion sub-TLV . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Problem Statement Some networks have been deployed widely are hybrid networks. There are different dynamic routing protocols running in the hybrid networks. Multicast services can also be provided in these kinds of networks because of the protocol independent feature of PIM. BIER [I-D.ietf-bier-architecture] provides a new architecture for the forwarding of multicast data packets. It does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. [I-D.ietf-bier-isis-extensions] and [I-D.ietf-bier-ospf-bier-extensions] are good at establishing BIER forwarding plane in network which uses OSPF or IS-IS as BIER underlay protocol. Zhang & Xu Expires April 3, 2018 [Page 2] Internet-Draft BIER Flooding September 2017 | | .........|................|......... . ISIS | | . . | | . . MR1--------------MR2 . . | . . | . . | . . | . . | . . | . . | .. | . . | . . | . . | . . | . . | . . | . . MR3 MR4 . . / \ / \ . .................................... / \ / \ / \ / \ / \ / \ ................... ................ . B1--------B2 . .B3--------B4 . . . . . . Rm . . Rx . . ... . . ... . . Rn . . Ry . . . . . . OSPF . . OSPF . ................... ................ Figure 1: An typical hybrid network In the mentioned networks, there are more than one dynamic routing protocols running in the networks. For example in figure 1, this is a partial typical network in actually deployment. Two different dynamic routing protocols and are used in the network. Sometimes static configured routes also are used in some parts of the network. In order to deploy BIER multicast, we can divide the network into several BIER domains. Obviously the efficiency slows down due to multiple encapsulating/ decapsulating executions. 2. Solution The Bootstrap Router mechanism (BSR) [RFC5059] is a commonly used mechanism for distributing dynamic Group to RP mappings in PIM. It is responsible for flooding information about such mappings throughout a PIM domain, so that all routers in the domain can have the same information. [I-D.ietf-pim-source-discovery-bsr] defines a mechanism that can flood any kind of information throughout a PIM domain. This document borrows the idea from the two drafts, introduces a mechanism to flood BIER node's information throughout a Zhang & Xu Expires April 3, 2018 [Page 3] Internet-Draft BIER Flooding September 2017 BIER domain to build BIER forwarding plane. Nodes can use unicast forwarding table directly to establish BIER forwarding plane. The validation processing of PFM messages is the same as the definition in [I-D.ietf-pim-source-discovery-bsr] section 3.2. BIER node originates BIER information TLV and optional associated sub-TLVs in PFM message. The PFM messages are flooded by throughout the BIER domain. BFR gets routing information from the unicast forwarding table directly, and computes BIER forwarding table. Then BIER forwarding plane is established. 2.1. Scheduled Update Because PIM advertisement is scheduled, the node's BIER information is refreshed periodically. In case one node's BIER information changes or expires, the other nodes recompute the BIER forwarding table. The holdtime in the BIER information TLV is used to make the item expired. 2.2. Triggered Update If the BIER node's configuration changes, such as BFR-id, the node should send update PFM messages immediately. Then other nodes can recompute the new BIER forwarding table. 3. Message Format 3.1. PFM message New TLVs are defined in PFM message to flood node's BIER information, such as BFR-id, BFR-prefix and so on. The new TLVs align exactly with the definition and restrictions in [I-D.ietf-bier-isis-extensions] and [I-D.ietf-bier-ospf-bier-extensions]. Zhang & Xu Expires April 3, 2018 [Page 4] Internet-Draft BIER Flooding September 2017 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type |N| Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type 1 | Length 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value 1 | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | Type n | Length n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value n | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: PFM message format The format of PFM message is defined in [I-D.ietf-pim-source-discovery-bsr]. Originator Address: The router's address that originate the message. The address SHOULD be the same with the node's BFR-prefix. The other fields is the same as definition in [I-D.ietf-pim-source-discovery-bsr]. 3.2. BIER information TLV A new type of TLV is defined in PFM message. This new type TLV is named by BIER information TLV. Two types of sub-TLV are associated with it. There is no optional BIER tree type sub-TLV in PFM message because of the independence of routing protocol. Zhang & Xu Expires April 3, 2018 [Page 5] Internet-Draft BIER Flooding September 2017 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | subdomain-id | BFR-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFR-prefix (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: BIER information TLV o Type: The value of type should be assigned by IANA. o Length: The total length of the BIER information TLV except for the first two fields. o Reserved: Must be 0 on transmission, ignored on reception. May be used in future version. 1 octets. o Subdomain-id: Unique value identifying the BIER sub-domain. 1 octet. o BFR-id: The value of BFR-id defined in [BIER-arch], 2 octets. 0 is invalid value. If the value of this field is set to 0, the whole TLV MUST be ignored and not forwarded. o Holdtime: The life cycle of the BIER information. The default value is 60s. o BFR-prefix: The BFR-prefix of the node in this sub-domain. The format for this address is given in the Encoded-Unicast address in [RFC7761]. A node may belong to several BIER sub-domains, so it is possible that there are multiple BIER information TLVs in the PFM message. 3.3. BIER MPLS Encapsulation sub-TLV In case the nodes in the network support MPLS forwarding, BIER MPLS encapsulation sub-TLV can be advertised for a specific bitstring length for a certain (MT,subdomain). This sub-TLV may appear multiple times within single BIER information TLV. The format and restriction is the same as the definition in [I-D.ietf-bier-isis-extensions] and [I-D.ietf-bier-ospf-bier-extensions]. Zhang & Xu Expires April 3, 2018 [Page 6] Internet-Draft BIER Flooding September 2017 The type value of this sub-TLV should be assigned by IANA. The suggestion value is 1. 3.4. Optional BIER sub-domain BSL conversion sub-TLV The format and restriction is the same as the definition in [I-D.ietf-bier-isis-extensions] and [I-D.ietf-bier-ospf-bier-extensions]. The type value of this sub-TLV should be assigned by IANA. The suggestion value is 2. 4. Security Considerations The security considerations are mainly similar to what is documented in [I-D.ietf-pim-source-discovery-bsr]. 5. IANA Considerations This document requires the assignment of a new PFM TLV type for the BIER information Flooding Mechanism. IANA is also requested to create two sub-TLV types for BIER MPLS encapsulation sub-TLV and BIER sub-domain BSL conversion sub-TLV. 6. Normative References [I-D.ietf-bier-architecture] Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast using Bit Index Explicit Replication", draft-ietf-bier-architecture-08 (work in progress), September 2017. [I-D.ietf-bier-isis-extensions] Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, "BIER support via ISIS", draft-ietf-bier-isis- extensions-05 (work in progress), July 2017. [I-D.ietf-bier-ospf-bier-extensions] Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions for BIER", draft-ietf-bier-ospf-bier-extensions-07 (work in progress), July 2017. [I-D.ietf-pim-source-discovery-bsr] Wijnands, I., Venaas, S., Brig, M., and A. Jonasson, "PIM flooding mechanism and source discovery", draft-ietf-pim- source-discovery-bsr-06 (work in progress), March 2017. Zhang & Xu Expires April 3, 2018 [Page 7] Internet-Draft BIER Flooding September 2017 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 2008, . [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, . Authors' Addresses Zheng(Sandy) Zhang ZTE Corporation No. 50 Software Ave, Yuhuatai Distinct Nanjing China Email: zhang.zheng@zte.com.cn BenChong Xu ZTE Corporation No. 68 Zijinghua Road, Yuhuatai Distinct Nanjing China Email: xu.benchong@zte.com.cn Zhang & Xu Expires April 3, 2018 [Page 8]