draft-ietf-bess-bgp-multicast-02.txt   draft-ietf-bess-bgp-multicast-03.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: December 12, 2020 K. Patel Expires: July 10, 2021 K. Patel
Arrcus Arrcus
I. Wijnands I. Wijnands
M. Mishra M. Mishra
Cisco Systems Cisco Systems
A. Gulko A. Gulko
Refinitiv Refinitiv
June 10, 2020 January 6, 2021
BGP Based Multicast BGP Based Multicast
draft-ietf-bess-bgp-multicast-02 draft-ietf-bess-bgp-multicast-03
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
here are based on the BGP multicast procedures that were originally here are based on the BGP multicast procedures that were originally
designed for use by providers of Multicast Virtual Private Network designed for use by providers of Multicast Virtual Private Network
service. service.
This document also describes how various signaling mechanisms can be
used to set up end-to-end inter-region multiast trees.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC2119. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 12, 2020. This Internet-Draft will expire on July 10, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . 6
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
1.2.6. Inter-region Multicast . . . . . . . . . . . . . . . 9 1.2.6. Inter-region Multicast . . . . . . . . . . . . . . . 10
1.2.6.1. Same BGP Signaling Inline across a Region . . . . 10 1.2.6.1. Inband Signaling across a Region . . . . . . . . 10
1.2.6.2. Different Signaling Inline across a Region . . . 10 1.2.6.2. Overlay Signaling Over a Region . . . . . . . . . 10
1.2.6.3. Overlay Signaling Over a Region . . . . . . . . . 10 1.2.6.3. Controller Based Signaling . . . . . . . . . . . 11
1.2.6.4. Controller Based Signaling . . . . . . . . . . . 11 1.2.7. BGP Classful Transport Planes . . . . . . . . . . . . 12
2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2.8. Flexible Algorithm and Multi-topology . . . . . . . . 13
2.1. BGP NLRIs and Attributes . . . . . . . . . . . . . . . . 12 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1. S-PMSI A-D Route . . . . . . . . . . . . . . . . . . 13 2.1. BGP NLRIs and Attributes . . . . . . . . . . . . . . . . 13
2.1.2. Leaf A-D Route . . . . . . . . . . . . . . . . . . . 13 2.1.1. S-PMSI A-D Route . . . . . . . . . . . . . . . . . . 14
2.1.3. Source Active A-D Route . . . . . . . . . . . . . . . 14 2.1.2. Leaf A-D Route . . . . . . . . . . . . . . . . . . . 15
2.1.4. S-PMSI A-D Route for C-multicast mLDP . . . . . . . . 15 2.1.3. Source Active A-D Route . . . . . . . . . . . . . . . 16
2.1.5. Session Address Extended Community . . . . . . . . . 15 2.1.4. S-PMSI A-D Route for C-multicast mLDP . . . . . . . . 17
2.1.6. Multicast RPF Address Extended Community . . . . . . 16 2.1.5. Session Address Extended Community . . . . . . . . . 17
2.1.6. Multicast RPF Address Extended Community . . . . . . 18
2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 16 2.1.7. Topology/IPA Extended Community . . . . . . . . . . . 18
2.2.1. Source Discovery for ASM . . . . . . . . . . . . . . 16 2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.2. Originating Tree Join Routes . . . . . . . . . . . . 16 2.2.1. Source Discovery for ASM . . . . . . . . . . . . . . 18
2.2.2.1. (x,g) Multicast Tree . . . . . . . . . . . . . . 16 2.2.2. Originating Tree Join Routes . . . . . . . . . . . . 19
2.2.2.2. BGP Inband Signaling for mLDP Tunnel . . . . . . 17 2.2.2.1. (x,g) Multicast Tree . . . . . . . . . . . . . . 19
2.2.3. Receiving Tree Join Routes . . . . . . . . . . . . . 18 2.2.2.2. BGP Inband Signaling for mLDP Tunnel . . . . . . 20
2.2.4. Withdrawl of Tree Join Routes . . . . . . . . . . . . 18 2.2.3. Receiving Tree Join Routes . . . . . . . . . . . . . 20
2.2.5. LAN procedures for (x,g) Unidirectional Tree . . . . 18 2.2.4. Withdrawl of Tree Join Routes . . . . . . . . . . . . 20
2.2.5.1. Originating S-PMSI A-D Routes . . . . . . . . . . 18 2.2.5. LAN procedures for (x,g) Unidirectional Tree . . . . 21
2.2.5.2. Receiving S-PMSI A-D Routes . . . . . . . . . . . 19 2.2.5.1. Originating S-PMSI A-D Routes . . . . . . . . . . 21
2.2.5.2. Receiving S-PMSI A-D Routes . . . . . . . . . . . 21
2.2.6. Distributing Label for Upstream Traffic for 2.2.6. Distributing Label for Upstream Traffic for
Bidirectional Tree/Tunnel . . . . . . . . . . . . . . 20 Bidirectional Tree/Tunnel . . . . . . . . . . . . . . 22
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 4. Security Considerations . . . . . . . . . . . . . . . . . . . 23
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Normative References . . . . . . . . . . . . . . . . . . 21 6.1. Normative References . . . . . . . . . . . . . . . . . . 23
6.2. Informative References . . . . . . . . . . . . . . . . . 22 6.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 7, line 31 skipping to change at page 7, line 38
1.2.2. BGP Inband Signaling for mLDP Tunnel 1.2.2. BGP Inband Signaling for mLDP Tunnel
Part of an (or the whole) mLDP tunnel can also be signaled via BGP Part of an (or the whole) mLDP tunnel can also be signaled via BGP
and seamlessly integrated with the rest of mLDP tunnel signaled and seamlessly integrated with the rest of mLDP tunnel signaled
natively via mLDP. All the procedures are similar to mLDP except natively via mLDP. All the procedures are similar to mLDP except
that the signaling is done via BGP. The mLDP FEC is encoded as the that the signaling is done via BGP. The mLDP FEC is encoded as the
BGP NLRI, with MCAST-TREE SAFI and S-PMSI/Leaf A-D Routes for BGP NLRI, with MCAST-TREE SAFI and S-PMSI/Leaf A-D Routes for
C-multicast mLDP defined in this document. The Leaf A-D routes C-multicast mLDP defined in this document. The Leaf A-D routes
correspond to mLDP Label Mapping messages, and the S-PMSI A-D routes correspond to mLDP Label Mapping messages, and the S-PMSI A-D routes
are used to signal upstream FEC for MP2MP mLDP tunnels, similar to are used to signal upstream FEC for MP2MP mLDP tunnels, similar to
the bidirection (*,g) case. the bidirectional (*,g) case.
1.2.3. BGP Sessions 1.2.3. BGP Sessions
In order for two BGP speakers to exchange MCAST-TREE NLRI, they must In order for two BGP speakers to exchange MCAST-TREE NLRI, they must
use BGP Capabilities Advertisement [RFC5492] to ensure that they both use BGP Capabilities Advertisement [RFC5492] to ensure that they both
are capable of properly processing the MCAST-TREE NLRI. This is done are capable of properly processing the MCAST-TREE NLRI. This is done
as specified in [RFC4760], by using a capability code 1 as specified in [RFC4760], by using a capability code 1
(multiprotocol BGP) with an AFI of IPv4 (1) or IPv6 (2) and a SAFI of (multiprotocol BGP) with an AFI of IPv4 (1) or IPv6 (2) and a SAFI of
MCAST-TREE with a value to be assigned by IANA. MCAST-TREE with a value to be assigned by IANA.
skipping to change at page 9, line 51 skipping to change at page 10, line 12
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 1.2.6. Inter-region Multicast
An end-to-end multicast tree or P2MP tunnel may span multiple 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 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. an Autonomous System (AS), and different multicast signaling could be
used in different regions. There are several situations to consider.
1.2.6.1. Same BGP Signaling Inline across a Region 1.2.6.1. Inband Signaling across a Region
With inline signaling, the multicast tree/tunnel is signaled through With inband signaling, the multicast tree/tunnel is signaled through
the region and internal routers in the region maintain corresponding a region and internal routers in the region maintain corresponding
per-tree/tunnel state. per-tree/tunnel state. A downstream region and an upstream region
may use the same or different signaling. For example, An (*/s, g) IP
multicast tree with BGP signaling in a downstream region can be
signaled with mLDP Inband Signaling [RFC6826] or with PIM across the
upstream region, and a p2mp tunnel with BGP signaling in the
downstream region can be signaled with mLDP across the upstream
region, or vice versa. A RBR will stitch the upstream portion (e.g
PIM/mLDP-signaled) to downstream portion (e.g BGP-signaled).
If all routers in the region have route towards the source/root of 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 the tree/tunnel then there is nothing different from the intra-region
case. On the other hand, if internal routers do not have route case. On the other hand, if internal routers do not have route
towards the source/root, e.g. BGP-LU is used as in Seamless MPLS, towards the source/root, e.g. as with Seamless MPLS
the internal routers need to do RPF towards an upstream Regional [I-D.ietf-mpls-seamless-mpls] or Seamless SR
Border Router (RBR). To signal the RBR information to an internal [I-D.hegde-spring-mpls-seamless-sr], the internal routers need to do
upstream router, the Leaf A-D Route carries a new BGP Extended RPF towards an upstream Regional Border Router (RBR). To signal the
Community referred to as Multicast RPF Address EC, similar to PIM RPF RBR information to an internal upstream router, one of the following
Vector [RFC5496] and mLDP Recursive FEC [RFC6512]. ways is used depending on the signaling method:
1.2.6.2. Different Signaling Inline across a Region o With BGP signaling, 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]
Just like that part of a PIM multicast tree can be signaled as an o With PIM signaling, PIM RPF Vector is used.
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/ o With mLDP signaling, mLDP Recursive FEC is used.
root, PIM RPF Vector or mLDP Recursive FEC may be used.
1.2.6.3. Overlay Signaling Over a Region 1.2.6.2. Overlay Signaling Over a Region
With overlay signaling, a downstream RBR signals via BGP to its With overlay signaling, a downstream RBR signals to its upstream RBR
upstream RBR over the region (whether via a RR or not) and the over the region and the internal routers do not maintain the state of
internal routers do not maintain the state of the (overlay) tree/ the (overlay) tree/tunnel. This can be done with one of the
tunnel. The upstream RBR tunnels packets to the downstream RBR, just following methods:
as in the intra-region case when two routers on the tree/tunnel are
not directly connected. For example, when BGP-LU is used as in o mLDP P2MP tunnels can be signaled over the region via targeted LDP
Seamless MPLS, a downstream RBR determines that the route towards the sessions [RFC7060]
source/root has a BGP Next Hop towards a BGP speaker capable of
multicast signaling via BGP as specified in this document, so it o Both IP multicast tree and mLDP P2MP tunnels can be signaled over
signals to that BGP speaker (via a RR or not). a region via BGP-MVPN procedures [RFC6514].
o Both IP multicast tree and mLDP P2MP tunnels can be signaled over
a region via BGP as discussed in the rest of this section.
All three methods are actually very similar in concept. 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. The rest of this section only discusses BGP signaling.
When 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, it signals to that
BGP speaker (via a RR or not).
Suppose an upstream RBR receives the signaling for the same tree/ Suppose an upstream RBR receives the signaling for the same tree/
tunnel from several downstream RBRs. It could use Ingress tunnel from several downstream RBRs. It could use Ingress
Replication to replicate packets directly to those downstream RBRs, Replication to replicate packets directly to those downstream RBRs,
or it could use underlay P2MP tunnels instead. or it could use underlay P2MP tunnels instead.
In the latter case, the upstream RBR advertises an S-PMSI A-D route In the latter case, the upstream RBR advertises an S-PMSI A-D route
with a Provider Tunnel Attribute (PTA) specifying the underlay with a Provider Tunnel Attribute (PTA) specifying the underlay
tunnel. This is very much like the "mLDP Over Targeted Sessions" tunnel. This is very much like the "mLDP Over Targeted Sessions"
[RFC7060] or BGP-MVPN [RFC6514]. If the mapping between overlay [RFC7060] or BGP-MVPN [RFC6514] (though MCAST-VPN's C-Muilticast
tree/tunnel and underlay tunnel is one-to-one, the MPLS Label field routes are replaced with MCAST-TREE's Leaf A-D routes). If the
in the PTA is set to 0 or otherwise set to a Domain-wide Common Block mapping between overlay tree/tunnel and underlay tunnel is one-to-
(DCB) label [I-D.ietf-bess-mvpn-evpn-aggregation-label] or an one, the MPLS Label field in the PTA is set to 0 or otherwise set to
upstream-assigned label corresponding to the overlay tree/tunnel. 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 The underlay tunnel, whether P2P to individual downstream RBRs or
P2MP to the set of downstream RBRs, can be of any type including P2MP to the set of downstream RBRs, can be of any type including
Segment Routing (SR) [RFC8402] policies [I-D.ietf-spring-segment- Segment Routing (SR) [RFC8402] policies [I-D.ietf-spring-segment-
routing-policy] [I-D.voyer-pim-sr-p2mp-policy]. routing-policy] [I-D.ietf-pim-sr-p2mp-policy].
1.2.6.4. Controller Based Signaling 1.2.6.3. Controller Based Signaling
[I-D.ietf-bess-bgp-multicast-controller] specifies the procedures for [I-D.ietf-bess-bgp-multicast-controller] specifies the procedures for
a controller to signal multicast forwarding state to each router on a a controller to signal multicast forwarding state to each router on a
multicast tree based on the controller's computation. Depending on multicast tree based on the controller's computation. Depending on
deployment scenarios, in inter-region cases it is possible that the deployment scenarios, in inter-region cases it is possible that the
hop-by-hop signaling specified in this document and the controller hop-by-hop signaling specified in this document and the controller
based signaling may be used in different regions. based signaling may be used in different regions.
Consider a situation where an ABR is connected three regions A, B, Consider a situation where an ABR is connected three regions A, B,
and C, where hop-by-hop signaling is used in A and B, while and C, where hop-by-hop signaling is used in A and B, while
controller based signaling is used in C. controller based signaling is used in C.
For a particular multicast tree, A is the upstream region, while B For a particular multicast tree, A is the upstream region, while B
and C are two downtream regions. The ABR receives a Leaf A-D route and C are two downstream regions. The ABR receives a Leaf A-D route
from region B and a Leaf A-D route from C's controller, and sends a from region B and a Leaf A-D route from C's controller, and sends a
Leaf A-D route to its upstream router in A. Leaf A-D route to its upstream router in A.
For a different tree, C is the upstream region while A and B are For a different tree, C is the upstream region while A and B are
downstream. The ABR receives two Leaf A-D routes for the tree from downstream. The ABR receives two Leaf A-D routes for the tree from
regions A and B, and one Leaf A-D route from C's controller. Note regions A and B, and one Leaf A-D route from C's controller. Note
that the ABR needs to signal to the controller that it is a leaf of that the ABR needs to signal to the controller that it is a leaf of
the tree (because of the Leaf A-D routes received from regions A and the tree (because of the Leaf A-D routes received from regions A and
B). B).
For both cases, the ABR stitches together different segments in For both cases, the ABR stitches together different segments in
different regions by creating forwarding state based on the Leaf A-D different regions by creating forwarding state based on the Leaf A-D
routes (optionally based on the S-PMSI A-D routes in region A and B routes (optionally based on the S-PMSI A-D routes in region A and B
in addition.) in addition.)
1.2.7. BGP Classful Transport Planes
[I-D.kaliraj-idr-bgp-classful-transport-planes] specifies a framework
for classifying underlay routes into transport classes and mapping
service routes to specific transport classes. An underlay route
signaled with BGP-CT SAFI carries a Transport Class Route Target (TC-
RT) to both indicate the transport class that the route belongs to
and to control the propagation and importation of the underlay route.
The recipient of the underlay routes use the TC-RT to determine how
the Protocol NH (PNH) is resolved. A service/overlay route may carry
a mapping community that maps to a transport class that is used to
resolve the service route's PNH.
In case of multicast, the selection of the link/tunnel between an
upstream and downstream tree node may be subject to the transport
class that the tree is for (in case of an underlay tree) or the class
of transport that the tree should use (in case of an overlay tree).
In both the underlay and overlay case, the transport class is
indicated by a mapping community attached to the BGP multicast
routes, which could be a color community or any community intended
for mapping to the transport.
The mapping community not only affects an upstream node's selection
of link/tunnel to a downstream node, but may also affect a downstream
node's selection of its upstream node (i.e. the RPF procedure).
1.2.8. Flexible Algorithm and Multi-topology
Similar to classful transport, in case of multi-topology [RFC4915]
[RFC5120] or Flexible Algorithm [I-D.ietf-lsr-flex-algo], a multicast
tree may be required to do RPF based on a particular topology or
Flexible Algorithm (IPA). To signal that, the BGP-MCAST Leaf A-D
route may carry an extended community to encode the topology and/or
IPA. Note that this could also be an operator defined mapping
community that maps to a transport class (that is associated with a
topology or a Flexible Algorithm).
In the grand scheme of inter-region scenario, if mLDP is to be used
with Flexible Algorithm or Multi-topology for signaling in a
particular region, [I-D.wijnands-mpls-mldp-multi-topology] specifies
how topology and/or IPA are encoded.
Similarly, in case of PIM, [RFC6420] specifies how topology
information is encoded in PIM signaling and similar mechanism can be
specified for Flexible Algorithm. However, that, and potentially
encoding transport class in PIM/mLDP are outside the scope of this
document.
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
skipping to change at page 14, line 23 skipping to change at page 16, line 14
+- +-----------------------------------+ +- +-----------------------------------+
| | Route Type - 4 (Leaf A-D) | | | Route Type - 4 (Leaf A-D) |
| +-----------------------------------+ | +-----------------------------------+
| | Length (1 octet) | | | Length (1 octet) |
| +- +-----------------------------------+ --+ | +- +-----------------------------------+ --+
| | | Route Type - 3 (S-PMSI A-D) | | | | | Route Type - 3 (S-PMSI A-D) | |
L | L | +-----------------------------------+ | S L | L | +-----------------------------------+ | S
E | E | | Length (1 octet) | | | E | E | | Length (1 octet) | | |
A | A | +-----------------------------------+ | P A | A | +-----------------------------------+ | P
F | F | RD (8 octets) | | M F | F | | RD (8 octets) | | M
| | | Multicast Source Length (1 octet) | | S | | +-----------------------------------+ | S
| | +-----------------------------------+ | I | | | Multicast Source Length (1 octet) | | I
| | +-----------------------------------+ | I
N | R | | Multicast Source (variable) | | N | R | | Multicast Source (variable) | |
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 Address | | Y | | Originating Router's IP Address |
+- +- +-----------------------------------+ +- +- +-----------------------------------+
skipping to change at page 16, line 21 skipping to change at page 18, line 21
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 2.1.6. Multicast RPF Address Extended Community
This is an IP or IPv6 Address Specific EC with the Global Admin Field 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 set to the address of the upstream RBR and the Local Admin Field set
to 0. to 0.
2.1.7. Topology/IPA Extended Community
This is an Transitive Opaque Extended Community with the following
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 | Sub-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPA is the Flexible Algorithm number and MT-ID is the Multi-Topology
Identifier to be used for setting a multicast tree.
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 21, line 7 skipping to change at page 23, line 25
3 - S-PMSI A-D Route for (x,g) 3 - S-PMSI A-D Route for (x,g)
4 - Leaf A-D Route 4 - Leaf A-D Route
5 - Source Active A-D Route 5 - Source Active A-D Route
0x43 - S-PMSI A-D Route for C-multicast mLDP 0x43 - S-PMSI A-D Route for C-multicast mLDP
This document requests IANA to assign two Sub-type values from This document requests IANA to assign two Sub-type values from
Transitive IPv4-Address-Specific Extended Community Sub-types Transitive IPv4-Address-Specific Extended Community Sub-types
Registry for Session Address EC and Multicast RPF Address EC Registry for Session Address EC and Multicast RPF Address EC
respectively. respectively.
This document requests IANA to assign two Type values from Transitive This document requests IANA to assign two Sub-Type values from
IPv6-Address-Specific Extended Community Types Registry for Session Transitive IPv6-Address-Specific Extended Community Types Registry
Address EC and Multicast RPF Address EC respectively. for Session Address EC and Multicast RPF Address EC respectively.
This document requests IANA to assign one Sub-Type value from
Transitive Opaque Extended Community Types Registry for the Topology/
IPA EC.
4. Security Considerations 4. Security Considerations
This document does not introduce new security risks. This document does not introduce new security risks.
5. 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, James Uttaro and Shraddha Hegde for their
support for the work. comments and support for the work.
6. References 6. References
6.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., Sangli, S., and J. Scudder, "The BGP
Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel-
(work in progress), December 2019. encaps-20 (work in progress), November 2020.
[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>.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, Protocol Specification (Revised)", RFC 4601,
DOI 10.17487/RFC4601, August 2006, DOI 10.17487/RFC4601, August 2006,
skipping to change at page 22, line 23 skipping to change at page 24, line 41
<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>.
6.2. Informative References 6.2. Informative References
[I-D.hegde-spring-mpls-seamless-sr]
Hegde, S., Bowers, C., Xu, X., Gulko, A., Bogdanov, A.,
Uttaro, J., Jalil, L., Khaddam, M., and A. Alston,
"Seamless Segment Routing", draft-hegde-spring-mpls-
seamless-sr-03 (work in progress), November 2020.
[I-D.ietf-bess-bgp-multicast-controller] [I-D.ietf-bess-bgp-multicast-controller]
Zhang, Z., Raszuk, R., Pacella, D., and A. Gulko, Zhang, Z., Raszuk, R., Pacella, D., and A. Gulko,
"Controller Based BGP Multicast Signaling", draft-ietf- "Controller Based BGP Multicast Signaling", draft-ietf-
bess-bgp-multicast-controller-01 (work in progress), June bess-bgp-multicast-controller-05 (work in progress),
2020. September 2020.
[I-D.ietf-bess-mvpn-evpn-aggregation-label] [I-D.ietf-bess-mvpn-evpn-aggregation-label]
Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands,
"MVPN/EVPN Tunnel Aggregation with Common Labels", draft- "MVPN/EVPN Tunnel Aggregation with Common Labels", draft-
ietf-bess-mvpn-evpn-aggregation-label-03 (work in ietf-bess-mvpn-evpn-aggregation-label-04 (work in
progress), October 2019. progress), November 2020.
[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] [I-D.ietf-lsr-flex-algo]
Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
P. Mattes, "Segment Routing Policy Architecture", draft- A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
ietf-spring-segment-routing-policy-07 (work in progress), algo-13 (work in progress), October 2020.
May 2020.
[I-D.voyer-pim-sr-p2mp-policy] [I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", draft-
ietf-mpls-seamless-mpls-07 (work in progress), June 2014.
[I-D.ietf-pim-sr-p2mp-policy]
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
Zhang, "Segment Routing Point-to-Multipoint Policy", Zhang, "Segment Routing Point-to-Multipoint Policy",
draft-voyer-pim-sr-p2mp-policy-01 (work in progress), draft-ietf-pim-sr-p2mp-policy-01 (work in progress),
April 2020. October 2020.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-09 (work in progress),
November 2020.
[I-D.kaliraj-idr-bgp-classful-transport-planes]
Vairavakkalai, K., Venkataraman, N., Rajagopalan, B., and
G. Mishra, "BGP Classful Transport Planes", draft-kaliraj-
idr-bgp-classful-transport-planes-03 (work in progress),
December 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.
[I-D.wijnands-mpls-mldp-multi-topology]
Wijnands, I., Raza, K., Mishra, M., Budhiraja, A., Zhang,
Z., and A. Gulko, "mLDP Extensions for Multi-Topology
Routing", draft-wijnands-mpls-mldp-multi-topology-01 (work
in progress), November 2020.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/info/rfc4915>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496, Forwarding (RPF) Vector TLV", RFC 5496,
DOI 10.17487/RFC5496, March 2009, DOI 10.17487/RFC5496, March 2009,
<https://www.rfc-editor.org/info/rfc5496>. <https://www.rfc-editor.org/info/rfc5496>.
[RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join
Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011,
<https://www.rfc-editor.org/info/rfc6420>.
[RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, [RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann,
"Using Multipoint LDP When the Backbone Has No Route to "Using Multipoint LDP When the Backbone Has No Route to
the Root", RFC 6512, DOI 10.17487/RFC6512, February 2012, the Root", RFC 6512, DOI 10.17487/RFC6512, February 2012,
<https://www.rfc-editor.org/info/rfc6512>. <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>.
 End of changes. 38 change blocks. 
104 lines changed or deleted 240 lines changed or added

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