RFC 7988

Ingress Replication Tunnels in Multicast VPN

📅 published October 2016, from ietf

RFC 7988: Ingress Replication Tunnels in Multicast VPN ✨

Okay bestie, this is RFC 7988, and it's giving Ingress Replication Tunnels in Multicast VPN 🦋. It's a Standards Track document (so it's the real spec, not just vibes 👑), dated October 2016, with ISSN 2070-1721. The authors are E. Rosen (Ed.) from Juniper Networks, Inc., K. Subramanian from Sproute Networks, and Z. Zhang from Juniper Networks, Inc. 💜 It updates [RFC6513] and [RFC6514], and there's no Obsoletes line in the header, so it doesn't replace anything 🌸.

Abstract 💖

[RFC6513], [RFC6514], and other RFCs describe procedures so a Service Provider can offer Multicast VPN (MVPN) service to its customers. ✨ These procedures build point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) trees across the Service Provider's backbone. One P2MP tree type is called an "Ingress Replication (IR) tunnel" 🌈. In an IR tunnel, a parent node doesn't have to be directly connected to its child nodes. When a parent needs to send a multicast data packet to its n child nodes, it doesn't use Layer 2 multicast, IP multicast, or MPLS multicast. Instead, it makes n separate copies and unicasts each copy through an IP or MPLS unicast tunnel to exactly one child node 💅. The older MVPN specs do allow IR tunnels, but they aren't always super clear about how the MVPN protocol elements and procedures apply to them 🙈. This document updates [RFC6513] and [RFC6514] by adding details that are specific to using IR tunnels 🫶.

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 went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841 📚.

For the current status of this document, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7988 🧚.

Copyright (c) 2016 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 read these carefully, because they spell out your rights and restrictions for this document 🙏. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💜.

Table of Contents 🦋

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  What is an IR P-tunnel? . . . . . . . . . . . . . . . . . . .   5
3.  How are IR P-tunnels identified?  . . . . . . . . . . . . . .   7
4.  How to Join an IR P-Tunnel  . . . . . . . . . . . . . . . . .   9
  4.1.  Advertised IR P-Tunnels . . . . . . . . . . . . . . . . .   9
    4.1.1.  If the Leaf Information Required Bit Is Set . . . . .  10
    4.1.2.  If the Leaf Information Required Bit Is Not Set . . .  10
  4.2.  Unadvertised IR P-Tunnels . . . . . . . . . . . . . . . .  11
5.  The PTA's Tunnel Identifier Field . . . . . . . . . . . . . .  11
6.  A Note on IR P-Tunnels and Discarding Packets from the Wrong
    PE  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
7.  The PTA's MPLS Label Field  . . . . . . . . . . . . . . . . .  14
  7.1.  Leaf A-D Route Originated by an Egress PE . . . . . . . .  14
  7.2.  Leaf A-D Route Originated by an Intermediate Node . . . .  16
  7.3.  Intra-AS I-PMSI A-D Route . . . . . . . . . . . . . . . .  17
8.  How A Child Node Prunes Itself from an IR P-Tunnel  . . . . .  17
9.  Parent Node Actions upon Receiving Leaf A-D Route . . . . . .  18
10. Use of Timers When Switching UMH  . . . . . . . . . . . . . .  19
11. Security Considerations . . . . . . . . . . . . . . . . . . .  20
12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
  12.1. Normative References . . . . . . . . . . . . . . . . . .  21
  12.2. Informative References . . . . . . . . . . . . . . . . .  21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  23
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1. Introduction ✨

[RFC6513], [RFC6514], and other RFCs describe procedures so a Service Provider (SP) can offer Multicast VPN (MVPN) service to its customers 💁‍♀️. These procedures make point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) tunnels, called "P-tunnels" (provider tunnels), across the SP's backbone network. Customer multicast traffic rides through those P-tunnels 🚀.

There are a bunch of P-tunnel technologies. One of them is called "ingress replication" or "unicast replication". We'll use the acronym "IR" for this P-tunnel technology 🌷.

An IR P-tunnel is a P2MP tree, but a node on that tree isn't necessarily directly attached to its parent or its child nodes 🙃. To send a multicast data packet from a parent node to one of its child nodes, the parent encapsulates the packet and unicasts it through a tunnel to that child. The tunnel can be a P2P or MP2P MPLS LSP (Label Switched Path) or a unicast IP tunnel 🎀. If a node on an IR tree has n child nodes and has a multicast data packet to send along the tree, the parent makes n individual copies of the packet and sends each copy through a unicast tunnel to exactly one child node 💫. No lower-layer multicast tech is used when sending traffic from parent to child, so multiple copies of the same packet can go out a single interface 😭.

Here's the tea 🍵: except for IR, the P-tunnel technologies supported by the MVPN specs are existing IP multicast or MPLS multicast technologies. Each one comes with its own specs, its own setup and maintenance protocols, its own syntax for identifying specific multicast trees, and its own procedures for adding a router to or removing it from a tree 📋. IR P-tunnels, on the other hand, don't have any earlier spec for setting up and maintaining the P2MP trees. The procedures and protocol elements for that are defined in the MVPN specs themselves, and all the signaling and setup is done with the BGP Auto-Discovery (A-D) routes defined in [RFC6514] 🧠. (The unicast tunnels that carry multicast data from one node to another inside an IR P-tunnel can of course have their own setup and maintenance protocols, e.g., [RFC5036], [RFC3209] 🔧.)

