draft-ietf-bess-bgp-multicast-controller-11.txt   draft-ietf-bess-bgp-multicast-controller-13.txt 
BESS Z. Zhang BESS Z. Zhang
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track R. Raszuk Intended status: Standards Track R. Raszuk
Expires: 22 February 2024 Arrcus Expires: 2 January 2025 Arrcus
D. Pacella D. Pacella
Verizon Verizon
A. Gulko A. Gulko
Edward Jones Wealth Management Edward Jones Wealth Management
21 August 2023 1 July 2024
Controller Based BGP Multicast Signaling Controller Based BGP Multicast Signaling
draft-ietf-bess-bgp-multicast-controller-11 draft-ietf-bess-bgp-multicast-controller-13
Abstract Abstract
This document specifies a way that one or more centralized This document specifies a way that one or more centralized
controllers can use BGP to set up multicast distribution trees controllers can use BGP to set up multicast distribution trees
(identified by either IP source/destination address pair, or mLDP (identified by either IP source/destination address pair, or mLDP
FEC) in a network. Since the controllers calculate the trees, they FEC) in a network. Since the controllers calculate the trees, they
can use sophisticated algorithms and constraints to achieve traffic can use sophisticated algorithms and constraints to achieve traffic
engineering. The controllers directly signal dynamic replication engineering. The controllers directly signal dynamic replication
state to tree nodes, leading to very simple multicast control plane state to tree nodes, leading to very simple multicast control plane
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 22 February 2024. This Internet-Draft will expire on 2 January 2025.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Resilience . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Introduction . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Resilience . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Label Allocation . . . . . . . . . . . . . . . . . . . . 6 1.4. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1. Using a Common per-tree Label for All Routers . . . . 7 1.5. Label Allocation . . . . . . . . . . . . . . . . . . . . 7
1.4.2. Upstream-assignment from Controller's Local Label 1.5.1. Using a Common per-tree Label for All Routers . . . . 8
Space . . . . . . . . . . . . . . . . . . . . . . . . 8 1.5.2. Upstream-assignment from Controller's Local Label
1.5. Determining Root/Leaves . . . . . . . . . . . . . . . . . 9 Space . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.1. PIM-SSM/Bidir or mLDP . . . . . . . . . . . . . . . . 9 1.6. Determining Root/Leaves . . . . . . . . . . . . . . . . . 10
1.5.2. PIM ASM . . . . . . . . . . . . . . . . . . . . . . . 9 1.6.1. PIM-SSM/Bidir or mLDP . . . . . . . . . . . . . . . . 10
1.6. Multiple Domains . . . . . . . . . . . . . . . . . . . . 10 1.6.2. PIM ASM . . . . . . . . . . . . . . . . . . . . . . . 10
2. Alternative to BGP-MVPN . . . . . . . . . . . . . . . . . . . 11 1.7. Multiple Domains . . . . . . . . . . . . . . . . . . . . 11
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 12 2. Alternative to BGP-MVPN . . . . . . . . . . . . . . . . . . . 12
3.1. Enhancements to TEA . . . . . . . . . . . . . . . . . . . 13 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1. Any-Encapsulation Tunnel . . . . . . . . . . . . . . 13 3.1. Enhancements to TEA . . . . . . . . . . . . . . . . . . . 14
3.1.2. Load-balancing Tunnel . . . . . . . . . . . . . . . . 13 3.1.1. Any-Encapsulation Tunnel . . . . . . . . . . . . . . 14
3.1.3. Segment List Tunnel . . . . . . . . . . . . . . . . . 14 3.1.2. Load-balancing Tunnel . . . . . . . . . . . . . . . . 14
3.1.4. Receiving MPLS Label Stack . . . . . . . . . . . . . 14 3.1.3. Segment List Tunnel . . . . . . . . . . . . . . . . . 15
3.1.5. RPF Sub-TLV . . . . . . . . . . . . . . . . . . . . . 14 3.1.4. Receiving MPLS Label Stack . . . . . . . . . . . . . 15
3.1.6. Tree Label Stack sub-TLV . . . . . . . . . . . . . . 15 3.1.5. RPF Sub-TLV . . . . . . . . . . . . . . . . . . . . . 15
3.1.7. Backup Tunnel sub-TLV . . . . . . . . . . . . . . . . 15 3.1.6. Tree Label Stack sub-TLV . . . . . . . . . . . . . . 16
3.2. Context Label TLV in BGP-LS Node Attribute . . . . . . . 16 3.1.7. Backup Tunnel sub-TLV . . . . . . . . . . . . . . . . 16
3.3. MCAST Extended Community . . . . . . . . . . . . . . . . 17 3.2. Context Label TLV in BGP-LS Node Attribute . . . . . . . 17
3.4. Replication State Route Type . . . . . . . . . . . . . . 17 3.3. MCAST Extended Community . . . . . . . . . . . . . . . . 18
3.4. Replication State Route Type . . . . . . . . . . . . . . 18
3.5. Replication State Route with Label Stack for Tree 3.5. Replication State Route with Label Stack for Tree
Identification . . . . . . . . . . . . . . . . . . . . . 18 Identification . . . . . . . . . . . . . . . . . . . . . 19
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Label Space and Tree Label Allocation . . . . . . . . . . 19 4.1. Label Space and Tree Label Allocation . . . . . . . . . . 20
4.2. Advertising Replication State Routes . . . . . . . . . . 20 4.2. Advertising Replication State Routes . . . . . . . . . . 21
4.3. Receiving Replication State Routes . . . . . . . . . . . 22 4.3. Receiving Replication State Routes . . . . . . . . . . . 23
4.3.1. Compiling Replication Branches . . . . . . . . . . . 23 4.3.1. Compiling Replication Branches . . . . . . . . . . . 24
4.3.2. Installing Forwarding State . . . . . . . . . . . . . 24 4.3.2. Installing Forwarding State . . . . . . . . . . . . . 25
4.3.3. Acknowledgement to Controller . . . . . . . . . . . . 25 4.3.3. Acknowledgement to Controller . . . . . . . . . . . . 26
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Overview 1. Overview
1.1. Introduction 1.1. Terminology
Some terminologies are originally introduced in [RFC6514]. They are
reused in [I-D.ietf-bess-bgp-multicast] and in this document.
PMSI [RFC6514]: Provider Multicast Service Interface - a
conceptual interface for a PE to send customer multicast traffic
to all or some PEs in the same VPN.
I-PMSI: Inclusive PMSI - to all PEs in the same VPN.
S-PMSI: Selective PMSI - to some of the PEs in the same VPN.
I-PMSI A-D Route: Inclusive PMSI Auto-Discovery route used to
advertise the tunnels that instantiate an I-PMSI.
S-PMSI A-D route: Selective PMSI Auto-Discovery route used to
advertise that particular C-flows are bound to (i.e., are
traveling through) particular P-tunnels.
Leaf A-D route: Leaf Auto-Discovery route used to advertise leaf/
receiver information.
PMSI Tunnel attribute (PTA): A BGP attribute used to identify a
particular P-tunnel.
1.2. Introduction
[I-D.ietf-bess-bgp-multicast] describes a way to use BGP as a [I-D.ietf-bess-bgp-multicast] describes a way to use BGP as a
replacement signaling for PIM [RFC7761] or mLDP [RFC6388]. The BGP- replacement signaling for Protocol Independent Multicast (PIM)
based multicast signaling described there provides a mechanism for [RFC7761] or Label Distribution Protocol Extensions for P2MP and
setting up both (s,g)/(*,g) multicast trees (as PIM does, but MP2MP Label Switched Paths (mLDP) [RFC6388]. The BGP-based multicast
optionally with labels) and labeled (MPLS) multicast tunnels (as mLDP signaling described there provides a mechanism for setting up both
does). Each router on a tree performs essentially the same (s,g)/(*,g) multicast trees (as PIM does, but optionally with labels)
procedures as it would perform if using PIM or mLDP, but all the and labeled (MPLS) multicast tunnels (as mLDP does). Each router on
inter-router signaling is done using BGP. a tree performs essentially the same procedures as it would perform
if using PIM or mLDP, but all the inter-router signaling is done
using BGP.
These procedures allow the routers to set up a separate tree for each These procedures allow the routers to set up a separate tree for each
individual multicast (x,g) flow where the 'x' could be either 's' or individual multicast (x,g) flow where the 'x' could be either 's' or
'*', but they also allow the routers to set up trees that are used '*', but they also allow the routers to set up trees that are used
for more than one flow. In the latter case, the trees are often for more than one flow. In the latter case, the trees are often
referred to as "multicast tunnels" or "multipoint tunnels", and referred to as "multicast tunnels" or "multipoint tunnels", and
specifically in this document they are mLDP tunnels (except that they specifically in this document they are mLDP tunnels (except that they
are set up with BGP signaling). While it actually does not have to are set up with BGP signaling). While it actually does not have to
be restricted to mLDP tunnels, mLDP FEC is conveniently borrowed to be restricted to mLDP tunnels, mLDP Forwarding Equivalent Class (FEC)
identify the tunnel. In the rest of the document, the term tree and [RFC6388] is conveniently borrowed to identify the tunnel. In the
tunnel are used interchangeably. rest of the document, the term tree and tunnel are used
interchangeably.
The trees/tunnels are set up using the "receiver-initiated join" The trees/tunnels are set up using the "receiver-initiated join"
technique of PIM/mLDP, hop by hop from downstream routers towards the technique of PIM/mLDP, hop by hop from downstream routers towards the
root. The BGP messages of MCAST-TREE SAFI are either sent hop by hop root but using BGP NLRIs of MCAST-TREE SAFI, either sent hop by hop
between downstream routers and their upstream neighbors, or can be between downstream routers and their upstream neighbors, or reflected
reflected by Route Reflectors (RRs). by Route Reflectors (RRs).
As an alternative to each hop independently determining its upstream As an alternative to each hop independently determining its upstream
router and signaling upstream towards the root (following PIM/mLDP router and signaling upstream towards the root (following PIM/mLDP
model), the entire tree can be calculated by a centralized model), the entire tree can be calculated by a centralized
controller, and the signaling can be entirely done from the controller, and the signaling can be entirely done from the
controller using the same MCAST-TREE SAFI. For that, some additional controller using the same MCAST-TREE SAFI. For that, some additional
procedures and optimizations are specified in this document. procedures and optimizations are specified in this document.
[I-D.ietf-bess-bgp-multicast] uses S-PMSI, Leaf, and Source Active [I-D.ietf-bess-bgp-multicast] uses some terminologies introduced in
Auto-Discovery (A-D) routes because the main procedures and concepts BGP-MVPN [RFC6514] because the main procedures and concepts are
are borrowed from the BGP-MVPN [RFC6514]. While the same Leaf A-D borrowed from there. While the same Leaf A-D routes in
routes can be used to signal replication state to tree nodes from [I-D.ietf-bess-bgp-multicast] can be used to signal replication state
controllers, this document introduces a new route type "Replication to tree nodes from controllers, this document introduces a new route
State" for the same functionality, so that familiarity with the BGP- type "Replication State" for the same functionality so that
MVPN concepts is not required. familiarity with the BGP-MVPN concepts is not required.
While it is outside the scope of this document, signaling from the While it is outside the scope of this document, signaling from the
controllers could be done via other means as well, like Netconf or controllers could be done via other means as well, like Netconf or
any other SDN methods. any other SDN methods.
1.2. Resilience 1.3. Resilience
Each router could establish direct BGP sessions with one or more Each router could establish direct BGP sessions with one or more
controllers, or it could establish BGP sessions with RRs who in turn controllers, or it could establish BGP sessions with RRs who in turn
peer with controllers. For the same tree/tunnel, each controller may peer with controllers. For the same tree/tunnel, each controller may
independently calculate the tree/tunnel and signal the routers on the independently calculate the tree/tunnel and signal the routers on the
tree/tunnel using MCAST-TREE Replication State routes. How the tree/tunnel using MCAST-TREE Replication State routes. How the
calculation is done are outside the scope of this document. calculations are done is outside the scope of this document.
On each router, BGP route selection rules will lead to one On each router, BGP route selection rules will lead to one
controller's route for the tree/tunnel being selected as the active controller's route for the tree/tunnel being selected as the active
route and used for setting up forwarding state. As long as all the route and used for setting up forwarding state. As long as all the
routers on a tree/tunnel consistently pick the same controller's routers on a tree/tunnel consistently pick the same controller's
routes for the tree/tunnel, the setup should be consistent. If the routes for the tree/tunnel, the setup should be consistent. If the
tree/tunnel is labeled, different labels will be used from different tree/tunnel is labeled, different labels will be used from different
controllers so there is no traffic loop issue even if the routers do controllers so there is no traffic loop issue even if the routers do
not consistently select the same controller's routes. In the not consistently select the same controller's routes. In the
unlabeled case, to ensure the consistency the selection SHOULD be unlabeled case, to ensure the consistency the selection SHOULD be
solely based on the identifier of the controller. solely based on the identifier of the controller.
Another consistency issue is when a bidirectional tree/tunnel needs Another consistency issue is when a bidirectional tree/tunnel needs
to be re-routed. Because this is no longer triggered hop-by-hop from to be re-routed. Because this is no longer triggered hop-by-hop from
downstream to upstream, it is possible that the upstream change downstream to upstream, it is possible that the upstream change
happens before the downstream, causing traffic loop. In the happens before the downstream, causing a traffic loop. In the
unlabeled case, there is no good solution (other than that the unlabeled case, there is no good solution (other than that the
controller issues upstream change only after it gets acknowledgement controller issues upstream change only after it gets acknowledgement
from downstream). In the labeled case, as long as a new label is from downstream). In the labeled case, as long as a new label is
used there should be no problem. used there should be no problem.
Besides the traffic loop issue, there could be transient traffic loss Besides the traffic loop issue, there could be transient traffic loss
before both the upstream and downstream's forwarding state are before both the upstream and downstream's forwarding state are
updated. This could be mitigated if the upstream keep sending updated. This could be mitigated if the upstream keep sending
traffic on the old path (in addition to the new path) and the traffic on the old path (in addition to the new path) and the
downstream keep accepting traffic on the old path (but not on the new downstream keep accepting traffic on the old path (but not on the new
path) for some time. It is a local matter when for the downstream to path) for some time. When the downstream switches to the new path is
switch to the new path - it could be data driven (e.g., after traffic a local matter - it could be data driven (e.g., after traffic arrives
arrives on the new path) or timer driven. on the new path) or timer driven.
For each tree, multiple disjoint instances could be calculated and For each tree, multiple disjoint instances could be calculated and
signaled for live-live protection. Different labels are used for signaled for live-live protection. Different labels are used for
different instances, so that the leaves can differentiate incoming different instances, so that the leaves can differentiate incoming
traffic on different instances. As far as transit routers are traffic on different instances. As far as transit routers are
concerned, the instances are just independent. Note that the two concerned, the instances are just independent. Note that the two
instances are not expected to share common transit routers (it is instances are not expected to share common transit routers (it is
otherwise outside the scope of this document/revision). otherwise outside the scope of this document/revision).
1.3. Signaling 1.4. Signaling
When a router receives a Replication State route, the re- When a router receives a Replication State route, the re-
advertisement is blocked if a configured import RT matches the RT of advertisement is blocked if a configured import RT matches the RT of
the route, which indicates that this router is the target and the route, which indicates that this router is the target and
consumer of the route hence it should not be re-advertised further. consumer of the route hence it should not be re-advertised further.
The routes includes the forwarding information in the form of Tunnel The routes includes the forwarding information in the form of Tunnel
Encapsulation Attributes (TEA) [RFC9012], with enhancements specified Encapsulation Attributes (TEA) [RFC9012], with enhancements specified
in this document. in this document.
Suppose that for a particular tree, there are two downstream routers Suppose that for a particular tree, there are two downstream routers
skipping to change at page 6, line 5 skipping to change at page 6, line 44
It could be that U may need to replicate to many downstream routers, It could be that U may need to replicate to many downstream routers,
say D1 through D1000. In that case, it may not be possible to encode say D1 through D1000. In that case, it may not be possible to encode
all those branches in a single TEA, or may not be optimal to update a all those branches in a single TEA, or may not be optimal to update a
large TEA when a branch is added/removed. In that case, C may send large TEA when a branch is added/removed. In that case, C may send
multiple Replication State routes, each with a different RD and a multiple Replication State routes, each with a different RD and a
different TEA that encodes a subset of the branches. This provides a different TEA that encodes a subset of the branches. This provides a
flexible way to optimize the encoding of large number of branches and flexible way to optimize the encoding of large number of branches and
incremental updates of branches. incremental updates of branches.
Notice that, in case of labeled trees, the (x,g) or mLDP FEC Notice that, in the case of labeled trees, the (x,g) or mLDP FEC
signaling is actually not needed to transit routers but only needed signaling is actually not needed to transit routers but only needed
to tunnel root/leaves. However, for consistency among the root/leaf/ to tunnel root/leaves. However, for consistency among the root/leaf/
transit nodes, and for consistency with the hop-by-hop signaling, the transit nodes, and for consistency with the hop-by-hop signaling, the
same signaling (with tree identification encoded in the NLRI) is used same signaling (with tree identification encoded in the NLRI) is used
to all routers. to all routers.
Nonetheless, a new NLRI route type of the MCAST-TREE SAFI is defined Nonetheless, a new NLRI route type of the MCAST-TREE SAFI is defined
to encode label/SID instead of tree identification in the NLRI, for to encode label/SID instead of tree identification in the NLRI, for
scenarios where there is really no need to signal tree scenarios where there is really no need to signal tree
identification, e.g. as described in Section 2. On a tunnel root, identification, e.g. as described in Section 2. On a tunnel root,
skipping to change at page 6, line 35 skipping to change at page 7, line 28
matching the tree node. The two Replication State routes (for matching the tree node. The two Replication State routes (for
controller to signal to a tree node and for a tree node to controller to signal to a tree node and for a tree node to
acknowledge back) differ only in those two aspects. acknowledge back) differ only in those two aspects.
With the acknowledgement Replication State routes, the controller With the acknowledgement Replication State routes, the controller
knows if tree setup is complete. The information can be used for knows if tree setup is complete. The information can be used for
many purposes, e.g. the controller may instruct the ingress to start many purposes, e.g. the controller may instruct the ingress to start
forwarding traffic onto a tree only after it knows that the tree forwarding traffic onto a tree only after it knows that the tree
setup has completed. setup has completed.
1.4. Label Allocation 1.5. Label Allocation
In the case of labeled multicast signaled hop by hop towards the In the case of labeled multicast signaled hop by hop towards the
root, whether it's (x,g) multicast or "mLDP" tunnel, labels are root, whether it's (x,g) multicast or "mLDP" tunnel, labels are
assigned by a downstream router and advertised to its upstream router assigned by a downstream router and advertised to its upstream router
(from traffic direction point of view). In the case of controller (from traffic direction point of view). In the case of controller
based signaling, routers do not originate tree join routes anymore, based signaling, routers do not originate tree join routes anymore,
so the controllers have to assign labels on behalf of routers, and so the controllers have to assign labels on behalf of routers, and
there are three options for label assignment: there are three options for label assignment:
* From each router's SRLB that the controller learns * From each router's SRLB that the controller learns
skipping to change at page 7, line 4 skipping to change at page 7, line 43
(from traffic direction point of view). In the case of controller (from traffic direction point of view). In the case of controller
based signaling, routers do not originate tree join routes anymore, based signaling, routers do not originate tree join routes anymore,
so the controllers have to assign labels on behalf of routers, and so the controllers have to assign labels on behalf of routers, and
there are three options for label assignment: there are three options for label assignment:
* From each router's SRLB that the controller learns * From each router's SRLB that the controller learns
* From the common SRGB that the controller learns * From the common SRGB that the controller learns
* From the controller's local label space * From the controller's local label space
Assignment from each router's SRLB is no different from each router Assignment from each router's SRLB is no different from each router
assigning labels from its own local label space in the hop-by-hop assigning labels from its own local label space in the hop-by-hop
signaling case. The assignments for one router is independent of signaling case. The assignments for one router is independent of
assignments for another router, even for the same tree. assignments for another router, even for the same tree.
Assignment from the controller's local label space is upstream- Assignment from the controller's local label space is upstream-
assigned [RFC5331]. It is used if the controller does not learn the assigned [RFC5331]. It is used if the controller does not learn the
common SRGB or each router's SRLB. Assignment from the SRGB common SRGB or each router's SRLB. Assignment from the SRGB
[RFC8402] is only meaningful if all SRGBs are the same and a single [RFC8402] is only meaningful if all SRGBs are the same and a single
common label is used for all the routers on a tree in case of common label is used for all the routers on a tree in the case of
unidirectional tree/tunnel (Section 1.4.1). Otherwise, assignment unidirectional tree/tunnel (Section 1.5.1). Otherwise, assignment
from SRLB is preferred. from SRLB is preferred.
The choice of which of the options to use depends on many factors. The choice of which of the options to use depends on many factors.
An operator may want to use a single common label per tree for ease An operator may want to use a single common label per tree for ease
of monitoring and debugging, but that requires explicit RPF checking of monitoring and debugging, but that requires explicit RPF checking
and either common SRGB or upstream assigned labels, which may not be and either common SRGB or upstream assigned labels, which may not be
supported due to either the software or hardware limitations (e.g. supported due to either the software or hardware limitations (e.g.
label imposition/disposition limits). In an SR network, assignment label imposition/disposition limits). In an SR network, the
from the common SRGB if it's required to use a single common label assignment from the common SRGB is used if it's required to use a
per unidirectional tree, or otherwise assignment from SRLB is a good single common label per unidirectional tree; otherwise, the
choice because it does not require support for context label spaces. assignment from SRLB is a good choice because it does not require
support for context label spaces.
1.4.1. Using a Common per-tree Label for All Routers 1.5.1. Using a Common per-tree Label for All Routers
MPLS labels only have local significance. For an LSP that goes MPLS labels only have local significance. For an LSP that goes
through a series of routers, each router allocates a label through a series of routers, each router allocates a label
independently and it swaps the incoming label (that it advertised to independently and it swaps the incoming label (that it advertised to
its upstream) to an outgoing label (that it received from its its upstream) to an outgoing label (that it received from its
downstream) when it forwards a labeled packet. Even if the incoming downstream) when it forwards a labeled packet. Even if the incoming
and outgoing labels happen to be the same on a particular router, and outgoing labels happen to be the same on a particular router,
that is just incidental. that is just incidental.
With Segment Routing, it is becoming a common practice that all With Segment Routing, it is becoming a common practice that all
routers use the same SRGB so that a SID maps to the same label on all routers use the same SRGB so that a SID maps to the same label on all
routers. This makes it easier for operators to monitor and debug routers. This makes it easier for operators to monitor and debug
their network. The same concept applies to multicast trees as well - their network. The same concept applies to multicast trees as well -
a common per-tree label can be used for a router to receive traffic a common per-tree label can be used for a router to receive traffic
from its upstream neighbor and replicate traffic to all its from its upstream neighbor and replicate traffic to all its
downstream neighbor. downstream neighbor.
However, a common per-tree label can only be used for unidirectional However, a common per-tree label can only be used for unidirectional
trees. In case of bidirectional trees, the common label needs to be trees. In the case of bidirectional trees, the common label needs to
per- <tree, direction>. Additionally, unless the entire tree is be per- <tree, direction>. Additionally, unless the entire tree is
updated for every tree node to use a new common per-tree or updated for every tree node to use a new common per-tree or
per-<tree, direction>label with any change in the tree (no matter how per-<tree, direction> label with any change in the tree (no matter
small and local the change is), it requires each router to do how small and local the change is), it requires each router to do
explicit RPF check, so that only packets from its expected upstream explicit RPF check, so that only packets from its expected upstream
neighbor are accepted. Otherwise, traffic loop may form during neighbor are accepted. Otherwise, traffic loop may form during
topology changes, because the forwarding state update is no longer topology changes, because the forwarding state update is no longer
ordered. ordered.
Traditionally, p2mp mpls forwarding does not require explicit RPF Traditionally, p2mp mpls forwarding does not require explicit RPF
check as a downstream router advertises a label only to its upstream check as a downstream router advertises a label only to its upstream
router and all traffic with that incoming label is presumed to be router and all traffic with that incoming label is presumed to be
from the upstream router and accepted. When a downstream router from the upstream router and accepted. When a downstream router
switches to a different upstream router a different label will be switches to a different upstream router a different label will be
skipping to change at page 8, line 24 skipping to change at page 9, line 16
upstream neighbor purely based on the label. Now with a single upstream neighbor purely based on the label. Now with a single
common label used for all routers on a tree to send and receive common label used for all routers on a tree to send and receive
traffic with, a router can no longer determine if the traffic is from traffic with, a router can no longer determine if the traffic is from
its expected neighbor just based on that common tree label. its expected neighbor just based on that common tree label.
Therefore, explicit RPF check is needed. Instead of interface based Therefore, explicit RPF check is needed. Instead of interface based
RPF checking as in PIM case, neighbor based RPF checking is used - a RPF checking as in PIM case, neighbor based RPF checking is used - a
label identifying the upstream neighbor precedes the common tree label identifying the upstream neighbor precedes the common tree
label and the receiving router checks if that preceding neighbor label and the receiving router checks if that preceding neighbor
label matches its expected upstream neighbor. Notice that this is label matches its expected upstream neighbor. Notice that this is
similar to what's described in Section "9.1.1 Discarding Packets from similar to what's described in Section "9.1.1 Discarding Packets from
Wrong PE" of RFC 6513 (an egress PE discards traffic sent from a Wrong PE" of [RFC6513] (an egress PE discards traffic sent from a
wrong ingress PE). The only difference is one is used for label wrong ingress PE). The only difference is one is used for label
based forwarding and the other is used for (s,g) based forwarding.. based forwarding and the other is used for (s,g) based forwarding..
Both the common per-tree label and the neighbor label are allocated Both the common per-tree label and the neighbor label are allocated
either from the common SRGB or from the controller's local label either from the common SRGB or from the controller's local label
space. In the latter case, an additional label identifying the space. In the latter case, an additional label identifying the
controller's label space is needed, as described in the following controller's label space is needed, as described in the following
section. section.
1.4.2. Upstream-assignment from Controller's Local Label Space 1.5.2. Upstream-assignment from Controller's Local Label Space
In this case in the multicast packet's label stack the tree label and In this case, in the multicast packet's label stack, the tree label
upstream neighbor label (if used in case of single common-label per and upstream neighbor label (if used in the case of single common-
tree) are preceded by a downstream-assigned "context label". The label per tree) are preceded by a downstream-assigned "context
context label identifies a context-specific label space (the label". The context label identifies a context-specific label space
controller's local label space), and the upstream-assigned label that (the controller's local label space), and the upstream-assigned label
follows it is looked up in that space. that follows it is looked up in that space.
This specification requires that, in case of upstream-assignment from This specification requires that, in the case of upstream-assignment
a controller's local label space, each router D to assign, from a controller's local label space, each router D to assign,
corresponding to each controller C, a context label that identifies corresponding to each controller C, a context label that identifies
the upstream-assigned label space used by that controller. This the upstream-assigned label space used by that controller. This
label, call it Lc-D, is communicated by D to C via BGP-LS [RFC 7752]. label, call it Lc-D, is communicated by D to C via BGP-LS [RFC7752].
Suppose a controller is setting up unidirectional tree T. It assigns Suppose a controller is setting up unidirectional tree T. It assigns
that tree the label Lt, and assigns label Lu to identify router U that tree the label Lt, and assigns label Lu to identify router U
which is the upstream of router D on tree T. C needs to tell U: "to which is the upstream of router D on tree T. C needs to tell U: "to
send a packet on the given tree/tunnel, one of the things you have to send a packet on the given tree/tunnel, one of the things you have to
do is push Lt onto the packet's label stack, then push Lu, then push do is push Lt onto the packet's label stack, then push Lu, then push
Lc-D onto the packet's label stack, then unicast the packet to D". Lc-D onto the packet's label stack, then unicast the packet to D".
Controller C also needs to inform router D of the correspondence Controller C also needs to inform router D of the correspondence
between <Lc-D, Lu, Lt> and tree T. between <Lc-D, Lu, Lt> and tree T.
skipping to change at page 9, line 24 skipping to change at page 10, line 19
the upstream neighbor label Lu, and the inner label being the label the upstream neighbor label Lu, and the inner label being the label
Lt assigned by the controller for the tree. The router receiving the Lt assigned by the controller for the tree. The router receiving the
route will use the label stacks to send traffic to its downstreams. route will use the label stacks to send traffic to its downstreams.
For C to signal the expected label stack for D to receive traffic For C to signal the expected label stack for D to receive traffic
with, we overload a tunnel TLV in the TEA of the Replication State with, we overload a tunnel TLV in the TEA of the Replication State
route sent to D - if the tunnel TLV has a RPF sub-TLV route sent to D - if the tunnel TLV has a RPF sub-TLV
(Section 3.1.5), then it indicates that this is actually for (Section 3.1.5), then it indicates that this is actually for
receiving traffic from the upstream. receiving traffic from the upstream.
1.5. Determining Root/Leaves 1.6. Determining Root/Leaves
For the controller to calculate a tree, it needs to determine the For the controller to calculate a tree, it needs to determine the
root and leaves of the tree. This may be based on provisioning root and leaves of the tree. This may be based on provisioning
(static or dynamically programmed), or based on BGP signaling as (static or dynamically programmed), or based on BGP signaling as
described in the following two sections. described in the following two sections.
In both of the following cases, the BGP updates are targeted at the In both of the following cases, the BGP updates are targeted at the
controller, via an address specific Route Target with Global controller, via an address specific Route Target with Global
Administration Field set to the controller's address and the Local Administration Field set to the controller's address and the Local
Administration Field set to 0. Administration Field set to 0.
1.5.1. PIM-SSM/Bidir or mLDP 1.6.1. PIM-SSM/Bidir or mLDP
In this case, the PIM Last Hop Routers (LHRs) with interested In this case, the PIM Last Hop Routers (LHRs) with interested
receivers or mLDP tunnel leaves encode a Leaf A-D route receivers or mLDP tunnel leaves encode a Leaf A-D route
([I-D.ietf-bess-bgp-multicast]) with the Upstream Router's IP Address ([I-D.ietf-bess-bgp-multicast]) with the Upstream Router's IP Address
field set to the controller's address and the Originating Router's IP field set to the controller's address and the Originating Router's IP
Address set to the address of the LHR or the P2MP tunnel leaf. The Address set to the address of the LHR or the P2MP tunnel leaf. The
encoded PIM SSM source or mLDP FEC provides root information and the encoded PIM SSM source or mLDP FEC provides root information and the
Originating Router's IP Address provides leaf information. Originating Router's IP Address provides leaf information.
1.5.2. PIM ASM 1.6.2. PIM ASM
In this case, the First Hop Routers (FHRs) originate Source Active In this case, the First Hop Routers (FHRs) originate Source Active
routes which provides root information, and the LHRs originate Leaf routes which provides root information, and the LHRs originate Leaf
A-D routes, encoded as in the PIM-SSM case except that it is (*,G) A-D routes, encoded as in the PIM-SSM case except that it is (*,G)
instead of (S,G). The Leaf A-D routes provide leaf information. instead of (S,G). The Leaf A-D routes provide leaf information.
1.6. Multiple Domains 1.7. Multiple Domains
An end to end multicast tree may span multiple routing domains, and An end to end multicast tree may span multiple routing domains, and
the setup of the tree in each domain may be done differently as the setup of the tree in each domain may be done differently as
specified in [I-D.ietf-bess-bgp-multicast]. This section discusses a specified in [I-D.ietf-bess-bgp-multicast]. This section discusses a
few aspects specific to controller signaling. few aspects specific to controller signaling.
Consider two adjacent domains each with its own controller in the Consider two adjacent domains each with its own controller in the
following configuration where router B is an upstream node of C for a following configuration where router B is an upstream node of C for a
multicast tree: multicast tree:
skipping to change at page 10, line 38 skipping to change at page 11, line 38
Controller 2 signals C to accept traffic on the B-C link. Controller 2 signals C to accept traffic on the B-C link.
In the case of labeled IP multicast or mLDP tunnel, the controllers In the case of labeled IP multicast or mLDP tunnel, the controllers
may be able to coordinate their actions such that Controller 1 may be able to coordinate their actions such that Controller 1
signals B to send traffic out of B-C link with label X while signals B to send traffic out of B-C link with label X while
Controller 2 signals C to accept traffic with the same label X on the Controller 2 signals C to accept traffic with the same label X on the
B-C link. If the coordination is not possible, then C needs to use B-C link. If the coordination is not possible, then C needs to use
hop-by-hop BGP signaling to signal towards B, as specified in hop-by-hop BGP signaling to signal towards B, as specified in
[I-D.ietf-bess-bgp-multicast]. [I-D.ietf-bess-bgp-multicast].
The configuration could also be as following, where router B borders The configuration could also be as follows, where router B borders
both domain 1 and domain 2 and is controlled by both controllers: both domain 1 and domain 2 and is controlled by both controllers:
| |
domain 1 | domain 2 domain 1 | domain 2
| |
ctrlr1 | ctrlr2 ctrlr1 | ctrlr2
/\ | /\ /\ | /\
/ \ | / \ / \ | / \
/ \ | / \ / \ | / \
/ \|/ \ / \|/ \
A--...---B--...---C A--...---B--...---C
| |
As discussed in Section 1.2, when B receives signaling from both As discussed in Section 1.3, when B receives signaling from both
Controller 1 and Controller 2, only one of the routes would be Controller 1 and Controller 2, only one of the routes would be
selected as the best route and used for programming the forwarding selected as the best route and used for programming the forwarding
state of the corresponding segment. For B to stitch the two segments state of the corresponding segment. For B to stitch the two segments
together, it is expected for B to know by provisioning that it is a together, it is expected for B to know by provisioning that it is a
border router so that B will look for the other segment (represented border router so that B will look for the other segment (represented
by the signaling from the other controller) and stitch the two by the signaling from the other controller) and stitch the two
together. together.
2. Alternative to BGP-MVPN 2. Alternative to BGP-MVPN
Multicast with BGP signaling from controllers can be an alternative Multicast with BGP signaling from controllers can be an alternative
to BGP-MVPN [RFC6514]. It is an attractive option especially when to BGP-MVPN [RFC6514]. It is an attractive option especially when
the controller can easily determine the source and leaf information. the controller can easily determine the source and leaf information.
With BGP-MVPN, distributed signaling is used for the following: With BGP-MVPN, distributed signaling is used for the following:
* Egress PEs advertise C-multicast (Type-6/7) Auto-Discovery (A-D) * Egress PEs advertise C-multicast (Type-6/7) Auto-Discovery (A-D)
routes to join C-multicast trees at the overlay (PE-PE). routes to join C-multicast trees at the overlay (PE-PE).
* In case of ASM, ingress PEs advertise Source Active (Type-5) A-D * In the case of ASM, ingress PEs advertise Source Active (Type-5)
routes to signal sources so that egress PEs can establish Shortest A-D routes to advertise sources so that egress PEs can establish
Path Trees (SPT). Shortest Path Trees (SPT).
* PEs advertise I/S-PMSI (Type-1/2/3) A-D routes to signal the * PEs advertise I/S-PMSI (Type-1/2/3) A-D routes to advertise the
binding of overlay/customer traffic to underlay/provider tunnels. binding of overlay/customer traffic to underlay/provider tunnels.
For some types of tunnels, Leaf (Type-4) A-D routes are advertised For some types of tunnels, Leaf (Type-4) A-D routes are advertised
by egress PEs in response to I/S-PMSI A-D routes to join the by egress PEs in response to I/S-PMSI A-D routes so that the
tunnels. ingress PE can discover the leaves.
Based on the above signaled information, an ingress PE builds Based on the above signaled information, an ingress PE builds
forwarding state to forward traffic arriving on the PE-CE interface forwarding state to forward traffic arriving on the PE-CE interface
to the provider tunnel (and local interfaces if there are local to the provider tunnel (and local interfaces if there are local
downstream receivers), and an egress PE builds forwarding state to downstream receivers), and an egress PE builds forwarding state to
forward traffic arriving on a provider tunnel to local interfaces forward traffic arriving on a provider tunnel to local interfaces
with downstream receivers. with downstream receivers.
Notice that multicast with BGP signaling from controllers essentially Notice that multicast with BGP signaling from controllers essentially
programs "static" forwarding state onto multicast tree nodes. As programs "static" forwarding state onto multicast tree nodes. As
long as a controller can determine how a C-multicast flow should be long as a controller can determine how a C-multicast flow should be
forwarded on ingress/egress PEs, it can signal to the ingress/egress forwarded on ingress/egress PEs, it can signal to the ingress/egress
PEs using the procedures in this document to set up forwarding state, PEs using the procedures in this document to set up forwarding state,
removing the need of the above-mentioned distributed signaling and removing the need of the above-mentioned distributed signaling and
processing. processing.
For the controller to learn the egress PEs for a C-multicast tree (so For the controller to learn the egress PEs for a C-multicast tree (so
that it can set up or find a corresponding provider tunnel), the that it can set up or find a corresponding provider tunnel), the
egress PEs advertise MCAST-TREE Leaf A-D routes (Section 1.5.1) egress PEs advertise MCAST-TREE Leaf A-D routes (Section 1.6.1)
towards the controller to signal its desire to join C-multicast towards the controller to signal its desire to join C-multicast
trees, each with an appropriate RD and an extended community derived trees, each with an appropriate RD and an extended community derived
from the Route Target for the VPN from the Route Target for the VPN
([I-D.ietf-idr-rt-derived-community]) so that the controller knows ([I-D.ietf-idr-rt-derived-community]) so that the controller knows
which VPN it is for. The controller then advertises corresponding which VPN it is for. The controller then advertises corresponding
MCAST-TREE Replication State routes to set up C-multicast forwarding MCAST-TREE Replication State routes to set up C-multicast forwarding
state on ingress and egress PEs. To encode the provider tunnel state on ingress and egress PEs. To encode the provider tunnel
information in the MCAST-TREE Replication State route for an ingress information in the MCAST-TREE Replication State route for an ingress
PE, the TEA can explicitly list all replication branches of the PE, the TEA can explicitly list all replication branches of the
tunnel, or just the binding SID for the provider tunnel in the form tunnel, or just the binding SID for the provider tunnel in the form
of Segment List tunnel type, if the tunnel has a binding SID. of Segment List tunnel type, if the tunnel has a binding SID.
The Replication State route may also have a PMSI Tunnel Attribute The Replication State route may also include a PMSI Tunnel Attribute
(PTA) attached to specify the provider tunnel while the TEA specifies (PTA) attached to specify the provider tunnel, while the TEA
the local PE-CE interfaces where traffic need to be sent out. This specifies the local PE-CE interfaces where traffic need to be
not only allows provider tunnel without a binding SID (e.g., in a directed. This not only allows provider tunnel without a binding SID
non-SR network) to be specified without explicitly listing its (e.g., in a non-SR network) to be specified without explicitly
replication branches, but also allows the service controller for MVPN listing its replication branches, but also allows the service
overlay state to be independent of provider tunnel setup (which could controller for MVPN overlay state to be independent of provider
be from a different transport controller or even without a tunnel setup (which could be from a different transport controller or
controller). even without a controller).
However, notice that if the service controller and transport However, notice that if the service controller and transport
controller are different, then the service controller needs to signal controller are different, then the service controller needs to signal
the transport controller the tree information: identification, set of the transport controller the tree information: identification, set of
leaves, and applicable constraints. While this can be achieved (see leaves, and applicable constraints. While this can be achieved (see
Section 1.5.1), it is easier for the service and transport controller Section 1.6.1), it is easier for the service and transport controller
to be the same. to be the same.
Depending on local policy, a PE may add PE-CE interfaces to its Depending on local policy, a PE may add PE-CE interfaces to its
replication state based on local signaling (e.g., IGMP/PIM) instead replication state based on local signaling (e.g., IGMP/PIM) instead
of completely relying on signaling from controllers. of completely relying on signaling from controllers.
If dynamic switching between inclusive and selective tunnels based on If there is a need for dynamic switching between inclusive and
data rate is needed, the ingress PE can advertise/withdraw S-PMSI selective tunnels based on data rate, the ingress PE can advertise or
routes targeted only at the controllers, without PMSI Tunnel withdraw S-PMSI routes targeted only at the controllers, without
Attribute attached. The controller then updates relevant MCAST-TREE attaching a PMSI Tunnel Attribute. The controller then updates
Replication State routes to update C-multicast forwarding states on relevant MCAST-TREE Replication State routes to update C-multicast
PEs to switch to a new tunnel. forwarding states on PEs to switch to a new tunnel.
3. Specification 3. Specification
3.1. Enhancements to TEA 3.1. Enhancements to TEA
A TEA may encode a list of tunnels. A TEA attached to an MCAST-TREE A TEA can encode a list of tunnels. A TEA attached to an MCAST-TREE
NLRI encodes replication information for a <tree, node > that is NLRI encodes replication information for a <tree, node > that is
identified by the NRLI. Each tunnel in the TEA identifies a branch - identified by the NLRI. Each tunnel in the TEA identifies a branch -
either an upstream branch towards the tree root (Section 3.1.5) or a either an upstream branch towards the tree root (Section 3.1.5) or a
downstream branch towards some leaves. A tunnel in the TEA could downstream branch towards some leaves. A tunnel in the TEA could
have an outer encapsulation (e.g. MPLS label stack) or it could just have an outer encapsulation (e.g. MPLS label stack) or it could just
be a one-hop direct connection for native IP multicast forwarding be a one-hop direct connection for native IP multicast forwarding
without any outer encapsulation. without any outer encapsulation.
This document specifies three new Tunnel Types and four new sub-TLVs. This document specifies three new Tunnel Types and four new sub-TLVs.
The type codes will be assigned by IANA from the "BGP Tunnel The type codes will be assigned by IANA from the "BGP Tunnel
Encapsulation Attribute Tunnel Types". Encapsulation Attribute Tunnel Types".
3.1.1. Any-Encapsulation Tunnel 3.1.1. Any-Encapsulation Tunnel
When a multicast packet needs to be sent from an upstream node to a When a multicast packet needs to be sent from an upstream node to a
downstream node, it may not matter how it is sent - natively when the downstream node, it may not matter how it is sent - natively when the
two nodes are directly connected or tunneled otherwise. In case of two nodes are directly connected or tunneled otherwise. In the case
tunneling, it may not matter what kind of tunnel is used - MPLS, GRE, of tunneling, it may not matter what kind of tunnel is used - MPLS,
IPinIP, or whatever. GRE, IPinIP, or whatever.
To support this, an "Any-Encapsulation" tunnel type of value 20 is To support this, an "Any-Encapsulation" tunnel type of value 20 is
defined. This tunnel MAY have a Tunnel Egress Endpoint and other defined. This tunnel MAY have a Tunnel Egress Endpoint and other
Sub-TLVs. The Tunnel Egress Endpoint Sub-TLV specifies an IP Sub-TLVs. The Tunnel Egress Endpoint Sub-TLV specifies an IP
address, which could be any of the following: address, which could be any of the following:
* An interface's local address - when a packet needs to sent out of * An interface's local address - when a packet needs to be sent out
the corresponding interface natively. On a LAN multicast MAC of the corresponding interface natively. On a LAN multicast MAC
address MUST be used. address MUST be used.
* A directly connected neighbor's interface address - when a packet * A directly connected neighbor's interface address - when a packet
needs to unicast to the address natively. needs to unicast to the address natively.
* An address that is not directly connected - when a packet needs to * An address that is not directly connected - when a packet needs to
be tunneled to the address (any tunnel type/instance can be used). be tunneled to the address (any tunnel type/instance can be used).
3.1.2. Load-balancing Tunnel 3.1.2. Load-balancing Tunnel
Consider that a multicast packet needs to be sent to a downstream Consider that a multicast packet needs to be sent to a downstream
node, which could be reached via four paths P1~P4. If it does not node, which could be reached via four paths P1~P4. If it does not
matter which of path is taken, an "Any-Encapsulation" tunnel with the matter which of path is taken, an "Any-Encapsulation" tunnel with the
Tunnel Egress Endpoint Sub-TLV specifying the downstream node's Tunnel Egress Endpoint Sub-TLV specifying the downstream node's
loopback address works well. If the controller wants to specify that loopback address works well. If the controller wants to specify that
only P1~P2 should be used, then a "Load-balancing" tunnel needs to be only P1~P2 should be used, then a "Load-balancing" tunnel needs to be
used, listing P1 and P2 as member tunnels of the "Load-balancing" used, listing P1 and P2 as member tunnels of the "Load-balancing"
tunnel. tunnel.
A load-balancing tunnel has one "Member Tunnels" Sub-TLV defined in A load-balancing tunnel is of type TBD1. It has one "Member Tunnels"
this document. The Sub-TLV is a list of tunnels, each specifying a Sub-TLV of type TBD3 defined in this document. The Sub-TLV is a list
way to reach the downstream. A packet will be sent out of one of the of tunnels, each specifying a way to reach the downstream. A packet
tunnels listed in the Member Tunnels Sub-TLV of the load-balancing will be sent out of one of the tunnels listed in the Member Tunnels
tunnel. Sub-TLV of the load-balancing tunnel.
3.1.3. Segment List Tunnel 3.1.3. Segment List Tunnel
A Segment List tunnel has a Segment List sub-TLV. The encoding of A Segment List tunnel is of type TBD2. It has a Segment List sub-
the sub-TLV is as specified in Section 2.4.4 of TLV. The encoding of the sub-TLV is as specified in Section 2.4.4 of
[I-D.ietf-idr-segment-routing-te-policy]. [I-D.ietf-idr-segment-routing-te-policy].
3.1.4. Receiving MPLS Label Stack 3.1.4. Receiving MPLS Label Stack
While [I-D.ietf-bess-bgp-multicast] uses S-PMSI A-D routes to signal While [I-D.ietf-bess-bgp-multicast] uses S-PMSI A-D routes to signal
forwarding information for MP2MP upstream traffic, when controller forwarding information for MP2MP upstream traffic, when controller
signaling is used, a single Replication State route is used for both signaling is used, a single Replication State route is used for both
upstream and downstream traffic. Since different upstream and upstream and downstream traffic. Since different upstream and
downstream labels need to be used, a new "Receiving MPLS Label Stack" downstream labels need to be used, a new "Receiving MPLS Label Stack"
of type TBD is added as a tunnel sub-TLV in addition to the existing of type TBD5 is added as a tunnel sub-TLV in addition to the existing
MPLS Label Stack sub-TLV. Other than type difference, the two are MPLS Label Stack sub-TLV. Other than type difference, the two are
the encoded the same way. encoded the same way.
The Receiving MPLS Label Stack sub-TLV is added to each downstream The Receiving MPLS Label Stack sub-TLV is added to each downstream
tunnel in the TEA of Replication State route for an MP2MP tunnel to tunnel in the TEA of Replication State route for an MP2MP tunnel to
specify the forwarding information for upstream traffic from the specify the forwarding information for upstream traffic from the
corresponding downstream node. A label stack instead of a single corresponding downstream node. A label stack instead of a single
label is used because of the need for neighbor based RPF check, as label is used because of the need for neighbor based RPF check, as
further explained in the following section. further explained in the following section.
The Receiving MPLS Label Stack sub-TLV is also used for downstream The Receiving MPLS Label Stack sub-TLV is also used for downstream
traffic from the upstream for both P2MP and MP2MP, as specified traffic from the upstream for both P2MP and MP2MP, as specified
below. below.
3.1.5. RPF Sub-TLV 3.1.5. RPF Sub-TLV
The RPF sub-TLV is of type 124 allocated by IANA and has a one-octet The RPF sub-TLV is of type 124 and has a one-octet length. The
length. The length is 0 currently, but if necessary in the future, length is 0 currently, but if necessary in the future, sub-sub-TLVs
sub-sub-TLVs could be placed in its value part. If the RPF sub-TLV could be placed in its value part. If the RPF sub-TLV appears in a
appears in a tunnel, it indicates that the "tunnel" is for the tunnel, it indicates that the "tunnel" is for the upstream node
upstream node instead of a downstream node. instead of a downstream node.
In case of MPLS, the tunnel contains an Receiving MPLS Label Stack In the case of MPLS, the tunnel contains an Receiving MPLS Label
sub-TLV for downstream traffic from the upstream node, and in case of Stack sub-TLV for downstream traffic from the upstream node, and in
MP2MP it also contains a regular MPLS Label Stack sub-TLV for the case of MP2MP it also contains a regular MPLS Label Stack sub-TLV
upstream traffic to the upstream node. for upstream traffic to the upstream node.
The inner most label in the Receiving MPLS Label Stack is the The inner most label in the Receiving MPLS Label Stack is the
incoming label identifying the tree (for comparison the inner most incoming label identifying the tree (for comparison the inner most
label for a regular MPLS Label Stack is the outgoing label). If the label for a regular MPLS Label Stack is the outgoing label). If the
Receiving MPLS Label Stack sub-TLVe has more than one labels, the Receiving MPLS Label Stack sub-TLVe has more than one labels, the
second inner most label in the stack identifies the expected upstream second inner most label in the stack identifies the expected upstream
neighbor and explicit RPF checking needs to be set up for the tree neighbor and explicit RPF checking needs to be set up for the tree
label accordingly. label accordingly.
3.1.6. Tree Label Stack sub-TLV 3.1.6. Tree Label Stack sub-TLV
The MPLS Label Stack sub-TLV can be used to specify the complete The MPLS Label Stack sub-TLV can be utilized to specify the complete
label stack used to send traffic, with the stack including both a label stack used to transmit traffic, with the stack including both a
transport label (stack) and label(s) that identify the (tree, transport label (stack) and label(s) that identify the (tree,
neighbor) to the downstream node. There are cases where the neighbor) to the downstream node. There are cases where the
controller only wants to specify the tree-identifying labels but controller only wants to specify the tree-identifying labels but
leave the transport details to the router itself. For example, the leave the transport details to the router itself. For example, the
router could locally determine a transport label (stack) and combine router could locally determine a transport label (stack) and combine
with the tree-identifying labels signaled from the controller to get with the tree-identifying labels signaled from the controller to get
the complete outgoing label stack. the complete outgoing label stack.
For that purpose, a new Tree Label Stack sub-TLV of type 125 is For that purpose, a new Tree Label Stack sub-TLV of type 125 is
defined, with a one-octet length field. It MAY appear in an Any- defined, with a one-octet length field. It MAY appear in an Any-
Encapsulation tunnel. The value field contains a label stack with Encapsulation tunnel. The value field contains a label stack with
the same encoding as value part of the MPLS Label Stack sub-TLV, but the same encoding as the value field of the MPLS Label Stack sub-TLV,
with a different type. A stack is specified because it may take up but with a different type. A stack is specified because it may take
to three labels (see Section 1.4): up to three labels (see Section 1.5):
* If different nodes use different labels (allocated from the common * If different nodes use different labels (allocated from the common
SRGB or the node's SRLB) for a (tree, neighbor) tuple, only a SRGB or the node's SRLB) for a (tree, neighbor) tuple, only a
single label is in the stack. This is similar to current mLDP hop single label is in the stack. This is similar to current mLDP hop
by hop signaling case. by hop signaling case.
* If different nodes use the same tree label, then an additional * If different nodes use the same tree label, then an additional
neighbor-identifying label is needed in front of the tree label. neighbor-identifying label is needed in front of the tree label.
* For the previous bullet, if the neighbor-identifying label is * For the previous bullet, if the neighbor-identifying label is
allocated from the controller's local label space, then an allocated from the controller's local label space, then an
additional context label is needed in front of the neighbor label. additional context label is needed in front of the neighbor label.
3.1.7. Backup Tunnel sub-TLV 3.1.7. Backup Tunnel sub-TLV
The Backup Tunnel sub-TLV is used to specify the backup paths for an The Backup Tunnel sub-TLV is used to specify the backup paths for an
Any-Encapsulation or Segment List tunnel. The length is two-octet. Any-Encapsulation or Segment List tunnel. The type is TBD4. The
The value part encodes a one-octet flags field and a variable length length is two-octet. The value field encodes a one-octet flags field
Tunnel Encapsulation Attribute. If the tunnel goes down, traffic and a variable length Tunnel Encapsulation Attribute. If the tunnel
that is normally sent out of the tunnel is fast rerouted to the goes down, traffic that is normally sent out of the tunnel is fast
tunnels listed in the encoded TEA. rerouted to the tunnels listed in the encoded TEA.
+- - - - - - - - - - - - - - - - + +- - - - - - - - - - - - - - - - +
| Sub-TLV Type (1 Octet, TBD) | | Sub-TLV Type (1 Octet, TBD4) |
+- - - - - - - - - - - - - - - - + +- - - - - - - - - - - - - - - - +
| Sub-TLV Length (2 Octets) | | Sub-TLV Length (2 Octets) |
+- - - - - - - - - - - - - - - - + +- - - - - - - - - - - - - - - - +
| P | rest of 1 Octet Flags | | P | rest of 1 Octet Flags |
+- - - - - - - - - - - - - - - - + +- - - - - - - - - - - - - - - - +
| Backup TEA (variable length) | | Backup TEA (variable length) |
+- - - - - - - - - - - - - - - - + +- - - - - - - - - - - - - - - - +
The backup tunnels can be going to the same or different nodes The backup tunnels can lead to the same or different nodes reached by
reached by the original tunnel. the original tunnel.
If the tunnel carries a RPF sub-TLV and a Backup Tunnel sub-TLV, then If the tunnel carries a RPF sub-TLV and a Backup Tunnel sub-TLV, then
both traffic arriving on the original tunnel and on the tunnels both traffic arriving on the original tunnel and on the tunnels
encoded in the Backup Tunnel sub-TLV's TEA can be accepted, if the encoded in the Backup Tunnel sub-TLV's TEA can be accepted, provided
Parallel (P-)bit in the flags field is set. If the P-bit is not set, that the Parallel (P-)bit in the flags field is set. If the P-bit is
then traffic arriving on the backup tunnel is accepted only if router not set, then traffic arriving on the backup tunnel is accepted only
has switched to receiving on the backup tunnel (this is the if router has switched to receiving on the backup tunnel (this is the
equivalent of PIM/mLDP MoFRR). equivalent of PIM/mLDP MoFRR).
3.2. Context Label TLV in BGP-LS Node Attribute 3.2. Context Label TLV in BGP-LS Node Attribute
For a router to signal the context label that it assigns for a For a router to signal the context label that it assigns for a
controller (or any label allocator that assigns labels - from its controller (or any label allocator that assigns labels - from its
local label space - that will be received by this router), a new BGP- local label space - that will be received by this router), a new BGP-
LS Node Attribute TLV is defined: LS Node Attribute TLV of type TBD6 is defined:
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 | Length | | Type TBD6 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context Label | | Context Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4/v6 Address of Label Space Owner | | IPv4/v6 Address of Label Space Owner |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field implies the type of the address. Multiple Context The Length field implies the type of the address. Multiple Context
Label TLVs may be included in a Node Attribute, one for each label Label TLVs may be included in a Node Attribute, one for each label
space owner. space owner.
An as example, a controller with address 11.11.11.11 allocates label An as example, a controller with address 198.51.100.1 allocates label
200 from its own label space, and router A assigns label 100 to 200 from its own label space, and router A assigns label 100 to
identify this controller's label space. The router includes the identify this controller's label space. The router includes the
Context Label TLV (100, 11.11.11.11) in its BGP-LS Node Attribute and Context Label TLV (100, 198.51.100.1) in its BGP-LS Node Attribute
the controller instructs router B to send traffic to router A with a and the controller instructs router B to send traffic to router A
label stack (100, 200), and router A uses label 100 to determine the with a label stack (100, 200), and router A uses label 100 to
Label FIB in which to look up label 200. determine the Label FIB in which to look up label 200.
3.3. MCAST Extended Community 3.3. MCAST Extended Community
A tree node needs to acknowledge to the controller the success/ A tree node needs to acknowledge to the controller the success/
failure in installing forwarding state for a tree. In case of failure in installing forwarding state for a tree. In case of
failure, an MCAST NACK Extended Community is attached. The value failure, an MCAST NACK Extended Community is attached. The value
field is set to 0. In the future, flag bits may be defined to signal field is set to 0. In the future, flag bits may be defined to signal
specific failure. specific failure.
The MCAST NACK Extended Community is an MCAST Extended Community with The MCAST NACK Extended Community is an MCAST Extended Community with
a sub-type to be assigned by IANA. The MCAST Extended Community is a a sub-type TBD9 to be assigned by IANA. The MCAST Extended Community
new Extended Community with a type to be assigned by IANA. is a new Extended Community with a type TBD8 to be assigned by IANA.
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=TBD1 | Sub-Type=TBD2 | Reserved=0 | | Type=TBD8 | Sub-Type=TBD9 | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 | | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.4. Replication State Route Type 3.4. Replication State Route Type
The NLRI route type for signaling from controllers to tree nodes is The NLRI route type (TBD7) for signaling from controllers to tree
"Replication State". The NLRI has the following format: nodes is "Replication State". The NLRI has the following format:
+-----------------------------------+ +-----------------------------------+
| Route Type - Replication State | |Route Type - Replication State TBD7|
+-----------------------------------+ +-----------------------------------+
| Length (1 octet) | | Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Tree Type (1 octet) | | Tree Type (1 octet) |
+-----------------------------------+ +-----------------------------------+
|Tree Type Specific Length (1 octet)| |Tree Type Specific Length (1 octet)|
+-----------------------------------+ +-----------------------------------+
| RD (8 octets) | | RD (8 octets) |
+-----------------------------------+ +-----------------------------------+
~ Tree Identification (variable) ~ ~ Tree Identification (variable) ~
skipping to change at page 18, line 42 skipping to change at page 19, line 42
the PMSI route key in Leaf A-D route the PMSI route key in Leaf A-D route
With this arrangement, IP multicast tree and mLDP tunnel can be With this arrangement, IP multicast tree and mLDP tunnel can be
signaled via Replication State routes from controllers, or via Leaf signaled via Replication State routes from controllers, or via Leaf
A-D routes either hop by hop or from controllers with maximum code A-D routes either hop by hop or from controllers with maximum code
reuse, while newer types of trees can be signaled via Replication reuse, while newer types of trees can be signaled via Replication
State routes with maximum code reuse as well. State routes with maximum code reuse as well.
3.5. Replication State Route with Label Stack for Tree Identification 3.5. Replication State Route with Label Stack for Tree Identification
As described in Section 1.3, tree label instead of tree As described in Section 1.4, the tree label, instead of tree
identification could be encoded in the NLRI to identify the tree in identification could be encoded in the NLRI to identify the tree in
the control plane as well as in the forwarding plane. For that a new the control plane as well as in the forwarding plane. For that a new
Tree Type of 2 is used and the Replication State route has the Tree Type of 2 is used and the Replication State route has the
following format: following format:
+-------------------------------------+ +-------------------------------------+
| Route Type - Replication State | | Route Type - Replication State |
+-------------------------------------+ +-------------------------------------+
| Length (1 octet) | | Length (1 octet) |
+-------------------------------------+ +-------------------------------------+
skipping to change at page 19, line 25 skipping to change at page 20, line 25
+-------------------------------------+ +-------------------------------------+
~ Label Stack (variable) ~ ~ Label Stack (variable) ~
+-------------------------------------+ +-------------------------------------+
| Tree Node's IP Address | | Tree Node's IP Address |
+-------------------------------------+ +-------------------------------------+
| Originating Router's IP Address | | Originating Router's IP Address |
+-------------------------------------+ +-------------------------------------+
Replication State route for tree identification by label stack Replication State route for tree identification by label stack
As discussed in Section 1.4.2, a label stack may have to be used to As discussed in Section 1.5.2, a label stack may have to be used to
identify a tree in the data plane so a label stack is encoded here. identify a tree in the data plane so a label stack is encoded here.
The number of labels is derived from the Tree Type Specific Length The number of labels is derived from the Tree Type Specific Length
field. Each label stack entry is encoded as following: field. Each label stack entry is encoded as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |0 0 0 0 0 0 0 0 0 0 0 0| | Label |0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. Procedures 4. Procedures
This section applies to MPLS data plane. While the concept of BGP This section applies to MPLS data plane. While the concept of BGP
signaling applies to SRv6 data plane as well, SRv6 related signaling applies to SRv6 data plane as well, SRv6 related
specification is outside the scope of this document. Note that, this specification is outside the scope of this document. Note that, this
document does not assume Segment Routing is used, even though the document does not assume Segment Routing is used, even though the
SRGB/SRLB terminologies are used to describe label blocks, and some SRGB/SRLB terminologies are used to describe label blocks, and some
scenarios of Segment routing are considered. scenarios of Segment routing are considered.
4.1. Label Space and Tree Label Allocation 4.1. Label Space and Tree Label Allocation
In case of labeled trees for either (x, g) IP multicast or mLDP In the case of labeled trees for either (x, g) IP multicast or mLDP
tunnels, an operator first determines which of the following methods tunnels, an operator first determines which of the following methods
is used to allocate tree-identifying labels, as explained in is used to allocate tree-identifying labels, as explained in
Section 1.4: Section 1.5:
1. A common per-tree label on all nodes of a P2MP tree, or a common 1. A common per-tree label on all nodes of a P2MP tree, or a common
per-<tree, direction> label on all nodes of a MP2MP tree, per-<tree, direction> label on all nodes of a MP2MP tree,
allocated from the controller's own label space. allocated from the controller's own label space.
2. A common per-tree label on all nodes of a P2MP tree, or a common 2. A common per-tree label on all nodes of a P2MP tree, or a common
per-<tree, direction> label on all nodes of a MP2MP tree, per-<tree, direction> label on all nodes of a MP2MP tree,
allocated from a common SRGB. allocated from a common SRGB.
3. Uncorrelated labels independently allocated from each node's 3. Uncorrelated labels independently allocated from each node's
SRLB. SRLB.
For option 2 and 3, how the controller learns the common SRGB or each For option 2 and 3, the process through which the controller learns
node's SRLB is outside the scope of this document. the common SRGB or each node's SRLB is outside the scope of this
document.
For option 1, each tree node MUST advertise a label from its default For option 1, each tree node MUST advertise a label from its default
label space to identify the controller's label space, via the Context label space to identify the controller's label space, via the Context
Label TLV in BGP-LS Node Attribute (Section 3.2). The tree- Label TLV in BGP-LS Node Attribute (Section 3.2). The tree-
identifying label in TEA and packets MUST be preceded by the label- identifying label in TEA and packets MUST be preceded by the label-
space-identifying label. space-identifying label.
For option 1 and 2, the operator also determines if the controller For option 1 and 2, the operator also determines if the controller
allocates a new label for each tree or <tree, direction> and resignal allocates a new label for each tree or <tree, direction> and resignal
to all tree nodes even when only some tree nodes need to be changed. to all tree nodes even when only some tree nodes need to be changed.
If not, then another neighbor-identifying label needs to precede the If not, then another neighbor-identifying label needs to precede the
tree-identifying label (and follow the label-space-identifying label tree-identifying label (and follow the label-space-identifying label
in case of option 1). The neighbor-identifying label MUST be in the case of option 1). The neighbor-identifying label MUST be
allocated from the same label space or SRGB from which the tree- allocated from the same label space or SRGB from which the tree-
identifying label is allocated. identifying label is allocated.
To generalize, a label stack of one label (for option 3), two labels To generalize, a label stack can contain one label (for option 3),
(for option 2 and 1 if neighbor-identifying label is not needed), or two labels (for option 2 and 1 if neighbor-identifying label is not
three labels (for option 2 and 1 if neighbor-identifying label is needed), or three labels (for option 2 and 1 if neighbor-identifying
needed). In the rest of the document, tree-identifying label(-stack) label is needed). In the rest of the document, tree-identifying
term is used generically. label(-stack) term is used generically.
4.2. Advertising Replication State Routes 4.2. Advertising Replication State Routes
After the controller calculates a tree, it constructs one or more After the controller calculates a tree, it constructs one or more
Replication State Route for each tree node as following: Replication State Routes for each tree node as follows:
* If the tree is for the default routing instance and only one route * If the tree is for the default routing instance and only one route
is needed, the RD MAY be set to 0:0. Otherwise, the RD is set to is needed, the RD MAY be set to 0:0. Otherwise, the RD is set to
a value to distinguish the routes for trees in different routing a value to distinguish the routes for trees in different routing
instances but with the same tree identifier (e.g., (x, g) or mLDP instances but with the same tree identifier (e.g., (x, g) or mLDP
FEC for a VPN), or to distinguish the multiple routes needed for FEC for a VPN), or to distinguish the multiple routes needed for
the same <tree, node>. the same <tree, node>.
* The Route Type, Length, Tree Type, Tree Type Specific Length, and * The Route Type, Length, Tree Type, Tree Type Specific Length, and
Tree Identification are set accordingly. Tree Identification are set accordingly.
* The Tree Node's IP Address is set to an address of the tree node, * The Tree Node's IP Address is set to an address of the tree node,
typically the loopback address. typically the loopback address.
* The Originator's IP Address is set to the controller's address. * The Originator's IP Address is set to the controller's address.
* An IP Address Specific Route Target is attached, with the Global * An IP Address Specific Route Target is attached, with the Global
Administration Field set to the same as the Tree Node's IP Address Administration Field set to match the Tree Node's IP Address in
in the NLRI, and the Local Admin Field set to 0. the NLRI, and the Local Admin Field set to 0.
* In case of VPN, an Extended Community derived from the Route * In the case of VPN, an Extended Community derived from the Route
Target for the VPN ([I-D.ietf-idr-rt-derived-community]) is Target for the VPN ([I-D.ietf-idr-rt-derived-community]) is
attached. attached.
* A Tunnel Encapsulation Attribute (TEA) is attached to encode * A Tunnel Encapsulation Attribute (TEA) is attached to encode the
replication information, as detailed below. replication information, as detailed below.
The TEA includes one or more tunnels. If the route is for the root The TEA encompasses one or more tunnels. If the route is for the
node, one and only one tunnel of type Any-Encapsulation MAY be root node, a single tunnel of type Any-Encapsulation MAY be included
included with a RPF sub-TLV and a Receiving MPLS Label Stack sub-TLV with a RPF sub-TLV and a Receiving MPLS Label Stack sub-TLV to encode
to encode a binding SID if it is assigned for the tree. If the route a binding SID, if it is assigned for the tree. If the route is for a
is for a leaf or bud node (which is both a leaf node and transit node leaf or bud node (which is both a leaf node and transit node
at the same time), one and only one tunnel of type Any-Encapsulation simultaneously), a single tunnel of type Any-Encapsulation MUST be
MUST be included with a Tunnel Egress Endpoint sub-TLV whose address included with a Tunnel Egress Endpoint sub-TLV. The address of this
is set to a loopback address on the node. sub-TLV MUST be set to a loopback address on the node.
Additionally, for any node, a tunnel is included for each upstream/ Additionally, for any node, a tunnel is included for each upstream/
downstream node. Each tunnel MUST include a Tunnel Egress Endpoint downstream node. Each tunnel MUST include a Tunnel Egress Endpoint
sub-TLV if it is needed to derive forwarding information. Otherwise, sub-TLV if it is needed to derive forwarding information. Otherwise,
the sub-TLV MAY be included for informational purposes. the sub-TLV MAY be included for informational purposes.
* For any neighbor from which labeled traffic may be received for * For any neighbor from which labeled traffic may be received for
the tree (notice that on a bidirectional tree traffic may be the tree (notice that on a bidirectional tree traffic may be
recevied on multiple branches), the tunnel MUST include a received on multiple branches), the tunnel MUST include a
Receiving MPLS Label Stack sub-TLV to encode the incoming tree- Receiving MPLS Label Stack sub-TLV to encode the incoming tree-
identifying label(-stack). identifying label(-stack).
* For any neighbor from which unlabeled IP multicast traffic may be * For any neighbor from which unlabeled IP multicast traffic may be
received for the IP multicast tree (notice that on a bidirectional received for the IP multicast tree (notice that on a bidirectional
tree traffic may be recevied on multiple branches), the tunnel tree traffic may be received on multiple branches), the tunnel
MUST be of type Any-Encapsulation with a Tunnel Egress Endpoint MUST be of type Any-Encapsulation with a Tunnel Egress Endpoint
sub-TLV with the address set to the local address of incoming sub-TLV with the address set to the local address of incoming
interface. interface.
* A tunnel MAY be one of the following types: * A tunnel MAY be one of the following types:
- Any-Encapsulation: any encapsulation can be used to send or - Any-Encapsulation: any encapsulation can be used to send or
receive traffic. it MUST include a Tunnel Egress Endpoint Sub- receive traffic. it MUST include a Tunnel Egress Endpoint Sub-
TLV, with the address set to either a local address of TLV, with the address set to either a local address of
incoming/outgoing interface, or the address of a neighbor to incoming/outgoing interface, or the address of a neighbor to
skipping to change at page 22, line 38 skipping to change at page 23, line 38
- Load-balancing: This is for a downstream node to be reached via - Load-balancing: This is for a downstream node to be reached via
one of the member tunnels listed in a Load-balancing tunnel. one of the member tunnels listed in a Load-balancing tunnel.
Other tunnel types and sub-TLVs may also be used but not specified Other tunnel types and sub-TLVs may also be used but not specified
here. here.
4.3. Receiving Replication State Routes 4.3. Receiving Replication State Routes
Each potential tree node MUST be (auto-)configured with an IP Address Each potential tree node MUST be (auto-)configured with an IP Address
Specific Route Target to import Replication State Routes targeted at Specific Route Target to import Replication State Routes targeted at
itself. The Route Target's Global Administration Field is set to a itself. The Global Administration Field MUST be set to a local
local address known to be used by the controller to identify the address known to be used by the controller to identify the node, and
node, and the Local Administration Field is set to 0. the Local Administration Field MUST set to 0.
When a BGP speaker receives Replication State Route and the attached When a BGP speaker receives a Replication State Route and the
Route Target matches its (auto-)configured Route Target to import the attached Route Target matches its (auto-)configured Route Target to
route, it MUST stops re-advertising the route further. Otherwise, import the route, it MUST stops re-advertising the route further.
normal BGP route propagation rules apply. Otherwise, normal BGP route propagation rules apply.
If an imported Replication State Route carries an Extented Community If an imported Replication State Route carries an Extended Community
derived from a Route Target for a local VRF, the route is imported derived from a Route Target for a local VRF, the route is imported
into that VRF otherwise it is imported into the default routing into that VRF. Otherwise, it is imported into the default routing
instance. instance.
For the same <tree, node>, there may be multiple routes imported, For the same <tree, node>, there may be multiple routes imported,
from the same or different controllers. BGP best route selection from the same or different controllers. BGP best route selection
process selects one of them as the active path. Without considering process selects one of them as the active path. Without considering
the RD field, all routes with the same NLRI as the active path MUST the RD field, all routes with the same NLRI as the active path MUST
be considered together to create forwarding state on the node for the be considered together to create forwarding state on the node for the
tree. Recall that multiple such routes may be advertised when it is tree. Recall that multiple such routes may be advertised when it is
desired to signal a large set of replication branches via multiple desired to signal a large set of replication branches via multiple
routes. routes.
skipping to change at page 24, line 28 skipping to change at page 25, line 28
branch that comprises the set of Load-Balancing members, so that a branch that comprises the set of Load-Balancing members, so that a
replicated copy will be sent out of one of Load-Balancing members. replicated copy will be sent out of one of Load-Balancing members.
4.3.2. Installing Forwarding State 4.3.2. Installing Forwarding State
The above procedures build a nexthop to be pointed to by some label The above procedures build a nexthop to be pointed to by some label
or (x,g) routes. The routes are determined by checking the tree or (x,g) routes. The routes are determined by checking the tree
identification in the NLRI and tunnels in the TEA. identification in the NLRI and tunnels in the TEA.
If the tree is a bidirectional (*,g) IP multicast, a (*,g) route is If the tree is a bidirectional (*,g) IP multicast, a (*,g) route is
installed, pointing to the nexthop built as above, installed, pointing to the previously constructed nexthop.
If the tree is a unidirectional (x,g) IP multicast, one of the If the tree is a unidirectional (x,g) IP multicast, one of the
tunnels MUST have the RPF sub-TLV (referred to as the RPF tunnel) tunnels MUST have the RPF sub-TLV (referred to as the RPF tunnel)
with a Tunnel Egress Endpoint sub-TLV with a local interface address. with a Tunnel Egress Endpoint sub-TLV with a local interface address.
If it has no Receiving MPLS Label Stack sub-TLV, an (x,g) route MUST If it has no Receiving MPLS Label Stack sub-TLV, an (x,g) route MUST
be installed with the corresponding interface as the expected be installed with the corresponding interface as the expected
incoming interface and the route points to the nexthop built as incoming interface and the route points to the previously constructed
above. The route MAY be installed even if there is a receiving MPLS nexthop. The route MAY be installed even if there is a receiving
Label Stack sub-TLV in the tunnel - this is to allow native IP MPLS Label Stack sub-TLV in the tunnel - this is to allow native IP
multicast packets to be put onto the tree at this node. multicast packets to be put onto the tree at this node.
If the tree is unidirectional, only one of the tunnels MAY have a If the tree is unidirectional, only one of the tunnels MAY contain a
Receiving MPLS Label Stack sub-TLV. If it is bidirectional, multiple Receiving MPLS Label Stack sub-TLV. If it is bidirectional, multiple
tunnels MAY have the Receiving MPLS Label Stack sub-TLV. For each tunnels MAY contain the Receiving MPLS Label Stack sub-TLV. For each
tunnel with the Receiving MPLS Label Stack sub-TLV: tunnel with the Receiving MPLS Label Stack sub-TLV:
* If the sub-TLV includes only one label (which is allocated from * If the sub-TLV includes only one label (which is allocated from
SRGB or the node's SRLB), a label forwarding entry for that label SRGB or the node's SRLB), a label forwarding entry for that label
is installed in the default label forwarding table, pointing at is installed in the default label forwarding table, pointing at
the nexthop built as above. the previously constructed nexthop.
* If the sub-TLV includes two labels and the first label is locally * If the sub-TLV includes two labels and the first label is locally
allocated for a label forwarding table, a label forwarding entry allocated for a label forwarding table, a label forwarding entry
for the second label is installed in the label forwarding table for the second label is installed in the label forwarding table
for which the first label is allocated, pointing to the nexthop for which the first label is allocated, pointing to the previously
built as above. constructed nexthop.
* If the sub-TLV includes two labels, the first label is not * If the sub-TLV includes two labels and the first label is not
allocated for a label forwarding table, then it is assumed to be allocated for a label forwarding table, then it is assumed to be
for a particular neighbor. A Label forwarding entry for the first for a particular neighbor. A Label forwarding entry for the first
label is installed in the default label forwarding table with the label is installed in the default label forwarding table with the
forwarding behavior "pop the label and save it for later forwarding behavior "pop the label and save it for later
comparison", and a label forwarding entry for the second label is comparison", and a label forwarding entry for the second label is
installed in the default label forwarding table pointing to the installed in the default label forwarding table, pointing to the
nexthop built as above, with additional RPF check such that previously constructed nexthop, with additional RPF check such
packets are forwarded only if the popped and saved preceding label that packets are forwarded only if the popped and saved preceding
match the first (neighbor-identifying) label in the sub-TLV. label match the first (neighbor-identifying) label in the sub-TLV.
* If the sub-TLV includes three labels and the first label is * If the sub-TLV includes three labels and the first label is
locally allocated for a label forwarding table, a Label forwarding locally allocated for a label forwarding table, a Label forwarding
entry for the second label is installed in the label forwarding entry for the second label is installed in the label forwarding
table identified by the first label with the forwarding behavior table identified by the first label with the forwarding behavior
"pop the label and save it for later comparison", and a label "pop the label and save it for later comparison", and a label
forwarding entry for the third label is installed in the label forwarding entry for the third label is installed in the label
forwarding table identified by the first label, pointing to the forwarding table identified by the first label, pointing to the
nexthop built as above, with additional RPF check such that previously constructed nexthop, with additional RPF check such
packets are forwarded only if the popped and saved preceding label that packets are forwarded only if the popped and saved preceding
match the second (neighbor-identifying) label in the sub-TLV. label match the second (neighbor-identifying) label in the sub-
TLV.
* Otherwise, the TEA is considered semantically incorrect and a * Otherwise, the TEA is considered semantically incorrect and a
negative acknowledgement MUST be sent back to the controller - see negative acknowledgement MUST be sent back to the controller - see
Section 4.3.3. Section 4.3.3.
4.3.3. Acknowledgement to Controller 4.3.3. Acknowledgement to Controller
After processing a received Replication State Route, the node MUST After processing a received Replication State Route, the node MUST
send an acknowledgement back to the controller. It originates a send an acknowledgement back to the controller. It originates a
route with similar NLRI except that the Originating Router's IP route with the same NLRI, except that the Originating Router's IP
Address is set to the same Tree Node's IP Address. It attaches a IP Address is set to match the Tree Node's IP Address. It attaches a IP
Address Specific Route Target with the Global Administration Field Address Specific Route Target, with the Global Administration Field
set to the same as the Originating Router's IP Address in the receive set to match the Originating Router's IP Address in the receive
route and the Local Administration Field to 0. route, and the Local Administration Field set to 0.
If the processing is not successful (e.g., due to If the processing is not successful (e.g., due to unsupported tunnels
missing/conflicting/inappropriate sub-TLVs in the TEA), an MCAST NACK or missing/conflicting/inappropriate sub-TLVs in the TEA), an MCAST
Extended Community MUST be attached. NACK Extended Community MUST be attached.
5. Security Considerations 5. Security Considerations
This document does not introduce new security implications beyond This document does not introduce new security implications beyond
what a typical BGP-based controller-to-node signaling of forwarding typical BGP-based controller-to-node signaling of forwarding state.
state.
6. IANA Considerations 6. IANA Considerations
IANA has assigned the following code points: IANA has assigned the following code points:
* "Any-Encapsulation" tunnel type 78 from "BGP Tunnel Encapsulation * "Any-Encapsulation" tunnel type 78 from "BGP Tunnel Encapsulation
Attribute Tunnel Types" registry Attribute Tunnel Types" registry
* "RPF" sub-TLV type 124 and "Tree Label Stack" sub-TLV type 125 * "RPF" sub-TLV type 124 and "Tree Label Stack" sub-TLV type 125
from "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry from "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry
This document makes the following additional IANA requests: This document makes the following additional IANA requests:
* Assign "Segment List" and "Load-balancing" tunnel types from the * Assign the following tunnel types from the "BGP Tunnel
"BGP Tunnel Encapsulation Attribute Tunnel Types" registry Encapsulation Attribute Tunnel Types" registry:
* Assign "Member Tunnels", "Backup Tunnels" and "Receiving MPLS - Load-balancing: TBD1
Label Stack" sub-TLV types from the "BGP Tunnel Encapsulation
Attribute Sub-TLVs" registry. The "Member Tunnels" and "Backup
Tunnels" sub-TLV have a two-octet value length (so the type should
be in the 128-255 range), while the "Receiving MPLS Label Stack"
sub-TLV has a one-octet value length.
* Assign "Context Label TLV" type from the "BGP-LS Node Descriptor, - Segment List: TBD2
Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry.
* Assign "Replication State" route type from the "BGP MCAST-TREE * Assign the following sub-TLV types from the "BGP Tunnel
Route Types" registry. Encapsulation Attribute Sub-TLVs" registry:
* Create a "Tree Type Registry for Replication State Route", with - Member Tunnels: TBD3, from range 128-255
the following initial assignments:
- Backup Tunnels: TBD4, from range 128-255
- Receiving MPLS Label Stack: TBD5
* Assign "Context Label TLV" type TBD6 from the "BGP-LS Node
Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
TLVs" registry.
* Assign "Replication State" route type TBD7 from the "BGP MCAST-
TREE Route Types" registry.
* Create a "Tree Type Registry for MCAST-TREE Replication State
Route", with the following initial assignments:
- 2: P2MP Tree with Label as Identification - 2: P2MP Tree with Label as Identification
- 3: IP Multicast - 3: IP Multicast
- 0x43: mLDP - 0x43: mLDP
The registration procedure is "Standards Action".
* Assign a type from the BGP Transitive Extended Community Types * Assign type TBD8 from the BGP Transitive Extended Community Types
registry for the MCAST Extended Community. registry for the MCAST Extended Community.
* Create an MCAST Extended Community Sub-Type registry with the * Create an MCAST Extended Community Sub-Type registry with the
following initial assignments: following initial assignments:
- 0x00-0x02: Reserved - 0x00-0x02: Reserved
- 0x03: NACK (Negative Acknowledgement). - TBD9: NACK (Negative Acknowledgement).
The registration procedure is First Come First Served. The registration procedure is First Come First Served.
7. Acknowledgements 7. Acknowledgements
The authors Eric Rosen for his questions, suggestions, and help The authors Eric Rosen for his questions, suggestions, and help
finding solutions to some issues like the neighbor based explicit RPF finding solutions to some issues like the neighbor based explicit RPF
checking. The authors also thank Lenny Giuliano, Sanoj Vivekanandan checking. The authors also thank Lenny Giuliano, Sanoj Vivekanandan
and IJsbrand Wijnands for their review and comments. and IJsbrand Wijnands for their review and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-bess-bgp-multicast] [I-D.ietf-bess-bgp-multicast]
Zhang, Z. J., Giuliano, L., Patel, K., Wijnands, I., Zhang, Z. J., Giuliano, L., Patel, K., Wijnands, I.,
Mishra, M. P., and A. Gulko, "BGP Based Multicast", Work Mishra, M. P., and A. Gulko, "BGP Based Multicast", Work
in Progress, Internet-Draft, draft-ietf-bess-bgp- in Progress, Internet-Draft, draft-ietf-bess-bgp-
multicast-05, 27 June 2023, multicast-08, 3 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess- <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
bgp-multicast-05>. bgp-multicast-08>.
[I-D.ietf-idr-rt-derived-community] [I-D.ietf-idr-rt-derived-community]
Zhang, Z. J., Haas, J., and K. Patel, "Extended Zhang, Z. J., Haas, J., and K. Patel, "Extended
Communities Derived from Route Targets", Work in Progress, Communities Derived from Route Targets", Work in Progress,
Internet-Draft, draft-ietf-idr-rt-derived-community-00, 7 Internet-Draft, draft-ietf-idr-rt-derived-community-01, 17
March 2023, <https://datatracker.ietf.org/doc/html/draft- January 2024, <https://datatracker.ietf.org/doc/html/
ietf-idr-rt-derived-community-00>. draft-ietf-idr-rt-derived-community-01>.
[I-D.ietf-idr-segment-routing-te-policy] [I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and
D. Jain, "Advertising Segment Routing Policies in BGP", D. Jain, "Advertising Segment Routing Policies in BGP",
Work in Progress, Internet-Draft, draft-ietf-idr-segment- Work in Progress, Internet-Draft, draft-ietf-idr-segment-
routing-te-policy-23, 25 July 2023, routing-te-policy-26, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
segment-routing-te-policy-23>.
[I-D.ietf-idr-wide-bgp-communities]
Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S.,
and P. Jakma, "BGP Community Container Attribute", Work in
Progress, Internet-Draft, draft-ietf-idr-wide-bgp-
communities-11, 9 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr- <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
wide-bgp-communities-11>. segment-routing-te-policy-26>.
[I-D.ietf-pim-sr-p2mp-policy]
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
J. Zhang, "Segment Routing Point-to-Multipoint Policy",
Work in Progress, Internet-Draft, draft-ietf-pim-sr-p2mp-
policy-06, 13 April 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-
p2mp-policy-06>.
[I-D.ietf-spring-sr-replication-segment]
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
J. Zhang, "SR Replication segment for Multi-point Service
Delivery", Work in Progress, Internet-Draft, draft-ietf-
spring-sr-replication-segment-16, 31 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-replication-segment-16>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012, "The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021, DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>. <https://www.rfc-editor.org/info/rfc9012>.
8.2. Informative References 8.2. Informative References
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008,
<https://www.rfc-editor.org/info/rfc5331>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point- Thomas, "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
<https://www.rfc-editor.org/info/rfc6388>. <https://www.rfc-editor.org/info/rfc6388>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>. 2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>. <https://www.rfc-editor.org/info/rfc6514>.
[RFC7060] Napierala, M., Rosen, E., and IJ. Wijnands, "Using LDP [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
Multipoint Extensions on Targeted LDP Sessions", RFC 7060, S. Ray, "North-Bound Distribution of Link-State and
DOI 10.17487/RFC7060, November 2013, Traffic Engineering (TE) Information Using BGP", RFC 7752,
<https://www.rfc-editor.org/info/rfc7060>. DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>. 2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
 End of changes. 114 change blocks. 
301 lines changed or deleted 318 lines changed or added

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