draft-ietf-bess-bgp-multicast-01.txt   draft-ietf-bess-bgp-multicast-02.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: November 14, 2020 K. Patel Expires: December 12, 2020 K. Patel
Arrcus Arrcus
I. Wijnands I. Wijnands
M. Mishra M. Mishra
Cisco Systems Cisco Systems
A. Gulko A. Gulko
Refinitiv Refinitiv
May 13, 2020 June 10, 2020
BGP Based Multicast BGP Based Multicast
draft-ietf-bess-bgp-multicast-01 draft-ietf-bess-bgp-multicast-02
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 November 14, 2020. This Internet-Draft will expire on December 12, 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 43 skipping to change at page 2, line 43
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 . . . . . . . . . . . . . . . 9
1.2.6.1. Same BGP Signaling Inline across a Region . . . . 10 1.2.6.1. Same BGP Signaling Inline across a Region . . . . 10
1.2.6.2. Different Signaling Inline across a Region . . . 10 1.2.6.2. Different Signaling Inline across a Region . . . 10
1.2.6.3. Overlay Signaling Over a Region . . . . . . . . . 10 1.2.6.3. Overlay Signaling Over a Region . . . . . . . . . 10
2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2.6.4. Controller Based Signaling . . . . . . . . . . . 11
2.1. BGP NLRIs and Attributes . . . . . . . . . . . . . . . . 11 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.1. S-PMSI A-D Route . . . . . . . . . . . . . . . . . . 12 2.1. BGP NLRIs and Attributes . . . . . . . . . . . . . . . . 12
2.1.1. S-PMSI A-D Route . . . . . . . . . . . . . . . . . . 13
2.1.2. Leaf A-D Route . . . . . . . . . . . . . . . . . . . 13 2.1.2. Leaf A-D Route . . . . . . . . . . . . . . . . . . . 13
2.1.3. Source Active A-D Route . . . . . . . . . . . . . . . 14 2.1.3. Source Active A-D Route . . . . . . . . . . . . . . . 14
2.1.4. S-PMSI A-D Route for C-multicast mLDP . . . . . . . . 14 2.1.4. S-PMSI A-D Route for C-multicast mLDP . . . . . . . . 15
2.1.5. Session Address Extended Community . . . . . . . . . 14 2.1.5. Session Address Extended Community . . . . . . . . . 15
2.1.6. Multicast RPF Address Extended Community . . . . . . 15 2.1.6. Multicast RPF Address Extended Community . . . . . . 16
2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1. Source Discovery for ASM . . . . . . . . . . . . . . 15 2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.2. Originating Tree Join Routes . . . . . . . . . . . . 15 2.2.1. Source Discovery for ASM . . . . . . . . . . . . . . 16
2.2.2.1. (x,g) Multicast Tree . . . . . . . . . . . . . . 15 2.2.2. Originating Tree Join Routes . . . . . . . . . . . . 16
2.2.2.2. BGP Inband Signaling for mLDP Tunnel . . . . . . 16 2.2.2.1. (x,g) Multicast Tree . . . . . . . . . . . . . . 16
2.2.3. Receiving Tree Join Routes . . . . . . . . . . . . . 17 2.2.2.2. BGP Inband Signaling for mLDP Tunnel . . . . . . 17
2.2.4. Withdrawl of Tree Join Routes . . . . . . . . . . . . 17 2.2.3. Receiving Tree Join Routes . . . . . . . . . . . . . 18
2.2.5. LAN procedures for (x,g) Unidirectional Tree . . . . 17 2.2.4. Withdrawl of Tree Join Routes . . . . . . . . . . . . 18
2.2.5.1. Originating S-PMSI A-D Routes . . . . . . . . . . 17 2.2.5. LAN procedures for (x,g) Unidirectional Tree . . . . 18
2.2.5.2. Receiving S-PMSI A-D Routes . . . . . . . . . . . 18 2.2.5.1. Originating S-PMSI A-D Routes . . . . . . . . . . 18
2.2.5.2. Receiving S-PMSI A-D Routes . . . . . . . . . . . 19
2.2.6. Distributing Label for Upstream Traffic for 2.2.6. Distributing Label for Upstream Traffic for
Bidirectional Tree/Tunnel . . . . . . . . . . . . . . 19 Bidirectional Tree/Tunnel . . . . . . . . . . . . . . 20
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Normative References . . . . . . . . . . . . . . . . . . 20 6.1. Normative References . . . . . . . . . . . . . . . . . . 21
6.2. Informative References . . . . . . . . . . . . . . . . . 21 6.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 6, line 13 skipping to change at page 6, line 13
FHRs, LHRs, and optionally RRs work together to propagate/discover FHRs, LHRs, and optionally RRs work together to propagate/discover
source information via control plane and LHRs join source specific source information via control plane and LHRs join source specific
Shortest Path Trees (SPT) directly. Shortest Path Trees (SPT) directly.
A FHR originates Source Active A-D routes upon discovering sources A FHR originates Source Active A-D routes upon discovering sources
for particular flows and advertise them to its peers. It is desired for particular flows and advertise them to its peers. It is desired
that the SA routes only reach LHRs that are interested in receiving that the SA routes only reach LHRs that are interested in receiving
the traffic. To achieve that, the SA routes carry an IPv4 or IPv6 the traffic. To achieve that, the SA routes carry an IPv4 or IPv6
address specific Route Target. The Global Administrator field is set address specific Route Target. The Global Administrator field is set
the group address of the flow, and the Local Administrator field is the group address of the flow, and the Local Administrator field is
set to 0. An LHR advertises Route Target Membership routes, with the set to 0 or a pre-assigned domain-wide unique value that identifies a
VPN. An LHR advertises Route Target Membership routes, with the
Route Target field in the NLRI set according to the groups it wants Route Target field in the NLRI set according to the groups it wants
to receive traffic for, as how a FHR encode the Route Target in its to receive traffic for, as how a FHR encode the Route Target in its
Source Active routes. The propagation of the SA routes is subject to Source Active routes. The propagation of the SA routes is subject to
cooperative export filtering as specified in [RFC4684] and referred cooperative export filtering as specified in [RFC4684] and referred
to as RTC mechanism in this document. That way, the LHR only to as RTC mechanism in this document. That way, the LHR only
receives Source Active routes for groups that it is interested in. receives Source Active routes for groups that it is interested in.
Typically, a set of RRs are used and they maintains all Source Active Typically, a set of RRs are used and they maintains all Source Active
routes but only distribute to interested LHRs on demand (upon routes but only distribute to interested LHRs on demand (upon
receiving corresponding Route Target Membership routes, which are receiving corresponding Route Target Membership routes, which are
skipping to change at page 10, line 14 skipping to change at page 10, line 14
1.2.6.1. Same BGP Signaling Inline across a Region 1.2.6.1. Same BGP Signaling Inline across a Region
With inline signaling, the multicast tree/tunnel is signaled through With inline signaling, the multicast tree/tunnel is signaled through
the region and internal routers in the region maintain corresponding the region and internal routers in the region maintain corresponding
per-tree/tunnel state. per-tree/tunnel state.
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-LS is used as in Seamless MPLS, towards the source/root, e.g. BGP-LU is used as in Seamless MPLS,
the internal routers need to do RPF towards an upstream Regional the internal routers need to do RPF towards an upstream Regional
Border Router (RBR). To signal the RBR information to an internal Border Router (RBR). To signal the RBR information to an internal
upstream router, the Leaf A-D Route carries a new BGP Extended upstream router, the Leaf A-D Route carries a new BGP Extended
Community referred to as Multicast RPF Address EC, similar to PIM RPF Community referred to as Multicast RPF Address EC, similar to PIM RPF
Vector [RFC5496] and mLDP Recursive FEC [RFC6512]. Vector [RFC5496] and mLDP Recursive FEC [RFC6512].
1.2.6.2. Different Signaling Inline across a Region 1.2.6.2. Different Signaling Inline across a Region
Just like that part of a PIM multicast tree can be signaled as an Just like that part of a PIM multicast tree can be signaled as an
mLDP P2MP/MP2MP tunnel with mLDP Inband Signaling [RFC6826], BGP- mLDP P2MP/MP2MP tunnel with mLDP Inband Signaling [RFC6826], BGP-
skipping to change at page 10, line 41 skipping to change at page 10, line 41
Depending on whether internal routers have route towards the source/ Depending on whether internal routers have route towards the source/
root, PIM RPF Vector or mLDP Recursive FEC may be used. root, PIM RPF Vector or mLDP Recursive FEC may be used.
1.2.6.3. Overlay Signaling Over a Region 1.2.6.3. Overlay Signaling Over a Region
With overlay signaling, a downstream RBR signals via BGP to its With overlay signaling, a downstream RBR signals via BGP to its
upstream RBR over the region (whether via a RR or not) and the upstream RBR over the region (whether via a RR or not) and the
internal routers do not maintain the state of the (overlay) tree/ internal routers do not maintain the state of the (overlay) tree/
tunnel. The upstream RBR tunnels packets to the downstream RBR, just 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 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 not directly connected. For example, when BGP-LU is used as in
Seamless MPLS, a downstream RBR determines that the route towards the Seamless MPLS, a downstream RBR determines that the route towards the
source/root has a BGP Next Hop towards a BGP speaker capable of source/root has a BGP Next Hop towards a BGP speaker capable of
multicast signaling via BGP as specified in this document, so it multicast signaling via BGP as specified in this document, so it
signals to that BGP speaker (via a RR or not). 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.
skipping to change at page 11, line 19 skipping to change at page 11, line 19
tree/tunnel and underlay tunnel is one-to-one, the MPLS Label field 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 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 (DCB) label [I-D.ietf-bess-mvpn-evpn-aggregation-label] or an
upstream-assigned label corresponding to the overlay tree/tunnel. 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.voyer-pim-sr-p2mp-policy].
1.2.6.4. Controller Based Signaling
[I-D.ietf-bess-bgp-multicast-controller] specifies the procedures for
a controller to signal multicast forwarding state to each router on a
multicast tree based on the controller's computation. Depending on
deployment scenarios, in inter-region cases it is possible that the
hop-by-hop signaling specified in this document and the controller
based signaling may be used in different regions.
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
controller based signaling is used in C.
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
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.
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
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
the tree (because of the Leaf A-D routes received from regions A and
B).
For both cases, the ABR stitches together different segments in
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
in addition.)
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 12, line 29 skipping to change at page 13, line 14
The Type-3/4 routes MAY carry a Tunnel Encapsulation Attribute (TEA) The Type-3/4 routes MAY carry a Tunnel Encapsulation Attribute (TEA)
[I-D.ietf-idr-tunnel-encaps]. The Type-0x43 route MUST carry a TEA. [I-D.ietf-idr-tunnel-encaps]. The Type-0x43 route MUST carry a TEA.
When used for mLDP, the Type-4 route MUST carry a TEA. Only the MPLS When used for mLDP, the Type-4 route MUST carry a TEA. Only the MPLS
tunnel type for the TEA is considered. Others are outside the scope tunnel type for the TEA is considered. Others are outside the scope
of this document. of this document.
2.1.1. S-PMSI A-D Route 2.1.1. S-PMSI A-D Route
Similar to defined in RFC 6514, an S-PMSI A-D Route Type specific Similar to defined in RFC 6514, an S-PMSI A-D Route Type specific
MCAST-TREE NLRI consists of the following, though it does not have an MCAST-TREE NLRI consists of the following:
RD:
+-----------------------------------+ +-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Multicast Source Length (1 octet) | | Multicast Source Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Multicast Source (variable) | | Multicast Source (variable) |
+-----------------------------------+ +-----------------------------------+
| Multicast Group Length (1 octet) | | Multicast Group Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Multicast Group (variable) | | Multicast Group (variable) |
+-----------------------------------+ +-----------------------------------+
| Upstream Router's IP Address | | Upstream Router's IP Address |
+-----------------------------------+ +-----------------------------------+
skipping to change at page 13, line 32 skipping to change at page 14, line 23
+- +-----------------------------------+ +- +-----------------------------------+
| | 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 | | Multicast Source Length (1 octet) | | M F | F | RD (8 octets) | | M
| | +-----------------------------------+ | S | | | Multicast Source Length (1 octet) | | S
N | R | | Multicast Source (variable) | | I | | +-----------------------------------+ | I
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 14, line 13 skipping to change at page 15, line 6
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.
2.1.3. Source Active A-D Route 2.1.3. Source Active A-D Route
Similar to defined in RFC 6514, a Source Active A-D Route Type Similar to defined in RFC 6514, a Source Active A-D Route Type
specific MCAST NLRI consists of the following: specific MCAST NLRI consists of the following:
+-----------------------------------+ +-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Multicast Source Length (1 octet) | | Multicast Source Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Multicast Source (variable) | | Multicast Source (variable) |
+-----------------------------------+ +-----------------------------------+
| Multicast Group Length (1 octet) | | Multicast Group Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Multicast Group (variable) | | Multicast Group (variable) |
+-----------------------------------+ +-----------------------------------+
The definition of the source/length and group/length fields are the The definition of the source/length and group/length fields are the
same as in the S-PMSI A-D routes. same as in the S-PMSI A-D routes.
Usage of Source Active A-D routes is described in Section 1.2.1.1. Usage of Source Active A-D routes is described in Section 1.2.1.1.
2.1.4. S-PMSI A-D Route for C-multicast mLDP 2.1.4. S-PMSI A-D Route for C-multicast mLDP
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].
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 IPv4/IPv6 Address Specific EC Address Extended Community. This is an IPv4/IPv6 Address Specific EC
with the Global Admin Field set to the local address used for its with the Global Admin Field set to the local address used for its
multihop 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.
skipping to change at page 16, line 12 skipping to change at page 17, line 8
defined for PIM. It further finds the BGP router that advertised the defined for PIM. It further finds the BGP router that advertised the
nexthop address as one of its local addresses. nexthop address as one of its local addresses.
If the RPF neighbor supports MCAST-TREE SAFI, this router originates If the RPF neighbor supports MCAST-TREE SAFI, this router originates
a Leaf A-D route. Although it is unsolicited, it is constructed as a Leaf A-D route. Although it is unsolicited, it is constructed as
if there was a corresponding S-PMSI A-D route. The Upstream Router's if there was a corresponding S-PMSI A-D route. The Upstream Router's
IP Address field is set to the RPF neighbor's session address (learnt IP Address field is set to the RPF neighbor's session address (learnt
via the EC attached to the host route for the RPF nexthop address). via the EC attached to the host route for the RPF nexthop address).
An Address Specific RT corresponding to the session address is An Address Specific RT corresponding to the session address is
attached to the route, with the Global Administrative Field set to attached to the route, with the Global Administrative Field set to
the session address and the local administrative field set to 0. the session address and the local administrative field set to 0 or a
pre-assigned domain-wide unique value that identifies a VPN.
Similarly, when a router learns that it needs to join a bi- Similarly, when a router learns that it needs to join a bi-
directional tree for a particular group, it determines the RPF directional tree for a particular group, it determines the RPF
neighbor wrt the RPA. If the neighbor supports MCAST-TREE SAFI, it neighbor wrt the RPA. If the neighbor supports MCAST-TREE SAFI, it
originates a Leaf A-D Route and advertises the route to the RPF originates a Leaf A-D Route and advertises the route to the RPF
neighbor (in case of EBGP or hop-by-hop IBGP), or one or more RRs. neighbor (in case of EBGP or hop-by-hop IBGP), or one or more RRs.
When a router first learns that it needs to receive traffic for an When a router first learns that it needs to receive traffic for an
ASM group, either because of a local (*,g) IGMP/MLD report or a ASM group, either because of a local (*,g) IGMP/MLD report or a
downstream PIM (*,g) join, it originates a RTC route with the NLRI's downstream PIM (*,g) join, it originates a RTC route with the NLRI's
AS field set to its AS number and the Route Target field set to an AS field set to its AS number and the Route Target field set to an
address based RT, with the Global Administrator field set to group address based RT, with the Global Administrator field set to group
address and the Local Administrator field set to 0. The route is address and the Local Administrator field set to 0 or a pre-assigned
domain-wide unique value that identifies a VPN. The route is
advertised to its peers (most practically some RRs), so that the advertised to its peers (most practically some RRs), so that the
router can receive matching Source Active A-D routes. Upon the router can receive matching Source Active A-D routes. Upon the
receiving of the Source Active A-D routes, the router originates Leaf receiving of the Source Active A-D routes, the router originates Leaf
A-D routes as described above, as long as it still needs to receive A-D routes as described above, as long as it still needs to receive
traffic for the flows (i.e., the corresponding IGMP/MLD membership traffic for the flows (i.e., the corresponding IGMP/MLD membership
exists or join from downstream PIM/BGP neighbor exists). exists or join from downstream PIM/BGP neighbor exists).
When a Leaf A-D route is originated by this router, it sets up When a Leaf A-D route is originated by this router, it sets up
corresponding forwarding state such that the expected incoming corresponding forwarding state such that the expected incoming
interface list includes all non-LAN interfaces directly connecting to interface list includes all non-LAN interfaces directly connecting to
skipping to change at page 21, line 23 skipping to change at page 22, line 23
<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.ietf-bess-bgp-multicast-controller]
Zhang, Z., Raszuk, R., Pacella, D., and A. Gulko,
"Controller Based BGP Multicast Signaling", draft-ietf-
bess-bgp-multicast-controller-01 (work in progress), June
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-03 (work in
progress), October 2019. 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] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft- P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-06 (work in progress), ietf-spring-segment-routing-policy-07 (work in progress),
December 2019. May 2020.
[I-D.voyer-pim-sr-p2mp-policy] [I-D.voyer-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-voyer-pim-sr-p2mp-policy-01 (work in progress),
April 2020. 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-
 End of changes. 20 change blocks. 
41 lines changed or deleted 86 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/