Since multicast data goes along an IR P-tunnel by way of a unicast tunnel, older RFCs sometimes say an IR P-tunnel "consists of" a set of unicast tunnels 🤷‍♀️. That's not quite accurate, though. First, it hides the fact that an IR P-tunnel is really a P2MP tree, whose nodes have to keep multicast state in both the control plane and the data plane 🌳. Second, it hides the fact that the unicast tunnels used by one IR P-tunnel don't have to belong to that P-tunnel. A single unicast tunnel can carry the multicast traffic of lots of different IR P-tunnels, and it can carry unicast traffic too 🫧.

In this document, we give a clearer, more explicit conceptual model for IR P-tunnels, and we spell out how an IR P-tunnel relates to the unicast tunnels it uses for data transmission 💖.

Section 5 of [RFC6514] defines a BGP Path Attribute called the "PMSI (Provider Multicast Service Interface) Tunnel attribute" (PTA). This attribute has a field called the "Tunnel Identifier" field. For most P-tunnel technologies, the PTA's "Tunnel Identifier" field is used to identify a P-tunnel (that is, a P2MP or MP2MP tree) 🌟. But with IR P-tunnels, the PTA "Tunnel Identifier" field doesn't actually identify the IR P-tunnel. Sometimes it identifies one of the P-tunnel's constituent unicast tunnels, and other times it isn't used to identify a tunnel at all 😵‍💫. This document gives an explicit spec for how IR P-tunnels actually get identified 🦋.

Some MVPN specs require a PE router to join the P-tunnel identified in a particular MVPN route. But until now, there hasn't been an explicit spec for how to identify an IR P-tunnel, how a router joins one, or how a router prunes itself from one 🥺. This document makes those procedures more explicit 👑.

[RFC6514] does provide a way to bind an MPLS label to a P-tunnel, but it doesn't cover the label allocation policies needed for correct operation when the P-tunnel is an IR P-tunnel. This document covers those policies 🏷️.

This document doesn't add any new protocol elements or any fundamentally new procedures. Its whole purpose is to spell out how a router uses the protocol elements and procedures of [RFC6513] and [RFC6514] to identify an IR P-tunnel, join it, and prune itself from it 🎯.

This document also covers the MPLS label allocation policies that need to be supported when binding MPLS labels to IR P-tunnels, and the timer policies that need to be supported when switching a customer multicast flow from one IR P-tunnel to another. Neither of these is clearly specified in [RFC6513] or [RFC6514] 🕰️.

Because the material here has to be understood in order to properly implement IR P-tunnels, this document updates [RFC6513] and [RFC6514] 🫶.

This document also discusses how "seamless multicast" [RFC7524] and "extranet" [RFC7900] procedures apply to IR P-tunnels 🌈.

This document doesn't discuss using IR P-tunnels to support a VPN customer's use of Bidirectional Protocol Independent Multicast (BIDIR-PIM). [RFC7740] explains how to adapt the procedures of [RFC6513], [RFC6514], and [RFC7582] so IR P-tunnels can support a customer's BIDIR-PIM use 💜.

If this document conflicts with either [RFC6513] or [RFC6514], this document wins 👑.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when and only when appearing in all capital letters, are to be interpreted as described in [RFC2119] 📖.

2. What is an IR P-tunnel? 🎀

Okay so, an IR P-tunnel is a P2MP tree 🌳. Its nodes are BGP speakers that support the MVPN procedures of [RFC6514] and related RFCs. Generally, the nodes are Provider Edge (PE) routers, Autonomous System Border Routers (ASBRs), or, if [RFC7524] is supported, Area Border Routers (ABRs) 💅.

MVPN procedures are sometimes used for non-MVPN multicast, also called "global table" multicast ✨. One way to do this is defined in [RFC7524], and another is defined in [RFC7716]. In those cases, IR P-tunnels can be used outside the context of MVPN 🦋.

MVPN P-tunnels can be either "segmented" or "non-segmented," and those terms are defined in [RFC6513] and [RFC6514] 📚.

A "non-segmented" IR P-tunnel is a two-level P2MP tree. It has only a root node and a set of nodes that are children of that root. When it's used in an MVPN context, the root is an ingress PE, and the root's children are the egress PEs 🫶.

In a segmented P-tunnel, IR may be used for some or all of the segments. If a particular segment uses IR, then the root of that segment may have children that are ABRs or ASBRs, instead of egress PEs 🌸.

Like any P2MP tree, every node of an IR P-tunnel holds "multicast state" for the P-tunnel. That means each node knows who its parent is on the tree, and each node knows who its children are on the tree 🧠. In the MVPN specs, the parent node is also called the "Upstream Multicast Hop" or "UMH." The UMH can be a PE, an ASBR, or, if procedures from [RFC7524] are being used, an ABR. (In [RFC7524], the term "upstream node" is used instead of "UMH.")

