| Network Working Group | D. Voyer, Ed. |
| Internet-Draft | Bell Canada |
| Intended status: Standards Track | C. Filsfils |
| Expires: January 28, 2021 | R. Parekh |
| Cisco Systems, Inc. | |
| H. Bidgoli | |
| Nokia | |
| Z. Zhang | |
| Juniper Networks | |
| July 27, 2020 |
Segment Routing Point-to-Multipoint Policy
draft-ietf-pim-sr-p2mp-policy-00
This document describes an architecture to construct a Point-to-Multipoint (P2MP) tree to deliver Multi-point services in a Segment Routing domain. A SR P2MP tree is constructed by stitching a set of Replication segments together. A SR Point-to-Multipoint (SR P2MP) Policy is used to define and instantiate a P2MP tree which is computed by a PCE.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 28, 2021.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
A Multi-point service delivery could be realized via P2MP trees in a Segment Routing domain [RFC8402]. A P2MP tree spans from a Root node to a set of Leaf nodes via intermediate Replication nodes. It consists of a Replication segment [I-D.ietf-spring-sr-replication-segment] at the root node, one or more Replication segments at Leaf nodes and intermediate Replication nodes. The Replication segments are stitched together.
A Segment Routing P2MP policy, a variant of the SR Policy [I-D.ietf-spring-segment-routing-policy], is used to define a P2MP tree. A PCE is used to compute the tree from the Root node to the set of Leaf nodes via a set of replication nodes. The PCE then instantiates the P2MP tree in the SR domain by signaling Replication segments to Root, replication and Leaf nodes using various protocols (PCEP, BGP, NetConf etc.).
A P2MP tree in a SR domain connects a Root to a set of Leaf nodes via a set of intermediate Replication nodes. It consists of a Replication segment at the root stitched to Replication segments at intermediate Replication nodes eventually reaching the Leaf nodes.
The Replication SID of the Replication Segment at Root node is called Tree-SID. The Tree-SID SHOULD also be used as Replication SID of Replication segments at Replication and Leaf nodes. The Replication segments at Replication and Leaf nodes MAY use Replication SIDs that are not same as the Tree-SID.
The Replication segment at Root of a P2MP tree MUST be associated with that P2MP tree (i.e. <Root, Tree-ID> identifier in SR P2MP policy section below) to map a Multi-point service to the tree. A Replication segment that terminates a P2MP tree at a Leaf node MUST be associated with the P2MP tree to determine the context for a Multi-point service. The The information that can be used to derive this association is specific to encoding of the protocol (PCEP, BGP, NetConf etc.) used to instantiate the Replication segment for a P2MP tree. Replication segments at intermediate Replication nodes of a tree are also associated with that tree.
A PCE MAY decide not instantiate Replication segments at Leaf nodes of a P2MP tree if it is known a priori that Multi-point services mapped to the P2MP tree can be identified using a context that is globally unique in SR domain. Multi-point service contexts assigned from "Domain-wide Common Block" (DCB) [I-D.ietf-bess-mvpn-evpn-aggregation-label] are an example of such globally unique contexts. A Segment Routing Global Block (SRGB) [RFC8402] MAY be used to allocate globally unique Multi-point service contexts, but it is NOT RECOMMENDED to do so as the service contexts only need to be unique at service edge nodes. In this case, Replication nodes connecting to Leaf nodes SHOULD use Penultimate-Hop Pop (PHP) behavior to pop Tree-SID from a packet.
A packet steered into a P2MP tree is replicated by the Replication segment at Root node to each downstream node in the Replication segment, with the Replication SID of the Replication Segment at the downstream node. A downstream node could be a Leaf node or an intermediate Replication node. In the latter case, replication continues with the Replication segments until all Leaf nodes are reached. A packet is steered into a P2MP tree in two ways:
Two or more P2MP trees MAY share a Replication segment at Root or Replication nodes if at minimum as the first condition below is satisfied. A tree always has its own Replication segment at its root even if shares another Replication segment. A tree that shares another Replication segment may or may not have its own Replication segment on its Leaf nodes. If not, the second and third conditions apply to such situations.
Sharing of a Replication segment for P2MP trees is OPTIONAL. Exact procedures to ensure validity of above conditions across PM2P services on nodes of a Segment Routing domain are outside the scope of this document.
The SR P2MP policy is a variant of an SR policy[I-D.ietf-spring-segment-routing-policy] and is used to instantiate SR P2MP trees.
A SR P2MP Policy is identified by the tuple <Root, Tree-ID>, where:
A SR P2MP Policy is defined by following elements:
A SR P2MP policy is provisioned on a PCE to instantiate the P2MP tree. The Tree-SID SHOULD be used as Binding SID of the P2MP policy. A PCE computes the P2MP tree and instantiates Replication segments at Root, Replication and Leaf nodes. When Replication segments are not shared across P2MP trees, the Root and Tree-ID of the SR P2MP policy are mapped to Replication-ID element of the Replication segment identifier i.e the SR Replication segment identifier is <Root, Tree-ID, Node-ID>. A shared Replication segment MAY be identified with zero Root-ID address (0.0.0.0 for IPv4 and :: for IPv6) and a Replication-ID that is unique in context of Node address where the Replication segment is instantiated when it is not associated a particular tree.
A SR P2MP Policy has one or more Candidate paths. The active Candidate path is selected based on the tie breaking rules amongst the candidate-paths as specified in[I-D.ietf-spring-segment-routing-policy]. Each candidate path has a set of topological/resource constraints and/or optimization objectives which determine the P2MP tree for that Candidate path. Tree-SID is an identifier of the P2MP tree of the candidate path in the forwarding plane. It is instantiated in the forwarding plane at Root node, intermediate Replication nodes and Leaf nodes. The Tree-SID MAY be different at Replication and Leaf nodes.
A P2MP tree can be built using a Path Computation Element (PCE). This section outlines a high-level architecture for such an approach.
North Bound South Bound
Programming ..... Programming
Interface Interface
|
|
v
+-----+ ..........................
.............| PCE | ............. .
. +-----+ . .
. . . .
. . . .
. . . .
. . V .
. . +----+ .
. . | N3 | .
. . +----+ .
. . | Leaf (L2) .
. . | .
. . | .
V V | V
+----+ +----+ -------------- +----+
| N1 |----------| N2 |-------------------------| N4 |
+----+ +----+ +----+
Root (R) Replication node (M) Leaf (L1)
Figure 1: Centralized Control Plane Model
A SR P2MP policy can be instantiated and maintained in a centralized fashion using a Path Computation Element (PCE).
North-bound APIs on a PCE can be used to:
Interaction with a PCE can be via PCEP, REST, Netconf, gRPC, CLI. Yang model shall be be developed for this purpose as well.
An entity (an operator, a network node or a machine) provisions a SR P2MP policy by specifying the addresses of the root (R) and set of leaves {L} as well as Traffic Engineering (TE) attributes of Candidate paths via a suitable North-Bound API. The PCE computes the tree of Active candidate path. The PCE MAY compute P2MP trees for all Candidate paths., If tree computation is successful, PCE instantiates the P2MP tree(s) using Replication segments on Root, Replication, and Leaf nodes.
Candidate path constraints shall include link color affinity, bandwidth, disjointness (link, node, SRLG), delay bound, link loss, etc. Candidate path shall be optimized based on IGP or TE metric or link latency.
The Tree SID of Candidate path of a SR P2MP policy can be either dynamically allocated by the PCE or statically assigned by entity provisioning the SR P2MP policy. Ideally, same Tree-SID SHOULD be used for Replication segments at Root, Replication, and Leaf nodes. Different Tree-SIDs MAY be used at replication node(s) if it is not feasible to use same Tree SID.
A PCE can modify a P2MP tree following network element failure or in case a better path can be found based on the new network state. In this case, the PCE may want to setup the new instance of the tree and remove the old instance of the tree from the network in order to minimize traffic loss. In this case, the instances of trees for all the Candidate paths of a P2MP policy can be identified by an Instance-ID which is unique in context of the P2MP policy. As such, the identifier of non-shared Replication segments used to instantiate these trees becomes <Root-ID, Tree-ID, Node-ID, Instance-ID>.
A PCE shall be capable of computing paths across multiple IGP areas or levels as well as Autonomous Systems (ASs).
A PCE shall learn network topology, TE attributes of link/node as well as SIDs via dynamic routing protocols (IGP and/or BGP-LS). It may be possible for entities to pass topology information to PCE via north-bound API.
It shall be possible for a node to advertise SR P2MP tree capability via IGP and/or BGP-LS. Similarly, a PCE can also advertise its P2MP tree computation capability via IGP and/or BGP-LS. Capability advertisement allows a network node to dynamically choose one or more PCE(s) to obtain services pertaining to SR P2MP policies, as well a PCE to dynamically identify SR P2MP tree capable nodes.
Once a PCE computes a P2MP tree for Candidate path of SR P2MP policy, it needs to instantiate the tree on the relevant network nodes via Replication segments. The PCE can use various protocols to program the Replication segments as described below.
PCE Protocol (PCEP)has been traditionally used:
PCEP protocol can be stateful in that a PCE can have a stateful control of an SR policy on a head-end which has delegated the control of the SR policy to the PCE. PCEP shall be extended to provision and maintain SR P2MP trees in a stateful fashion.
BGP has been extended to instantiate and report SR policies. It shall be extended to instantiate and maintain P2MP trees for SR P2MP policies.
TBD
A network link, node or path on the tree of a P2MP tree can be protected using SR policies computed by PCE. The backup SR policies shall be programmed in forwarding plane in order to minimize traffic loss when the protected link/node fails. It is also possible to use node local Fast Re-Route protection mechanisms (LFA) to protect link/nodes of P2MP tree.
It is possible for PCE create a disjoint backup tree for providing end-to-end path protection.
This document makes no request of IANA.
There are no additional security risks introduced by this design.
The authors would like to acknowledge Siva Sivabalan, Mike Koldychev and Vishnu Pavan Beeram for their valuable inputs..
Clayton Hassen
Bell Canada
Vancouver
Canada
Email: clayton.hassen@bell.ca
Kurtis Gillis
Bell Canada
Halifax
Canada
Email: kurtis.gillis@bell.ca
Arvind Venkateswaran
Cisco Systems, Inc.
San Jose
US
Email: arvvenka@cisco.com
Zafar Ali
Cisco Systems, Inc.
US
Email: zali@cisco.com
Swadesh Agrawal
Cisco Systems, Inc.
San Jose
US
Email: swaagraw@cisco.com
Jayant Kotalwar
Nokia
Mountain View
US
Email: jayant.kotalwar@nokia.com
Tanmoy Kundu
Nokia
Mountain View
US
Email: tanmoy.kundu@nokia.com
Andrew Stone
Nokia
Ottawa
Canada
Email: andrew.stone@nokia.com
Tarek Saad
Juniper Networks
Canada
Email:tsaad@juniper.net
| [I-D.ietf-spring-segment-routing-policy] | Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A. and P. Mattes, "Segment Routing Policy Architecture", Internet-Draft draft-ietf-spring-segment-routing-policy-08, July 2020. |
| [I-D.ietf-spring-sr-replication-segment] | Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H. and Z. Zhang, "SR Replication Segment for Multi-point Service Delivery", Internet-Draft draft-ietf-spring-sr-replication-segment-00, July 2020. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC8402] | Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S. and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018. |
| [I-D.ietf-bess-mvpn-evpn-aggregation-label] | Zhang, Z., Rosen, E., Lin, W., Li, Z. and I. Wijnands, "MVPN/EVPN Tunnel Aggregation with Common Labels", Internet-Draft draft-ietf-bess-mvpn-evpn-aggregation-label-03, October 2019. |
| [RFC7900] | Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y. and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", RFC 7900, DOI 10.17487/RFC7900, June 2016. |
Consider the following topology:
R3------R6
PCE--/ \
R1----R2----R5-----R7
\ /
+--R4---+
Figure 1
In these examples, the Node-SID of a node Rn is N-SIDn and Adjacency-SID from node Rm to node Rn is A-SIDmn. Interface between Rm and Rn is Lmn.
Assume PCE is provisioned following SR P2MP policy at Root R1 with Tree-ID T-ID:
SR P2MP Policy <R1,T-ID>:
Leaf Nodes: {R2, R6, R7}
Candidate-path 1:
Optimize: IGP metric
Tree-SID: T-SID1
The PCE is responsible for P2MP tree computation. Assume PCE instantiates P2MP trees by signalling non-shared Replication segments i.e. Replication-ID of these Replication Segments is <Root, Tree-ID>. If a Candidat-path can have multiple instances of P2MP trees, the Replication-ID is <Root, Tree-ID, Instance-ID>. In this example, we assume one instance of P2MP tree for a candidate-path. All Replication Segments use the Tree-SID T-SID1 as Replication-SID.
Assume PCE computes a P2MP tree with Root node R1, Intermediate and Leaf node R2, and Leaf nodes R6 and R7. The PCE instantiates the P2MP tree by stitching Replication Segments at R1, R2, R6 and R7. Replication Segment at R1 replicates to R2. Replication Segment at R2 replicates to R6 and R7. Note nodes R3, R4 and R5 do not have any Replication Segment state for the tree.
The Replication Segment state at nodes R1, R2, R6 and R7 is shown below.
Replication Segment at R1:
Replication Segment <R1,T-ID,R1>: Replication SID: T-SID1 Replication State: R2: <T-SID1->L12>
Replication to R2 steers packet directly to the node on interface L12.
Replication Segment at R2:
Replication Segment <R1,T-ID,R2>: Replication SID: T-SID1 Replication State: R2: <Leaf> R6: <N-SID6, T-SID1> R7: <N-SID7, T-SID1>
R2 is a Bud-Node. It performs role of Leaf as well as a transit node replicating to R6 and R7. Replication to R6, using N-SID6, steers packet via IGP shortest path to that node. Replication to R7, using N-SID7, steers packet via IGP shortest path to R7 via either R5 or R4 based on ECMP hashing.
Replication Segment at R6:
Replication Segment <R1,T-ID,R6>: Replication SID: T-SID1 Replication State: R6: <Leaf>
Replication Segment at R7:
Replication Segment <R1,T-ID,R7>: Replication SID: T-SID1 Replication State: R7: <Leaf>
When a packet is steered into the SR P2MP Policy at R1:
Assume PCE computes a P2MP tree with Root node R1, Intermediate and Leaf node R2, Intermediate nodes R3 and R5, and Leaf nodes R6 and R7. The PCE instantiates the P2MP tree by stitching Replication Segments at R1, R2, R3, R5, R6 and R7. Replication Segment at R1 replicates to R2. Replication Segment at R2 replicates to R3 and R5. Replication segment at R3 replicates to R6. Replication segment at R5 replicates to R7. Note node R4 does not have any Replication Segment state for the tree.
The Replication Segment state at nodes R1, R2, R3, R5, R6 and R7 is shown below.
Replication Segment at R1:
Replication Segment <R1,T-ID,R1>: Replication SID: T-SID1 Replication State: R2: <T-SID1->L12>
Replication to R2 steers packet directly to tje node on interface L12.
Replication Segment at R2:
Replication Segment <R1,T-ID,R2>: Replication SID: T-SID1 Replication State: R2: <Leaf> R3: <T-SID1->L23> R5: <T-SID1->L25>
R2 is a Bud-Node. It performs role of Leaf as well as a transit node replicating to R3 and R5. Replication to R3, steers packet directly to the node on L23. Replication to R5, steers packet directly to the node on L25.
Replication Segment at R3:
Replication Segment <R1,T-ID,R3>: Replication SID: T-SID1 Replication State: R6: <T-SID1->L36>
Replication to R6, steers packet directly to the node on L36.
Replication Segment at R5:
Replication Segment <R1,T-ID,R5>: Replication SID: T-SID1 Replication State: R7: <T-SID1->L57>
Replication to R7, steers packet directly to the node on L57.
Replication Segment at R6:
Replication Segment <R1,T-ID,R6>: Replication SID: T-SID1 Replication State: R6: <Leaf>
Replication Segment at R7:
Replication Segment <R1,T-ID,R7>: Replication SID: T-SID1 Replication State: R7: <Leaf>
When a packet is steered into the SR P2MP Policy at R1: