RFC 7441

Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes

📅 published January 2015, from ietf

RFC 7441: Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes 🦋

okay so this one's from the IETF 💅 and it's all about how to fit mLDP info into BGP MCAST-VPN routes.

  • Published: January 2015 📅
  • Category: Standards Track (it's an Internet Standards Track document ✨)
  • ISSN: 2070-1721
  • Authors: IJ. Wijnands (Cisco Systems, Inc.), E. Rosen (Juniper Networks, Inc.), and U. Joorde (Deutsche Telekom) 🫶
  • Updates: RFC 6514 🔥
  • Obsoletes: nothing listed

Abstract 💖

Lots of service providers offer a "BGP/MPLS IP VPN" service to their customers. Existing IETF standards already cover how a service provider handles this for customers with IP unicast and IP multicast traffic in their VPNs. It's also desirable to support customers who have MPLS multicast traffic in their VPNs.

This document specifies the procedures and protocol extensions needed to support customers who use Multipoint LDP (mLDP) as the control protocol for their MPLS multicast traffic. Existing standards give some support to mLDP customers, but only under a restrictive set of circumstances. This document generalizes that existing support to include all cases where the customer uses mLDP, without any restrictions. This document updates RFC 6514.

Status of This Memo 🌸

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It 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). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7441.

Copyright (c) 2015 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) 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. Introduction ....................................................2
   2. Why This Document is Needed .....................................3
   3. Encoding an mLDP FEC in the MCAST-VPN NLRI ......................5
   4. Wildcards .......................................................7
   5. IANA Considerations .............................................7
   6. Security Considerations .........................................8
   7. References ......................................................9
      7.1. Normative References .......................................9
      7.2. Informative References .....................................9
   Acknowledgments ...................................................10
   Authors' Addresses ................................................10

1. Introduction ✨

Okay so, service providers (SPs) offer BGP/MPLS IP VPN service to their customers 💅. When a customer has IP multicast traffic in its VPN, the SP needs to signal the customer multicast states across the backbone. A customer with IP multicast traffic is typically using PIM (Protocol Independent Multicast) [PIM] and/or IGMP (Internet Group Management Protocol) [IGMP] as its multicast control protocol. The IP multicast states of these protocols are commonly denoted as "(S,G)" and/or "(*,G)" states, where "S" is a multicast source address and "G" is a multicast group address.

[MVPN-BGP] explains how an SP may use BGP to signal a customer's IP multicast states across the SP backbone. It does this with Multiprotocol BGP Updates whose Subsequent Address Family Identifier (SAFI) values contain the codepoint for MCAST-VPN (as defined in [MVPN-BGP]). The NLRI (Network Layer Reachability Information) field of these BGP Updates includes a customer Multicast Source field and a customer Multicast Group field, so the customer's (S,G) or (*,G) states can be encoded in the NLRI. Iconic 🎀

It's also desirable for the BGP/MPLS IP VPN service to support customers who use MPLS multicast, either instead of or in addition to IP multicast 🦋. This document specifies the procedures and protocol extensions needed to support customers who use mLDP [mLDP] to create and maintain Point-to-Multipoint (P2MP) and/or Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs). While mLDP is not the only protocol that can create and maintain multipoint LSPs, looking at other MPLS multicast control protocols is outside the scope of this document.

When a customer uses mLDP in its VPN, the customer multicast states associated with mLDP are denoted by an mLDP FEC Element (Forwarding Equivalence Class Element; see [mLDP]) instead of by an (S,G) or (*,G). So we need a way to encode a customer's mLDP FEC Elements in the NLRI field of BGP MCAST-VPN routes. 🧚

[MVPN-BGP] does specify a way of encoding an mLDP FEC Element in the MCAST-VPN NLRI field 🙈, but that encoding makes a bunch of restrictive assumptions about the customer's use of mLDP. (These assumptions are described in Section 2 of this document.) The purpose of this document is to update RFC 6514 [MVPN-BGP] so that customers using mLDP can be supported even when those assumptions do not hold.