So what makes an IR P-tunnel different from every other kind of P2MP tree? It's the way a data packet gets sent from a parent node to a child node 👑. To send a multicast data packet from a parent to a child along a particular IR P-tunnel, the parent node does the following:

  • It labels the packet with a label (call it a "P-tunnel label") that the child node has assigned to that P-tunnel.
  • It then puts the packet in a unicast encapsulation and unicasts it to the child node. In other words, the parent sends the packet through a unicast tunnel to one specific child. That unicast tunnel doesn't have to be specially made to be part of the IR P-tunnel. It can be any P2P or MP2P unicast tunnel that gets the packets from the parent to the child 🧚. One unicast tunnel can carry multicast data packets from several different P2MP trees, and it can also carry unicast data packets too.

The parent repeats this for every child, making one copy per child and sending each copy through a unicast tunnel to the matching child 💜. It does not use Layer 2 multicast, IP multicast, or MPLS multicast to send packets to its children. Because of that, several copies of each packet can go out the same interface. That can happen, for example, when that interface is the next-hop interface, according to unicast routing, from the parent to several of the children 😭.

Since data on an IR P-tunnel is always unicast from parent to child, it's convenient to picture an IR P-tunnel as a P2MP tree whose arcs are unicast tunnels 🍓. But here's the important bit: the unicast tunnels don't have to belong to any particular IR P-tunnel. If R1 is the parent of R2 on two different IR P-tunnels, one unicast tunnel from R1 to R2 can carry data along both of them 🔥. All that's required is that when the data packets reach R2, R2 sees the "P-tunnel label" at the top of the packets' label stack, and R2's further processing depends on that label. That same unicast tunnel between R1 and R2 can also be carrying unicast data packets ✨.

Usually, the unicast tunnels are the LSPs that already exist to carry unicast traffic. These are either MP2P LSPs created by the Label Distribution Protocol (LDP) [RFC5036], or P2P LSPs created by Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC3209] 🌈. But any other kind of unicast tunnel can be used too. A unicast tunnel can have any number of intermediate routers, and those routers don't keep any multicast state for the IR P-tunnel. In general, they aren't even aware it exists 🙈.

Just like every other P-tunnel type, an IR P-tunnel can be used to instantiate either an Inclusive PMSI (I-PMSI) or a Selective PMSI (S-PMSI). See Section 3.2 of [RFC6513] for an explanation of those concepts 💖.

3. How are IR P-tunnels identified? 🧚

There are four MVPN BGP route types in which P-tunnels can be identified: Intra-AS I-PMSI A-D routes, Inter-AS I-PMSI A-D routes, S-PMSI A-D routes, and Leaf A-D routes. (These route types are all defined in [RFC6514].) 📖

Whenever a P-tunnel needs to be identified in a route of one of these types, a "PMSI Tunnel Attribute" (PTA) gets added to the route ✨. As defined in Section 5 of [RFC6514], the PTA has four fields: Tunnel Type, MPLS Label, Tunnel Identifier, and Flags. [RFC6514] defines only one bit in the Flags field, which is the Leaf Information Required bit 🎀.

If a route identifies an IR P-tunnel, the Tunnel Type field of its PTA is set to the value 6, which means "Ingress Replication" 🫶.

Most P-tunnel types are tied to specific protocols that are used to set up and maintain tunnels of that type. For example, if the Tunnel Type field is set to 2, meaning "mLDP P2MP LSP," the associated setup protocol is Multipoint LDP (mLDP) [RFC6388]. That setup protocol always has a way of identifying the tunnels it sets up. For instance, mLDP uses an FEC element (Forwarding Equivalence Class element) to identify a tree. If the Tunnel Type field is set to 3, meaning "PIM-SSM Tree," where "SSM" stands for Source-Specific Multicast, the setup protocol is PIM and "(S,G)" is used to identify the tree 🍓. In these cases, the Tunnel Identifier field of the PTA carries a tree identifier, as defined by the setup protocol for that tunnel type.

IR P-tunnels are different. They're set up and maintained entirely through BGP A-D routes, and they aren't tied to any other setup protocol 💅. (The unicast tunnels that carry multicast data along an IR P-tunnel can have their own setup and maintenance protocols, of course 🌸.) Identifying a P-tunnel works very differently for IR P-tunnels than for other types:

When an IR P-tunnel is identified in an S-PMSI A-D route, an Intra-AS I-PMSI A-D route, or an Inter-AS I-PMSI A-D route (we will refer to these three route types as "advertising A-D routes"), its identifier is hereby defined to be the NLRI (Network Layer Reachability Information) of that route. See Sections 4.1, 4.2, and 4.3 of [RFC6514] for the specification of these NLRIs. Note that the IR P-tunnel identifier includes the Route Type and Length fields (see Section 4 of [RFC6514]) of the NLRI.

To reiterate, and this part really matters 🚨:

The identifier of the IR P-tunnel does not appear in the PTA at all. The Tunnel Identifier field of the PTA does not contain the identifier of the IR P-tunnel. Instead, the identifier of the IR P-tunnel appears in the Network Layer Reachability Information (NLRI) field of the A-D routes that are used to advertise and set up the IR P-tunnel.

Also, an advertising A-D route only counts as identifying an IR P-tunnel if it carries a PTA whose Tunnel Type field is set to "IR" 👀.

