RFC 8059

PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments

📅 published January 2017, from ietf

Part 1 of 2 🎀

RFC 8059: PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments 💖

Okay bestie, the receipts first 🧾✨ This is RFC 8059, published by the Internet Engineering Task Force (IETF) in January 2017. It's an Experimental document (category: Experimental) with ISSN 2070-1721. The authors are J. Arango, S. Venaas (Cisco Systems), I. Kouvelas (Arista Networks Inc.), and D. Farinacci (lispers.net). It doesn't obsolete or update any other RFC, since the title block has no Obsoletes or Updates lines. Now let's get into it 🦋

Abstract ✨

okay so this doc defines two PIM Join/Prune attributes that help build multicast distribution trees where the root and the receivers sit in different Locator/ID Separation Protocol (LISP) sites 🌈 The first attribute lets the receiver site choose between unicast and multicast underlying transport. The second one carries the RLOC (Routing Locator) address of the receiver ETR (Egress Tunnel Router) over to the control plane of the root ITR (Ingress Tunnel Router) 💅

Status of This Memo 📜

bestie, read this part, it's the vibe check on what kind of document this is 🙈 This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation.

This document defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that 💜

Info about the current status of this document, any errata, and how to give feedback on it is at http://www.rfc-editor.org/info/rfc8059.

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 (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please review these documents carefully, because 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 they are provided without warranty as described in the Simplified BSD License 📝

Table of Contents 📚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   3
3.  PIM Join/Prune Attributes . . . . . . . . . . . . . . . . . .   3
4.  The Transport Attribute . . . . . . . . . . . . . . . . . . .   4
  4.1.  Transport Attribute Format  . . . . . . . . . . . . . . .   4
  4.2.  Using the Transport Attribute . . . . . . . . . . . . . .   5
5.  Receiver ETR RLOC Attribute . . . . . . . . . . . . . . . . .   5
  5.1.  Receiver RLOC Attribute Format  . . . . . . . . . . . . .   6
  5.2.  Using the Receiver RLOC Attribute . . . . . . . . . . . .   6
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
  8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction 🌸

okay so picture this: you've got multicast distribution trees where the root and the receivers live in different LISP sites [RFC6830]. Building those is defined in [RFC6831]. To create (root-EID,G) state in the root site, unicast LISP-encapsulated Join/Prune messages have to get sent from an ETR on the receiver site to an ITR on the root site. (Quick reminder: "EID" is short for "Endpoint ID" 🧚)

[RFC6831] says (root-EID,G) data packets are LISP-encapsulated into (root-RLOC,G) multicast packets. Real talk though, a wide deployment of multicast connectivity between LISP sites isn't happening any time soon 😭 Some implementations are starting out with unicast transport and head-end replication between the root and receiver sites instead.

The unicast LISP-encapsulated Join/Prune message says which (root-EID,G) state needs to be set up in the root site, but it says absolutely nothing about whether the receiver can do multicast or even wants to 💀 This doc adds a Join/Prune attribute so the receiver ETR can pick the transport it actually wants 🎀

The word "transport" here is intentionally a little vague 🦋 Right now it only tells you whether multicast or head-end replication is being used, which means the outer destination address is either a unicast or a multicast address. Future documents may spell out other kinds of delivery, encapsulation, or underlay.

The root ITR really needs the receiver ETR's RLOC address 👑 The RLOC decides the downstream destination for unicast head-end replication, and it identifies which receiver ETR needs a heads-up if the root ITR of the distribution tree moves to another site. And yes, the root ITR can change when the source EID roams to another LISP site.

Service providers may implement unicast reverse path forwarding (uRPF) policies that require the outer source address of the LISP-encapsulated Join/Prune message to be the address of the receiver ETR's core-facing interface used to physically send the message. But because of policy and load-balancing stuff, the outer source address might not be the RLOC the receiver site wants to receive a particular flow on 🙈 So this doc specifies a Join/Prune attribute that conveys the right receiver ETR RLOC address to the control plane of the root ITR.

This document uses terminology from [RFC6830], like EID, RLOC, ITR, and ETR, so you're covered 💅

2. Requirements Notation 🫶

the BCP 14 key words, the capital-letter ones, are explained right here 🔥 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. PIM Join/Prune Attributes ✨

okay so [RFC5384] defines PIM Join/Prune attributes by introducing a new Encoded-Source type. Along with the Join/Prune source, it can carry multiple Type-Length-Value (TLV) attributes, and those attributes apply to the individual Join/Prune sources they're stored on 🧚

The attributes in this document follow the format of the encoding type from [RFC5384]. They'd usually be the same for all the sources in the Join/Prune message, which is why we RECOMMEND using the hierarchical Join/Prune attribute scheme from [RFC7887]. It's giving efficiency 🍓 That hierarchical system lets attributes ride in the Upstream Neighbor Address field, so one attribute instance can cover all the sources in the Join/Prune message.

LISP Tunnel Routers (xTRs) don't exchange PIM Hello Messages, so there's no Hello option defined to negotiate support for these attributes. Instead, systems that support unicast head-end replication are assumed to support these attributes 🌸

4. The Transport Attribute 🦋

It's essential that there's a way for receiver sites to convey the transport they want 💖 Root sites with multicast connectivity will want to take advantage of multicast replication. But not every receiver site can be expected to have multicast connectivity, so it's desirable that root sites be prepared to support (root-EID,G) state with a mix of multicast and unicast output state. This doc specifies a Join/Prune attribute that lets the receiver select its underlying transport 🎀

4.1. Transport Attribute Format 🎀

    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 = 5 | Length = 1    |  Transport    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's the breakdown of each field 💅

  • F bit: The Transitive bit. It specifies whether the attribute is transitive or non-transitive. It MUST be set to zero. This attribute is ALWAYS non-transitive 🙅‍♀️
  • E bit: End-of-Attributes bit. It specifies whether this attribute is the last one. Set it to zero if there are more attributes. Set it to 1 if this is the last attribute 🧚
  • Type: The Transport Attribute type is 5 ✨
  • Length: The length of the Transport Attribute value. It MUST be set to 1.
  • Transport: The type of transport being requested. Set it to zero for multicast and to 1 for unicast. The values from 2 to 255 may be assigned in the future 🌈

4.2. Using the Transport Attribute 💜

Hierarchical Join/Prune attribute instances [RFC7887] SHOULD be used when the same Transport Attribute is going to apply to all the sources within the Join/Prune message, or to all the sources within a group set. The root ITR MUST accept Transport Attributes in the Upstream Neighbor Encoded-Unicast address, Encoded-Group addresses, and Encoded-Source addresses 👑

There MUST NOT be more than one Transport Attribute within the same encoded address. If an encoded address has more than one instance of the attribute, the root ITR MUST discard all affected Join/Prune sources. The root ITR MUST also discard all affected Join/Prune sources if the Transport Attribute value is unknown 🙈

5. Receiver ETR RLOC Attribute ✨

Okay so, when a receiver ETR asks for unicast head-end replication on a given (root-EID,G) entry, the PIM control plane of the root ITR has to keep an oif-list entry for that receiver ETR and its matching RLOC address 💖. That's what lets the root ITR unicast-LISP-encapsulate multicast data to each and every receiver ETR that asked for it 🦋

The root ITR's PIM control plane could technically figure out the receiver ETR's RLOC from the outer source address of the LISP-encapsulated Join/Prune message 🤔 But receiver ETRs get uRPF-checked by the network providers on every core-facing interface 🛡️ So the outer source address has to be the RLOC of the core-facing interface that actually sent the LISP-encapsulated Join/Prune message. And because of policy and load-balancing stuff, that might not be the RLOC the receiver site wants to receive a specific flow on 🙈 So this document defines a Join/Prune attribute that carries the right receiver RLOC address over to the PIM control plane of the root ITR 🎀

Root-EID mobility is the other piece 🧚 Receiver ETRs have to be tracked by the LISP control plane of the root ITR no matter which transport is in use ✨ When the root-EID moves to a new root ITR in a different LISP site, the receiver ETRs don't know it moved, so they don't know the RLOC of the new root ITR either 😭 That's true for both unicast and multicast transport modes. The new root ITR has no receiver ETR state at all, so the old root ITR is the one responsible for telling the receiver ETRs that the root-EID has moved 👑 When the old root ITR notices the move, it sends a LISP Solicit-Map-Request (SMR) message to each receiver ETR. The receiver ETRs then do a mapping database lookup to grab the RLOC of the new root ITR. The old root ITR finds out the root-EID moved when it gets a Map-Notify from the Map-Server, and that Map-Notify gets triggered when the new root ITR registers the root-EID [EID-MOBILITY]. Once a receiver ETR sees that the root ITR changed, it sends a LISP-encapsulated PIM prune message to the old root xTR and a LISP-encapsulated PIM join message to the new root xTR 💅

5.1. Receiver RLOC Attribute Format 🎀

Here's the layout, bestie 👀

   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 = 6 |    Length     |  Addr Family  |  Receiver RLOC
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
  • F bit (Transitive bit): this one says whether the attribute is transitive or non-transitive. It MUST be set to zero. The attribute is always non-transitive 🙅‍♀️
  • E bit (End-of-Attributes bit): this one says whether this attribute is the last one. Set it to zero if more attributes are coming, and set it to 1 if this is the last attribute 🏁
  • Type: the Receiver RLOC Attribute type is 6 🔢
  • Length: the length in octets of the attribute value. It MUST be set to the length in octets of the receiver RLOC address plus 1 octet, to account for the Address Family field 📏
  • Addr Family: the PIM Address Family of the receiver RLOC, as defined in [RFC7761] 🌍
  • Receiver RLOC: the RLOC address on which the receiver ETR wants to receive the unicast-encapsulated flow 🦋

5.2. Using the Receiver RLOC Attribute 🧚

Hierarchical Join/Prune attribute instances [RFC7887] SHOULD be used when the same Receiver RLOC Attribute is going to apply to all the sources in the message, or to all the sources in a group set 💜 The root ITR MUST accept Transport Attributes in the Upstream Neighbor Encoded-Unicast address, the Encoded-Group addresses, and the Encoded-Source addresses ✨

There MUST NOT be more than one Receiver RLOC Attribute within the same encoded address 🙅‍♀️ If an encoded address has more than one instance of the attribute, the root ITR MUST discard all affected Join/Prune sources 🗑️ The root ITR MUST also discard all affected Join/Prune sources if the address family is unknown, or if the address length is incorrect for the specified address family 💀

6. Security Considerations 🔐

Okay this part is serious, babe 😤 Security of Join/Prune attributes is only guaranteed by the security of the PIM packet itself. The attributes in this document don't make the privacy or authenticity of a Join/Prune message any better or any worse 🙈 A site that legitimately or maliciously sends and delivers a Join/Prune message to another site can add these attributes, plus any other attributes it wants, just the same 🥲 For general security considerations on Join/Prune attributes, see [RFC5384] 🔒

7. IANA Considerations 📋

Two new PIM Join/Prune attribute types were assigned: value 5 for the Transport Attribute, and value 6 for the Receiver RLOC Attribute 🎀

The "PIM Join/Prune Transport Types" registry was created for the Join/Prune Transport attribute 🗂️ Its registration policy is IETF Review [RFC5226], and the values are in the range 0-255. This document assigns value 0 for multicast and value 1 for unicast 🌈

8. References 📚

8.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>.

[RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
           Locator/ID Separation Protocol (LISP)", RFC 6830,
           DOI 10.17487/RFC6830, January 2013,
           <http://www.rfc-editor.org/info/rfc6830>.

[RFC6831]  Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
           Locator/ID Separation Protocol (LISP) for Multicast
           Environments", RFC 6831, DOI 10.17487/RFC6831, January
           2013, <http://www.rfc-editor.org/info/rfc6831>.

[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>.

[RFC7887]  Venaas, S., Arango, J., and I. Kouvelas, "Hierarchical
           Join/Prune Attributes", RFC 7887, DOI 10.17487/RFC7887,
           June 2016, <http://www.rfc-editor.org/info/rfc7887>.

8.2. Informative References 🦋

[EID-MOBILITY]
           Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
           F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
           Unified Control Plane", Work in Progress, draft-portoles-
           lisp-eid-mobility-01, October 2016.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           DOI 10.17487/RFC5226, May 2008,
           <http://www.rfc-editor.org/info/rfc5226>.

Authors' Addresses 🌸

Jesus Arango
Cisco Systems
170 Tasman Drive
San Jose, CA  95134
United States of America

Email: jearango@cisco.com


Stig Venaas
Cisco Systems
170 Tasman Drive
San Jose, CA  95134
United States of America

Email: stig@cisco.com


Isidor Kouvelas
Arista Networks Inc.
5453 Great America Parkway
Santa Clara, CA  95054
United States of America

Email: kouvelas@arista.com


Dino Farinacci
lispers.net
San Jose, CA
United States of America

Email: farinacci@gmail.com
📦 where this page comes from