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/ |