When an IR P-tunnel is identified in an S-PMSI A-D route or in an Inter-AS I-PMSI A-D route, the Leaf Information Required bit of the Flags field of the PTA MUST be set 🔥.

For an advertising A-D route:

  • If the Leaf Information Required bit of the Flags field of the PTA is set, then the Tunnel Identifier field of the PTA has no significance whatsoever and MUST be ignored upon reception 💀.

Per RFC 6514, the length of the Tunnel Identifier field of the PTA is variable and is inferred from the length of the PTA. Even when this field doesn't matter, its length MUST be the length of an IP address in the address space of the SP's backbone, as specified in Section 4.2 of [RFC6515]. In this case, it is RECOMMENDED that it be set to a routable address of the router that constructed the PTA 🌈. (Allowing or even requiring the field to be left out entirely might make more sense, but that could raise backwards compatibility issues with implementations designed before this document was published 🙈.)

  • If the Leaf Information Required bit is not set, the Tunnel Identifier field of the PTA does have significance, but it does not identify the IR P-tunnel. The use of the PTA's Tunnel Identifier field in this case is discussed in Section 5 of this document 🧠.

Here's the key takeaway: according to the definition above, two different advertising A-D routes (meaning two advertising A-D routes with different NLRIs) can never advertise the same IR P-tunnel 😤. In the terminology of [RFC6513], an IR P-tunnel can instantiate only a single PMSI. So if an ingress PE wants to bind two customer multicast flows to a single IR P-tunnel, it must advertise that IR P-tunnel either in an I-PMSI A-D route, or in an S-PMSI A-D route whose NLRI contains wildcards [RFC6625] 💜.

When an IR P-tunnel is identified in a Leaf A-D route, its identifier is the Route Key field of the route's NLRI. See Section 4.4 of [RFC6514] 🦋.

A Leaf A-D route only counts as identifying an IR P-tunnel if it carries a PTA whose Tunnel Type field is set to "IR." In this type of route, the Tunnel Identifier field of the PTA does have significance, but it does not identify the IR P-tunnel. The use of the PTA's Tunnel Identifier field in this case is discussed in Section 5 ✨.

4. How to Join an IR P-Tunnel 💜

How you join an IR P-tunnel depends on whether the P-tunnel was previously advertised and, if it was, on how it was advertised 🫶. Joining an unadvertised IR P-tunnel is only possible when using the "global table multicast" procedures of [RFC7524] 🌸.

4.1. Advertised IR P-tunnels 🦋

The procedures in this section apply when the IR P-tunnel to be joined has been advertised in an S-PMSI A-D route, an Inter-AS I-PMSI A-D route, or an Intra-AS I-PMSI A-D route 🎀.

The procedures for joining an advertised IR P-tunnel depend on whether the A-D route that advertises the IR P-tunnel has the Leaf Information Required bit set in its PTA 👑.

4.1.1. If the Leaf Information Required Bit Is Set ✨

okay bestie, this part is for when the P-tunnel you wanna join was advertised in a route whose PTA has the Leaf Information Required bit set 🎀

The router joining a particular IR P-tunnel must figure out its UMH for that P-tunnel 💅 If the route that advertised the IR P-tunnel has a P2MP Segmented Next Hop Extended Community, the UMH comes from the value of that community (see [RFC7524]). Otherwise, it comes from the route's next hop (see [RFC6514]).

Once the UMH is known, the router joining the IR P-tunnel originates a Leaf A-D route 🦋 The NLRI of the Leaf A-D route is formed following the procedures of [RFC6514], so it will contain the IR P-tunnel identifier defined in Section 3 above as its "route key". The UMH MUST be identified by attaching an "IP-address-specific Route Target" (or an "IPv6-address-specific Route Target") to the Leaf A-D route. The IP address of the UMH shows up in the Global Administrator field of the Route Target (RT). You can find the details in [RFC6514] and [RFC7524] 🫶

The Leaf A-D route MUST also contain a PTA whose fields are set as follows:

  • The Tunnel Type field is set to "IR".
  • The Tunnel Identifier field is set as described in Section 5 of this document. (Note that this field does not contain the IR P-tunnel Identifier that is defined in Section 3.)
  • The MPLS Label field is set to a non-zero value. This is the "P-tunnel label". The value must be chosen so as to satisfy various constraints, as discussed in Section 7 this document. 🌸

4.1.2. If the Leaf Information Required Bit Is Not Set 🙈

These steps apply when the IR P-tunnel you're joining was advertised in a route whose PTA does not have the Leaf Information Required bit set. This can only happen if the IR P-tunnel was advertised in an Intra-AS I-PMSI A-D route.

