Network Working Group R. Parekh
Internet-Draft C. Filsfils
Intended status: Standards Track A. Venkateswaran
Expires: June 5, 2021 Cisco Systems, Inc.
H. Bidgoli
Nokia
D. Voyer
Bell Canada
Z. Zhang
Juniper Networks
December 2, 2020
Multicast and Ethernet VPN with Segment Routing Point-to-Multipoint
Trees
draft-ietf-bess-mvpn-evpn-sr-p2mp-01
Abstract
A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain
efficiently carries traffic from a Root to a set of Leaves. This
document describes extensions to BGP encodings and procedures for
P2MP trees used in BGP/MPLS IP VPNs and Ethernet VPNs.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 5, 2021.
Parekh, et al. Expires June 5, 2021 [Page 1]
Internet-Draft BGP MVPN and EVPN with SR P2MP Trees December 2020
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SR P2MP P-Tunnels . . . . . . . . . . . . . . . . . . . . . . 3
3. PMSI Tunnel Attribute for SR P2MP . . . . . . . . . . . . . . 4
3.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. SR MPLS . . . . . . . . . . . . . . . . . . . . . . . 5
4. MVPN Auto-Discovery and Binding Procedures . . . . . . . . . 5
4.1. Intra-AS I-PMSI . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Originating Intra-AS I-PMSI routes . . . . . . . . . 5
4.1.2. Receiving Intra-AS I-PMSI A-D routes . . . . . . . . 6
4.2. Using S-PMSIs for binding customer flows to P2MP Segments 7
4.2.1. Originating S-PMSI A-D routes . . . . . . . . . . . . 7
4.2.2. Receiving S-PMSI A-D routes . . . . . . . . . . . . . 8
4.3. Inter-AS P-tunnels using P2MP Segments . . . . . . . . . 8
4.3.1. Advertising Inter-AS I-PMSI routes into iBGP . . . . 8
4.3.2. Receiving Inter-AS I-PMSI A-D routes in iBGP . . . . 8
4.4. Leaf A-D routes for P2MP Segment Leaf Discovery . . . . . 9
4.4.1. Originating Leaf A-D routes . . . . . . . . . . . . . 9
4.4.2. Receiving Leaf A-D routes . . . . . . . . . . . . . . 9
5. Dampening of MVPN routes . . . . . . . . . . . . . . . . . . 9
6. SR P2MP Trees for EVPN . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Parekh, et al. Expires June 5, 2021 [Page 2]
Internet-Draft BGP MVPN and EVPN with SR P2MP Trees December 2020
1. Introduction
Multicast in MPLS/BGP IP VPNs [RFC6513] and BGP Encodings and
Procedures for Multicast in MPLS/BGP IP VPNs [RFC6514] specify
procedures that allow a Service Provider to provide Multicast VPN
(MVPN) service to its customers. Multicast traffic from a customer
is tunneled across the service provider network over Provider Tunnels
(P-Tunnels). P-tunnels can be instantiated via different
technologies. A service provider network that uses Segment Routing
can use a Point-to-Multipoint (SR P2MP) tree
[I-D.ietf-pim-sr-p2mp-policy] to instantiate P-Tunnels for MVPN.
In a Segment Routing network, a P2MP tree allows efficient delivery
of traffic from a Root to set of Leaf nodes. A SR P2MP tree is
defined by a SR P2MP Policy and instantiated via a PCE. A P2MP
Policy consists of a Root, a Set of Leaf Nodes and a set of candidate
paths with optional set of constraints and/or optimization objectives
to be satisfied by the P2MP tree. A unique Identifier, called Tree-
SID, is associated with a P2MP tree. This Tree-SID can be an MPLS
label or an IPv6 address.
This document describes extensions to BGP Auto-Discovery procedures
specified in RFC 6514 for SR P2MP P-Tunnels. Use of PIM for Auto-
Discovery is outside scope of this document. Support for customer
BIDIR-PIM is outside the scope of this document.
For BGP MPLS Ethernet VPN specified in [RFC7432] and extensions to
this document, P-Tunnels are advertised for handling multi-
destination traffic. These P-tunnels can be realized by SR P2MP
trees. SRv6 P2MP trees can also be used to support Multicast in
Network Virtualization over Layer 3 [RFC8293].
The reader is expected to be familiar with concepts and terminology
of RFC 6513, RFC 6514 and SR P2MP draft.
2. SR P2MP P-Tunnels
For MVPN or EVPN, Provider Edge(PE) routers steer customer traffic
into a P-Tunnel that can be instantiated by SR P2MP tree. A SR P2MP
tree is defined by a SR P2MP policy [I-D.ietf-pim-sr-p2mp-policy].
SR P2MP P-tunnel can be instantiated by either SR-MPLS or SRv6 P2MP
trees. Details for SRv6 P2MP trees will be added in future revision
of this document.
Given a SR P2MP policy, a PCE computes and instantiates the SR P2MP
tree on the nodes that are part of the tree using Replication
segments and Tree-SID which a unique identifier for the tree
Parekh, et al. Expires June 5, 2021 [Page 3]
Internet-Draft BGP MVPN and EVPN with SR P2MP Trees December 2020
[I-D.ietf-spring-sr-replication-segment]. A Replication segment can
be initiated by various methods (BGP, PCEP, others) which are outside
the scope of this document.
A PCE provides conceptual APIs, listed below, to define and modify SR
P2MP policies SR P2MP Policy Section 4.1.1 [1]. These APIs are
invoked by a PCC, which is the root of P2MP tree, using various
methods (BGP, PCEP, etc.) which are outside the scope of this
document.
CreatePolicy: CreateSRP2MPPolicy<Root, Tree-ID>
DeletePolicy: DeleteSRP2MPPolicy<Root, Tree-ID>
UpdateLeafSet: SRP2MPPolicyLeafSetModify<Root, Tree-ID, {Leaf
Set}>
The Root of a P2MP tree imposes the Tree-SID to steer the customer
payload into the P2MP tree. Provider (P) routers replicate customer
payload, using Replication segments, towards the Leaf nodes of the
P2MP tree. Leaf nodes of the P2MP tree deliver the customer payload
after dispoing the Tree-SID.
3. PMSI Tunnel Attribute for SR P2MP
A PMSI Tunnel Attribute (PTA) is defined in RFC 6514 to identify the
P-Tunnel that is used to instantiate a Provider Multicast Service
Interface (PMSI). The PTA is carried in Intra-AS I-PMSI, Inter-AS
I-PMSI, Selective PMSI, and Leaf Auto-Discovery routes.
A P2MP tree PTA is constructed as follows:
o Tunnel Type: The codepoint is set to [[CREF1: TBD]]for SR P2MP
tree from the "P-Multicast Service Interface Tunnel (PMSI Tunnel)
Tunnel Types" registry.
o Flags: See Section 4 for use of "Leaf Info Required bit".
o MPLS Label: See Section 3.1
o Tunnel Identifier: The SR P2MP P-tunnel is identified by <Tree-ID,
Root> where,
* Tree-ID is a 32-bit unsigned value that identifies a unique
P2MP tree at a Root..
Parekh, et al. Expires June 5, 2021 [Page 4]
Internet-Draft BGP MVPN and EVPN with SR P2MP Trees December 2020
* Root is an IP address identifying the Root of a P2MP tree.
This can be either an IPv4 or IPv6 address and can be inferred
from the PTA length.
When a P-Tunnel is non-segmented, the PTA is created by PE router at
the Root of a SR P2MP tree. For segmented P-tunnels, each segment
can be instantiated by a different technology. If a segment is
instantiated using P2MP tree, the router at the root of a P2MP tree
creates the PTA.
3.1. MPLS Label
[RFC6514] allows a PE to aggregate two or more MVPNs onto one
P-tunnel by advertising the same P-tunnel in PTA of Auto-Discovery
routes of different MVPNs. This section specifies how the "MPLS
Label" field of PTA is filled to provide a context bound to a
specific MPVN. For EVPN considerations, see SR P2MP Trees for EVPN
section.
3.1.1. SR MPLS
When a SR P2MP P-tunnel, shared across different MVPNs, is
instantiated in a SR MPLS domain [RFC8660], "MPLS Field" of a PTA
advertised in a Auto-Discovery route MUST contain an upstream-
assigned MPLS label that the advertising PE has bound to the MVPN.
When a customer payload is steered into a shared SR P2MP P-tunnel,
this MPLS label MUST be imposed before the MPLS label representing
the Tree-SID.
4. MVPN Auto-Discovery and Binding Procedures
RFC 6514 defines procedures for discovering PEs participating in a
given MVPN and binding customer multicast flows to specific
P-Tunnels. This section specifies modifications to these procedures
for SR P2MP P-Tunnels.
4.1. Intra-AS I-PMSI
Intra-AS I-PMSI A-D routes are exchanged to discover PEs
participating in a MVPN within an AS, or across different ASes when
non-segmented P-tunnels for inter-AS MVPNs.
4.1.1. Originating Intra-AS I-PMSI routes
RFC 6514 Section 9.1.1 [2] describes procedures for originating
Intra-AS I-PMSI A-D routes. For SR P2MP P-tunnels, these procedures
remain unchanged except as described in the following paragraphs.
Parekh, et al. Expires June 5, 2021 [Page 5]
Internet-Draft BGP MVPN and EVPN with SR P2MP Trees December 2020
When a PE originates an Intra-AS I-PMSI A-D route with a PTA having
SR P2MP P-tunnel Type, it MUST create a P2MP policy by invoking
CreatePolicy API of the PCE. When the PCE instantiates the P2MP tree
on the PE, the Tree-SID MUST be imposed for customer flow(s) steered
into the P2MP tree. The Leaf nodes of P2MP tree are discovered using
procedures described in Section 4.1.2.
For a PE in "Receiver Sites set", condition (c) is modified to
include P2MP tree i.e. such a PE MUST originate an Intra-AS I-PMSI
A-D route when some PEs of the MVPN have VRFs that use SR P2MP tree
but MUST NOT create a SR P2MP policy as described above.
When a PE withdraws an Intra-AS I-PMSI A-D route, advertised with a
PTA having SR P2MP P-tunnel Type, the Tree-SID imposition state at
the PE MUST be removed.
A PE MAY aggregate two or more Intra-AS I-PMSIs from different MVPNs
onto the same SR P2MP P-tunnel. When a PE withdraws the last Intra-
AS I-PMSI A-D route, advertised with a PTA identifying a SR P2MP
P-tunnel , it SHOULD remove the SR P2MP policy by invoking
DeletePolicy API of the PCE.
4.1.2. Receiving Intra-AS I-PMSI A-D routes
Procedure for receiving Intra-AS I-PMSI A-D routes, as described in
RFC 6514 Section 9.1.2 [3], remain unchanged for SR P2MP P-tunnels
except as described in the following paragraphs.
When a PE that advertises a SR P2MP P-tunnel in the PTA of its Intra-
AS I-PMSI A-D route, imports an Intra-AS I-PMSI A-D route from some
PE, it MUST add that PE as a Leaf node of the P2MP tree. The
Originating IP Address of the Intra-AS i-PMSI A-D route is used as
the Leaf Address when invoking UpdateLeafSet API of the PCE. This
procedure MUST also be followed for all Intra-AS I-PMSI routes that
are already imported when the PE advertises a SR P2MP P-tunnel in PTA
of its Intra-AS I-PMSI A-D route.
A PE that imports and processes an Intra-AS I-PMSI A-D route from
another PE with PTA having SR P2MP P-Tunnel MUST program the Tree-SID
of the P2MP tree identified in the PTA of the route for disposition.
Note that an Intra-AS I-PMSI A-D route from another PE can be
imported before the P2MP tree identified in the PTA of the route is
instantiated by the PCEat the importing PE. In such case, the PE
MUST correctly program Tree-SID for disposition. A PE in "Sender
Sites set" MAY avoid programming the Tree-SID for disposition.
Parekh, et al. Expires June 5, 2021 [Page 6]
Internet-Draft BGP MVPN and EVPN with SR P2MP Trees December 2020
When an Intra-AS I-PMSI A-D route, advertised with a PTA having SR
P2MP P-tunnel Type is withdrawn, a PE MUST remove the disposition
state of the Tree-SID associated with P2MP tree.
A PE MAY aggregate two or more Intra-AS I-PMSIs from different MVPNs
onto the same SR P2MP P-tunnel. When a remote PE withdraws an Intra-
AS I-PMSI A-D route from a MVPN, and if this is the last MVPN sharing
a SR P2MP P-tunnel, a PE must remove the originating PE as a Leaf
from the P2MP tree, by invoking UpdateLeafSet API.
4.2. Using S-PMSIs for binding customer flows to P2MP Segments
RFC 6514 specifies procedures for binding (C-S,C-G) customer flows to
P-tunnels using S-PMSI A-D routes. Wildcards in Multicast VPN Auto-
Discovery Routes [RFC6625] specifies additional procedures to binding
aggregate customer flows to P-tunnels using "wildcard" S-PMSI A-D
routes. This section describes modification to these procedures for
SR P2MP P-tunnels.
4.2.1. Originating S-PMSI A-D routes
RFC 6514 Section 12.1 [4] describes procedures for originating S-PMSI
A-D routes. For SR P2MP P-tunnels, these procedures remain unchanged
except as described in the following paragraphs.
When a PE originates S-PMSI A-D route with a PTA having SR P2MP
P-tunnel Type, it MUST set the "Leaf Info Required bit" in the PTA.
The PE MUST create a SR P2MP policy by invoking1 API of the PCE.
When the PCEinstantiates the P2MP tree on the PE, the Tree-SID MUST
be imposed for customer flows steered into the SR P2MP P-tunnel.
The Leaf nodes of P2MP tree are discovered by Leaf A-D routes using
procedures described in Section 4.4.2. When a PE originates S-PMSI
A-D route with a PTA having SR P2MP P-tunnel Type, it is possible the
PE might have imported Leaf A-D routes whose route keys match the
S-PMSI A-D route. The PE MUST re-apply procedures of Section 4.4.2
to these Leaf A-D routes.
When a PE withdraws a S-PMSI A-D route, advetised with PTA having
P2MP tree P-tunnle type, the Tree-SID imposition state MUST be
removed.
A PE MAY aggregate two or more S-PMSIs onto the same SR P2MP
P-tunnel. When a PE withdraws the last S-PMSI A-D route, advertised
with a PTA identifying a specific SR P2MP P-tunnel , it SHOULD remove
the SR P2MP policy by invoking DeletePolicy API of the PCE.
Parekh, et al. Expires June 5, 2021 [Page 7]
Internet-Draft BGP MVPN and EVPN with SR P2MP Trees December 2020
4.2.2. Receiving S-PMSI A-D routes
RFC 6514 Section 12.3 [5] describes procedures for receiving S-PMSI
A-D routes. For SR P2MP P-tunnels, these procedures remain unchanged
except as described in the following paragraphs.
The procedure to join SR P2MP P-tunnel of S-PMSI A-D route by using a
Leaf A-D route is described in Section 4.4.1. If P2MP tree
identified in PTA of S-PMSI A-D route is already instantiated by PCE,
the PE MUST program Tree-SID for disposition. If the P2MP tree is
instantiated later, the Tree-SID MUST be programmed for disposition
at that time.
When a S-PMSI A-D route, whose SR P2MP P-tunnel is joined by a PE, is
withdrawn, or when conditions (see RFC 6514 Section 12.3 [6])
required to join that P-Tunnel are no longer satisfied, the PE MUST
leave the P-Tunnel. The PE MUST withdraw the Leaf A-D route it had
originated and remove the Tree-SID disposition state.
4.3. Inter-AS P-tunnels using P2MP Segments
A segmented inter-AS P-tunnel consists of one or more intra-AS
segments, one in each AS, connected by inter-AS segments between
ASBRs of different ASes <https://tools.ietf.org/html/rfc6514#section-
9.2>. These segments are constructed by PEs/ASBRs originating or re-
advertising Inter-AS I-PMSI A-D routes. This section describes
procedures for instantiating intra-AS segments using SR P2MP trees.
4.3.1. Advertising Inter-AS I-PMSI routes into iBGP
RFC 6514 Section 9.2.3.2 [7] specifies procedures for advertising an
Inter-AS I-PMSI A-D route to construct an intra-AS segment. The PTA
of the route identifies the type and identifier of the P-tunnel
instantiating the intra-AS segment. The procedure for creating SR
P2MP P-tunnel for intra-AS segment are same as specified in
Section 4.2.1 except that instead of S-PMSI A-D routes, the
procedures apply to Inter-AS I-PMSI A-D routes.
4.3.2. Receiving Inter-AS I-PMSI A-D routes in iBGP
RFC 6514 Section 9.2.3.2 [8] specifies procedures for processing an
Inter-AS I-PMSI A-D route received via iBGP. If the PTA of the
Inter-AS I-PMSI A-D route has SR P2MP P-tunnel Type, the procedures
are same as specified in Section 4.2.2 except that instead of S-PMSI
A-D routes, the procedures apply to Inter-AS I-PMSI A-D routes. If
the receiving router is an ASBR, the Tree-SID is stitched to the
inter-AS segments to ASBRs in other ASes.
Parekh, et al. Expires June 5, 2021 [Page 8]
Internet-Draft BGP MVPN and EVPN with SR P2MP Trees December 2020
4.4. Leaf A-D routes for P2MP Segment Leaf Discovery
This section describes procedures for originating and processing Leaf
A-D routes used for Leaf discovery of SR P2MP trees.
4.4.1. Originating Leaf A-D routes
The procedures for originating Leaf A-D route in response to
receiving a S-PMSI or Inter-AS I-PMSI A-D route with PTA having SR
P2MP P-tunnel Type are same as specified in RFC 6514
Section 9.2.3.4.1 [9].
4.4.2. Receiving Leaf A-D routes
Procedures for processing a received Leaf A-D route are specified in
RFC 6514 Section 9.2.3.5 [10]. These procedures remain unchanged for
discovering Leaf nodes of P2MP trees except for considerations
described in following paragraphs. These procedures apply to Leaf
A-D routes received in response to both S-PMSI and Inter-AS I-PMSI
A-D routes, shortened to "A-D routes" in this section
A Root PE/ASBR MAY use the same SR P2MP P-tunnel in PTA of two or
more A-D routes. For such aggregated P2MP trees, the PE/ASBR MAY
receive multiple Leaf A-D routes from a Leaf PE. The P2MP tree for
which a Leaf A-D is received can be identified by examining the P2MP
tunnel Identifier in the PTA of A-D route that matches "Route Key"
field of the Leaf A-D route. When the PE receives the first Leaf A-D
route from a Leaf PE, identified by the Originating Router's IP
address field, it MUST add that PE as Leaf of the P2MP tree by
invoking the UpdateLeafSet API of the PCE.
When a Leaf PE withdraws the last Leaf A-D route for a given SR P2MP
P-tunnel, the Root PE MUST remove the Leaf PE from the P2MP tree by
invoking UpdateLeafSet API of PCE. Note that Root PE MAY remove the
P2MP tree, via the DeletePolicyAPI, before the last Leaf A-D is
withdrawn. In this case, the Root PE MAY decide to not invoke the
UpdateLeafSet API.
5. Dampening of MVPN routes
When P2MP trees are used as P-Tunnels for S-PMSI A-D routes, change
in group membership of receivers connected to PEs has direct impact
on the Leaf node set of a P2MP tree. If group membership changes
frequently for a large number of groups with a lot of receivers
across sites connected to different PEs, it can have an impact on the
interaction between PEs and the PCE.
Parekh, et al. Expires June 5, 2021 [Page 9]
Internet-Draft BGP MVPN and EVPN with SR P2MP Trees December 2020
Since Leaf A-D routes are used to discover Leaf PE of a P2MP tree, it
is RECOMMENDED that PEs SHOULD damp Leaf A-D routes as described in
Section 6.1 of RFC 7899 [RFC7899]. PEs MAY also implement procedures
for damping other Auto-Discovery and BGP C-multicast routes as
described in [RFC7899].
6. SR P2MP Trees for EVPN
BGP MPLS Ethernet VPN specified in RFC 7432 specifies Inclusive
Multicast Ethernet Tag route to support Broadcast, Unknown Unicast
and Multicast (BUM) traffic. This IMET route is the equivalent of
MVPN Intra-AS I-PMSI route and is advertised with a PMSI Tunnel
Attribute (PTA) as specified in RFC 6514 to advertise the inclusive
P-tunnels.
[I-D.ietf-bess-evpn-bum-procedure-updates] updates BUM procedures to
support selective P-tunnels and P-tunnel segmentation in EVPN. That
document specifies new route types that are advertised with PTA,
including Selective PMSI (S-PMSI) Auto-Discovery route.
These inclusive/selective P-tunnels can be realized by SR P2MP trees.
As with other types of P2MP P-tunnels, the ESI label used for split
horizon MUST be either upstream assigned by PE advertising the IMET
or S-PMSI route, or assigned from a global context such as "Domain-
wide Common Block" (DCB) as specified in
[I-D.ietf-bess-mvpn-evpn-aggregation-label].
[I-D.ietf-bess-evpn-irb-mcast] specifies procedures to support Inter-
Subnet Multicast. [I-D.ietf-bess-evpn-mvpn-seamless-interop]
specifies how MVPN SAFI routes can be used to support Inter-Subnet
Multicast. The P-tunnels advertised in PTA of either EVPN and MVPN
routes as specified in these documents respectively can be realized
by SR P2MP trees.
SRv6 P2MP trees can serve as an underlay multicast as described in
RFC 8293 Section 3.4 [11]. A NVE encapsuates a tenant packet in an
SRv6 header and deliver it over SRv6 P2MP trees to other NVEs.
The same procedures specified for MVPN are used to collect the leaf
information of corresponding SR P2MP tree (either based on IMET route
or Leaf A-D routes in response to x-PMSI routes), to pass the tree
information to the PCE controller, and to get back tree forwarding
state used for customer multicast traffic forwarding.
Parekh, et al. Expires June 5, 2021 [Page 10]
Internet-Draft BGP MVPN and EVPN with SR P2MP Trees December 2020
7. IANA Considerations
IANA is requested assign codepoint for "SR-MPLS P2MP Tree" in the
"P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types"
registry <https://www.iana.org/assignments/bgp-parameters/bgp-
parameters.xhtml#pmsi-tunnel-types> [RFC 7538] in the "Border Gateway
Protocol (BGP) Parameters" registry. A proposed value is 0x0C.
8. Security Considerations
The procedures in this document do not introduce any additional
security considerations beyond those mentioned in [RFC6513] and
[RFC6514]. For general security considerations applicable to P2MP
trees, please refer to [I-D.ietf-pim-sr-p2mp-policy] .
9. Acknowledgements
The authors would like to acknowledge Luc Andre Burdett reviweing the
document..
10. Contributors
Zafar Ali
Cisco Systems, Inc.
US
Email: zali@cisco.com
Ehsan Hemmati
Cisco Systems, Inc.
US
Email: ehemmati@cisco.com
Jayant Kotalwar
Nokia
Mountain View
US
Email: jayant.kotalwar@nokia.com
Tanmoy Kundu
Nokia
Mountain View
US
Email: tanmoy.kundu@nokia.com
Parekh, et al. Expires June 5, 2021 [Page 11]
Internet-Draft BGP MVPN and EVPN with SR P2MP Trees December 2020
Clayton Hassen
Bell Canada
Vancouver
CA
Email: clayton.hassen@bell.ca
11. References
11.1. Normative References
[I-D.ietf-pim-sr-p2mp-policy]
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
Zhang, "Segment Routing Point-to-Multipoint Policy",
draft-ietf-pim-sr-p2mp-policy-01 (work in progress),
October 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>.
11.2. Informative References
[I-D.ietf-bess-evpn-bum-procedure-updates]
Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A.
Sajassi, "Updates on EVPN BUM Procedures", draft-ietf-
bess-evpn-bum-procedure-updates-08 (work in progress),
November 2019.
[I-D.ietf-bess-evpn-irb-mcast]
Lin, W., Zhang, Z., Drake, J., Rosen, E., Rabadan, J., and
A. Sajassi, "EVPN Optimized Inter-Subnet Multicast (OISM)
Forwarding", draft-ietf-bess-evpn-irb-mcast-05 (work in
progress), October 2020.
Parekh, et al. Expires June 5, 2021 [Page 12]
Internet-Draft BGP MVPN and EVPN with SR P2MP Trees December 2020
[I-D.ietf-bess-evpn-mvpn-seamless-interop]
Sajassi, A., Thiruvenkatasamy, K., Thoria, S., Gupta, A.,
and L. Jalil, "Seamless Multicast Interoperability between
EVPN and MVPN PEs", draft-ietf-bess-evpn-mvpn-seamless-
interop-01 (work in progress), July 2020.
[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-04 (work in
progress), November 2020.
[I-D.ietf-spring-sr-replication-segment]
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
Zhang, "SR Replication Segment for Multi-point Service
Delivery", draft-ietf-spring-sr-replication-segment-03
(work in progress), October 2020.
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
RFC 6625, DOI 10.17487/RFC6625, May 2012,
<https://www.rfc-editor.org/info/rfc6625>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7899] Morin, T., Ed., Litkowski, S., Patel, K., Zhang, Z.,
Kebler, R., and J. Haas, "Multicast VPN State Damping",
RFC 7899, DOI 10.17487/RFC7899, June 2016,
<https://www.rfc-editor.org/info/rfc7899>.
[RFC8293] Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R.
Krishnan, "A Framework for Multicast in Network
Virtualization over Layer 3", RFC 8293,
DOI 10.17487/RFC8293, January 2018,
<https://www.rfc-editor.org/info/rfc8293>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
Parekh, et al. Expires June 5, 2021 [Page 13]
Internet-Draft BGP MVPN and EVPN with SR P2MP Trees December 2020
11.3. URIs
[1] https://tools.ietf.org/html/draft-ietf-pim-sr-p2mp-policy-
00#section-4.1.1
[2] https://tools.ietf.org/html/rfc6514#section-9.1.1
[3] https://tools.ietf.org/html/rfc6514#section-9.1.2
[4] https://tools.ietf.org/html/rfc6514#section-12.1
[5] https://tools.ietf.org/html/rfc6514#section-12.3
[6] https://tools.ietf.org/html/rfc6514#section-12.3
[7] https://tools.ietf.org/html/rfc6514#section-9.2.3.2
[8] https://tools.ietf.org/html/rfc6514#section-9.2.3.2
[9] https://tools.ietf.org/html/rfc6514#section-9.2.3.4.1
[10] https://tools.ietf.org/html/rfc6514#section-9.2.3.5
[11] https://tools.ietf.org/html/rfc8293#section-3.4
Authors' Addresses
Rishabh Parekh
Cisco Systems, Inc.
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: riparekh@cisco.com
Clarence Filsfils
Cisco Systems, Inc.
Brussels
BE
Email: cfilsfil@cisco.com
Parekh, et al. Expires June 5, 2021 [Page 14]
Internet-Draft BGP MVPN and EVPN with SR P2MP Trees December 2020
Arvind Venkateswaran
Cisco Systems, Inc.
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: arvvenka@cisco.com
Hooman Bidgoli
Nokia
Ottawa
CA
Email: hooman.bidgoli@nokia.com
Daniel Voyer
Bell Canada
Montreal
CA
Email: daniel.voyer@bell.ca
Zhaohui Zhang
Juniper Networks
Email: zzhang@juniper.net
Parekh, et al. Expires June 5, 2021 [Page 15]
