| rfc9960v2.txt | rfc9960.txt | |||
|---|---|---|---|---|
| skipping to change at line 237 ¶ | skipping to change at line 237 ¶ | |||
| Section 5.3) procedure to handle a network state change. However, | Section 5.3) procedure to handle a network state change. However, | |||
| one and only one PTI MUST be the active instance of the CP. If more | one and only one PTI MUST be the active instance of the CP. If more | |||
| than one PTI of a CP is active at same time, and that CP is the | than one PTI of a CP is active at same time, and that CP is the | |||
| active CP of the SR P2MP Policy, then duplicate traffic may be | active CP of the SR P2MP Policy, then duplicate traffic may be | |||
| delivered to the Leaf nodes. | delivered to the Leaf nodes. | |||
| A PTI is identified by an Instance-ID. This is an unsigned 16-bit | A PTI is identified by an Instance-ID. This is an unsigned 16-bit | |||
| number that is unique in context of the SR P2MP Policy of the CP. | number that is unique in context of the SR P2MP Policy of the CP. | |||
| PTIs are instantiated using Replication segments. Section 2 of | PTIs are instantiated using Replication segments. Section 2 of | |||
| [RFC9524] specifies the Replication-ID of the Replication-SID tuple | [RFC9524] specifies the Replication-ID of the Replication segment | |||
| as a variable length field that can be modified as required based on | control plane identifier tuple as a variable length field that can be | |||
| the use of a Replication segment. However, length is an imprecise | modified as required based on the use of a Replication segment. | |||
| indicator of the actual structure of the Replication-ID. This | However, length is an imprecise indicator of the actual structure of | |||
| document updates the Replication-ID of a Replication-SID [RFC9524] to | the Replication-ID. This document updates the Replication-ID of the | |||
| be the tuple: <Root, Tree-ID, Instance-ID, Node-ID>, where <Root, | control plane identifier of a Replication segment [RFC9524] to be the | |||
| Tree-ID> identifies the SR P2MP Policy and Instance-ID identifies the | tuple: <Root, Tree-ID, Instance-ID, Node-ID>, where <Root, Tree-ID> | |||
| PTI within that SR P2MP Policy. This results in the Replication | identifies the SR P2MP Policy and Instance-ID identifies the PTI | |||
| segments used to instantiate a PTI being identified by the tuple: | within that SR P2MP Policy. The Replication segments used to | |||
| <Root, Tree-ID, Instance-ID, Node-ID>. In the simplest case, the | instantiate a PTI are thus identified in the control plane by the | |||
| Replication-ID of a Replication segment is a 32-bit number as per | tuple: <Root, Tree-ID, Instance-ID, Node-ID>. As per Section 2 of | |||
| Section 2 of [RFC9524] for which the Root MUST be zero (0.0.0.0 for | [RFC9524], for a simple use case, the Replication-ID is a 32-bit | |||
| IPv4 and :: for IPv6), the Instance-ID MUST be zero, and the 32-bit | number. To map this use case to the tuple for the control plane | |||
| Tree-ID to effectively make the Replication-SID <[0.0.0.0 or ::], | identifier of a Replication segment as defined in this document, the | |||
| Tree-ID, 0, Node-ID>. | Root MUST be zero (0.0.0.0 for IPv4 and :: for IPv6), the Instance-ID | |||
| MUST be zero, and the 32-bit Tree-ID to effectively make the tuple | ||||
| <[0.0.0.0 or ::], Tree-ID, 0, Node-ID>. | ||||
| PTIs may have different tree topologies due to possibly differing | PTIs may have different tree topologies due to possibly differing | |||
| constraints and optimization objectives of the CPs in an SR P2MP | constraints and optimization objectives of the CPs in an SR P2MP | |||
| Policy and across different policies. Even within a given CP, two | Policy and across different policies. Even within a given CP, two | |||
| PTIs of that CP, say during the Make-Before-Break procedure, are | PTIs of that CP, say during the Make-Before-Break procedure, are | |||
| likely to have different tree topologies due to a change in the | likely to have different tree topologies due to a change in the | |||
| network state. Since the PTIs may have different tree topologies, | network state. Since the PTIs may have different tree topologies, | |||
| their replication states also differ at various nodes in the SR | their replication states also differ at various nodes in the SR | |||
| domain. Therefore, each PTI has its own Replication segment and a | domain. Therefore, each PTI has its own Replication segment and a | |||
| unique Replication-SID at a given node in the SR domain. | unique Replication-SID in the data plane at a given node in the SR | |||
| domain. | ||||
| A controller designates an active instance of a CP at the Root node | A controller designates an active instance of a CP at the Root node | |||
| of the SR P2MP Policy by signaling this state through the protocol | of the SR P2MP Policy by signaling this state through the protocol | |||
| used to instantiate the Replication segment of the instance. | used to instantiate the Replication segment of the instance. | |||
| This document focuses on the use of a controller to compute and | This document focuses on the use of a controller to compute and | |||
| instantiate PTIs of SR P2MP Policy CPs. It is also feasible to | instantiate PTIs of SR P2MP Policy CPs. It is also feasible to | |||
| provision an explicit CP in an SR P2MP Policy with a static tree | provision an explicit CP in an SR P2MP Policy with a static tree | |||
| topology using NETCONF/YANG or CLI. Note that a static tree topology | topology using NETCONF/YANG or CLI. Note that a static tree topology | |||
| will not adapt to any changes in the network state of an SR domain. | will not adapt to any changes in the network state of an SR domain. | |||
| skipping to change at line 750 ¶ | skipping to change at line 753 ¶ | |||
| [RFC9855] Bashandy, A., Litkowski, S., Filsfils, C., Francois, P., | [RFC9855] Bashandy, A., Litkowski, S., Filsfils, C., Francois, P., | |||
| Decraene, B., and D. Voyer, "Topology Independent Fast | Decraene, B., and D. Voyer, "Topology Independent Fast | |||
| Reroute Using Segment Routing", RFC 9855, | Reroute Using Segment Routing", RFC 9855, | |||
| DOI 10.17487/RFC9855, October 2025, | DOI 10.17487/RFC9855, October 2025, | |||
| <https://www.rfc-editor.org/info/rfc9855>. | <https://www.rfc-editor.org/info/rfc9855>. | |||
| [SR-LOOP] Bashandy, A., Filsfils, C., Litkowski, S., Decraene, B., | [SR-LOOP] Bashandy, A., Filsfils, C., Litkowski, S., Decraene, B., | |||
| Francois, P., and P. Psenak, "Loop avoidance using Segment | Francois, P., and P. Psenak, "Loop avoidance using Segment | |||
| Routing", Work in Progress, Internet-Draft, draft- | Routing", Work in Progress, Internet-Draft, draft- | |||
| bashandy-rtgwg-segment-routing-uloop-17, 29 June 2024, | bashandy-rtgwg-segment-routing-uloop-18, 19 April 2026, | |||
| <https://datatracker.ietf.org/doc/html/draft-bashandy- | <https://datatracker.ietf.org/doc/html/draft-bashandy- | |||
| rtgwg-segment-routing-uloop-17>. | rtgwg-segment-routing-uloop-18>. | |||
| [SR-P2MP-PCEP] | [SR-P2MP-PCEP] | |||
| Bidgoli, H., Voyer, D., Budhiraja, A., Parekh, R., and S. | Bidgoli, H., Voyer, D., Budhiraja, A., Parekh, R., and S. | |||
| Sivabalan, "PCEP extensions for SR P2MP Policy", Work in | Sivabalan, "PCEP extensions for SR P2MP Policy", Work in | |||
| Progress, Internet-Draft, draft-ietf-pce-sr-p2mp-policy- | Progress, Internet-Draft, draft-ietf-pce-sr-p2mp-policy- | |||
| 14, 23 February 2026, | 14, 23 February 2026, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr- | <https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr- | |||
| p2mp-policy-14>. | p2mp-policy-14>. | |||
| [SR-P2MP-YANG] | [SR-P2MP-YANG] | |||
| End of changes. 4 change blocks. | ||||
| 18 lines changed or deleted | 21 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||