If an IR P-tunnel is advertised in the Intra-AS I-PMSI A-D routes originated by the PE routers of a given MVPN, the Intra-AS I-PMSI can be thought of as being instantiated by a set of IR P-tunnels 🧚 Each PE is the root of one such IR P-tunnel, and the other PEs are children of that root. A PE joins all of these P-tunnels at once by originating (if it hasn't already done so) an Intra-AS I-PMSI A-D route with a PTA whose fields are set as follows:

  • The Tunnel Type field is set to "IR".
  • The Tunnel Identifier field is set as described in Section 5 of this document. (Note that this field does not contain the IR P-tunnel identifier that is defined in Section 3.)
  • The MPLS Label field MUST be set to a non-zero value. This label value will be used by the child node to associate a received packet with the I-PMSI of a particular MVPN. The MPLS label allocation policy must be such as to ensure that the binding from label to I-PMSI is one to one. 💜

The NLRI and the RTs of the originated I-PMSI A-D route are set as specified in [RFC6514].

4.2. Unadvertised IR P-Tunnels 🌈

In [RFC7524], there's a procedure for "global table multicast" where you can join a P-tunnel even if nobody advertised it first 😭 See Sections 6.2.2 and 6.2.3 of [RFC7524]: "Leaf A-D Route for Global Table Multicast" and "Constructing the Rest of the Leaf A-D Route". In this case, the route key of the Leaf A-D route has the form of the "S-PMSI Route-Type Specific NLRI" (see Section 4.3 of [RFC6514]), and that should be treated as the IR P-tunnel identifier. Heads up, though: finding the UMH works differently here. The UMH is the next hop of the best UMH-eligible route towards the "ingress PE". See Section 6.1 of [RFC7524], entitled "Determining the Upstream ABR/PE/ASBR (Upstream Node)". 👑

5. The PTA's Tunnel Identifier Field 💖

As we covered in Section 1, when the Tunnel Type field of a PTA is set to "IR", the Tunnel Identifier field of that PTA does not hold the IR P-tunnel identifier. This section explains how to set the Tunnel Identifier field of the PTA when the Tunnel Type field is "IR".

If the Tunnel Type field of a PTA is set to "IR", its Tunnel Identifier field only matters when one of these two conditions holds:

  • The PTA is carried by a Leaf A-D route, or
  • The Leaf Information Required bit of the Flags field of the PTA is not set.

If one of these conditions holds, the Tunnel Identifier field must contain a routable IP address of the originator of the route. (See Sections 9.2.3.2.1 and 9.2.3.4.1 of [RFC6514] for the detailed specification of what goes in this field.) The UMH uses this address to figure out which unicast tunnel to send data over, along the IR P-tunnel identified by the route key, to the originator of the Leaf A-D route 🦋

How that unicast tunnel gets determined from this IP address is outside the scope of this document. How the unicast tunnel gets set up and maintained is also outside the scope of this document.

Section 4 of [RFC6515] MUST be applied when a PTA is carried in a Leaf A-D route. It explains how to tell whether the Tunnel Identifier field carries an IPv4 or an IPv6 address. 🫶

If neither of the above conditions holds, then the Tunnel Identifier field has no significance and MUST be ignored upon reception. 💅

6. A Note on IR P-Tunnels and Discarding Packets from the Wrong PE 🕵️‍♀️

Section 9.1.1 of [RFC6513] describes a procedure called "Discarding Packets from the Wrong PE". When an egress PE receives a multicast data packet, this procedure requires it to work out the packet's ingress PE.

In this document, we assume that when a packet reaches an egress PE via an IR P-tunnel, the egress PE will infer the identity of the packet's ingress PE by looking at the packet's P-tunnel label 🎀

Section 7 sets some constraints on how the P-tunnel label gets allocated for a given P-tunnel. Generally, if those constraints are followed, an egress PE can work out the packet's ingress PE from the P-tunnel label, and can therefore apply the procedures of Section 9.1.1 of [RFC6513]. This method works exactly the same whether the unicast tunnels are IP tunnels or MPLS LSPs. ✨

However, if the egress PE joined a particular IR P-tunnel using the procedures of Section 4.1.2, then when that egress PE receives a packet through the P-tunnel, it won't be able to infer the packet's ingress PE from the P-tunnel label, so it won't be able to apply the procedures of Section 9.1.1 of [RFC6513]. 😭

You might think that if an IR P-tunnel uses IP unicast tunnels rather than MPLS LSPs, an egress PE could just check the IP source address field of the encapsulating IP header to find the ingress PE. But there are a few reasons why that's not the move 🙅‍♀️

  • When segmented P-tunnels are being used, the IP source address field of the encapsulating IP header might not contain the address of the ingress PE.
  • Even if the IP source address field of the encapsulating IP header does identify the ingress PE, there's no guarantee that this IP source address is the same as the IP address the ingress PE uses for the MVPN signaling procedures.
  • To apply the procedures of Section 9.1.1 of [RFC6513] when extranet functionality [RFC7900] is supported, it's necessary to infer a packet's ingress VRF (Virtual Routing and Forwarding table), not just its ingress PE. This can be inferred from the P-tunnel label (assuming the label is allocated following the procedures of Section 7), but it can't be inferred from the IP source address of the encapsulating IP header. 💜

So we assume in this document that if the procedures of Section 9.1.1 of [RFC6513] are to be applied to packets traveling through IR P-tunnels, those procedures will be based on the P-tunnel label, even when the IR P-tunnel is using IP unicast tunnels. 🌸

This means that if an egress PE joined a particular IR P-tunnel using the procedures of Section 4.1.2, duplicate prevention on that IR P-tunnel requires the use of either Single Forwarder Selection (Section 9.1.2 of [RFC6513]) or native PIM procedures (Section 9.1.3 of [RFC6513]). 🔥

7. The PTA's MPLS Label Field 🏷️

When the Tunnel Type field of a PTA is set to "IR", the MPLS Label field isn't always significant. It only matters under the following conditions:

  1. Either the PTA is being carried in a Leaf A-D route, or
  2. the Leaf Information Required flag of the PTA is NOT set.

Note that the Leaf Information Required flag of the PTA is always set when a PTA specifying an IR P-tunnel is carried in an S-PMSI A-D route or in an Inter-AS I-PMSI A-D route. So the MPLS Label field of the PTA is never significant when the PTA is carried by one of these route types 💅 The MPLS Label field is only significant when the PTA appears either in a Leaf A-D route or in an Intra-AS I-PMSI A-D route that does not have the Leaf Information Required bit set. In these cases, the MPLS label is the label that the originator of the route is assigning to the IR P-tunnel(s) identified by the route's NLRI. (That is, the MPLS label assigned in the PTA is what we've been calling the "P-tunnel label".) 🦋