Some SPs use the MVPN procedures to provide "global table multicast" service (i.e., multicast service that is not in the context of a VPN) to customers. Methods for doing this are specified in [GTM] and in [SEAMLESS-MCAST]. The procedures described in this document can be used along with the procedures of [GTM] or [SEAMLESS-MCAST] to provide global table multicast service to customers that use MPLS multicast in a global table context. 🌈

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. Why This Document Is Needed 🔥

An mLDP FEC Element consists of a FEC Type, a Root Node, and an Opaque Value. mLDP uses several FEC Types and, in particular, uses the FEC Type to tell P2MP LSPs apart from MP2MP LSPs. 👑

Section 11.1.2 of [MVPN-BGP] ("Originating Routes: mLDP as the C-Multicast Protocol") states:

Whenever a PE [Provider Edge router] receives, from one of its CEs [Customer Edge routers], a P2MP Label Map <X, Y, L> over interface I, where X is the Root Node Address, Y is the Opaque Value, and L is an MPLS label ... the PE constructs a Source Tree Join C-multicast route whose MCAST-VPN NLRI contains X as the Multicast Source field, and Y as the Multicast Group field.

In other words, the Root Node of the mLDP FEC Element appears in the Multicast Source field, and the Opaque Value of the mLDP FEC Element appears in the Multicast Group field. 🍓

This method of encoding an mLDP FEC in an MCAST-VPN NLRI can only be used if all of the following conditions hold:

  1. A customer using mLDP is not also using PIM/IGMP. The encoding in [MVPN-BGP] does not specify any way in which one can determine, upon receiving a BGP Update, whether the Multicast Group field contains an IP address or whether it contains an mLDP FEC Element Opaque Value. Therefore, it might not uniquely identify a customer multicast state if the customer is using both PIM/IGMP and mLDP in its VPN. 🙈
  2. A customer using mLDP is using only the mLDP P2MP FEC Element and is not using the mLDP MP2MP FEC Element. The encoding in [MVPN-BGP] does not specify any way to encode the type of the mLDP FEC Element; it just assumes it to be a P2MP FEC Element. 💀
  3. A customer using mLDP is using only an mLDP Opaque Value type for which the Opaque Value is exactly 32 bits or 128 bits long. The use of Multicast Group fields that have other lengths is declared by [MVPN-BGP] to be "out of scope" of that document (see, e.g., Section 4.3 of that document). This condition holds if the customer uses only the mLDP "Generic LSP Identifier" Opaque Value type (defined in [mLDP]). However, mLDP supports many other Opaque Value types whose length is not restricted to be 32 or 128 bits. 😭

The purpose of this document is to update [MVPN-BGP] so that customers using mLDP can be supported, even when these conditions do not hold. ✨

3. Encoding an mLDP FEC in the MCAST-VPN NLRI ✨

okay so bestie, when mLDP is the customer multicast control protocol, [MVPN-BGP] assumes an mLDP FEC Element gets encoded in the NLRI of three MCAST-VPN route types 💖:

  • C-multicast Source Tree Join route,
  • S-PMSI A-D route, and
  • Leaf A-D route.

The other four MCAST-VPN route types from [MVPN-BGP] never need to carry mLDP FEC Elements 🙈. The C-multicast Shared Tree Join route and the Source Active A-D route talk about unidirectional shared trees, and mLDP doesn't have those, so these routes aren't used to signal mLDP states. The Intra-AS I-PMSI A-D route and the Inter-AS I-PMSI A-D route don't point at specific customer multicast states, so they don't carry anything specific to the customer's multicast control protocol. Not them being main characters here 💀.

This document adds three new route types 🦋:

  • C-Multicast Source Tree Join route for C-multicast mLDP,
  • S-PMSI A-D route for C-multicast mLDP, and
  • Leaf A-D route for C-multicast mLDP.

The "C-multicast mLDP" part of each name is there to show that the NLRI of these routes holds mLDP FEC Elements. Iconic naming, no notes 👑.

Each of these maps onto a route type from [MVPN-BGP]. IANA has been asked to allocate codepoints for these three route types so that (a) the high-order two bits have the value 0x01, and (b) the low-order six bits match the codepoints of the corresponding route types from [MVPN-BGP] 🌸.

