draft-ietf-bess-bgp-multicast-00.txt   draft-ietf-bess-bgp-multicast-01.txt 
BESS Z. Zhang BESS Z. Zhang
Internet-Draft L. Giuliano Internet-Draft L. Giuliano
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: July 27, 2020 K. Patel Expires: November 14, 2020 K. Patel
Arrcus Arrcus
I. Wijnands I. Wijnands
M. Mishra M. Mishra
Cisco Systems Cisco Systems
A. Gulko A. Gulko
Refinitiv Refinitiv
January 24, 2020 May 13, 2020
BGP Based Multicast BGP Based Multicast
draft-ietf-bess-bgp-multicast-00 draft-ietf-bess-bgp-multicast-01
Abstract Abstract
This document specifies a BGP address family and related procedures This document specifies a BGP address family and related procedures
that allow BGP to be used for setting up multicast distribution that allow BGP to be used for setting up multicast distribution
trees. This document also specifies procedures that enable BGP to be trees. This document also specifies procedures that enable BGP to be
used for multicast source discovery, and for showing interest in used for multicast source discovery, and for showing interest in
receiving particular multicast flows. Taken together, these receiving particular multicast flows. Taken together, these
procedures allow BGP to be used as a replacement for other multicast procedures allow BGP to be used as a replacement for other multicast
routing protocols, such as PIM or mLDP. The BGP procedures specified routing protocols, such as PIM or mLDP. The BGP procedures specified
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 27, 2020. This Internet-Draft will expire on November 14, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1. Native/unlabeled Multicast . . . . . . . . . . . . . 3 1.1.1. Native/unlabeled Multicast . . . . . . . . . . . . . 3
1.1.2. Labeled Multicast . . . . . . . . . . . . . . . . . . 4 1.1.2. Labeled Multicast . . . . . . . . . . . . . . . . . . 4
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. (x,g) Multicast . . . . . . . . . . . . . . . . . . . 5 1.2.1. (x,g) Multicast . . . . . . . . . . . . . . . . . . . 5
1.2.1.1. Source Discovery for ASM . . . . . . . . . . . . 5 1.2.1.1. Source Discovery for ASM . . . . . . . . . . . . 5
1.2.1.2. ASM Shared-tree-only Mode . . . . . . . . . . . . 6 1.2.1.2. ASM Shared-tree-only Mode . . . . . . . . . . . . 6
1.2.1.3. Integration with BGP-MVPN . . . . . . . . . . . . 7 1.2.1.3. Integration with BGP-MVPN . . . . . . . . . . . . 7
1.2.2. BGP Inband Signaling for mLDP Tunnel . . . . . . . . 7 1.2.2. BGP Inband Signaling for mLDP Tunnel . . . . . . . . 7
1.2.3. BGP Sessions . . . . . . . . . . . . . . . . . . . . 7 1.2.3. BGP Sessions . . . . . . . . . . . . . . . . . . . . 7
1.2.4. LAN and Parallel Links . . . . . . . . . . . . . . . 8 1.2.4. LAN and Parallel Links . . . . . . . . . . . . . . . 8
1.2.5. Transition . . . . . . . . . . . . . . . . . . . . . 9 1.2.5. Transition . . . . . . . . . . . . . . . . . . . . . 9
2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 10 1.2.6. Inter-region Multicast . . . . . . . . . . . . . . . 9
2.1. BGP NLRIs and Attributes . . . . . . . . . . . . . . . . 10 1.2.6.1. Same BGP Signaling Inline across a Region . . . . 10
2.1.1. S-PMSI A-D Route . . . . . . . . . . . . . . . . . . 11 1.2.6.2. Different Signaling Inline across a Region . . . 10
2.1.2. Leaf A-D Route . . . . . . . . . . . . . . . . . . . 11 1.2.6.3. Overlay Signaling Over a Region . . . . . . . . . 10
2.1.3. Source Active A-D Route . . . . . . . . . . . . . . . 12 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.4. S-PMSI A-D Route for C-multicast mLDP . . . . . . . . 13 2.1. BGP NLRIs and Attributes . . . . . . . . . . . . . . . . 11
2.1.5. Session Address Extended Community . . . . . . . . . 13 2.1.1. S-PMSI A-D Route . . . . . . . . . . . . . . . . . . 12
2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.2. Leaf A-D Route . . . . . . . . . . . . . . . . . . . 13
2.2.1. Source Discovery for ASM . . . . . . . . . . . . . . 14 2.1.3. Source Active A-D Route . . . . . . . . . . . . . . . 14
2.2.2. Originating Tree Join Routes . . . . . . . . . . . . 14 2.1.4. S-PMSI A-D Route for C-multicast mLDP . . . . . . . . 14
2.2.2.1. (x,g) Multicast Tree . . . . . . . . . . . . . . 14 2.1.5. Session Address Extended Community . . . . . . . . . 14
2.2.2.2. BGP Inband Signaling for mLDP Tunnel . . . . . . 15 2.1.6. Multicast RPF Address Extended Community . . . . . . 15
2.2.3. Receiving Tree Join Routes . . . . . . . . . . . . . 15 2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4. Withdrawl of Tree Join Routes . . . . . . . . . . . . 16 2.2.1. Source Discovery for ASM . . . . . . . . . . . . . . 15
2.2.5. LAN procedures for (x,g) Unidirectional Tree . . . . 16 2.2.2. Originating Tree Join Routes . . . . . . . . . . . . 15
2.2.5.1. Originating S-PMSI A-D Routes . . . . . . . . . . 16 2.2.2.1. (x,g) Multicast Tree . . . . . . . . . . . . . . 15
2.2.5.2. Receiving S-PMSI A-D Routes . . . . . . . . . . . 17 2.2.2.2. BGP Inband Signaling for mLDP Tunnel . . . . . . 16
2.2.3. Receiving Tree Join Routes . . . . . . . . . . . . . 17
2.2.4. Withdrawl of Tree Join Routes . . . . . . . . . . . . 17
2.2.5. LAN procedures for (x,g) Unidirectional Tree . . . . 17
2.2.5.1. Originating S-PMSI A-D Routes . . . . . . . . . . 17
2.2.5.2. Receiving S-PMSI A-D Routes . . . . . . . . . . . 18
2.2.6. Distributing Label for Upstream Traffic for 2.2.6. Distributing Label for Upstream Traffic for
Bidirectional Tree/Tunnel . . . . . . . . . . . . . . 17 Bidirectional Tree/Tunnel . . . . . . . . . . . . . . 19
3. Security Considerations . . . . . . . . . . . . . . . . . . . 18 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Normative References . . . . . . . . . . . . . . . . . . 18 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Informative References . . . . . . . . . . . . . . . . . 19 6.1. Normative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
1.1. Motivation 1.1. Motivation
This section provides some motivation for BGP signaling for native This section provides some motivation for BGP signaling for native
and labeled multicast. One target deployment would be a Data Center and labeled multicast. One target deployment would be a Data Center
that requires multicast but uses BGP as its only routing protocol that requires multicast but uses BGP as its only routing protocol
[RFC7938]. In such a deployment, it would be desirable to support [RFC7938]. In such a deployment, it would be desirable to support
multicast by extending the deployed routing protocol, without multicast by extending the deployed routing protocol, without
skipping to change at page 5, line 20 skipping to change at page 5, line 23
The same RPF procedures as in PIM are used for each router to The same RPF procedures as in PIM are used for each router to
determine the RPF neighbor for a particular source or RPA (in case of determine the RPF neighbor for a particular source or RPA (in case of
Bidirectional Tree). Except in the Bidirectional Tree case and a Bidirectional Tree). Except in the Bidirectional Tree case and a
special case described in Section 1.2.1.2, no (*,G) join is used - special case described in Section 1.2.1.2, no (*,G) join is used -
LHR routers discover the sources for ASM and then join towards the LHR routers discover the sources for ASM and then join towards the
sources directly. Data driven mechanisms like PIM Assert is replaced sources directly. Data driven mechanisms like PIM Assert is replaced
by control driven mechanisms (Section 1.2.4). by control driven mechanisms (Section 1.2.4).
The joins are carried in BGP Updates with MCAST-TREE SAFI and S-PMSI/ The joins are carried in BGP Updates with MCAST-TREE SAFI and S-PMSI/
Leaf A-D routes defined in this document. The updates are targeted Leaf A-D routes defined in this document. The updates are targeted
at the upstream neighbor by use of Route Targets. [Note - earlier at the upstream neighbor by use of Route Targets. There are three
version of this draft uses C-multicast route to send joins. We're benefits of using S-PMSI/Leaf routes for this purpose: a) when the
now switching to S-PMSI/Leaf routes for three reasons. a) when the
routes go through RRs, we have to distinguish different routes based routes go through RRs, we have to distinguish different routes based
on upstream router and downstream router. This leads to Leaf routes. on upstream router and downstream router. This leads to Leaf routes.
b) for labeled bidirectional trees, we need to signal "upstream fec". b) for labeled bidirectional trees, we need to signal "upstream fec".
S-PMSI suits this very well. c) we may want to allow the option of S-PMSI suits this very well. c) we may want to allow the option of
setting up trees from the roots instead of from the leaves. S-PMSI setting up trees or parts of a tree from the root/upstream towards
suits that very well.] leaves/downstream and S-PMSI suits that very well.
If the BGP updates carry labels (via Tunnel Encapsulation Attribute If the BGP updates carry labels (via Tunnel Encapsulation Attribute
[I-D.ietf-idr-tunnel-encaps]), then (s,g) multicast traffic can use [I-D.ietf-idr-tunnel-encaps]), then (s,g) multicast traffic can use
the labels. This is very similar to mLDP Inband Signaling [RFC6826], the labels. This is very similar to mLDP Inband Signaling [RFC6826],
except that there are no corresponding "mLDP tunnels" for the PIM except that there are no corresponding "mLDP tunnels" for the PIM
trees. Similar to mLDP, labeled traffic on transit LANs are point to trees. Similar to mLDP, labeled traffic on transit LANs are point to
point. Of course, traffic sent to receivers on a LAN by a LHR is point. Of course, traffic sent to receivers on a LAN by a LHR is
native multicast. native multicast.
For labeled bidirectional (*,g) trees, downstream traffic (away from For labeled bidirectional (*,g) trees, downstream traffic (away from
skipping to change at page 9, line 20 skipping to change at page 9, line 20
A network currently running PIM can be incrementally transitioned to A network currently running PIM can be incrementally transitioned to
BGP based multicast. At any time, a router supporting BGP based BGP based multicast. At any time, a router supporting BGP based
multicast can use PIM with some neighbors (upstream or downstream) multicast can use PIM with some neighbors (upstream or downstream)
and BGP with some other neighbors. PIM and BGP MUST not be used and BGP with some other neighbors. PIM and BGP MUST not be used
simultaneously between two neighbors for multicast purpose, and simultaneously between two neighbors for multicast purpose, and
routers connected to the same LAN MUST be transitioned during the routers connected to the same LAN MUST be transitioned during the
same maintenance window. same maintenance window.
In case of PIM-SSM, any router can be transitioned at any time In case of PIM-SSM, any router can be transitioned at any time
(except on a LAN all routers must be transitioned together). It may (except on a LAN). It may receive source tree joins from a mixed set
receive source tree joins from a mixed set of BGP and PIM downstream of BGP and PIM downstream neighbors and send source tree joins to its
neighbors and send source tree joins to its upstream neighbor using upstream neighbor using either PIM or BGP signaling.
either PIM or BGP signaling.
In case of PIM-ASM, the RPs are first upgraded to support BGP based In case of PIM-ASM, the RPs are first upgraded to support BGP based
multicast. They learn sources either via PIM procedures from PIM multicast. They learn sources either via PIM procedures from PIM
FHRs, or via Source Active A-D routes from BGP FHRs. In the former FHRs, or via Source Active A-D routes from BGP FHRs. In the former
case, the RPs can originate proxy Source Active A-D routes. There case, the RPs can originate proxy Source Active A-D routes. There
may be a mixed set of RPs/RRs - some capable of both traditional PIM may be a mixed set of RPs/RRs - some capable of both traditional PIM
RP functionalities while some only redistribute SA routes. RP functionalities while some only redistribute SA routes.
Then any routers can be transitioned incrementally. A transitioned Then any routers can be transitioned incrementally. A transitioned
LHR router will pull Source Active A-D routes from the RPs/RRs when LHR router will pull Source Active A-D routes from the RPs/RRs when
skipping to change at page 10, line 5 skipping to change at page 9, line 47
Similarly, a network currently running mLDP can be incrementally Similarly, a network currently running mLDP can be incrementally
transitioned to BGP signaling. Without the complication of ASM, any transitioned to BGP signaling. Without the complication of ASM, any
router can be transitioned at any time, even without the restriction router can be transitioned at any time, even without the restriction
of coordinated transition on a LAN. It may receive mixed mLDP label of coordinated transition on a LAN. It may receive mixed mLDP label
mapping or BGP updates from different downstream neighbors, and may mapping or BGP updates from different downstream neighbors, and may
exchange either mLDP label mapping or BGP updates with its upstream exchange either mLDP label mapping or BGP updates with its upstream
neighbors, depending on if the neighbor is using BGP based signaling neighbors, depending on if the neighbor is using BGP based signaling
or not. or not.
1.2.6. Inter-region Multicast
An end-to-end multicast tree or P2MP tunnel may span multiple
regions, where a region could be an IGP area (or even a sub-area) or
an Autonomous System (AS). There are several situations to consider.
1.2.6.1. Same BGP Signaling Inline across a Region
With inline signaling, the multicast tree/tunnel is signaled through
the region and internal routers in the region maintain corresponding
per-tree/tunnel state.
If all routers in the region have route towards the source/root of
the tree/tunnel then there is nothing different from the intra-region
case. On the other hand, if internal routers do not have route
towards the source/root, e.g. BGP-LS is used as in Seamless MPLS,
the internal routers need to do RPF towards an upstream Regional
Border Router (RBR). To signal the RBR information to an internal
upstream router, the Leaf A-D Route carries a new BGP Extended
Community referred to as Multicast RPF Address EC, similar to PIM RPF
Vector [RFC5496] and mLDP Recursive FEC [RFC6512].
1.2.6.2. Different Signaling Inline across a Region
Just like that part of a PIM multicast tree can be signaled as an
mLDP P2MP/MP2MP tunnel with mLDP Inband Signaling [RFC6826], BGP-
signaled (*/s, g) multicast tree can be signaled with mLDP Inband
Signaling or even with PIM across the region, and a BGP-signaled p2mp
tunnel can be signaled with mLDP across the region. A RBR will
stitch the upstream portion (e.g BGP-signaled) to downstream portion
(e.g mLDP-signaled).
Depending on whether internal routers have route towards the source/
root, PIM RPF Vector or mLDP Recursive FEC may be used.
1.2.6.3. Overlay Signaling Over a Region
With overlay signaling, a downstream RBR signals via BGP to its
upstream RBR over the region (whether via a RR or not) and the
internal routers do not maintain the state of the (overlay) tree/
tunnel. The upstream RBR tunnels packets to the downstream RBR, just
as in the intra-region case when two routers on the tree/tunnel are
not directly connected. For example, when BGP-LS is used as in
Seamless MPLS, a downstream RBR determines that the route towards the
source/root has a BGP Next Hop towards a BGP speaker capable of
multicast signaling via BGP as specified in this document, so it
signals to that BGP speaker (via a RR or not).
Suppose an upstream RBR receives the signaling for the same tree/
tunnel from several downstream RBRs. It could use Ingress
Replication to replicate packets directly to those downstream RBRs,
or it could use underlay P2MP tunnels instead.
In the latter case, the upstream RBR advertises an S-PMSI A-D route
with a Provider Tunnel Attribute (PTA) specifying the underlay
tunnel. This is very much like the "mLDP Over Targeted Sessions"
[RFC7060] or BGP-MVPN [RFC6514]. If the mapping between overlay
tree/tunnel and underlay tunnel is one-to-one, the MPLS Label field
in the PTA is set to 0 or otherwise set to a Domain-wide Common Block
(DCB) label [I-D.ietf-bess-mvpn-evpn-aggregation-label] or an
upstream-assigned label corresponding to the overlay tree/tunnel.
The underlay tunnel, whether P2P to individual downstream RBRs or
P2MP to the set of downstream RBRs, can be of any type including
Segment Routing (SR) [RFC8402] policies [I-D.ietf-spring-segment-
routing-policy] [I-D.voyer-pim-sr-p2mp-policy].
2. Specification 2. Specification
2.1. BGP NLRIs and Attributes 2.1. BGP NLRIs and Attributes
The BGP Multiprotocol Extensions [RFC4760] allow BGP to carry routes The BGP Multiprotocol Extensions [RFC4760] allow BGP to carry routes
from multiple different "AFI/SAFIs". This document defines a new from multiple different "AFI/SAFIs". This document defines a new
SAFI known as a MCAST-TREE SAFI with a value to be assigned by the SAFI known as a MCAST-TREE SAFI with a value to be assigned by the
IANA. This SAFI is used along with the AFI of IPv4 (1) or IPv6 (2). IANA. This SAFI is used along with the AFI of IPv4 (1) or IPv6 (2).
The MCAST-TREE NLRI defined below is carried in the BGP UPDATE The MCAST-TREE NLRI defined below is carried in the BGP UPDATE
messages [RFC4271] using the BGP multiprotocol extensions [RFC4760] messages [RFC4271] using the BGP multiprotocol extensions [RFC4760]
with a AFI of IPv4 (1) or IPv6 (2) assigned by IANA and a MCAST-TREE with a AFI of IPv4 (1) or IPv6 (2) assigned by IANA and a MCAST-TREE
SAFI with a value to be assigned by the IANA. SAFI with a value to be assigned by the IANA.
The Next hop field of MP_REACH_NLRI attribute SHALL be interpreted as The Next hop field of MP_REACH_NLRI attribute SHALL be interpreted as
an IPv4 adress whenever the length of the Next Hop address is 4 an IPv4 address whenever the length of the Next Hop address is 4
octets, and as an IPv6 address whenever the length of the Next Hop is octets, and as an IPv6 address whenever the length of the Next Hop is
address is 16 octets. address is 16 octets.
The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix
with a maximum length of 12 octers for IPv4 AFI and 36 octets for with a maximum length of 12 octets for IPv4 AFI and 36 octets for
IPv6 AFI. The following is the format of the MCAST-TREE NLRI: IPv6 AFI. The following is the format of the MCAST-TREE NLRI:
+-----------------------------------+ +-----------------------------------+
| Route Type (1 octet) | | Route Type (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Length (1 octet) | | Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Route Type specific (variable) | | Route Type specific (variable) |
+-----------------------------------+ +-----------------------------------+
skipping to change at page 12, line 8 skipping to change at page 13, line 17
2.1.2. Leaf A-D Route 2.1.2. Leaf A-D Route
Similar to the Leaf A-D route in [RFC6514], a MCAST-TREE Leaf A-D Similar to the Leaf A-D route in [RFC6514], a MCAST-TREE Leaf A-D
route's route key includes the corresponding S-PMSI NLRI, plus the route's route key includes the corresponding S-PMSI NLRI, plus the
Originating Router's IP Addr. The difference is that there is no RD. Originating Router's IP Addr. The difference is that there is no RD.
+-----------------------------------+ +-----------------------------------+
| S-PMSI NLRI | | S-PMSI NLRI |
+-----------------------------------+ +-----------------------------------+
| Originating Router's IP Addrress | | Originating Router's IP Address |
+-----------------------------------+ +-----------------------------------+
For example, the entire NLRI of a Leaf A-D route for (x,g) tree is as For example, the entire NLRI of a Leaf A-D route for (x,g) tree is as
following: following:
+- +-----------------------------------+ +- +-----------------------------------+
| | Route Type - 4 (Leaf A-D) | | | Route Type - 4 (Leaf A-D) |
| +-----------------------------------+ | +-----------------------------------+
| | Length (1 octet) | | | Length (1 octet) |
| +- +-----------------------------------+ --+ | +- +-----------------------------------+ --+
skipping to change at page 12, line 33 skipping to change at page 13, line 42
F | F | | Multicast Source Length (1 octet) | | M F | F | | Multicast Source Length (1 octet) | | M
| | +-----------------------------------+ | S | | +-----------------------------------+ | S
N | R | | Multicast Source (variable) | | I N | R | | Multicast Source (variable) | | I
L | O | +-----------------------------------+ | L | O | +-----------------------------------+ |
R | U | | Multicast Group Length (1 octet) | | N R | U | | Multicast Group Length (1 octet) | | N
I | T | +-----------------------------------+ | L I | T | +-----------------------------------+ | L
| E | | Multicast Group (variable) | | R | E | | Multicast Group (variable) | | R
| | +-----------------------------------+ | I | | +-----------------------------------+ | I
| K | | Upstream Router's IP Address | | | K | | Upstream Router's IP Address | |
| E | +-----------------------------------+ --+ | E | +-----------------------------------+ --+
| Y | | Originating Router's IP Addrress | | Y | | Originating Router's IP Address |
+- +- +-----------------------------------+ +- +- +-----------------------------------+
Even though the MCAST-TREE Leaf A-D route is unsolicited, unlike the Even though the MCAST-TREE Leaf A-D route is unsolicited, unlike the
Leaf A-D route for GTM in [RFC7524], it is encoded as if a Leaf A-D route for GTM in [RFC7524], it is encoded as if a
corresponding S-PMSI A-D route had been received. corresponding S-PMSI A-D route had been received.
When used for signaling mLDP tunnels, even though the Leaf A-D route When used for signaling mLDP tunnels, even though the Leaf A-D route
is unsolicited, unlike the "Route-type 0x44 Leaf A-D route for is unsolicited, unlike the "Route-type 0x44 Leaf A-D route for
C-multicast mLDP" as in [RFC7441], it is Route-type 4 and encoded as C-multicast mLDP" as in [RFC7441], it is Route-type 4 and encoded as
if a corresponding S-PMSI A-D route had been received. if a corresponding S-PMSI A-D route had been received.
skipping to change at page 13, line 31 skipping to change at page 14, line 38
The route is used to signal upstream FEC for an MP2MP mLDP tunnel. The route is used to signal upstream FEC for an MP2MP mLDP tunnel.
The route key include the mLDP FEC and the Upstream Router's IP The route key include the mLDP FEC and the Upstream Router's IP
Address field. The encoding is similar to the same route in Address field. The encoding is similar to the same route in
[RFC7441], though there is no RD. [RFC7441], though there is no RD.
2.1.5. Session Address Extended Community 2.1.5. Session Address Extended Community
For two BGP speakers to determine if they are directly connected, For two BGP speakers to determine if they are directly connected,
each will advertise their local interface addresses, with an Session each will advertise their local interface addresses, with an Session
Address Extended Community. This is an Address Specific EC, with the Address Extended Community. This is an IPv4/IPv6 Address Specific EC
Global Admin Field set to the local address used for its multihop with the Global Admin Field set to the local address used for its
sessions and the Local Admin Field set to the prefix length multihop sessions and the Local Admin Field set to the prefix length
corresponding to the interface's network mask. corresponding to the interface's network mask.
For example, if a router has two interfaces with address For example, if a router has two interfaces with address
10.10.10.1/24 and 10.12.0.1/16 respectively (notice the different 10.10.10.1/24 and 10.12.0.1/16 respectively (notice the different
network mask), and a loopback address 11.11.11.1/32 that is used for network mask), and a loopback address 11.11.11.1/32 that is used for
BGP sessions, then it will advertise prefix 10.10.10.1/32 with a BGP sessions, then it will advertise prefix 10.10.10.1/32 with a
Session Address EC 11.11.11.1:24 and 10.12.0.1/32 with a Session Session Address EC 11.11.11.1:24 and 10.12.0.1/32 with a Session
Address EC 11.11.11.1:16. If it also uses another loopback address Address EC 11.11.11.1:16. If it also uses another loopback address
11.11.11.11/32 for other BGP sessions, then the routes will 11.11.11.11/32 for other BGP sessions, then the routes will
additionally carry Session Address EC 11.11.11.11:24 and additionally carry Session Address EC 11.11.11.11:24 and
skipping to change at page 14, line 11 skipping to change at page 15, line 19
Only those interface addresses that will be used as resolved nexthops Only those interface addresses that will be used as resolved nexthops
in the RIB need to be advertised with the Session Address EC. For in the RIB need to be advertised with the Session Address EC. For
example, the RPF lookup may say that the resolved nexthop address is example, the RPF lookup may say that the resolved nexthop address is
A1, so the router needs to find out the corresponding BGP speaker A1, so the router needs to find out the corresponding BGP speaker
with address A1 through the (interface address, session address) with address A1 through the (interface address, session address)
mapping built according to the interface address NLRI with the mapping built according to the interface address NLRI with the
Session Address EC. For comparison with LDP, this is done via the Session Address EC. For comparison with LDP, this is done via the
(interface address, session address) mapping that is built by the LDP (interface address, session address) mapping that is built by the LDP
Address Messages. Address Messages.
2.1.6. Multicast RPF Address Extended Community
This is an IP or IPv6 Address Specific EC with the Global Admin Field
set to the address of the upstream RBR and the Local Admin Field set
to 0.
2.2. Procedures 2.2. Procedures
2.2.1. Source Discovery for ASM 2.2.1. Source Discovery for ASM
When a FHR first receives a multicast packet addressed to an ASM When a FHR first receives a multicast packet addressed to an ASM
group, it originates a Source Active route. It carries a IP/IPv6 group, it originates a Source Active route. It carries a IP/IPv6
Address Specific RT, with the Global Admin Field set to the group Address Specific RT, with the Global Admin Field set to the group
address and the Local Admin Field set to 0. The route is advertised address and the Local Admin Field set to 0. The route is advertised
to its peers, who will re-advertise further based on the RTC to its peers, who will re-advertise further based on the RTC
mechanisms. Note that typically the route is advertised only to the mechanisms. Note that typically the route is advertised only to the
skipping to change at page 16, line 9 skipping to change at page 17, line 20
When a router receives a tree join route and imports it, it When a router receives a tree join route and imports it, it
determines if it needs to originate its own corresponding route and determines if it needs to originate its own corresponding route and
advertise further upstream wrt the source/RPA or mLDP tunnel root. advertise further upstream wrt the source/RPA or mLDP tunnel root.
If this router is the FHR or is on the RPL or is the tunnel root, If this router is the FHR or is on the RPL or is the tunnel root,
then it does not need to. Otherwise the procedures in Section 2.2.2 then it does not need to. Otherwise the procedures in Section 2.2.2
are followed. are followed.
Additionally, the router sets up its corresponding forwarding state Additionally, the router sets up its corresponding forwarding state
such that traffic will be sent to the downstream neighbor, and such that traffic will be sent to the downstream neighbor, and
received from the downstream neighbor in case of birectional tree/ received from the downstream neighbor in case of bidirectional tree/
tunnel. If the downstream neighbor is not directly connected, tunnel. If the downstream neighbor is not directly connected,
tunnels may be used - details to be included in future revisions. tunnels may be used - details to be included in future revisions.
2.2.4. Withdrawl of Tree Join Routes 2.2.4. Withdrawl of Tree Join Routes
For a particular tree or tunnel, if a downstream neighbor withdraws For a particular tree or tunnel, if a downstream neighbor withdraws
its Leaf A-D route, the neighbor is removed from the corresponding its Leaf A-D route, the neighbor is removed from the corresponding
forwarding state. If all downstream neighbors withdraw their tree forwarding state. If all downstream neighbors withdraw their tree
join routes and this router no longer has local receivers, it join routes and this router no longer has local receivers, it
withdraws the tree join routes that it previously originated. withdraws the tree join routes that it previously originated.
skipping to change at page 18, line 24 skipping to change at page 19, line 34
from this router, but with multiple RTs (one for each downstream from this router, but with multiple RTs (one for each downstream
neighbor on the tree). A TEA specifies a label allocated by the neighbor on the tree). A TEA specifies a label allocated by the
upstream router for its downstream neighbors to send traffic with. upstream router for its downstream neighbors to send traffic with.
Note that this is still a "downstream allocated" label (the upstream Note that this is still a "downstream allocated" label (the upstream
router is "downstream" from traffic direction point of view). router is "downstream" from traffic direction point of view).
The S-PMSI routes do not carry a PTA, unless a P2MP tunnel is used to The S-PMSI routes do not carry a PTA, unless a P2MP tunnel is used to
reach downstream neighbors. Such use case is out of scope of this reach downstream neighbors. Such use case is out of scope of this
document for now and may be specified in the future. document for now and may be specified in the future.
3. Security Considerations 3. IANA Considerations
This document requests IANA to assign a new BGP SAFI value for the
MCAST-TREE SAFI.
This document requests IANA to create a new "BGP MCAST-TREE Route
Types" registry, referencing this document. The following initial
values are defined:
0~2 - Reserved
3 - S-PMSI A-D Route for (x,g)
4 - Leaf A-D Route
5 - Source Active A-D Route
0x43 - S-PMSI A-D Route for C-multicast mLDP
This document requests IANA to assign two Sub-type values from
Transitive IPv4-Address-Specific Extended Community Sub-types
Registry for Session Address EC and Multicast RPF Address EC
respectively.
This document requests IANA to assign two Type values from Transitive
IPv6-Address-Specific Extended Community Types Registry for Session
Address EC and Multicast RPF Address EC respectively.
4. Security Considerations
This document does not introduce new security risks. This document does not introduce new security risks.
4. Acknowledgements 5. Acknowledgements
The authors thank Marco Rodrigues for his initial idea/ask of using The authors thank Marco Rodrigues for his initial idea/ask of using
BGP for multicast signaling beyond MVPN. We thank Eric Rosen for his BGP for multicast signaling beyond MVPN. We thank Eric Rosen for his
questions, suggestions, and help finding solutions to some issues. questions, suggestions, and help finding solutions to some issues.
We also thank Luay Jalil and James Uttaro for their comments and We also thank Luay Jalil and James Uttaro for their comments and
support for the work. support for the work.
5. References 6. References
5.1. Normative References 6.1. Normative References
[I-D.ietf-idr-tunnel-encaps] [I-D.ietf-idr-tunnel-encaps]
Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel
Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15
(work in progress), December 2019. (work in progress), December 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 19, line 34 skipping to change at page 21, line 21
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>. <https://www.rfc-editor.org/info/rfc6514>.
[RFC7441] Wijnands, IJ., Rosen, E., and U. Joorde, "Encoding [RFC7441] Wijnands, IJ., Rosen, E., and U. Joorde, "Encoding
Multipoint LDP (mLDP) Forwarding Equivalence Classes Multipoint LDP (mLDP) Forwarding Equivalence Classes
(FECs) in the NLRI of BGP MCAST-VPN Routes", RFC 7441, (FECs) in the NLRI of BGP MCAST-VPN Routes", RFC 7441,
DOI 10.17487/RFC7441, January 2015, DOI 10.17487/RFC7441, January 2015,
<https://www.rfc-editor.org/info/rfc7441>. <https://www.rfc-editor.org/info/rfc7441>.
5.2. Informative References 6.2. Informative References
[I-D.ietf-bess-mvpn-evpn-aggregation-label]
Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands,
"MVPN/EVPN Tunnel Aggregation with Common Labels", draft-
ietf-bess-mvpn-evpn-aggregation-label-03 (work in
progress), October 2019.
[I-D.ietf-bess-mvpn-pe-ce] [I-D.ietf-bess-mvpn-pe-ce]
Patel, K., Rosen, E., and Y. Rekhter, "BGP as an MVPN PE- Patel, K., Rosen, E., and Y. Rekhter, "BGP as an MVPN PE-
CE Protocol", draft-ietf-bess-mvpn-pe-ce-01 (work in CE Protocol", draft-ietf-bess-mvpn-pe-ce-01 (work in
progress), October 2015. progress), October 2015.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-06 (work in progress),
December 2019.
[I-D.voyer-pim-sr-p2mp-policy]
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
Zhang, "Segment Routing Point-to-Multipoint Policy",
draft-voyer-pim-sr-p2mp-policy-01 (work in progress),
April 2020.
[I-D.wijnands-bier-mld-lan-election] [I-D.wijnands-bier-mld-lan-election]
Wijnands, I., Pfister, P., and Z. Zhang, "Generic Wijnands, I., Pfister, P., and Z. Zhang, "Generic
Multicast Router Election on LAN's", draft-wijnands-bier- Multicast Router Election on LAN's", draft-wijnands-bier-
mld-lan-election-01 (work in progress), July 2016. mld-lan-election-01 (work in progress), July 2016.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496,
DOI 10.17487/RFC5496, March 2009,
<https://www.rfc-editor.org/info/rfc5496>.
[RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann,
"Using Multipoint LDP When the Backbone Has No Route to
the Root", RFC 6512, DOI 10.17487/RFC6512, February 2012,
<https://www.rfc-editor.org/info/rfc6512>.
[RFC6826] Wijnands, IJ., Ed., Eckert, T., Leymann, N., and M. [RFC6826] Wijnands, IJ., Ed., Eckert, T., Leymann, N., and M.
Napierala, "Multipoint LDP In-Band Signaling for Point-to- Napierala, "Multipoint LDP In-Band Signaling for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6826, DOI 10.17487/RFC6826, January 2013, Paths", RFC 6826, DOI 10.17487/RFC6826, January 2013,
<https://www.rfc-editor.org/info/rfc6826>. <https://www.rfc-editor.org/info/rfc6826>.
[RFC7060] Napierala, M., Rosen, E., and IJ. Wijnands, "Using LDP
Multipoint Extensions on Targeted LDP Sessions", RFC 7060,
DOI 10.17487/RFC7060, November 2013,
<https://www.rfc-editor.org/info/rfc7060>.
[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. [RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B.
Decraene, "Multicast-Only Fast Reroute", RFC 7431, Decraene, "Multicast-Only Fast Reroute", RFC 7431,
DOI 10.17487/RFC7431, August 2015, DOI 10.17487/RFC7431, August 2015,
<https://www.rfc-editor.org/info/rfc7431>. <https://www.rfc-editor.org/info/rfc7431>.
[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of
BGP for Routing in Large-Scale Data Centers", RFC 7938, BGP for Routing in Large-Scale Data Centers", RFC 7938,
DOI 10.17487/RFC7938, August 2016, DOI 10.17487/RFC7938, August 2016,
<https://www.rfc-editor.org/info/rfc7938>. <https://www.rfc-editor.org/info/rfc7938>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
Authors' Addresses Authors' Addresses
Zhaohui Zhang Zhaohui Zhang
Juniper Networks Juniper Networks
EMail: zzhang@juniper.net EMail: zzhang@juniper.net
Lenny Giuliano Lenny Giuliano
Juniper Networks Juniper Networks
 End of changes. 27 change blocks. 
51 lines changed or deleted 190 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/