RFC 7891

Hiii bestie 💖 Okay, so the first 5 bits of RFC 7891 are here, and it's giving "PIM routing with main character energy" 👑

Here's the title block tea ☕: this is RFC 7891, "Explicit Reverse Path Forwarding (RPF) Vector," from the IETF. It's a Standards Track doc with ISSN 2070-1721 and it dropped in June 2016. The authors are J. Asghar, IJ. Wijnands (Ed.), S. Krishnaswamy, and A. Karan from Cisco Systems, plus V. Arya from DIRECTV Inc. ✨ The title block doesn't mention anything this document obsoletes or updates, so no drama there 🌸

Abstract 🦋

Okay, the abstract is basically this: the PIM Reverse Path Forwarding (RPF) Vector TLV from RFC 5496 can sit inside a PIM Join Attribute, and then the RPF neighbor gets picked based on unicast reachability to the RPF Vector, instead of the source or Rendezvous Point tied to the multicast tree 🌈

This doc makes a new RPF Vector Attribute type so an explicit RPF neighbor list can be encoded right in the PIM Join Attribute, and that skips the unicast route lookup entirely. Iconic, honestly 💅

Status of This Memo 📜

This is an Internet Standards Track document 🎀

It's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841 🫶

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7891 🔥

Copyright Notice 🌸

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they were in effect on the day it was published. Please actually read them, because they explain your rights and restrictions 🙈 Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Simplified BSD License 🧚

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Specification of Requirements . . . . . . . . . . . . . . . .   3
3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
4.  Use of the PIM Explicit RPF Vector  . . . . . . . . . . . . .   4
5.  Explicit RPF Vector Attribute TLV Format  . . . . . . . . . .   5
6.  Mixed Vector Processing . . . . . . . . . . . . . . . . . . .   5
7.  Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . .   5
8.  PIM Asserts . . . . . . . . . . . . . . . . . . . . . . . . .   6
9.  Join Suppression  . . . . . . . . . . . . . . . . . . . . . .   6
10. Unsupported Explicit Vector Handling  . . . . . . . . . . . .   7
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
12. Security Considerations . . . . . . . . . . . . . . . . . . .   7
13. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
  13.1.  Normative References . . . . . . . . . . . . . . . . . .   8
  13.2.  Informative References . . . . . . . . . . . . . . . . .   8
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction ✨

The procedures in [RFC5496] describe how an RPF Vector can steer path selection when there's no route to the source. The same procedures can also override a route to the source when one exists 👀 You can put several RPF Vectors in the list. Each router along the path does a unicast route lookup on the first Vector in the attribute list. Once the router that owns the RPF Vector's address is reached, the RPF Vector gets removed from the attribute list, following the procedures in [RFC5496]. The result is a 'loosely' routed path that still depends on unicast reachability to the RPF Vector(s) 🦋

Sometimes network administrators don't want to rely on unicast reachability to the RPF Vector address. They want to build a path strictly from the RPF Vectors instead. In that case, the RPF Vectors are a list of directly connected PIM neighbors along the path, and the router does NOT do a unicast routing table lookup for these Vectors. These are called 'Explicit' RPF Vector addresses 🌈

Here's the key bit 🔑 If a router gets an Explicit RPF Vector and doesn't have a PIM neighbor matching that address, it does not fall back to loosely routing the Join. Instead, it can process the packet and store the RPF Vector list, so the PIM Join can go out as soon as the neighbor comes up 💜 Because Explicit RPF Vector behavior is different from the 'loose' RPF Vector in [RFC5496], this doc defines a new attribute called the Explicit RPF Vector.

This document defines a new TLV in the PIM Join Attribute message [RFC5384] for specifying the explicit path 🎀

2. Specification of Requirements 📏

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] 🫶

3. Motivation 🌷

Some broadcast video transport networks use a multicast PIM Live-Live resiliency model for video delivery. It's based on PIM Source-Specific Multicast (PIM-SSM) or PIM Any-Source Multicast (PIM-ASM). Live-Live means using two active, spatially diverse multicast trees to carry video flows from root to leaf multicast routers. The leaf multicast router gets two copies from the PIM multicast core and replicates one copy toward the receivers [RFC7431] 📺

One requirement of the PIM Live-Live model is path diversity for the two active PIM trees in the core. They shouldn't intersect, so there's no single point of failure 😭 IGP-routed RPF paths for two PIM trees can end up going through the same transit router, which creates exactly that single point of failure 💀 So it's useful to be able to specify the explicit path the PIM Join travels along 🧚

How the Explicit RPF Vector list gets determined is outside the scope of this document. For example, the network operator could configure it manually, or the egress router could dynamically calculate the Vector list using a link-state database protocol, like OSPF or IS-IS 🍓

Because the leaf router receives two copies of the multicast stream over two diverse paths, PIM doesn't need to repair a broken path right away. It's up to the egress router to either wait for the broken path to be repaired or build a new explicit path with a new RPF Vector list. Which option makes sense depends a lot on how the Vector list was originally determined 🌸 Double failures are not considered and are outside the scope of this document 🙈

This document explains how to carry Explicit RPF Vectors in PIM. It's up to the mechanism(s) that produce the Explicit RPF Vectors to make sure they're correct. Existing mechanisms like [MTRACE-V2] may be used to verify how the PIM tree was built 🔍

4. Use of the PIM Explicit RPF Vector 🛤️

Figure 1 shows an example multicast join path, R4->R3->R6->R5->R2->R1. The multicast join is explicitly routed to the source hop by hop using the Explicit RPF Vector list. When the R5-R6 link fails, the Join will NOT take an alternate path 😤

                  [S]---(R1)--(R2)---(R3)--(R4)---[R]
                         <---   |      |  ---
                            |   |      |  |
                            | (R5)---(R6) |
                            - (S,G) Join -
                                |      |
                                |      |
                              (R7)---(R8)

                                 Figure 1