In general, the procedures other MVPN specifications define for the C-Multicast Source Tree Join route, the S-PMSI A-D route, and the Leaf A-D route also apply to the C-Multicast Source Tree Join route for C-multicast mLDP, the S-PMSI A-D route for C-multicast mLDP, and the Leaf A-D route for C-multicast mLDP, in that order. The NLRI is where it gets different, though 😭. Compared with the corresponding routes from [MVPN-BGP], the Multicast Source Length, Multicast Source, Multicast Group Length, and Multicast Group fields are left out, and a single mLDP FEC Element, as defined in [mLDP], takes their place. (See Section 2.2 of [mLDP] for a diagram of the mLDP FEC Element 🧚.)

So the NLRI of an S-PMSI A-D route for C-multicast mLDP is a Route Distinguisher, then the mLDP FEC, then the Originating Router's IP Address field 🎀.

The NLRI of a C-multicast Source Tree Join route for C-multicast mLDP is a Route Distinguisher, then the Source AS, then the mLDP FEC 💅.

In a Leaf A-D route for C-multicast mLDP that was derived from an S-PMSI A-D route for C-multicast mLDP, the Route Key field stays the NLRI of the S-PMSI A-D route it came from ✨.

In a Leaf A-D route for C-multicast mLDP that wasn't derived from an S-PMSI A-D route, the Route Key field follows [SEAMLESS-MCAST], except that the Multicast Source Length, Multicast Source, Multicast Group Length, and Multicast Group fields are omitted and a single mLDP FEC Element takes their place. So the Route Key is a Route Distinguisher, an mLDP FEC Element, and the IP address of the Ingress PE router 🫶.

Please note that [BGP-ERR], Section 5.4 ("Typed NLRI") applies if the Route Type field of the NLRI of a received MCAST-VPN route has a value that isn't recognized. Any such routes will be discarded 🙅‍♀️.

An mLDP FEC Element has an address family field, and its value comes from IANA's "Address Family Numbers" registry 🌈. That value tells you the address family of the Root Node Address field of the FEC Element. When an mLDP FEC Element gets encoded into the NLRI of a BGP Update whose SAFI is MCAST-VPN, the address family of the Root Node Address (as indicated in the FEC Element) MUST correspond to the address family identified in the Address Family Identifier (AFI) field of that BGP Update. These two address family fields count as corresponding to each other under the following conditions:

  • they contain identical values,
  • the BGP Update's AFI field identifies IPv4 as the address family, and the mLDP FEC Element identifies "Multi-Topology IPv4" as the address family of the Root Node, or
  • the BGP Update's AFI field identifies IPv6 as the address family, and the mLDP FEC Element identifies "Multi-Topology IPv6" as the address family of the Root Node.

If you want more on the "multi-topology" address families, check out [LDP-MT] and [mLDP-MT] 🔥.

4. Wildcards 🍓

[MVPN-WILDCARDS] specifies the encodings and procedures that let "wildcards" be specified in the NLRI of S-PMSI A-D routes. It also gives a set of rules for when a customer multicast flow "matches" an S-PMSI A-D route whose NLRI has wildcards. Here's the catch 😤: those wildcards are only defined for when the customer uses PIM as its multicast control protocol. Using wildcards when the customer uses mLDP as its multicast control protocol is outside the scope of this document. Not this doc's problem, babe 💜.

5. IANA Considerations 🌷

[MVPN-BGP] doesn't create a registry for allocating new MCAST-VPN Route Type values. Looking back, it probably should have 🙈. So IANA has created a new registry called "BGP MCAST-VPN Route Types", which references this document and [MVPN-BGP]. The registry sits under the top-level registry "Border Gateway Protocol (BGP) Parameters" (<http://www.iana.org/assignments/bgp-parameters>) ✨. The allocation policy is "Standards Action". Values can be assigned from one of several ranges:

  • Range 0x01-0x3f: Generic/PIM Range. Values come from this range when the NLRI format for the route type presupposes that PIM or IGMP is the C-multicast control protocol, or when the NLRI format for the route type is independent of the C-multicast control protocol 🦋.
  • Range 0x43-0x7f: mLDP Range. Values come from this range when the NLRI format for the route type presupposes that mLDP is the C-multicast control protocol 🧚.
  • Range 0x80-0xff: This range is reserved, so values should not be assigned from it 🚫.

