Explicit Tracking with Wildcard Routes in Multicast VPN
updates
- rfc-6514 — BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs
- rfc-6625 — Wildcards in Multicast VPN Auto-Discovery Routes
- rfc-7524 — Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)
- rfc-7582 — Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels
- rfc-7900 — Extranet Multicast in BGP/IP MPLS VPNs
Extracted elements (26)
Cross-domain explicit tracking (through segmented tunnels) can only be done when the match for tracking differs from the match for reception, because it relies on S-PMSI A-D routes that do not specify tunnel information. The LIR-pF mechanism enables the ingress PE to see egress PEs across segmentation boundaries for management purposes.
The separation of 'match for tracking' from 'match for reception' is introduced to handle the case where an ingress node uses a wildcard S-PMSI A-D route with 'no tunnel information present' and LIR set purely for explicit tracking of individual flows, while a separate wildcard route with a real tunnel handles actual data forwarding. Without this distinction, tracking routes without tunnel info would be ignored.
If egress nodes that do not support LIR-pF receive a wildcard S-PMSI A-D route with LIR-pF set, they respond with Leaf A-D routes without LIR-pF (per RFC 6514 LIR behavior). The ingress node can detect non-supporting egress nodes this way; the software MUST detect this and MUST have a way to alert the operator of misconfiguration.
Leaf A-D routes constructed per Section 5.2 of this document can always be distinguished from those of RFC 7524 Section 6.2.2 because this document's routes never set RD to 0 or -1, while RFC 7524's global table multicast Leaf A-D routes always use RD of 0 or -1.
An ingress node SHOULD NOT originate a (C-S,C-G) S-PMSI A-D route whose PTA specifies 'no tunnel information present' if it already originates a wildcard S-PMSI A-D route with LIR-pF set that covers that flow; such a route would not provide any additional functionality.
An ingress node that receives a Leaf A-D route with LIR-pF set in response to an S-PMSI A-D route with LIR-pF clear MUST log this by default; implementations SHOULD provide a knob to disable this logging to avoid noise from false positives.
For Ingress Replication tunnel type, the Leaf A-D route's PTA MAY specify Ingress Replication with a non-zero MPLS label (used by ingress PE for that specific flow), or MAY specify zero label or 'no tunnel information present', in which case the label from the match-for-reception Leaf A-D route is used.
For non-Ingress-Replication 6514-tunnel-types, the PTA attached to the Leaf A-D route MUST specify a tunnel type of 'no tunnel information present'.
If a Leaf A-D route is originated in response to a match for tracking whose PTA specifies 'no tunnel information present', the Leaf A-D route MUST carry a PTA that specifies 'no tunnel information present' with the LIR-pF flag set.
If a received Leaf A-D route's PTA specifies Ingress Replication with a non-zero MPLS label, the ingress node MUST use that label when sending packets of the identified flow to the egress PE.
If multiple Leaf A-D routes are originated in response to a single S-PMSI A-D route and that S-PMSI A-D route is withdrawn, all corresponding Leaf A-D routes MUST also be withdrawn. A Leaf A-D route must also be withdrawn if the egress node changes its UMH for the tracked flow or no longer needs to receive it.
If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the originator of that route MUST also set the LIR flag. If a received wildcard S-PMSI A-D route has LIR-pF set but LIR not set, the receiver MUST log the improper flag state and then process the route as if both flags were set.
Support for the LIR-pF flag is OPTIONAL, and this flag SHOULD NOT be set in a route's PTA unless it is known that the flag is supported by all PE routers that are to receive that route.
The LIR-pF-based per-flow tracking procedure (Procedure 2 of Section 4) SHOULD NOT be used unless it is known that all egress nodes support the LIR-pF flag, because unsupporting egress nodes may experience blackholed flows.
The LIR-pF flag is only specified for use with 6514-tunnel-types. For non-6514-tunnel-types, the originator SHOULD NOT set LIR-pF, and the receiver SHOULD treat LIR-pF as if not set, unless a separate specification covers that tunnel type's use with LIR-pF.
When an egress ABR/ASBR receives an installed S-PMSI A-D route whose PTA specifies 'no tunnel information present', it MUST pass the PTA along unchanged when forwarding the route, and the LIR and LIR-pF flags MUST be passed along unchanged.
When an egress node supports LIR-pF and has a flow for which the match for tracking has LIR-pF set, it MUST originate a Leaf A-D route whose NLRI identifies that specific flow. A single wildcard S-PMSI A-D route may trigger multiple Leaf A-D routes, one per matched flow.
When an ingress node receives a Leaf A-D route whose Route Key field does not match any current I-PMSI or S-PMSI A-D route it originated, but a wildcard S-PMSI A-D route originated by it is a valid match per Section 5.2 procedures, the Leaf A-D route MUST be processed by the ingress node.
When finding a 'match for reception', S-PMSI A-D routes that have no PTA or whose PTA specifies 'no tunnel information present' MUST be ignored, per modified rules updating RFC 6625.
When the egress node's match for tracking differs from its match for reception (the tracking route has 'no tunnel information present' with LIR or LIR-pF set), the egress node MUST respond separately to both the match for tracking and the match for reception.
For segmented P-tunnels, an egress ABR/ASBR propagates received Leaf A-D routes after changing the IP-address-specific Route Target (RT) Extended Community: the Global Administrator field is set to the IP address from the S-PMSI A-D route's Next-Hop field or its Segmented P2MP Next-Hop Extended Community (the latter takes precedence if present).
The 'Leaf Information Required per Flow' (LIR-pF) flag is a new flag defined in the Flags field of the PMSI Tunnel attribute (PTA). It may be set in the PTA of a (C-*,C-*), (C-*,C-G), or (C-S,C-*) S-PMSI A-D route, or in a Leaf A-D route, to enable per-flow explicit tracking via a single wildcard route.
The 'match for tracking' is a new concept distinct from 'match for reception'. It is determined by applying the RFC 6625 match-for-reception rules but NOT ignoring S-PMSI A-D routes whose PTA specifies 'no tunnel information present' if those routes have the LIR or LIR-pF flag set.
IANA has added an entry to the 'P-Multicast Service Interface (PMSI) Tunnel Attribute Flags' registry (under BGP Parameters, defined in RFC 7902): Value 2, Name 'Leaf Information Required per-Flow (LIR-pF)', Reference RFC 8534.
Setting the LIR-pF flag in a single wildcard S-PMSI A-D route can elicit a large number of Leaf A-D routes, causing significant control plane overhead. If set erroneously or maliciously, the attack is difficult to mitigate without disrupting multicast traffic, so reliance on general control-plane security mechanisms is recommended over flow-specific countermeasures.
The NLRI of a Leaf A-D route originated in response to LIR-pF contains: RD (8 octets), Multicast Source Length (1 octet), Multicast Source (variable), Multicast Group Length (1 octet), Multicast Group (variable), and Ingress PE's IP Address (variable). For (C-*,C-G) flows, Multicast Source is omitted and Source Length is set to 0.