PIM Z. Zhang Internet-Draft B. Xu Intended status: Standards Track ZTE Corporation Expires: 2 January 2025 S. Venaas Cisco Systems, Inc. Z. Zhang Juniper Networks H. Bidgoli Nokia 1 July 2024 Multi-Topology in PIM draft-xz-pim-flex-algo-02 Abstract PIM usually uses the shortest path computed by routing protocols to build multicast tree. Multi-Topology Routing is a technology to enable service differentiation within an IP network. IGP Flex Algorithm provides a way to compute constraint-based paths over the network. This document defines the PIM message extensions to provide a way to build multicast tree through the specific topology and constraint-based path instead of the shortest path. 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 2 January 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Zhang, et al. Expires 2 January 2025 [Page 1] Internet-Draft Abbreviated Title July 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. PIM Message extensions . . . . . . . . . . . . . . . . . . . 3 3.1. Group Source Info MT Sub-TLV . . . . . . . . . . . . . . 4 3.2. Multi-Topology Attribute Format . . . . . . . . . . . . . 4 3.3. Specification . . . . . . . . . . . . . . . . . . . . . . 5 3.3.1. Source with MT Sub-TLV advertisement . . . . . . . . 5 3.3.2. J/P message Processing . . . . . . . . . . . . . . . 6 3.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Protocol Independent Multicast (PIM) get the upstream neighbor and incoming interface to multicast source or Rendezvous Point (RP) from the unicast routing protocol. As described in section 3 in [RFC7761], PIM relies on an underlying topology-gathering protocol to populate the MRIB (Multicast Routing Information Base). Usually the MRIB is the best paths over the network based on the IGP metric. In some cases, alternative paths with low latency or high bandwidth are needed for specific requirements. Multi-Topology Routing (MTR) is a technology to enable service differentiation within an IP network. To support MTR, an IGP maintains independent IP topologies, termed as "Multi-Topologies" (MT), and computes/installs routes per topology. OSPF extensions [RFC4915] and ISIS extensions [RFC5120] specify the MT extensions. [RFC9350] specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. FA can be seen as creating a sub-topology within a topology using defined topology constraints Zhang, et al. Expires 2 January 2025 [Page 2] Internet-Draft Abbreviated Title July 2024 and computation algorithm. This can be done within a MTR topology or the default Topology. In the future different algorithms might be defined. For that reason, in the remainder of this document, we'll refer to this as the IGP Algorithm (IPA). +----(gR2)------(gR4)----+ / | | \ / | | \ Source--(R1)(RP) | | (R6)--Recv \ | | / \ | | / +----(rR3)------(rR5)----+ Figure 1 In Figure 1, there is only a defult topology in the network. R1 is the source DR and R6 is last-hop DR. Two multicast flows need to be received by the receiver: flow 1 (1.0.0.0/24, 233.252.0.1/32) and flow 2 (2.0.0.0/24, 233.252.0.2/32). The shortest paths to the two sources are the same: R6-R4-R2-R1. But the bandwidth on the path is not enough for the two flows delivery. Packet loss occurs. The network can be divided into 2 planes by different Flex-Algorithms defined in [RFC9350]. For example, R1/R2/R4/R6 belong to green plane, and R1/R3/R5/R6 belong to red plane. This document defines the PIM message extensions to provide the way to build multicast tree through the specific topology and constraint- based path instead of the shortest path. In this figure, flow 1 can be delivered in plan 1, flow 2 can be delivered in plan 2. 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 [RFC2119]. 2. Terminology This document does not introduce more terminologies than [RFC7761], [RFC5384], [RFC5496], [RFC4915], [RFC5120] and [RFC9350]. 3. PIM Message extensions Zhang, et al. Expires 2 January 2025 [Page 3] Internet-Draft Abbreviated Title July 2024 3.1. Group Source Info MT Sub-TLV [I-D.gopal-pim-pfm-forwarding-enhancements] defines a new TLV for announcing sources that allows for Sub-TLVs that can be used for providing various types of information. This document defines a new MT Sub-TLV that can be used for carrying the topology ID and the IPA value. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPA | MT-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Type: TBD (To be assigned by IANA). Length: 2-octet. This length is always 1. IPA: A 1-octet field The IGP Algorithm, values are from the IGP Algorithm registry. For using Flex-Algorithm (see Section 4 of [RFC9350]) to specify the sub-topology, the value is between 128 and 255 inclusive. MT-ID: A 2-octet field MT-ID (see Section 3.7 of [RFC4915], Section 7 of [RFC5120]) to special the topology. If this field is set to zero, it means the default topology. 3.2. Multi-Topology Attribute Format [RFC5384] defines a pim Join Attributes are encoded as TLVs into the Encoded-Source Address field of a PIM Join message. This document specifies the MT Attribute that allows the receiver to select the associated topology or algorithm. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|E| Type=TBD | Length = 1 | IPA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 Zhang, et al. Expires 2 January 2025 [Page 4] Internet-Draft Abbreviated Title July 2024 F bit: The Transitive bit. Specifies whether the attribute is transitive or non-transitive. This bit RECOMMENDED set to 1 and the attribute will be transitived. E bit: End-of-Attributes bit. Specifies whether this attribute is the last. Set to zero if there are more attributes. Set to 1 if this is the last attribute. Type: TBD (To be assigned by IANA). Length: 1-octet. IPA: A 1-octet field The IGP Algorithm, values are from the IGP Algorithm registry. For using Flex-Algorithm (see Section 4 of [RFC9350]) to specify the sub-topology, the value is between 128 and 255 inclusive. MT-ID: A 2-octet field MT-ID (see Section 3.7 of [RFC4915], Section 7 of [RFC5120]) to special the topology. If this field is set to zero, it means the default topology. 3.3. Specification 3.3.1. Source with MT Sub-TLV advertisement PIM Flooding Mechanism and Source Discovery [RFC8364] allows for announcement of active sources. [I-D.gopal-pim-pfm-forwarding-enhancements] defines a new TLV for announcing sources that allows for Sub-TLVs that can be used for providing various types of information. The MT Sub-TLV is advertised with Group Source Info TLV, and flooded in the network. The FHR advertises the announcing sources carrying the MT Sub-TLV to the network. All the routers in the network receive the information through PFM function. If two or more FHRs announce same source and group with different MT-ID and IPA value because of wrong configurations or other reasons, the LHR SHOULD select the MT-ID and the IPA by using the lowest or highest originator address. The PFM function defined in [RFC8364] is not changed. Zhang, et al. Expires 2 January 2025 [Page 5] Internet-Draft Abbreviated Title July 2024 3.3.2. J/P message Processing The LHR PIM router on the receiving side specifies the MT-ID and IPA of the unicast route to the multicast source according to the local policy. The LHR looks up the local topology routing table and gets the upstream neighbor, then the LHR sends the join message to the upstream neighbor with the specified MT-ID and IPA value set in the MT attribute. The local configured MT-ID and IPA is the same with the advertisement of LHR usually. In case there is inconsistent, the LHR MUST NOT send the J/P message with MT attribute. When there is no specific MT-ID and IPA value in local policy or configuration on LHR, LHR SHOULD use the MT-ID and IPA received by PFM advertisements if there is. After receiving join messages, the upstream PIM router checks all the received join messages, if all the received join messages carried the same MT-ID and IPA value, then it looks up unicast routes in the specific topology and selects the incoming interface and upstream neighbor according to the algorithm. And the continual join messages keep carrying the MT Attribute. When the local policy or configuration is deleted on LHR, LHR MUST send the associated prune message. And the continual prune message MUST carried the attribute. In case the upstream neighbor finds that not all the received join messages carried the same MT-ID and IPA value, or unicast routing is unreachable in the specific topology, the upstream neighbor MUST use the local routing table which is the default topology to get the upstream neighbor. And this inconsistency SHOULD be notified to the network administrator. If the upstream neighbor is FHR, the FHR SHOULD NOT continue advertising the MT Sub-TLV until all the received join messages carried the same MT-ID and IPA value. The MT attribute SHOULD NOT be used with RPF vector attribute([RFC5496]). In case the MT attribute is also received with the RPF vector attribute, the router SHOULD ignore one of them according to local policy. There should be no more than one MT attribute in an Encoded-Source Address when PIM build a join message. If the PIM router receives a join message with multiple MT attributes in an Encoded-Source Address, the first one is RECOMMENDED be used. Zhang, et al. Expires 2 January 2025 [Page 6] Internet-Draft Abbreviated Title July 2024 3.3.3. Example In the example of figure 1, R1 sends the PFM message with MT sub-TLV according to local policy or configuration. The MT-ID 0 which indicate the default topology and IPA M which indicates the FA is set in the sub-TLV. All the nodes in the network receive the message. R6 is configured with policy rule1 to match flow 1 (1.0.0.0/24, 233.252.0.1/32) and set IPA M to select green plane in the default topology, and R6 is configured with policy rule2 to match flow 2 (2.0.0.0/24, 233.252.0.2/32) and set Flex-Algorithm N to select red plane. When JoinDesired(1.0.0.1, 233.252.0.1) ([RFC7761]) is TRUE, R6 will match policy rule1 in local policy and send PIM join to R4 with MT-ID 0 and IPA M in MT Attribute. Also, when JoinDesired(2.0.0.1, 233.252.0.2) is TRUE, R6 will match policy rule2 in local policy and send PIM join to R5 with MT-ID 0 and IPA N in MT Attribute. Then flow 1 can be delivered in plan 1, flow 2 can be delivered in plan 2. 4. IANA Considerations TBD. 5. Security Considerations The consideration mentioned in [RFC7761] and [I-D.gopal-pim-pfm-forwarding-enhancements] apply to this document. If PIM routers in the multicast tree select different topology and algorithm based on different local policy, there may be a loop in the network. Forged router may advertise source and group information with wrong MT sub-TLV. The network administrator should be careful for the MT consistency. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, . Zhang, et al. Expires 2 January 2025 [Page 7] Internet-Draft Abbreviated Title July 2024 [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, . [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, DOI 10.17487/RFC5384, November 2008, . [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, DOI 10.17487/RFC5496, March 2009, . [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, . [RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, February 2023, . 6.2. Informative References [I-D.gopal-pim-pfm-forwarding-enhancements] Gopal, A., Venaas, S., and F. Meo, "PIM Flooding Mechanism and Source Discovery Enhancements", Work in Progress, Internet-Draft, draft-gopal-pim-pfm-forwarding- enhancements-03, 13 June 2024, . [RFC8364] Wijnands, IJ., Venaas, S., Brig, M., and A. Jonasson, "PIM Flooding Mechanism (PFM) and Source Discovery (SD)", RFC 8364, DOI 10.17487/RFC8364, March 2018, . Authors' Addresses Zheng Zhang ZTE Corporation China Email: zhang.zheng@zte.com.cn Zhang, et al. Expires 2 January 2025 [Page 8] Internet-Draft Abbreviated Title July 2024 Benchong Xu ZTE Corporation China Email: xu.benchong@zte.com.cn Stig Venaas Cisco Systems, Inc. Tasman Drive San Jose, CA 95134, United States of America Email: stig@cisco.com Zhaohui Zhang Juniper Networks Boston, United States of America Email: zzhang@juniper.net Hooman Bidgoli Nokia Ottawa Canada Email: hooman.bidgoli@nokia.com Zhang, et al. Expires 2 January 2025 [Page 9]