In those cases where the MPLS Label field is not significant, it SHOULD be set to zero upon transmission and MUST be ignored upon reception. 🫶

7.1. Leaf A-D Route Originated by an Egress PE ✨

okay so, bestie, remember how a Leaf A-D route's "route key" is the P-tunnel identifier when it's being used to join an IR P-tunnel? 💖 we're gonna build on that. this part is giving main character energy 💅

We now define the notion of the "root of an IR P-tunnel". 🌸

  • If the identifier of an IR P-tunnel is of the form of an S-PMSI NLRI, the "root" of the IR P-tunnel is the router identified in the Originating Router's IP Address field of that NLRI. 🎀
  • If the identifier of an IR P-tunnel is of the form specified in Section 6.2.2 of [RFC7524] ("Leaf A-D Route for Global Table Multicast"), the "root" of the IR P-tunnel is the router identified in the Ingress PE's IP Address field of that NLRI. 🦋
  • If the identifier of an IR P-tunnel is of the form of an Intra-AS I-PMSI NLRI, the "root" of the IR P-tunnel is the router identified in the Originating Router's IP Address field of that NLRI. 🧚
  • If the identifier of an IR P-tunnel is of the form of an Inter-AS I-PMSI NLRI, the "root" of the IR P-tunnel is same as the identifier of the IR P-tunnel, i.e., the combination of a Route Distinguisher (RD) and an AS. 👑

Note that if an IR P-tunnel is segmented, the root of the IR P-tunnel, by this definition, is actually the root of the entire P-tunnel, not the root of the local segment. In this case, there may be segments upstream that are not IR P-tunnels themselves. However, the egress PE is aware only of the final segment of the P-tunnel, and hence considers the P-tunnel to be an IR P-tunnel. 🫶

In order to apply the procedures of Section 9.1.1 of RFC 6513 ("Discarding Packets from Wrong PE"), the following condition MUST be met by the MPLS label allocation policy:

Suppose an egress PE originates two Leaf A-D routes, each with a different route key in its NLRI, and each with a PTA specifying a Tunnel Type field of "IR". Thus, each of the Leaf A-D routes identifies a different IR P-tunnel. Suppose further that each of those IR P-tunnels has a different root. Then, the egress PE MUST NOT specify the same MPLS label in both PMSI Tunnel attributes. 💀

That is, to apply the duplicate prevention procedures (in "Discarding Packets from Wrong PE", Section 9.1.1 of [RFC6513]), the same MPLS label MUST NOT be assigned to two IR P-tunnels that have different roots. 🙈

If segmented P-tunnels are in use, the above rule is necessary but not sufficient to prevent a PE from forwarding duplicate data to the CEs. For various reasons, a given egress PE or egress ABR or egress ASBR may decide to change its parent node, on a given segmented P-tunnel, from one router to another. It does this by changing the RT of the Leaf A-D route that it originated in order to join that P-tunnel. Once the RT is changed, there may be a period of time during which the old parent node and the new parent node are both sending data of the same multicast flow. To ensure that the egress node not forward duplicate data, whenever the egress node changes the RT that it attaches to a Leaf A-D route, it MUST also change the "MPLS Label" specified in the Leaf A-D route's PTA. This allows the egress router to distinguish between packets arriving on a given P-tunnel from the old parent and packets arriving on that same P-tunnel from the new parent. At any given time, a router MUST consider itself to have only a single parent node on a given P-tunnel and MUST discard traffic that arrives on that P-tunnel from a different parent node. 😭

If extranet functionality [RFC7900] is not implemented in a particular egress PE, or if an egress PE is provisioned with the knowledge that extranet functionality is not needed, the PE may adopt the policy of assigning a label that is unique for the ordered triple <root, parent node, egress VRF>. This will enable the egress PE to apply the duplicate prevention procedures discussed above and to determine the VRF to which an arriving packet must be directed. ✨