In general, whenever someone requests an assignment from this registry, two codepoints should be requested at the same time: one from the Generic/PIM range and one from the mLDP range. The two codepoints should have the same low-order 6 bits. If one of the two codepoints isn't actually needed, it should still be registered and marked as "Reserved" 🫶.

The "BGP MCAST-VPN Route Types" registry has these initial assignments 👑:

Value       Meaning                              Reference
---------   ----------------------------------   -------------------
0x00        Reserved                             This RFC

0x01        Intra-AS I-PMSI A-D route            This RFC, [RFC6514]

0x02        Inter-AS I-PMSI A-D route            This RFC, [RFC6514]

0x03        S-PMSI A-D route                     This RFC, [RFC6514]

0x04        Leaf A-D route                       This RFC, [RFC6514]

0x05        Source Active A-D route              This RFC, [RFC6514]

0x06        Shared Tree Join route               This RFC, [RFC6514]

0x07        Source Tree Join route               This RFC, [RFC6514]

0x08-0x3f   Unassigned (Generic/PIM range)       This RFC

0x40-0x42   Reserved                             This RFC

0x43        S-PMSI A-D route for
            C-multicast mLDP                     This RFC

0x44        Leaf A-D route for C-multicast mLDP  This RFC

0x45-0x46   Reserved                             This RFC

0x47        Source Tree Join route for
            C-multicast mLDP                     This RFC

0x48-0x7f   Unassigned (mLDP range)              This RFC

0x80-0xff   Reserved                             This RFC

6. Security Considerations 💀

This document specifies a way to encode an mLDP FEC Element in the NLRI of some of the BGP Update messages specified in [MVPN-BGP]. The security considerations of [mLDP] and of [MVPN-BGP] apply here, but this document doesn't raise any new security considerations. Phew, but still, don't skip those other docs 😭🔥.

7. References 📚

7.1. Normative References

[mLDP] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>.

[MVPN-BGP] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012, <http://www.rfc-editor.org/info/rfc6514>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

7.2. Informative References

[BGP-ERR] Chen, E., Ed, Scudder, J., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", Work in Progress, draft-ietf-idr-error-handling-18, December 2014.

[GTM] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K., Pacella, D., and J. Schiller, "Global Table Multicast with BGP-MVPN Procedures", Work in Progress, draft-ietf-bess-mvpn-global-table-mcast-00, November 2014.

[IGMP] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002, <http://www.rfc-editor.org/info/rfc3376>.

[LDP-MT] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. King, "LDP Extensions for Multi-Topology", RFC 7307, July 2014, <http://www.rfc-editor.org/info/rfc7307>.

[mLDP-MT] Wijnands, IJ. and K. Raza, "mLDP Extensions for Multi Topology Routing", Work in Progress, draft-iwijnand-mpls-mldp-multi-topology-03, June 2013.

[MVPN-WILDCARDS] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 6625, May 2012, <http://www.rfc-editor.org/info/rfc6625>.

[PIM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006, <http://www.rfc-editor.org/info/rfc4601>.

[SEAMLESS-MCAST] Rekhter, Y., Aggarwal, R., Morin, T., Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area P2MP Segmented LSPs", Work in Progress, draft-ietf-mpls-seamless-mcast-14, June 2014.

Acknowledgments 🫶

The authors wish to thank Pradosh Mohapatra and Saquib Najam for their ideas and comments. We also thank Yakov Rekhter and Martin Vigoureux for their comments 💖.

Authors' Addresses 🌸

IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a Diegem 1831
Belgium
EMail: ice@cisco.com
Eric C. Rosen
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA  01886
United States
EMail: erosen@juniper.net
Uwe Joorde
Deutsche Telekom
Dahlweg 100
D-48153 Muenster
Germany
EMail: Uwe.Joorde@telekom.de
📦 where this page comes from