Compare that with the procedures in [RFC5496]. If the R5-R6 link fails there, the Join may be rerouted along the R6-R8-R7 path to reach R5 🦋

5. Explicit RPF Vector Attribute TLV Format 🎀

       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |F|E| Type      | Length        |        Value
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......

                                 Figure 2

F bit: 'Transitive Attribute' bit. The F bit MUST be set to 0. Otherwise, there could be loops 🔁

E bit: 'End of Attributes' bit. If the E bit is set, then this is the last TLV specified in the list 🏁

Type: 4 (Explicit RPF Vector) 🩷

Length: The length depends on the Address Family (IPv4 or IPv6) of the Encoded-Unicast address 📐

Value: Encoded-Unicast address. This SHOULD be a valid IPv4 or IPv6 address of an upstream router 🌈

8. PIM Asserts ✨

Okay so, section 3.3.3 of [RFC5496] is the one that explains how to handle PIM Asserts when RPF Vectors are in play 🎀. The Explicit RPF Vector follows those exact same procedures, bestie 💅. There's one tiny difference though: the route metric that goes inside the PIM Assert should be the route metric of the first Explicit RPF Vector address in the list 🦋. But the first Explicit Vector should always be directly connected, so the metric will likely be zero 🌸. Which means the metric won't really be a tie breaker in the PIM Assert selection procedure 🙈 iykyk.

9. Join Suppression ✨

Section 3.3.4 of [RFC5496] covers how Join Suppression works when an RPF Vector Attribute shows up in the PIM Join 💖. The Explicit RPF Vector Attribute gets the same treatment 🧚. The procedure MUST match against all the Explicit RPF Vectors in the PIM Join before a PIM Join can be suppressed 🔥. So no skipping ahead, every single vector gets checked first 💅.

10. Unsupported Explicit Vector Handling ✨

Okay this one is so important 😭. The F bit MUST be set to 0 in all Explicit RPF Vectors, just in case the upstream router that gets the Join doesn't support the TLV 🫶. As Section 3.3.2 of [RFC5384] describes, routers that don't understand an attribute type whose F bit is clear will discard it and keep processing the Join 🦋. Literally a safe little escape hatch 🎀.

This is extra important when the routers that don't support the Explicit RPF TLV show up as hops in the Explicit RPF list 🙈. If the vectors aren't removed, upstream routers might send the Join right back toward those routers, and then you get loops 💀. Not it!

Since the administrator is manually picking the path the Joins travel on, it is recommended that they compute the path to include routers that support the Explicit Vector 🌈. They should also check that the state gets created correctly on each router along the path ✨. Tools like mtrace can be used for debugging and to make sure the Join state is set up correctly 🧚.

11. IANA Considerations ✨

In the "PIM Join Attribute Types" registry, IANA has assigned the value 4 to the Explicit RPF Vector Attribute 👑.

12. Security Considerations ✨

Okay, serious moment, bestie 😭. Security of the Explicit RPF Vector Attribute is only guaranteed by the security of the PIM packet itself, so the security considerations for PIM Join packets described in PIM-SM [RFC7761] apply here too 🔐. A malicious downstream node can try a denial-of-service attack by sending PIM Join packets with invalid addresses listed in the RPF Vector stack, trying to stop the Joins from reaching the correct upstream node 💀. Another denial-of-service move is a malicious downstream node targeting all Joins to one specific node, trying to overload its bandwidth by making it forward multicast traffic for more streams than it can handle 😱. To minimize the risk of denial-of-service attacks from forged PIM Join packets with an Explicit RPF Vector stack, it should be used within a single trusted management domain 🛡️💜.

If a router finds that it can't use the Vector list because the next hop router isn't a PIM neighbor, it may log an error 🙈. Also, if a router receives two conflicting Vectors, it may log an error too 🫣. It's up to the mechanisms that produced the Explicit RPF Vector to make sure the PIM tree is built correctly and to monitor any error logs 🍓.

13. References ✨

13.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, <http://www.rfc-editor.org/info/rfc2119>.

[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, DOI 10.17487/RFC5384, November 2008, <http://www.rfc-editor.org/info/rfc5384>.

[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, DOI 10.17487/RFC5496, March 2009, <http://www.rfc-editor.org/info/rfc5496>.

[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, <http://www.rfc-editor.org/info/rfc7761>.

13.2. Informative References 🦋

[MTRACE-V2] Asaeda, H., Meyer, K., and W. Lee, "Mtrace Version 2: Traceroute Facility for IP Multicast", Work in Progress, draft-ietf-mboned-mtrace-v2-13, June 2016.

[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. Decraene, "Multicast-Only Fast Reroute", RFC 7431, DOI 10.17487/RFC7431, August 2015, <http://www.rfc-editor.org/info/rfc7431>.

Acknowledgements 🎀

The authors would like to thank Vatsa Kumar, Nagendra Kumar, and Bharat Joshi for their comments on the document 🫶.

Authors' Addresses 💌

Javed Asghar Cisco Systems 725, Alder Drive Milpitas, CA 95035 United States

Email: jasghar@cisco.com

IJsbrand Wijnands (editor) Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium

Email: ice@cisco.com

Sowmya Krishnaswamy Cisco Systems 3750 Cisco Way San Jose, CA 95134 United States

Email: sowkrish@cisco.com

Apoorva Karan Cisco Systems 3750 Cisco Way San Jose, CA 95134 United States

Email: apoorva@cisco.com

Vishal Arya DIRECTV Inc. 2230 E Imperial Hwy El Segundo, CA 90245 United States

Email: varya@directv.com