BIER Zheng. Zhang Internet-Draft ZTE Corporation Intended status: Standards Track Bo. Wu Expires: March 26, 2020 Individual Zhaohui. Zhang Juniper Networks IJsbrand. Wijnands Cisco Systems, Inc. September 23, 2019 BIER Prefix Redistribute draft-zwzw-bier-prefix-redistribute-03 Abstract This document defines a BIER proxy function to interconnect different underlay routing protocol areas in a network. And a new BIER proxy range sub-TLV is also defined to convey BIER BFR-id information across the routing areas. 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 RFC2119. 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 March 26, 2020. Zhang, et al. Expires March 26, 2020 [Page 1] Internet-Draft BIER Prefix Redistribute September 2019 Copyright Notice Copyright (c) 2019 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. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2 2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Advertisement . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. BIER proxy range sub-TLV . . . . . . . . . . . . . . . . 6 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Problem statement Zhang, et al. Expires March 26, 2020 [Page 2] Internet-Draft BIER Prefix Redistribute September 2019 +-------------------------------------------------------+ | +----+ +----+ PIM | | +----+ R1 +-------------+ R2 +-----+ | | | +----+ +----+ | | | | | | | | OSPF area 0 / ISIS | | | | | | | | +----+ +----+ | | | +-----+ +------------+ +-----+ | | +------------+ R3 +---+ +---+ R4 +------------+ | | | +----+ | | +----+ | | | | | | | | | | OSPF area 1 | | OSPF area 2 | | | | | | | | | | +----+ +----+ | | +----+ +----+ | | | +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ | | +----+ +----+ +----+ +----+ | +-------------------------------------------------------+ Figure 1 Figure 1 shows that there are three areas in a traditional network. In some deployment situations, different routing protocols may also be used in a network. There are just small number of routers in each area of the network. Currently, multicast services are provided in this hybrid network by using protocol independent feature of PIM. BIER could be a candidate multicast protocol to replace PIM to reduce multicast states in the hybrid network. BIER [RFC8279] is 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. In order to build BIER forwarding plane, BIER key parameters must be flooded in one BIER domain such as BFR-prefix, BFR-id, subdomain-id, and so on. The routing protocols which are used to flood these BIER parameters are called BIER routing underlay. The associated routing protocol extensions are defined in documents such as [RFC8401], [RFC8444], [I-D.ietf-bier-idr-extensions], [I-D.ietf-bier-ospfv3-extensions], and so on. Zhang, et al. Expires March 26, 2020 [Page 3] Internet-Draft BIER Prefix Redistribute September 2019 +----+ +----+ +----+ R1 +-------------+ R2 +-----+ | +----+ +----+ | | OSPF / ISIS | | BIER domain 1 | | | | +----+ +----+ | +-----+ +------------+ +-----+ +------------+ R3 +---+ +---+ R4 +------------+ | +----+ | | +----+ | | OSPF | | OSPF | | | | | | BIER domain 2 | | BIER domain 3 | | +----+ +----+ | | +----+ +----+ | +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ +----+ +----+ +----+ +----+ Figure 2 Based on the BIER design, a BIER domain is limited by the underlay routing protocols flooding scope. As in a hybrid network depicted in figure 2, in case we want deploy BIER instead of PIM, there are several BIER domains because of different underlay routing protocols limitation. Multiple encapsulating/ decapsulation executions are needed to across multiple BIER domains. These executions slow down the forwarding efficiency. The border routers also need to maintain overlay state, which is undesired. Except the hybrid network, there is the situation that several areas formed by one same IGP protocol need to be merged into one BIER domain in existing network. The prefix redistribution method defined in this document can be used too. 2. Proposal Zhang, et al. Expires March 26, 2020 [Page 4] Internet-Draft BIER Prefix Redistribute September 2019 +-------------------------------------------------------+ | +----+ +----+ BIER | | +----+ R1 +-------------+ R2 +-----+ domain 1 | | | +----+ +----+ | | | | OSPF/ISIS | | | | | | | | +----+ +----+ | | | +-----+ +------------+ +-----+ | | +------------+ R3 +---+ +---+ R4 +------------+ | | | +----+ | | +----+ | | | | | | | | | | OSPF area 1 | | OSPF area 2 | | | | | | | | | | +----+ +----+ | | +----+ +----+ | | | +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ | | +----+ +----+ +----+ +----+ | +-------------------------------------------------------+ Figure 3 It is more efficient to deploy BIER by creating one BIER domain for the hybrid network to achieve forwarding benefit. Since the limitation of the BIER routing protocol scope, BFR-id is confined to only one routing area. A BIER proxy function is introduced to transport BIER BFR-id information in a BIER domain across multiple routing protocol areas. So BIER forwarding tables can be built across multiple underlay routing protocols to replace encapsulation/decapsulation processing. In the current deployment, border router (ABR) has a similar role, ABR summaries unicast routing information from one routing protocol area and sends it to another routing area by new routing protocol messages. So ABR can implement BIER proxy function to summarize BIER BFR-id information from one routing protocol area and sends it to another routing area. In figure 3, R3 and R4 connect two areas which running different routing protocols, they can be used as BIER proxies to transport BIER information. For example, after R3 receives BFR-ids information from OSPF area 1 and sends it to ISIS routing area, the routers in ISIS routing area can generate BIER forwarding items toward the BFR-ids in OSPF area 1. Similarly, R3 receives BFR-ids information from ISIS area and sends it to OSPF area 1, the routers in OSPF area 1 can build BIER forwarding items toward the BFR-ids in ISIS area. R4 does the same function, the BIER forwarding plane is constructed accordingly. Zhang, et al. Expires March 26, 2020 [Page 5] Internet-Draft BIER Prefix Redistribute September 2019 3. Advertisement According to [RFC8279], each BFER needs to have a unique (in each sub-domain) BFR-id, and each BFR and BFER floods itself BIER info sub-TLV and associated sub-sub-TLVs in the BIER domain. To keep consistent with the definition in [RFC8444], [I-D.ietf-bier-ospfv3-extensions], and [RFC8401], BIER info sub-TLV defined in [RFC8401] and BIER sub-TLV defined in [RFC8444], [I-D.ietf-bier-ospfv3-extensions] is reused to convey the BFR-id information. OSPF extended Prefix Opaque LSA [RFC7684] and TLVs 235, 237 defined in [RFC5120], or TLVs 135 [RFC5305], or TLV 236 [RFC5308] are still used to carry the BFR-id / BFR-prefix information. The key parameters got from the original routing protocol should be adapted to the format of next routing protocol, such as BFR-prefix, BFR-id, subdomain-id, and so on. Some parameters like BAR, MT-ID has local significance, So they should be set to same values with BIER proxy own advertisement when BIER proxy advertise them to the next routing area. And as the two BIER info sub-sub-TLVs (sub-TLVs) including MPLS encapsulation and BSL conversion also have local significance. The information carried in these two sub-sub-TLV need not, but MAY, be advertised to next routing area. 3.1. BIER proxy range sub-TLV In case unicast default route and aggregated / summarized routes are used in some routing areas and routers in next area can not see the specific BFR-prefix routes from original area, the prefix advertised should be set to default route or aggregated / summarized routes. Like in figure 3, in case R3/R4 does not advertise specific ISIS unicast routes to OSPF area and only advertises unicast default route or aggregated / summarized route to OSPF area 1/2, when R3/R4 advertises BIER info sub-TLV to OSPF area 1/2, R3 MUST advertise the prefix with default route or aggregated / summarized route. In that case, multiple BFR-ids will be mapped to one prefix. In order to advertise BFR-ids optimally, we define a new BIER proxy range sub-TLV to advertise the information of BFR-ids. 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 | Length | subdomain-id | resv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFR-id | BFR-id range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhang, et al. Expires March 26, 2020 [Page 6] Internet-Draft BIER Prefix Redistribute September 2019 o Type: TBD to indicate the BIER proxy range sub-TLV. o Length: variable. o Subdomain-id: The subdomain-id from original advertisement. o resv: The reserved field. o BFR-id: The first BFR-id from original advertisement. o BFR-id range: The range of BFR-ids with one subdomain-id. The BIER proxy range sub-TLV is attached to the aggregated / summarized route prefix or default route prefix. The summarized / aggregated / default prefix may need multiple BIER proxy range sub- TLVs if the BFR-ids covered by the prefix are allocated from different ranges (even if they're from a single range but if some BFR-ids in the range map to some BIER prefixes that are covered by a different summarized / aggregated prefix, then that single large range needs to be broken into smaller ranges). The BFR-ids associated with the summarized prefix can be advertised individally in the BIER range sub-TLV. Though BFR-id's range can increase advertisement efficiency, necessary configuration / policy should be provided to guide the range generation of BFR-ids. Otherwise unwanted amount of updates may occur when a BFR-id is removed from the range. Because a summarized / default prefix covers many BIER prefixes, the mapping between a BIER prefix and its BFR-id is no longer conveyed in the routing underlay. As a result, the mapping must be provided by other means, e.g. in the multicast overlay. 4. Example As in figure 3, R3 and R4 as BIER proxy, R3 as an example should advertise the BIER BFR-ids information from ISIS area to OSPF area 1 with the advertiser set to R3 itself, and advertise BIER info from OSPF area 1 to ISIS area as well. In case R3 and R4 generates specific BFR-prefix and BFR-ids from the original area to the next area, BIER info sub-TLV defined in [RFC8401] and BIER sub-TLV defined in [RFC8444], or [I-D.ietf-bier-ospfv3-extensions] is reused to convey the BFR-id information. All the routers generate BIER forwarding items to other area toward BIER proxy according to [RFC8279]. In case BIER proxy can not advertise specific BFR-prefix but aggregated / summarized / default prefix from the original area to Zhang, et al. Expires March 26, 2020 [Page 7] Internet-Draft BIER Prefix Redistribute September 2019 the next area, BIER proxy range sub-TLV is used to convey the information. Suppose that Rm is an ingress router, R1, R2, Rx and Ry is egress router, the BFR-ids of these egress router are 31, 55, 112, 157. The BFR prefixes of them are 10.1.1.5, 10.1.1.50, 203.1.1.10, 203.1.1.60. Suppose that summarized prefixes are advertised into OSPF area. The summarized prefixes are 10.1.1.0/24 and 203.1.1.0/24. All the routers in OSPF area 1 compute forwarding table for unicast / BIER according to the summarized prefixes, and they can get to these prefixes by routes toward proxy R3. Rm encapsulate multicast flow with BIER header that with 31, 55, 112 and 157 bit set in the BIER header (Supposed that 256 BitStringLength is used). The routers in OSPF area 1 forward packet toward R3. R3 forwards packet according to the BFR-ids set in the BIER header normally. Later packet reaches R1, R2 and R4. Similarly, R4 forwards packet into OSPF area 2 normally. Finally packet reaches Rx and Ry. 5. IANA Considerations IANA is requested to set up a new types of sub-TLV (TLV) registry value for BIER proxy range advertisement in OSPF, ISIS, BGP, etc. 6. Security Considerations Implementations must assure that malformed TLV and Sub-TLV permutations do not result in errors which cause hard protocol failures. 7. Acknowledgements The authors would like to thank Stig Venaas for his valuable comments and suggestions. 8. Normative References [I-D.ietf-bier-idr-extensions] Xu, X., Chen, M., Patel, K., Wijnands, I., and T. Przygienda, "BGP Extensions for BIER", draft-ietf-bier- idr-extensions-07 (work in progress), September 2019. [I-D.ietf-bier-ospfv3-extensions] Psenak, P., Kumar, N., and I. Wijnands, "OSPFv3 Extensions for BIER", draft-ietf-bier-ospfv3-extensions-00 (work in progress), May 2019. Zhang, et al. Expires March 26, 2020 [Page 8] Internet-Draft BIER Prefix Redistribute September 2019 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [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, . [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. Zhang, "Bit Index Explicit Replication (BIER) Support via IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, . [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 Extensions for Bit Index Explicit Replication (BIER)", RFC 8444, DOI 10.17487/RFC8444, November 2018, . Authors' Addresses Zheng(Sandy) Zhang ZTE Corporation EMail: zzhang_ietf@hotmail.com Bo Wu Individual EMail: w1973941761@163.com Zhang, et al. Expires March 26, 2020 [Page 9] Internet-Draft BIER Prefix Redistribute September 2019 Zhaohui Zhang Juniper Networks EMail: zzhang@juniper.net IJsbrand Wijnands Cisco Systems, Inc. EMail: ice@cisco.com Zhang, et al. Expires March 26, 2020 [Page 10]