]> false}="yes"?> Arista Networks, Inc.

fenner@fenron.com

Arista Networks, Inc.

skumar@arista.com

Cisco Systems, Inc.

stig@cisco.com

Nokia

hooman.bidgoli@nokia.com

Routing Protocols for IP Multicast ECMP PIM Join Data Center In densely interconnected networks, a PIM node may have many choices as to what upstream neighbor to send a JOIN message to, for a given source and group. This document describes a mechanism for multiple nodes (e.g., leaf nodes in a data center) to pick the same upstream node (e.g., spine node) to avoid redundant traffic flows. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Protocols for IP Multicast Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction In a densely interconnected network, there may be many equal-cost paths to a given source or RP. RFC7761 is silent on the issue of how to choose among these, just indicating that RPF_interface(S) and RPF_interface(RP) have a single answer. If different leaf routers make different choices, then traffic can flow over extra paths. This document introduces two mechanisms: one for two-tier networks and one for arbitrary multi-tier networks, to allow routers to make the same decision of which neighbor to use in an ECMP scenario. This eliminates undesired redundant traffic flow.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Hash Algorithm In this document, the hash algorithm used is Bob Jenkins' one-at-a-time hash. This is a very high quality, but fast hash function. A suite of related hash functions was originally published in an article in Dr. Dobbs' Journal . The "one at a time" hash used in this document is an update to that journal article that Jenkins later posted on his web site. This hash function is defined on sequences of octets; it is performed across all of the addresses given in network byte order. Pseudocode like hash( address1, address2, address3 ) conceptually lays out these addresses adjacent to each other in memory in network byte order, and performs a single hash operation across all 12 octets. Similarly, when there are two IPv6 addresses and a router ID, we conceptually lay these out identically, simply with larger addresses, and perform the hash operation across all 36 octets. When the hash involves a color, that 32-bit value in network byte order takes the place of the 32-bit router ID.

Deterministic Selection by Router-ID We use the Hello Option to allow multiple routers to hash a given (S,G) join to the same RPF neighbor. The procedure consists of two phases: first, we compute hash( S, G, routerId ) for each eligible RPF neighbor, and select the highest hash value among this list. If there are multiple entries with the highest hash value, we re-hash among this sub-list using hash( S, G, local-information ), and use the highest single resulting hash value. If multiple hops still hash to the same value, we simply take the first one in the list. This results in no coordination between nodes, since each node may have a different order for the list. The local-information is a value local to the router that can be influenced by the deployment to have the same result between multiple peers - e.g., it could be an interface name, and the deployment on multiple routers uses the same interface to connect to the same peer. It could also be a locally-configured value on each interface, which results in higher configuration overhead but more deployment flexibility.

Pseudocode for Deterministic Hashing based on Router ID bestHash: bestVias = [ via ] bestHash = curHash elif curHash == bestHash: bestVias.append( via ) if len( bestVias ) == 1: return bestVias[ 0 ] bestHash = 0 bestVia = None for via in bestVias: local_information = getLocalInformation( via ) curHash = calculateHash( source, group, local_information ) if curHash > bestHash: bestVia = via bestHash = curHash return bestVia ]]>

Hello Option to Exchange Color We describe a Hello Option to exchange "Color", an abstract notion of grouping of nodes. For example, in a 3-tier network, the routers in the middle tier could be colored by the spine to which they connect in the top tier. In this way, the color value presented to the leaf routers by the middle tier is a proxy for the routers in the top tier. This Hello option should only be advertised "downwards" towards the lower levels of the tree.

Color Hello Option Message Format The PIM Hello Option used to exchange Color values is shown below.

Color Hello Option

Type: TBD (see and ) Length: In bytes for the value part of the Type/Length/Value encoding. The Color will be 4 bytes long. Color: The color value being advertised by this router.

Deterministic Selection by Color We use the above Hello Option to add an initial round of hashing, falling back to the algorithm in to break ties. The eligible RPF neighbors are reduced to those that have advertised a color using the above Hello option. The first round is to calculate hash( S, G, color ) for each eligible RPF neighbor, and select the highest hash value among this list. If there are multiple entries with the highest hash value, we re-hash among this sub-list with viaMultipathRouterId defined above.

Pseudocode for Deterministic Hashing based on Color bestHash: bestVias = [ via ] bestHash = curHash elif curHash == bestHash: bestVias.append( via ) if len( bestVias ) == 1: return bestVias[ 0 ] return viaMultipathRouterId( source, group, bestVias ) ]]>

Comparison with RFC6754 , "ECMP Redirect", defines a mechanism that allows an upstream router to give an explicit RPF neighbor to a downstream, and suggest that the downstream start sending its Join messages to that different upstream. We compare the mechanism in this document with that one.