However, this policy is not sufficient to support the "Do Not Deliver Packets from the Wrong P-tunnel" procedures that are specified in Section 2.3.1 of [RFC7900]. To support those procedures, the labels specified in the PTA of Leaf A-D routes originated by a given egress PE MUST be unique for the ordered triple <root, root RD, parent node>, where the "root RD" is taken from the RD field of the IR P-tunnel identifier. (All forms of IR P-tunnel identifier contain an embedded RD field.) This policy is also sufficient for supporting non-extranet cases, but, in some cases, may result in the use of more labels than the policy of the preceding paragraph. 🌈

7.2. Leaf A-D Route Originated by an Intermediate Node 🦋

okay, so when a P-tunnel is segmented, there are going to be "intermediate nodes", i.e., nodes that have a parent AND also have children on the P-tunnel. 💅 Each intermediate node is a leaf node of an "upstream segment" and a root node of one or more "downstream segments". The intermediate node needs to set up its forwarding state so that data it receives on the upstream segment gets transmitted on the proper downstream segments. 🎀

If the upstream segment is instantiated by IR, the intermediate node will need to originate a Leaf A-D route to join that segment, and will need to allocate a downstream-assigned MPLS label to advertise in the MPLS Label field of the Leaf A-D route's PTA. Section 7.1 specifies constraints on the label allocation policy for egress PEs; this section specifies constraints on the label allocation policy for intermediate nodes. 🧚

Suppose intermediate node N originates two Leaf A-D routes, one whose route key is K1, and one whose route key is K2, where K1 != K2. The respective PTAs of these Leaf A-D routes MUST specify distinct non-zero MPLS labels, UNLESS the following conditions all hold:

  1. N's parent node for P-tunnel K1 is the same as N's parent node for P-tunnel K2.
  2. N's forwarding state is such that any packet it receives from P-tunnel K1 is forwarded to the exact same set of downstream neighbors as any packet it receives from P-tunnel K2.
  3. For each downstream neighbor D to which N sends the packets it receives from P-tunnels K1 and K2, N's forwarding state is such that it applies the exact same encapsulation to packets it forwards from either tunnel to D. (For example, if N uses MPLS to forward the packets to D, it pushes the exact same set of labels on packets from P-tunnel K1 as it pushes on packets from P-tunnel K2.) 🫶

Of course, N MAY always specify distinct non-zero labels in each of the Leaf A-D routes that it originates. 🌸

Note that the rules of this section apply whenever the upstream P-tunnel segment is an IR P-tunnel. These rules hold whether or not some or all of the downstream segments are other types of P-tunnels. 👑

If the P-tunnels from N to a particular downstream neighbor D are IR P-tunnels, then condition 3 above will hold with respect to D only if the following conditions all hold as well:

  • N has received and installed a Leaf A-D route from D, whose route key is K1, and which carries an IP-address-specific RT identifying N,
  • N has received and installed a Leaf A-D route from D, whose route key is K2, and which carries an IP-address-specific RT identifying N,
  • Those two Leaf A-D routes specify the same MPLS label in their respective PTAs. 🍓

7.3. Intra-AS I-PMSI A-D Route ⭐

When a router joins a set of IR P-tunnels using the procedures of Section 4.1.2 of this document, the procedures of Section 9.1.1 of [RFC6513] cannot be applied, no matter what the label allocation policy is. In this case, the ingress PE is the same as the UMH, but it is not possible to assign a label uniquely to a particular ingress PE or UMH. However, the label in the MPLS Label field of the PTA MUST NOT appear in the MPLS Label field of the PTA carried by any other route originated by the same router. 🥺

8. How a Child Node Prunes Itself from an IR P-Tunnel 🦋

okay so if a particular IR P-tunnel was joined via the procedures of Section 4.1.2, a router can prune itself from the P-tunnel by withdrawing the Intra-AS I-PMSI A-D route it used to join the P-tunnel. This is not usually done unless the router is removing itself entirely from a particular MVPN. 🫠

The procedures in the remainder of this section apply when a router joined a particular IR P-tunnel by originating a Leaf A-D route (as described in Sections 4.1.1 or 4.2). ✨

If a router no longer has a need to receive any multicast data from a given IR P-tunnel, it MAY prune itself from the P-tunnel by withdrawing the Leaf A-D route it used to join the tunnel. This is done, e.g., if the router no longer needs any of the flows traveling over the P-tunnel, or if all the flows the router does need are being received over other P-tunnels. 💖

A router that is attached to a particular IR P-tunnel via a particular parent node may determine that it needs to stay joined to that IR P-tunnel but via a different parent node. This can happen, for example, if there is a change in the Next Hop or the P2MP Segmented Next-Hop Extended Community of the S-PMSI A-D route in which that P-tunnel was advertised. In this case, the router changes the Route Target of the Leaf A-D route it used to join the IR P-tunnel, so that the Route Target now identifies the new parent node. 🔥

A parent node MUST notice when a child node has been pruned from a particular tree, as this will affect the parent node's multicast data state. Note that the pruning of a child node may appear to the parent node as the explicit withdrawal of a Leaf A-D route, or it may appear as a change in the Route Target of a Leaf A-D route. If the Route Target of a particular Leaf A-D route previously identified a particular parent node, but changes so that it no longer does so, the effect on the multicast state of the parent node is the same as if the Leaf A-D route had been explicitly withdrawn. 👀

9. Parent Node Actions upon Receiving Leaf A-D Route 💅

