< draft-li-pce-multicast-00.txt   draft-li-pce-multicast-01.txt >
pce H. Li pce H. Li
Internet-Draft A. Wang Internet-Draft A. Wang
Intended status: Standards Track China Telecom Intended status: Standards Track China Telecom
Expires: September 8, 2022 Z. Zhang Expires: September 21, 2022 Z. Zhang
Juniper Networks Juniper Networks
H. Chen H. Chen
Futurewei Futurewei
R. Chen R. Chen
ZTE Corporation ZTE Corporation
March 07, 2022 March 20, 2022
Multicast Tree Setup via PCEP Multicast Tree Setup via PCEP
draft-li-pce-multicast-00 draft-li-pce-multicast-01
Abstract Abstract
Multicast forwarding requires per-tree state on certain nodes. Even Multicast forwarding requires per-tree state on certain nodes. Even
with BIER, per-tree state is needed on ingress/egress BIER routers with BIER, per-tree state is needed on ingress/egress BIER routers
(though not needed on transit BIER routers). This documents (though not needed on transit BIER routers). This documents
specifies PCEP protocol to collect tree information (e.g. root, leaf, specifies PCEP protocol to collect tree information (e.g. root, leaf,
constraints) to allow a PCE to calculate a tree, and the procedures constraints) to allow a PCE to calculate a tree, and the procedures
to set up per-tree forwarding state on relevant nodes for various to set up per-tree forwarding state on relevant nodes for various
multicast trees and various replication technologies. multicast trees and various replication technologies.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 September 8, 2022. This Internet-Draft will expire on September 21, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 28 skipping to change at page 2, line 28
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Different Multicast Trees . . . . . . . . . . . . . . . . 4 2.1. Different Multicast Trees . . . . . . . . . . . . . . . . 4
2.1.1. IP Multicast . . . . . . . . . . . . . . . . . . . . 4 2.1.1. IP Multicast . . . . . . . . . . . . . . . . . . . . 4
2.1.2. mLDP/RSVP-TE P2MP Tunnels . . . . . . . . . . . . . . 4 2.1.2. mLDP/RSVP-TE P2MP Tunnels . . . . . . . . . . . . . . 4
2.1.3. SR-P2MP Tunnels . . . . . . . . . . . . . . . . . . . 5 2.1.3. SR-P2MP Tunnels . . . . . . . . . . . . . . . . . . . 5
2.2. Different Replication Technologies . . . . . . . . . . . 5 2.2. Different Replication Technologies . . . . . . . . . . . 5
2.3. Tree Information Discovery . . . . . . . . . . . . . . . 6 2.3. Tree Information Discovery . . . . . . . . . . . . . . . 6
2.3.1. Root node Discovery . . . . . . . . . . . . . . . . . 6 2.3.1. Root node Discovery . . . . . . . . . . . . . . . . . 6
2.3.2. Leaf node Discovery . . . . . . . . . . . . . . . . . 7 2.3.2. Leaf node Discovery . . . . . . . . . . . . . . . . . 7
2.4. Multicast Tree . . . . . . . . . . . . . . . . . . . . . 7 2.4. Multicast Tree . . . . . . . . . . . . . . . . . . . . . 7
2.4.1. mLDP Tree . . . . . . . . . . . . . . . . . . . . . . 7 2.4.1. Labeled Tree . . . . . . . . . . . . . . . . . . . . 8
2.4.2. SR-P2MP Tree . . . . . . . . . . . . . . . . . . . . 8 2.4.2. BIER Tree . . . . . . . . . . . . . . . . . . . . . . 8
2.4.3. BIER Tree . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Multicast Statistics . . . . . . . . . . . . . . . . . . 8 2.5. Multicast Statistics . . . . . . . . . . . . . . . . . . 8
3. PCEP Object Formats . . . . . . . . . . . . . . . . . . . . . 9 3. PCEP Object Formats . . . . . . . . . . . . . . . . . . . . . 9
3.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . 9 3.1.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . 9
3.1.2. PCECC Capability sub-TLV . . . . . . . . . . . . . . 9 3.1.2. PCECC Capability sub-TLV . . . . . . . . . . . . . . 10
3.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 10 3.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 10
3.3. Multicast Source Registration Object . . . . . . . . . . 10 3.3. Multicast Source Registration Object . . . . . . . . . . 10
3.3.1. Multicast Address TLV . . . . . . . . . . . . . . . . 11 3.3.1. Multicast Address TLV . . . . . . . . . . . . . . . . 11
3.3.2. mLDP FEC TLV . . . . . . . . . . . . . . . . . . . . 11 3.3.2. mLDP FEC TLV . . . . . . . . . . . . . . . . . . . . 12
3.3.3. VPN Information TLV . . . . . . . . . . . . . . . . . 12 3.3.3. VPN Information TLV . . . . . . . . . . . . . . . . . 12
3.4. Multicast Receiver Information Object . . . . . . . . . . 12 3.4. Multicast Receiver Information Object . . . . . . . . . . 12
3.4.1. BFR Information TLV . . . . . . . . . . . . . . . . . 13 3.4.1. BFR Information TLV . . . . . . . . . . . . . . . . . 13
3.5. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 13 3.5. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 14
3.5.1. MPLS Tree Label TLV . . . . . . . . . . . . . . . . . 14 3.5.1. Tree Label TLV . . . . . . . . . . . . . . . . . . . 14
3.6. Tree Forwarding State Synchronization Object . . . . . . 14 3.5.2. VPN Forwarding Identifier TLV . . . . . . . . . . . . 14
3.6. Tree Forwarding State Synchronization Object . . . . . . 15
3.6.1. BIER Attribute TLV . . . . . . . . . . . . . . . . . 15 3.6.1. BIER Attribute TLV . . . . . . . . . . . . . . . . . 15
3.7. Multicast Receiver Statistics Object . . . . . . . . . . 15 3.7. Multicast Receiver Statistics Object . . . . . . . . . . 16
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. PCRpt message . . . . . . . . . . . . . . . . . . . . . . 16 4.1. PCRpt message . . . . . . . . . . . . . . . . . . . . . . 16
4.2. PCInitiate message . . . . . . . . . . . . . . . . . . . 16 4.2. PCInitiate message . . . . . . . . . . . . . . . . . . . 17
4.3. PCUpd message . . . . . . . . . . . . . . . . . . . . . . 17 4.3. PCUpd message . . . . . . . . . . . . . . . . . . . . . . 17
5. Example Workflow . . . . . . . . . . . . . . . . . . . . . . 17 5. Example Workflow . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Multicast Tree Discovery . . . . . . . . . . . . . . . . 17 5.1. Multicast Tree Discovery . . . . . . . . . . . . . . . . 18
5.2. Multicast Tree Path Establishment and Update . . . . . . 18 5.2. Multicast Tree Path Establishment and Update . . . . . . 18
5.2.1. mLDP Tree and SR-P2MP Tree . . . . . . . . . . . . . 18 5.2.1. Labeled Tree . . . . . . . . . . . . . . . . . . . . 19
5.2.2. BIER Tree . . . . . . . . . . . . . . . . . . . . . . 18 5.2.2. BIER Tree . . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5.3. Multicast Statistics Synchronization . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7.1. MULTICAST-STATE-CAPABILITY . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7.2. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 20 7.1. MULTICAST-STATE-CAPABILITY . . . . . . . . . . . . . . . 22
7.3. New Objects . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 22
7.4. New TLVs . . . . . . . . . . . . . . . . . . . . . . . . 21 7.3. New Objects . . . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 7.4. New TLVs . . . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Currently, multicast management information is mainly signaled by PIM Currently, multicast management information is mainly signaled by PIM
[RFC2362], mLDP [RFC6388] or BGP [RFC6514]. The trees/tunnels are [RFC2362], mLDP [RFC6388] or BGP [RFC6514]. The trees/tunnels are
set up using the "receiver-initiated join" technique of PIM/mLDP, hop set up using the "receiver-initiated join" technique of PIM/mLDP, hop
by hop from downstream routers towards the root. The BGP messages by hop from downstream routers towards the root. The BGP messages
are either sent hop by hop between downstream routers and their are either sent hop by hop between downstream routers and their
upstream neighbors, or can be reflected by Route Reflectors (RRs). upstream neighbors, or can be reflected by Route Reflectors (RRs).
The signaling is the interaction between routers and cannot be The signaling is the interaction between routers and cannot be
skipping to change at page 7, line 33 skipping to change at page 7, line 33
If the receivers locate in different VPN domains, the VPN information If the receivers locate in different VPN domains, the VPN information
associated with the multicast source and multicast destination should associated with the multicast source and multicast destination should
also be reported by the LHR and FHR. The VPN information reported by also be reported by the LHR and FHR. The VPN information reported by
LHRs SHOULD be consistent. LHRs SHOULD be consistent.
2.4. Multicast Tree 2.4. Multicast Tree
The multicast trees are established with the FHRs of the multicast The multicast trees are established with the FHRs of the multicast
source as the root of the multicast trees. According to different source as the root of the multicast trees. According to different
multicast technologies, the types of multicast trees include mLDP multicast technologies, the types of multicast trees include labeled
tree, SR-P2MP tree and BIER tree. Different multicast trees tree and BIER tree. Different multicast trees correspond to
correspond to different processing. This section describes the state different processing. This section describes the state update of
update of different multicast operations. different multicast operations.
No matter which forwarding technology is used, there is a case that No matter which forwarding technology is used, there is a case that
local multicast receivers directly access to FHRs. In this case, local multicast receivers directly access to FHRs. In this case,
FHRs need to forward multicast data for local receivers in the way of FHRs need to forward multicast data for local receivers in the way of
native IP without other control information. native IP without other control information.
2.4.1. mLDP Tree In some scenarios, the egresses node needs a VPN forwarding
identifier to determine which VRF to forward the packet to. The
allocation of VPN forwarding identifier is performed by controller.
The scenario of egress assigning VPN tags has not been considered
yet. Controller sends the VPN forwarding identifier to ingress and
instructs ingress to encapsulate it. The VPN Forwarding Label may be
MPLS label or SRv6 segment.
For a multicast tree, each node needs a tree label to identify a 2.4.1. Labeled Tree
multicast tree. There are three options for tree label assignment:
For a Labeled multicast tree, whether the forwarding is based on
native IP, mLDP or SR-P2MP tunnel, each node needs a tree label to
identify a multicast tree. There are three options for tree label
assignment:
o From each router's SRLB that the controller learns o From each router's SRLB that the controller learns
o From the common SRGB that the controller learns o From the common SRGB that the controller learns
o From the controller's local label space o From the controller's local label space
The detailed instruction is as per The detailed instruction is as per
[I-D.ietf-bess-bgp-multicast-controller]. Section 3.5.1 defines a [I-D.ietf-bess-bgp-multicast-controller]. Section 3.5.1 defines two
new TLV to extend the CCI Object-Type support the tree label. new TLVs to extend the CCI Object-Type support the tree label and VPN
Label.
The operations for initiating multicast tree LSPs and The operations for initiating multicast tree LSPs and
downloadinglabels are consistent with [I-D.ietf-pce-sr-p2mp-policy]. downloadinglabels are consistent with [I-D.ietf-pce-sr-p2mp-policy].
2.4.2. SR-P2MP Tree 2.4.2. BIER Tree
The processing of PCE-based SR P2MP policy delivery and P2MP path
establishment has been defined in [I-D.ietf-pce-sr-p2mp-policy]. For
the calculated multicast tree, SR P2MP multicast tree update can
refer to that document.
2.4.3. BIER Tree
Different from other forwarding technologies, BIER does not need the Different from other forwarding technologies, BIER does not need the
transit nodes to maintain the multicast state, and only needs to transit nodes to maintain the multicast state, and only needs to
forward and encapsulate the packets according to the BitString and forward and encapsulate the packets according to the BitString and
BIFT. BIFT information can be learned by IGP. For each node of a BIFT. BIFT information can be learned by IGP. For each node of a
sub-domain, the BIFT can be configured locally or allocated by BGP sub-domain, the BIFT can be configured locally or allocated by BGP
controller or PCE. Allocation by PCE is as per controller or PCE. Allocation by PCE is as per
[I-D.chen-pce-pcep-extension-pce-controller-bier]. [I-D.chen-pce-pcep-extension-pce-controller-bier].
After receiving the BFR information reported from LHRs, the After receiving the BFR information reported from LHRs, the
controller combine BFR information of LHRs into a BitString to guide controller combine BFR information of LHRs into a BitString to guide
multicast data forwarding. multicast data forwarding.
The controller (PCE) sends the BitString to the FHR via PCInitiate or The controller (PCE) sends the BitString to the FHR via PCInitiate or
PCUpd message carrying Tree Forwarding State Synchronization (TFSS) PCUpd message carrying Tree Forwarding State Synchronization (TFSS)
object defined in Section 3.6 to inform the FHR to forward multicast object defined in Section 3.6 to inform the FHR to forward multicast
data for a specific multicast tree according to the BitString, and data for a specific multicast tree according to the BitString, and
the tree identifier is (*, g) or (s, g) tuple. the tree identifier is (*, g) or (s, g) tuple. Controller also needs
to inform FHR to encapsulate VPN forwarding identifier so that LHRs
can forward multicast data to specific VRF accordingly.
2.5. Multicast Statistics 2.5. Multicast Statistics
Multicast statistics are helpful for multicast service analysis and Multicast statistics are helpful for multicast service analysis and
business development. This section describes how to collect business development. This section describes how to collect
statistics about multicast users. statistics about multicast users.
For each LHR, the statistics consist of two parts, one is the number For each LHR, the statistics consist of two parts, one is the number
of local users in the its managed domain, and the other is the number of local users in the its managed domain, and the other is the number
of other managed domains. The sum of these two parts is the number of other managed domains. The sum of these two parts is the number
skipping to change at page 10, line 49 skipping to change at page 11, line 12
A (Authentication flag, 1 bit): The A flag set to 1 indicates success A (Authentication flag, 1 bit): The A flag set to 1 indicates success
of registration. The A flag set to 0 indicates failure of of registration. The A flag set to 0 indicates failure of
registration or revocation of registration. If there is no registration or revocation of registration. If there is no
authentication information, A flag SHOULD also be set to 0. authentication information, A flag SHOULD also be set to 0.
Auxiliary Length (1 Octet): indicates the length of Auxiliary Data. Auxiliary Length (1 Octet): indicates the length of Auxiliary Data.
Auxiliary Data (Variable length): contains functional data such as Auxiliary Data (Variable length): contains functional data such as
authentication information. authentication information.
MSR object MAY include Multicast Address TLV, mLDP FEC TLV, SR-IPV4- MSR object MAY include Multicast Address TLV, mLDP FEC TLV, P2MP SR
P2MP-POLICY-ID TLV, SR-IPV6-P2MP-POLICY-ID TLV, and VPN Information Policy Association Group Policy Identifiers TLV, and VPN Information
TLV. SR-IPV4-P2MP-POLICY-ID TLV and SR-IPV6-P2MP-POLICY-ID TLV are TLV. P2MP SR Policy Association Group Policy Identifiers TLV are
defined in [I-D.ietf-pce-sr-p2mp-policy]. MSR object carries defined in [I-D.ietf-pce-sr-p2mp-policy]. MSR object carries
different TLVs depending on the multicast tree. different TLVs depending on the multicast tree.
3.3.1. Multicast Address TLV 3.3.1. Multicast Address TLV
In IP multicast scenarios, Multicast Address TLV SHOULD be included. In IP multicast scenarios, Multicast Address TLV SHOULD be included.
The format of the Multicast Address TLV is: The format of the Multicast Address TLV is:
0 1 2 3 0 1 2 3
skipping to change at page 13, line 13 skipping to change at page 13, line 22
Figure 5: MRI Object Body Format Figure 5: MRI Object Body Format
B(BIER multicast flag, 1 bit): The B flag set to 1 indicates that B(BIER multicast flag, 1 bit): The B flag set to 1 indicates that
multicast protocol is BIER. If the B flag set to 1, MRI object multicast protocol is BIER. If the B flag set to 1, MRI object
SHOULD include BFR information TLV defined in Section 3.4.1. SHOULD include BFR information TLV defined in Section 3.4.1.
S(Subscribe flag, 1 bit): The S flag set to 1 indicates that PCC S(Subscribe flag, 1 bit): The S flag set to 1 indicates that PCC
delivers the message requesting to join PCE. The S flag set to 0 delivers the message requesting to join PCE. The S flag set to 0
indicates that PCC delivers the message requesting to leave to PCE. indicates that PCC delivers the message requesting to leave to PCE.
MRI object MAY include Multicast Address TLV, mLDP FEC TLV, SR-IPV4- MRI object MAY include Multicast Address TLV, mLDP FEC TLV, P2MP SR
P2MP-POLICY-ID TLV, SR-IPV6-P2MP-POLICY-ID TLV, VPN Information TLV, Policy Association Group Policy Identifiers TLV, VPN Information TLV,
and BFR information TLV. and BFR information TLV.
3.4.1. BFR Information TLV 3.4.1. BFR Information TLV
BFR Information TLV is used to report router location information in BFR Information TLV is used to report router location information in
the BIER domain. The format of the BFR Information TLV is: the BIER domain. The format of the BFR Information TLV is:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 50 skipping to change at page 14, line 15
3.5. CCI Object 3.5. CCI Object
The CCI object [RFC9050] is used by the PCE to specify the forwarding The CCI object [RFC9050] is used by the PCE to specify the forwarding
instructions to the PCC and MAY be carried within a PCInitiate or instructions to the PCC and MAY be carried within a PCInitiate or
PCRpt message for control information download/report. PCRpt message for control information download/report.
The CCI Object Type 1 for MPLS Label is defined in [RFC9050], which The CCI Object Type 1 for MPLS Label is defined in [RFC9050], which
is used for the P2MP LSPs as well. For mLDP multicast trees, in is used for the P2MP LSPs as well. For mLDP multicast trees, in
addition to forwarding labels, corresponding tree labels or label addition to forwarding labels, corresponding tree labels or label
stacks are required. Therefore, a new TLV is needed to carry tree stacks are required. Therefore, a new TLV is needed to carry tree
labels or label stacks. labels or label stacks. In addition, in order to meet the needs of
VPN scenarios, a new TLV with VPN forwarding Identifier is also
defined.
3.5.1. MPLS Tree Label TLV 3.5.1. Tree Label TLV
The format of MPLS Tree Label TLV is: The format of Tree Label TLV is:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD9 | Length | | Type = TBD9 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MPLS Tree Label stack ~ ~ Tree Label stack ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: MPLS Tree Label TLV Format Figure 7: Tree Label TLV Format
MPLS Tree Label stack (Variable length): contains tree labels used to Tree Label stack (Variable length): contains tree labels used to
identify multicast trees. There are three application scenarios, as identify multicast trees. There are three application scenarios, as
per [I-D.ietf-bess-bgp-multicast-controller]. per [I-D.ietf-bess-bgp-multicast-controller].
3.5.2. VPN Forwarding Identifier TLV
The format of VPN Forwarding Identifier TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD10 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VPN Forwarding Identifier ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: VPN Forwarding Identifier TLV Format
VPN Forwarding Identifier (Variable length): contains MPLS label or
IPv6 Segment Identifier with 16 Octets.
3.6. Tree Forwarding State Synchronization Object 3.6. Tree Forwarding State Synchronization Object
The TFSS object is optional and SHOULD contain the forwarding state The TFSS object is optional and SHOULD contain the forwarding state
of control plane that the tree node needs to synchronize. The TFSS of control plane that the tree node needs to synchronize. The TFSS
object SHOULD be carried within a PCInitiate or PCUpd message sent by object SHOULD be carried within a PCInitiate or PCUpd message sent by
PCE to PCC, or a PCRpt message sent by PCC to PCE for response. PCE to PCC, or a PCRpt message sent by PCC to PCE for response.
TFSS Object-Class is TBD10. TFSS Object-Type is 1. The format of TFSS Object-Class is TBD11. TFSS Object-Type is 1. The format of
the TFSS object body is: the TFSS object body is:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | flags |F| | Reserved | flags |F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~ ~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: TFSS Object Body Format Figure 9: TFSS Object Body Format
F (Forwarding flag, 1 bit): The F flag set to 1 indicates that the F (Forwarding flag, 1 bit): The F flag set to 1 indicates that the
node MAY start forwarding multicast packets. The F flag set to 0 node MAY start forwarding multicast packets. The F flag set to 0
indicates that the node SHOULD stop forwarding multicast packets. indicates that the node SHOULD stop forwarding multicast packets.
TFSS object MAY include Multicast Address TLV, VPN Information TLV, TFSS object MAY include Multicast Address TLV, VPN Forwarding
and BIER Attribute TLV. When TT=1, BIER Attribute TLV SHOULD be Identifier TLV, and BIER Attribute TLV. When TT=1, BIER Attribute
included. TLV SHOULD be included.
3.6.1. BIER Attribute TLV 3.6.1. BIER Attribute TLV
BIER Attribute TLV is used to instruct the FHR to forward multicast BIER Attribute TLV is used to instruct the FHR to forward multicast
packets to the users according to the BitString specified by the packets to the users according to the BitString specified by the
controller. The format of BIER Attribute TLV is: controller. The format of BIER Attribute TLV is:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD11 | Length | | Type = TBD12 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subdomain-id | SI | BSL ~ BitString ~ | Subdomain-id | SI | BSL ~ BitString ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: BIER Attribute TLV Format Figure 10: BIER Attribute TLV Format
Subdomain-id (1 Octet): Unique value identifying the BIER subdomain. Subdomain-id (1 Octet): Unique value identifying the BIER subdomain.
SI (Set Identifier, 1 Octet): encoding the Set Identifier used in the SI (Set Identifier, 1 Octet): encoding the Set Identifier used in the
encapsulation for this BIER subdomain for this BitString length. encapsulation for this BIER subdomain for this BitString length.
BSL (BitString Length, 4 bits): encodes the length in bits of the BSL (BitString Length, 4 bits): encodes the length in bits of the
BitString as per [RFC8296], the maximum length of the BitString is 7, BitString as per [RFC8296], the maximum length of the BitString is 7,
it indicates the length of BitString is 4096. It is used to refer to it indicates the length of BitString is 4096. It is used to refer to
the number of bits in the BitString. the number of bits in the BitString.
skipping to change at page 15, line 40 skipping to change at page 16, line 20
BitString(Variable length): indicates the path of multicast data BitString(Variable length): indicates the path of multicast data
packets forwarding for headend. packets forwarding for headend.
3.7. Multicast Receiver Statistics Object 3.7. Multicast Receiver Statistics Object
The MRS object is optional and used to inform PCE of the number of The MRS object is optional and used to inform PCE of the number of
receivers. The MRS object SHOULD be carried within a PCRpt or a receivers. The MRS object SHOULD be carried within a PCRpt or a
PCUpd message for synchronize receiver information periodically, or PCUpd message for synchronize receiver information periodically, or
PCRpt message for the leaving of receivers. PCRpt message for the leaving of receivers.
MRS Object-Class is TBD12. MRS Object-Type is 1. The format of the MRS Object-Class is TBD13. MRS Object-Type is 1. The format of the
MRS object body is: MRS object body is:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Length | Reserved | | Number Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Statistics | | Multicast Statistics |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~ ~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: MRS Object Body Format Figure 11: MRS Object Body Format
Number Length (2 Octets): indicates the length of receiver number. Number Length (2 Octets): indicates the length of receiver number.
Multicast Statistics (4 Octets): indicates the statistics information Multicast Statistics (4 Octets): indicates the statistics information
for a particular multicast tree of a controller or a LHR. for a particular multicast tree of a controller or a LHR.
MRS object MAY include Multicast Address TLV, mLDP FEC TLV, SR-IPV4- MRS object MAY include Multicast Address TLV, mLDP FEC TLV, P2MP SR
P2MP-POLICY-ID TLV, and SR-IPV6-P2MP-POLICY-ID TLV. Policy Association Group Policy Identifiers TLV.
4. Message Formats 4. Message Formats
4.1. PCRpt message 4.1. PCRpt message
The definition of the PCRpt message from [RFC8231] and [RFC9050] is The definition of the PCRpt message from [RFC8231] and [RFC9050] is
extended to optionally include MSR object, MRI object, TFSS object, extended to optionally include MSR object, MRI object, TFSS object,
and MRS object after the path object. The encoding will become: and MRS object after the path object. The encoding will become:
<PCRpt Message> ::= <Common Header> <PCRpt Message> ::= <Common Header>
skipping to change at page 18, line 4 skipping to change at page 18, line 25
[<TFSS>] [<TFSS>]
[<MRS>] [<MRS>]
Where: Where:
<path> is as per [RFC8231] and the LSP and SRP object are <path> is as per [RFC8231] and the LSP and SRP object are
also defined in [RFC8231]. also defined in [RFC8231].
5. Example Workflow 5. Example Workflow
5.1. Multicast Tree Discovery 5.1. Multicast Tree Discovery
+-------+ +-------+ +-------+ +-------+
|PCC | | PCE | |PCC | | PCE |
|ingress| +-------+ |ingress| +-------+
+-----| | | +-----| | |
|PCC +-------+ | |PCC +-------+ |
|transit| | | |transit| | |
+------| | | | +------| | | |
|PCC +-------+ | | |PCC +-------+ | |
|egress | | | | |egress | | | |
+-------+ | | | +-------+ | | |
| | |-----PCRpt,PLSP-ID=1,D=1------>|Source Registration | | |-----PCRpt,PLSP-ID=1,D=1------>|Source Registration
| | | MSR Object(R=1) |(Root Discovery) | | | MSR Object(R=1) |(Root Discovery)
| | | | | | | |
| | |<----PCUpd,PLSP-ID=1-----------|Source Registration | | |<----PCUpd,PLSP-ID=1-----------|Source Registration
| | | MSR Object(R=1) |Recognition | | | MSR Object(R=1) |Confirmation
| | | | | | | |
|------------------PCRpt,PLSP-ID=0---- ----->|Receiver Report |------------------PCRpt,PLSP-ID=0---------->|Receiver Report
| | | MRI Objetc(S=1) |(Leaf Discovery) | | | MRI Object(S=1) |(Leaf Discovery)
| | | | | | | |
Figure 11: Workflow of Multicast Tree Discovery Figure 11: Workflow of Multicast Tree Discovery
5.2. Multicast Tree Path Establishment and Update 5.2. Multicast Tree Path Establishment and Update
5.2.1. Labeled Tree
5.2.1. mLDP Tree and SR-P2MP Tree The workflow of Labeled Tree are as per
The workflow of mLDP Tree and SR-P2MP Tree are as per
[I-D.ietf-pce-sr-p2mp-policy]. [I-D.ietf-pce-sr-p2mp-policy].
5.2.2. BIER Tree 5.2.2. BIER Tree
+-------+ +-------+ +-------+ +-------+
|PCC | | PCE | |PCC | | PCE |
|ingress| +-------+ |ingress| +-------+
+------| | | +------| | |
| +-------+ | | +-------+ |
| transit| | | | transit| | |
+------| | | | +------| | | |
| +--------+ | | | +--------+ | |
|egress | | | | |egress | | | |
+--------+ | | | +--------+ | | |
|<-------------------PCInitiate,PLSP-ID=1-------|Tree State
| | | TFSS Object |Setup
| | | VPN Forwarding Identifier |
| | | |
|--------------------PCRpt,PLSP-ID=1----------->|Tree State
| | | |Confirmation
| | | |
| | |<-----PCInitiate,PLSP-ID=1-------|Tree State | | |<-----PCInitiate,PLSP-ID=1-------|Tree State
| | | TFSS Objetc (F=1,TT=1) |Setup | | | TFSS Object (F=1,TT=1) |Setup
| | | VPN Forwarding Identifier |
| | | | | | | |
| | |------PCRpt,PLSP-ID=1----------->|Tree State | | |------PCRpt,PLSP-ID=1----------->|Tree State
| | | |Recognition | | | |Confirmation
| | | |
| | | |
| | | | | | | |
|--------------------PCRpt,PLSP-ID=0----------->|Receiver Report |--------------------PCRpt,PLSP-ID=0----------->|Receiver Report
| | | MRI Objetc(S=1/S=0) |(Leaf Discovery) | | | MRI Object(S=1/S=0) |(Leaf Discovery)
| | | |
|<-------------------PCInitiate,PLSP-ID=1-------|Tree State
| | | TFSS Object |Update
| | | VPN Forwarding Identifier |
| | | |
|--------------------PCRpt,PLSP-ID=1----------->|Tree State
| | | |Confirmation
| | | | | | | |
| | |<-----PCUpd,PLSP-ID=1------------|Tree State | | |<-----PCUpd,PLSP-ID=1------------|Tree State
| | | TFSS Objetc (F=1,TT=1) |Update | | | TFSS Object (F=1,TT=1) |Update
| | | | | | | |
| | |------PCRpt,PLSP-ID=1----------->|Tree State | | |------PCRpt,PLSP-ID=1----------->|Tree State
| | | |Recognition | | | |Confirmation
| | | | | | | |
Figure 12: Workflow of Multicast Tree Discovery Figure 12: Workflow of BIER Tree Setup/Update
In the previous multicast tree discovery process, ingress has In the previous multicast tree discovery process, ingress has
delegated the PCE to calculate the multicast path. Therefore, during delegated the PCE to calculate the multicast path. Therefore, during
the establishment of the multicast tree, PCE informs the ingress to the establishment of the multicast tree, PCE informs the ingress to
forward multicast data for (S,G)/(*,G) via PCInitiate message forward multicast data for (S,G)/(*,G) via PCInitiate message
carrying TFSS object according to the delegation. The PLSP-ID is the carrying TFSS object according to the delegation. The PLSP-ID is the
value specified by the ingress. value specified by the ingress. PCE also sends VPN forwarding
identifier to ingress and egresses, so that multicast packets can be
forwarded to specified VPN.
Ingress then updates the tree state and responds to the PCE. At this Ingress then updates the tree state and responds to the PCE. At this
point, the BIER tree is formally established and the ingress starts point, the BIER tree is formally established and the ingress starts
forwarding for the multicast according to the BitString specified by forwarding for the multicast according to the BitString specified by
PCE. PCE.
If the topology of the BIER tree changes, the corresponding egresses If the topology of the BIER tree changes, the corresponding egresses
will send PCRpt messages carring MRI object to PCE to inform PCE of will send PCRpt messages carring MRI object to PCE to inform PCE of
their changes. their changes. PCE needs to send VPN forwarding identifier to these
egresses.
The PCE updates the BitStrig based on changes of the egresses and The PCE updates the BitStrig based on changes of the egresses and
informs the ingress to update. State update process is similar to informs the ingress to update. State update process is similar to
state setup process, except for the type of message sent by the PCE. state setup process, except for the type of message sent by the PCE.
5.3. Multicast Statistics Synchronization
+-------+ +-------+
|PCC | | PCE |
|ingress| +-------+
+-----| | |
|PCC +-------+ |
|transit| | |
+------| | | |
|PCC +-------+ | |
|egress | | | |
+-------+ | | |
| | | |
|------------------PCRpt,PLSP-ID=0---------->| Statistics
| | | MRS Object | Report
| | |case1: Periodic Synchronization|
| | | case2: Change Synchronization |
| | | |
| | | |
| | |<----PCUpd,PLSP-ID=0-----------| Statistics
| | | MRS Object | Feedback
| | | Periodic Synchronization |
| | | |
Figure 13: Workflow of Multicast Statistics Synchronization
6. Security Considerations 6. Security Considerations
To be added. To be added.
7. IANA Considerations 7. IANA Considerations
7.1. MULTICAST-STATE-CAPABILITY 7.1. MULTICAST-STATE-CAPABILITY
IANA is requested to allocate a new code point within registry IANA is requested to allocate a new code point within registry
"STATEFUL-PCE-CAPABILITY TLV Flag Field" under "Path Computation "STATEFUL-PCE-CAPABILITY TLV Flag Field" under "Path Computation
skipping to change at page 20, line 43 skipping to change at page 22, line 43
7.3. New Objects 7.3. New Objects
IANA is requested to allocate the following Object-Class Values in IANA is requested to allocate the following Object-Class Values in
the "PCEP Objects" sub-registry under the "Path Computation Element the "PCEP Objects" sub-registry under the "Path Computation Element
Protocol (PCEP) Numbers" registry: Protocol (PCEP) Numbers" registry:
Object-Class Value Description Reference Object-Class Value Description Reference
------------------ ------------------------------- --------------- ------------------ ------------------------------- ---------------
TBD3 Multicast Source Registration This document TBD3 Multicast Source Registration This document
TBD7 Multicast Receiver Information This document TBD7 Multicast Receiver Information This document
TBD10 Tree Forwarding State Synchronization This document TBD11 Tree Forwarding State Synchronization This document
TBD12 Multicast Receiver Statistics This document TBD13 Multicast Receiver Statistics This document
IANA is requested to allocate the following Object-Type Value of CCI IANA is requested to allocate the following Object-Type Value of CCI
object in the "PCEP Objects" sub-registry under the "Path Computation object in the "PCEP Objects" sub-registry under the "Path Computation
Element Protocol (PCEP) Numbers" registry: Element Protocol (PCEP) Numbers" registry:
7.4. New TLVs 7.4. New TLVs
IANA is requested to allocate the following TLVs: IANA is requested to allocate the following TLVs:
Type Description Reference Type Description Reference
------------------ ------------------------------- --------------- ------------------ ------------------------------- ---------------
TBD4 Multicast Source Address This document TBD4 Multicast Source Address This document
TBD5 mLDP FEC This document TBD5 mLDP FEC This document
TBD6 VPN Information This document TBD6 VPN Information This document
TBD8 BFR Information This document TBD8 BFR Information This document
TBD9 MPLS Tree Label This document TBD9 Tree Label This document
TBD10 BIER Attribute This document TBD10 VPN Forwarding Identifier TLV This document
TBD12 BIER Attribute This document
8. Acknowledgements 8. Acknowledgements
The author thanks ... for their review and comments. The author thanks ... for their review and comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-pce-sr-p2mp-policy] [I-D.ietf-pce-sr-p2mp-policy]
skipping to change at page 23, line 26 skipping to change at page 25, line 32
[RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path [RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Procedures and Extensions for Using the PCE as a Central Procedures and Extensions for Using the PCE as a Central
Controller (PCECC) of LSPs", RFC 9050, Controller (PCECC) of LSPs", RFC 9050,
DOI 10.17487/RFC9050, July 2021, DOI 10.17487/RFC9050, July 2021,
<https://www.rfc-editor.org/info/rfc9050>. <https://www.rfc-editor.org/info/rfc9050>.
9.2. Informative References 9.2. Informative References
[I-D.chen-pce-pcep-extension-pce-controller-bier] [I-D.chen-pce-pcep-extension-pce-controller-bier]
Chen, R. and B. Xu, "PCEP Procedures and Protocol Chen, R., Xu, B., Chen, H., and A. Wang, "PCEP Procedures
Extensions for Using PCE as a Central Controller (PCECC) and Protocol Extensions for Using PCE as a Central
of BIER", draft-chen-pce-pcep-extension-pce-controller- Controller (PCECC) of BIER", draft-chen-pce-pcep-
bier-02 (work in progress), December 2021. extension-pce-controller-bier-03 (work in progress), March
2022.
[I-D.dhody-pce-pcep-extension-pce-controller-p2mp] [I-D.dhody-pce-pcep-extension-pce-controller-p2mp]
Li, Z., Peng, S., Geng, X., and M. S. Negi, "Path Li, Z., Peng, S., Geng, X., and M. S. Negi, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Procedures and Extensions for Using the PCE as a Central Procedures and Extensions for Using the PCE as a Central
Controller (PCECC) of point-to-multipoint (P2MP) LSPs", Controller (PCECC) of point-to-multipoint (P2MP) LSPs",
draft-dhody-pce-pcep-extension-pce-controller-p2mp-08 draft-dhody-pce-pcep-extension-pce-controller-p2mp-08
(work in progress), March 2022. (work in progress), March 2022.
[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-07 (work in progress), July bess-bgp-multicast-controller-07 (work in progress), July
2021. 2021.
[I-D.ietf-pim-sr-p2mp-policy] [I-D.ietf-pim-sr-p2mp-policy]
(editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H.,
and Z. Zhang, "Segment Routing Point-to-Multipoint and Z. Zhang, "Segment Routing Point-to-Multipoint
Policy", draft-ietf-pim-sr-p2mp-policy-03 (work in Policy", draft-ietf-pim-sr-p2mp-policy-04 (work in
progress), August 2021. progress), March 2022.
[I-D.ietf-spring-sr-replication-segment] [I-D.ietf-spring-sr-replication-segment]
(editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H.,
and Z. Zhang, "SR Replication Segment for Multi-point and Z. Zhang, "SR Replication Segment for Multi-point
Service Delivery", draft-ietf-spring-sr-replication- Service Delivery", draft-ietf-spring-sr-replication-
segment-06 (work in progress), October 2021. segment-07 (work in progress), March 2022.
[I-D.zzhang-mvpn-evpn-controller] [I-D.zzhang-mvpn-evpn-controller]
Zhang, Z., Parekh, R., Zhang, Z., and H. Bidgoli, "MVPN Zhang, Z., Parekh, R., Zhang, Z., and H. Bidgoli, "MVPN
and EVPN BUM Signaling with Controllers", draft-zzhang- and EVPN BUM Signaling with Controllers", draft-zzhang-
mvpn-evpn-controller-01 (work in progress), October 2021. mvpn-evpn-controller-01 (work in progress), October 2021.
Authors' Addresses Authors' Addresses
Huanan Li Huanan Li
China Telecom China Telecom
 End of changes. 56 change blocks. 
94 lines changed or deleted 167 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/