Operation

In ECMP Redirect, the upstream router responds to a Join or notices traffic flowing and makes a decision that the traffic should be taking a different path. With this mechanism, each downstream router makes a consistent decision so no correction is necessary.

Message Exchange

In ECMP Redirect, an explicit Redirect message is sent, up to one message for each (S,G) for each peer. With this mechanism, the messages exchanged are limited to options in the Hello exchange.

Dynamic Behavior

In ECMP Redirect, traffic flow can be disrupted by the change from one upstream neighbor to another. With this mechanism, the initial choice is stable and does not change.

Complete Information

In ECMP Redirect, each upstream router must have complete information about what upstream router is appropriate for what stream. With this mechanism, color information is distributed in Hello messages and does not require complete knowledge. # Security Considerations

TODO Security

IANA Considerations IANA is requested to allocate a value from the PIM-Hello Options registry as shown:

Value	Length	Name	Reference
TBD	4	Color	This Document

References Normative References This document defines a new PIM Hello option to advertise an Interface Identifier that can be used by PIM protocols to uniquely identify an interface of a neighboring router. [STANDARDS-TRACK] This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source. This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References A Protocol Independent Multicast (PIM) router uses the Reverse Path Forwarding (RPF) procedure to select an upstream interface and router in order to build forwarding state. When there are equal cost multipaths (ECMPs), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources. This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP selection to be based on administratively selected metrics, such as data transmission delays, path preferences, and routing metrics. [STANDARDS-TRACK]

Arista Networks Compatibility This non-normative appendix describes the Arista Proprietary Color option, for the benefit of compatibility with the deployed base. A standards-compliant implementation SHOULD NOT emit or parse these options by default, but MAY have a configuration option to emit and parse these options on a given interface for interoperability. A pair of PIM Hello options is required for compatibility with the deployed base of Arista EOS. Both types are allocated from the "Private Use" reserved range. The first option, with type 65001, only serves to indicate with a "magic number" that the type 65002 option is indeed the Arista Proprietary Color option (as opposed to some other Private Use). These option formats are shown below.

Enable Arista Proprietary Hello options

By including this PIM Hello option, with type 65001 and 32-bit value 4028514875, you indicate that the rest of the PIM Hello options that you are including are Arista-proprietary.

Arista Proprietary Color option

The Arista Proprietary Color option is identical to the option described in figure , except for the Type field. It is only recognized if the Arista Proprietary Hello options are enabled by the option above.

Arista Color Hash Algorithm The Arista-compatible hash algorithm stores the color in little-endian byte order when hashing. When all routers in a set of vias are exchanging color information via the RFC-specified COLOR option, they MUST use the standard hash with the color in network byte order. When at least one router in a set of vias is exchanging color information via the Arista Proprietary Color option, they MUST use the Arista-compatible hash algorithm to compare colors.

Cisco Systems Compatibility Cisco has, independently of this draft, implemented hashing based on Router-ID as discussed in , except for a few differences listed here. The hash algorithm used is the RP hash defined in section 4.7.2. Using this hash, the hash value is calculated by doing hash(router-id, 32, hash(group, 32, source)). In case multiple entries hash to the same value, the re-hash is using the interface ID announced in the Hello Option rather than local information. Hashing based on color is not implemented.

Sample Hash Values Hashing with Router-ID: In this case, the neighbor with Router-ID 10.0.0.2 would be chosen. Hashing with Color, Arista-compatible: In this case, the neighbor with color 30 would be chosen. Hashing with Color, RFC-compatible: In this case, the neighbor with color 10 would be chosen.

Change history This section is to be removed before publishing as an RFC.

Changes since draft-fenner-pim-deterministic-ecmp-00

• Remove the note about coming up with a different term than Color, it feels like Color will suffice
• Added memory layout for IPv6 address hashing
• Added contributed by Stig about Cisco's deterministic hashing
• Corrected sample hash values in

Changes since draft-fenner-pim-deterministic-ecmp-01

• Accepted as PIM WG work item

Changes since draft-ietf-pim-deterministic-ecmp-00

• Fixed typos in hash pseudocode.
• Use python for pseudocode (it was already almost python)
• Update references to Jenkins hash
• Limit the eligible RPF neighbors to those that have advertised the color hello option
• Add section comparing with RFC6754
• Added Hooman as co-author

Acknowledgments Thanks to Kalpesh Suthar of Juniper Networks for pointing out that the sample hash values in draft-fenner-pim-deterministic-ecmp-00 were calculated incorrectly.