These actions are detailed in [RFC6514] and [RFC7524]. Two points of clarification are made:

  • If a router R1 receives and installs a Leaf A-D route originated by router R2, R1's multicast state is affected only if the Leaf A-D route carries an "IP-address-specific RT" (or "IPv6-address-specific RT") whose Global Administrator field identifies R1.

(This is as specified in [RFC6514] and [RFC7524].) If a Leaf A-D route's RT does not identify R1, but then changes so that it does identify R1, R1 must take the same actions it would take if the Leaf A-D route were newly received.

  • It is possible that router R1 will receive and install a Leaf A-D route originated by router R2, where:
    • the route's RT identifies R1,
    • the route's NLRI contains a route key whose first octet indicates that it is identifying a P-tunnel advertised in an S-PMSI A-D route,
    • R1 has neither originated nor installed any such S-PMSI A-D route.

If at some later time, R1 installs the corresponding S-PMSI A-D route, and the Leaf A-D route is still installed, and the Leaf A-D route's RT still identifies R1, then R1 MUST follow the same procedures it would have followed if the S-PMSI A-D route had been installed before the Leaf A-D route was installed. Implementers must not assume that events occur in the "usual" or "expected" order. 🌈

10. Use of Timers When Switching UMH ✨

okay so picture a child node that has already joined a particular IR P-tunnel through a particular UMH 🦋. To do that, it originated a Leaf A-D route with an RT that identifies the UMH. Now say the child node decides (for whatever reason 💅) that it needs to change its UMH for that P-tunnel. It does this by:

  • modifying the RT of the Leaf A-D route, so the RT now identifies the new parent instead of the old one, and by
  • modifying the PTA of the Leaf A-D route, changing the MPLS Label field as discussed in Section 7.

ngl this is giving "switch your ride mid-drive" energy 🚗💨. Note that, following the procedures of [RFC6514] and Section 4 of this document, the NLRI of the Leaf A-D route is not modified. Only the RT and the PTA change 🎀.

It is desirable for this "switch of UMH" to be done with a "make before break" technique 🌸. That means the old UMH keeps sending packets of the given P-tunnel to the child until the new UMH has had a chance to start sending them too. The tricky part is that the control-plane operation (modifying the RT and PTA of the Leaf A-D route) doesn't let the child node join the IR P-tunnel via the new UMH first and then prune itself from the old one. Nope 🙈. It's one single control-plane operation that does both things at once.

So, bestie, the old UMH MUST continue transmitting to the child node for a period of time after it sees the child's Leaf A-D route being withdrawn (or its RT changing to identify a different UMH). This timer, called the "parent-continues" timer, SHOULD have a default value of 60 seconds and SHOULD be configurable ⏰✨.

By the procedures of Section 7, the child node will have advertised a different label for the IR P-tunnel to the new UMH than it had advertised to the old UMH. That's how it can tell the packets from the new UMH apart from the packets from the old UMH 🧚. At any given time, the child node accepts packets of that IR P-tunnel from only one parent node and discards the ones it gets from the other. To get that "make before break" vibe, the child node has to keep accepting packets from the old UMH for a while. After that period ends, it discards any packets from the given IR P-tunnel that come from the old UMH and only accepts them from the new UMH 💅.

Once the child node modifies the RT of its Leaf A-D route, it MUST run a timer, called the "switch-parents-delay" timer 💜. This timer SHOULD default to 30 seconds and SHOULD be configurable. The child node MUST continue to accept packets of the given IR P-tunnel from the old UMH until this timer expires. Plot twist though 😭: once the child node receives a packet of the given IR P-tunnel from the new UMH, it MAY consider the "switch-parents-delay" timer to have expired.

The "parent-continues" timer MUST be longer than the "switch-parents-delay" timer 🌈. And periodt, both timers are specific to a given IR P-tunnel. Each P-tunnel gets its own set of timers 🍓.

11. Security Considerations 🔐

Okay, security time, and it's giving serious 🚨. No security considerations are raised by this document beyond those already discussed in [RFC6513] and [RFC6514]. So go read those two for the full story 📚🫶.

12. References ✨

12.1. Normative References

12.2. Informative References

Acknowledgments 💖

The authors wish to thank Yakov Rekhter for his contributions to this work 🫶. We also wish to thank Huajin Jeng and Samir Saad for their contributions, and to thank Thomas Morin for pointing out (both before and after the document was written) some of the issues that needed further elaboration. We also thank Lucy Yong for her review and comments 🌷.

Section 7.1 discusses the importance of having an MPLS label allocation policy that, when ingress replication is used, allows an egress PE to infer the identity of a received packet's ingress PE. This issue was first raised in earlier work by Xu Xiaohu 🧠✨.

Authors' Addresses 🦋

Eric C. Rosen (editor)
Juniper Networks, Inc.
10 Technology Park Drive
Westford, Massachusetts  01886
United States of America

Email: erosen@juniper.net


Karthik Subramanian
Sproute Networks

Email: karthik@sproute.com


Zhaohui Zhang
Juniper Networks, Inc.
10 Technology Park Drive
Westford, Massachusetts  01886
United States of America

Email: zzhang@juniper.net
📦 where this page comes from