Segment Routing Point-to-Multipoint Policy
draft-ietf-pim-sr-p2mp-policy-09

Network Working Group                                      D. Voyer, Ed.
Internet-Draft                                               Bell Canada
Intended status: Standards Track                             C. Filsfils
Expires: 7 November 2024                                       R. Parekh
                                                     Cisco Systems, Inc.
                                                              H. Bidgoli
                                                                   Nokia
                                                                Z. Zhang
                                                        Juniper Networks
                                                              6 May 2024

               Segment Routing Point-to-Multipoint Policy
                    draft-ietf-pim-sr-p2mp-policy-09

Abstract

   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.  A SR Point-to-Multipoint (SR P2MP) Policy
   defines a P2MP tree and a PCE computes and instantiates the tree.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Status of This Memo

   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 7 November 2024.

Voyer, Ed., et al.       Expires 7 November 2024                [Page 1]
Internet-Draft               SR P2MP Policy                     May 2024

Copyright Notice

   Copyright (c) 2024 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  SR P2MP Policy  . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  P2MP Tree . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Using Controller to build a P2MP Tree . . . . . . . . . . . .   5
     4.1.  Provisioning SR P2MP Policy Creation  . . . . . . . . . .   6
       4.1.1.  API . . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.1.2.  Invoking API  . . . . . . . . . . . . . . . . . . . .   7
     4.2.  P2MP Tree Computation . . . . . . . . . . . . . . . . . .   7
       4.2.1.  Topology Discovery  . . . . . . . . . . . . . . . . .   8
       4.2.2.  Capability and Attribute Discovery  . . . . . . . . .   8
       4.2.3.  Loop Prevention . . . . . . . . . . . . . . . . . . .   8
     4.3.  Instantiating P2MP tree on nodes  . . . . . . . . . . . .   9
       4.3.1.  PCEP  . . . . . . . . . . . . . . . . . . . . . . . .   9
       4.3.2.  BGP . . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.4.  Protection  . . . . . . . . . . . . . . . . . . . . . . .   9
       4.4.1.  Local Protection  . . . . . . . . . . . . . . . . . .   9
       4.4.2.  Path Protection . . . . . . . . . . . . . . . . . . .  10
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  11
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Appendix A.  Illustration of SR P2MP Policy and P2MP Tree . . . .  13
     A.1.  P2MP Tree with non-adjacent Replication Segments  . . . .  15
       A.1.1.  SR-MPLS . . . . . . . . . . . . . . . . . . . . . . .  15
       A.1.2.  SRv6  . . . . . . . . . . . . . . . . . . . . . . . .  16
     A.2.  P2MP Tree with adjacent Replication Segments  . . . . . .  18
       A.2.1.  SR-MPLS . . . . . . . . . . . . . . . . . . . . . . .  18
       A.2.2.  SRv6  . . . . . . . . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

Voyer, Ed., et al.       Expires 7 November 2024                [Page 2]
Internet-Draft               SR P2MP Policy                     May 2024

1.  Introduction

   A Multi-point service delivery can be realized with 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 [RFC9524] at the root node,
   stitched to one or more Replication segments at Leaf nodes and
   intermediate Replication nodes.  A Bud node [RFC9524] is a node that
   is both a Replication node and a Leaf node.  Any mention of "Leaf
   node(s)" in this document should be considered as referring to "Leaf
   or Bud node(s)".

   A Segment Routing P2MP policy, a variant of the SR Policy [RFC9256],
   defines the Root and Leaf nodes of a P2MP tree.  One or more
   Candidate Paths define optional constraints and/or optimization
   objectives for the tree.  A PCE computes the tree from the Root node
   to the set of Leaf nodes via a set of Replication nodes based on a SR
   P2MP Policy.  The PCE then instantiates the P2MP tree in the SR
   domain by signaling Replication segments to Root, Replication and
   Leaf nodes using protocols such as PCEP, BGP, NetConf etc.  The
   Replication segments of a P2MP tree can be instantiated for SR-MPLS
   and SRv6 dataplanes.

2.  SR P2MP Policy

   An SR P2MP policy is a variant of an SR policy[RFC9256] and is used
   to instantiate SR P2MP trees.

   A SR P2MP Policy is identified by the tuple <Root, Tree-ID>, where:

   *  Root: The address of Root node of a P2MP tree instantiated by the
      SR P2MP Policy

   *  Tree-ID: An identifier that is unique in context of the Root.
      This is an unsigned 32-bit number.

   A SR P2MP Policy is defined by following elements:

   *  Leaf nodes: A set of nodes that terminate the P2MP trees.

   *  Candidate Paths: See below.

   A SR P2MP policy is provisioned on a PCE to compute and instantiate
   P2MP trees.  A PCE computes the P2MP tree instances of a policy and
   instantiates Replication segments at Root, Replication and Leaf nodes
   of the trees.  The Root and Tree-ID of the SR P2MP policy are mapped
   to Replication-ID element of the Replication segment
   identifier[RFC9524].

Voyer, Ed., et al.       Expires 7 November 2024                [Page 3]
Internet-Draft               SR P2MP Policy                     May 2024

   A SR P2MP Policy has one or more Candidate Paths.  Each Candidate
   Path has optional topological/resource constraints and/or
   optimization objectives that determine the P2MP trees computed for
   that Candidate Path.  The Root node selects the active Candidate Path
   based on the tie breaking rules amongst the candidate-paths as
   specified in[RFC9256].

   A Candidate Path has zero or more P2MP tree instances.  Instance-ID
   is the identifier of an instance of a Candidate Path.  This is an
   unsigned 16-bit number which is unique in context of the SR P2MP
   policy of the Candidate Path.  The identifier of Replication segments
   used to instantiate an instance is <Root-ID, Tree-ID, Instance-ID,
   Node-ID>.  The PCE designates an Active instance of a Candidate Path
   at the Root node of SR P2MP policy by signalling this state in the
   protocol used to instantiate the Replication segment of the instance.

   The Tree-SID (Section 3 below) is an identifier of a P2MP tree
   instance in the forwarding plane.  It is instantiated in the
   forwarding plane at Root node, intermediate Replication nodes and
   Leaf nodes of the P2MP tree of an instance.  The Tree-SID of the
   active instance of the active Candidate Path SHOULD be used as
   Binding SID of the SR P2MP policy.

   The Root node steers an incoming packet of a Multi-point service into
   a SR P2MP policy in one of two ways:

   *  Based on a local policy-based routing at the Root node.  This
      packet is carried by the active instance of the active Candidate
      Path of the policy.

   *  Based on the Tree-SID (Binding SID) in the incoming packet.

3.  P2MP Tree

   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 zero or more Replication
   segments at intermediate Replication nodes, and eventually the
   Replication segments at Leaf nodes.

   The Replication SID of the Replication segment at Root node is called
   the Tree-SID.  The Tree-SID SHOULD also be the Replication-SID of
   Replication segments at Replication and Leaf nodes.  The Replication
   segments at Replication and Leaf nodes MAY have Replication-SIDs that
   are not same as the Tree-SID.

Voyer, Ed., et al.       Expires 7 November 2024                [Page 4]
Internet-Draft               SR P2MP Policy                     May 2024

   A Replication Segment MAY be shared by P2MP tree instances, e.g. for
   protection.  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.  A shared Replication Segment MUST NOT be
   associated with a SR P2MP tree.

   For SR-MPLS, a PCE MAY decide not to 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. In this case, Replication nodes
   upstream to the Leaf nodes effectively implement Penultimate-Hop Pop
   (PHP) behavior to pop Tree-SID from a packet.  A Multi-point service
   context assigned from "Domain-wide Common Block" (DCB)
   [I-D.ietf-bess-mvpn-evpn-aggregation-label] is an example of a
   globally unique context.

   A packet steered into a P2MP tree instance is replicated by the
   Replication segment at Root node to its downstream nodes.  A
   replicated packet has the Replication-SID of the Replication segment
   at a downstream node.  A downstream node could be a Leaf node or an
   intermediate Replication Node.  In the latter case, the packet is
   replicated through Replication segments till it reaches all the Leaf
   nodes.

4.  Using Controller to build a P2MP Tree

   A P2MP tree can be instantited by a Path Computation Element (PCE).
   This section outlines a high-level architecture for such an approach.

Voyer, Ed., et al.       Expires 7 November 2024                [Page 5]
Internet-Draft               SR P2MP Policy                     May 2024

                         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

4.1.  Provisioning SR P2MP Policy Creation

   A SR P2MP policy can be instantiated and maintained in a Path
   Computation Element (PCE).

4.1.1.  API

   North-bound APIs on a PCE can be used to:

   1.  Create SR P2MP policy: CreateSRP2MPPolicy<Root, Tree-ID>

   2.  Delete SR P2MP policy: DeleteSRP2MPPolicy<Root, Tree-ID>

   3.  Modify SR P2MP policy Leaf Set: SRP2MPPolicyLeafSetModify<Root,
       Tree-ID, {Leaf Set}>

   4.  Create a Candidate Path for SR P2MP policy:
       CreateSRP2MPCandidatePath<Root, Tree-ID, CP-ID> , Preference,
       Constraints, Optimization, ...>

Voyer, Ed., et al.       Expires 7 November 2024                [Page 6]
Internet-Draft               SR P2MP Policy                     May 2024

   5.  Update a Candidate Path for SR P2MP policy:
       UpdateSRP2MPCandidatePath<Root, Tree-ID, CP-ID, Preference,
       Constraints, Optimization, ...>

   6.  Delete a Candidate Path for SR P2MP policy:
       DeleteSRP2MPCandidatePath<Root, Tree-ID, CP-ID>

   CP-ID is the identifier of a Candidate Path within a SR P2MP policy.
   One possible identifier is the tuple <Protocol-Origin, originator,
   discriminator> as specified in [RFC9256].

   Note these are conceptual APIs.  Actual implementations may offer
   different APIs as long as they provide same functionality.  For
   example, API might allow symbolic name to be assigned for a P2MP
   policy or APIs might allow individual Leaf nodes to be added or
   deleted from a policy instead of an update operation.

4.1.2.  Invoking API

   Interaction with a PCE can be via PCEP, REST, Netconf, gRPC, CLI.  A
   YANG model shall be be developed for this purpose as well.

4.2.  P2MP Tree Computation

   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 one
   or more instances of P2MP trees of a Candidate Path.  The PCE MAY
   compute P2MP trees for all Candidate Paths.  If tree computation is
   successful, PCE instantiates the P2MP tree instance(s) using
   Replication segments on Root, Replication, and Leaf nodes.  A
   Candidate Path may not have any instance of P2MP tree if PCE cannot
   compute a tree.

   Candidate Path constraints shall include link color affinity,
   bandwidth, disjointness (link, node, SRLG), delay bound, link loss,
   flexible algorithm etc.  Candidate Path shall be optimized based on
   IGP or TE metric or link latency.  Other constraints and optimization
   objectives MAY be used for P2MP tree computation.

   The Tree SID of an instance of a 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.

Voyer, Ed., et al.       Expires 7 November 2024                [Page 7]
Internet-Draft               SR P2MP Policy                     May 2024

   A PCE can modify a P2MP tree of a Candidate Path on detecting a
   change in the network topology or in case a better path can be found
   based on the new network state.  In this case, the PCE MAY create a
   new instance of a P2MP tree and remove the old instance of the tree
   from the network in order to minimize traffic loss.

   A PCE shall be capable of computing paths across multiple IGP areas
   or levels as well as Autonomous Systems (ASs).

4.2.1.  Topology Discovery

   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.

4.2.2.  Capability and Attribute Discovery

   It shall be possible for a node to advertise SR P2MP tree capability
   via IGP, BGP-LS and/or PCEP.  Similarly, a PCE can also advertise its
   P2MP tree computation capability via IGP, BGP-LS and/or PCEP.
   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.

4.2.3.  Loop Prevention

   A PCE MUST compute a P2MP tree such that there are no loops in the
   tree at steady state (Section 2 of [RFC9524]).  An OPTIONAL algorithm
   to compute a loop free tree is listed below,

   Given SR P2MP Policy with Root (R) and Leaf node set (LS), a
   Candidate Path of the policy with constraints(C) and optimization
   objective(O), and Constrained Shortest Path First(CSPF) algorithm to
   compute a path between a pair of nodes:

   S01.  Path Set<PS> = {}
   S02.  For each Leaf(L) in LS {
   S03.    Path P = Compute CSPF(R, L, C, O)
   S04.    Add P to PS
   S05.  }
   S06.  Tree = Merge(PS)

   Notes:

   *  Specification of CSPF algorithm is outside the scope of this
      document

Voyer, Ed., et al.       Expires 7 November 2024                [Page 8]
Internet-Draft               SR P2MP Policy                     May 2024

   *  Path Set Merge function merges individual paths resulting in a
      tree of Root, intermediate Replication and Leaf nodes.  The
      specfication of this function is outside the scope of this
      document.

   A PCE MAY implement other tree computation algorithm(s) which MUST
   guarantee loop prevention or loop detection and mitigation at steady
   state.

4.3.  Instantiating P2MP tree on nodes

   Once a PCE computes a P2MP tree for an instance of a Candidate Path
   of a 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.

4.3.1.  PCEP

   PCE Protocol (PCEP) has been traditionally used:

   1.  For a head-end to obtain paths from a PCE.

   2.  A PCE to instantiate SR policies.

   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.

4.3.2.  BGP

   BGP has been extended to instantiate and report SR policies.  It
   shall be extended to instantiate and maintain P2MP trees for SR P2MP
   policies.

4.4.  Protection

4.4.1.  Local Protection

   A network link, node or path on the instance 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 Loop-Free Alternate protection mechanisms (LFA) to protect
   link/nodes of P2MP tree.

Voyer, Ed., et al.       Expires 7 November 2024                [Page 9]
Internet-Draft               SR P2MP Policy                     May 2024

4.4.2.  Path Protection

   It is possible for PCE create a disjoint backup tree for providing
   end-to-end path protection.

5.  IANA Considerations

   This document makes no request of IANA.

6.  Security Considerations

   This document describes how a P2MP tree can be created in an SR
   domain by stitching Replication Segments together.  Some security
   considerations for Replication Segments outlined in [RFC9524] are
   also appicable to this document.  Following is a brief reminder of
   the same.

   An SR domain needs protection from outside attackers as described in
   [RFC8754].

   Failure to protect the SR MPLS domain by correctly provisioning MPLS
   support per interface permits attackers from outside the domain to
   send packets to receivers of the Multipoint services that use the SR
   P2MP trees provisioned within the domain.

   Failure to protect the SRv6 domain with inbound Infrastructure Access
   Control Lists (IACLs) on external interfaces, combined with failure
   to implement BCP 38 [RFC2827]or apply IACLs on nodes provisioning
   SIDs, permits attackers from outside the SR domain to send packets to
   the receivers of Multipoint services that use the SR P2MP trees
   provisioned within the domain.

   Incorrect provisioning of Replication segments by a PCE that computes
   SR P2MP tree instance can result in a chain of Replication segments
   forming a loop.  In this case, replicated packets can create a storm
   till MPLS TTL (for SR-MPLS) or IPv6 Hop Limit (for SRv6) decrements
   to zero.

   The control plane protocols (like PCEP, BGP, etc.) used to
   instantiate Replication segments of SR P2MP tree instance can
   leverage their own security mechanisms such as encryption,
   authentication filtering etc.

Voyer, Ed., et al.       Expires 7 November 2024               [Page 10]
Internet-Draft               SR P2MP Policy                     May 2024

   For SRv6, [RFC9524] describes an exception for Parameter Problem
   Message, code 2 ICMPv6 Error messages.  If an attacker is able to
   inject a packet into Multipoint service with source address of a node
   and with an extension header using unknown option type marked as
   mandatory, then a large number of ICMPv6 Parameter Problem messages
   can cause a denial-of-service attack on the source node.

7.  Acknowledgements

   The authors would like to acknowledge Siva Sivabalan, Mike Koldychev
   and Vishnu Pavan Beeram for their valuable inputs.

8.  Contributors

   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

Voyer, Ed., et al.       Expires 7 November 2024               [Page 11]
Internet-Draft               SR P2MP Policy                     May 2024

   Email:tsaad@juniper.net

   Kamran Raza Cisco Systems, Inc.  Canada

   Email:skraza@cisco.com

   Anuj Budhiraja Cisco Systems, Inc.  US

   Email:abudhira@cisco.com

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
              A., and P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, DOI 10.17487/RFC9256, July 2022,
              <https://www.rfc-editor.org/info/rfc9256>.

   [RFC9524]  Voyer, D., Ed., Filsfils, C., Parekh, R., Bidgoli, H., and
              Z. Zhang, "Segment Routing Replication for Multipoint
              Service Delivery", RFC 9524, DOI 10.17487/RFC9524,
              February 2024, <https://www.rfc-editor.org/info/rfc9524>.

9.2.  Informative References

   [I-D.filsfils-spring-srv6-net-pgm-illustration]
              Filsfils, C., Camarillo, P., Li, Z., Matsushima, S.,
              Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and
              J. Leddy, "Illustrations for SRv6 Network Programming",
              Work in Progress, Internet-Draft, draft-filsfils-spring-
              srv6-net-pgm-illustration-04, 30 March 2021,
              <https://datatracker.ietf.org/doc/html/draft-filsfils-
              spring-srv6-net-pgm-illustration-04>.

Voyer, Ed., et al.       Expires 7 November 2024               [Page 12]
Internet-Draft               SR P2MP Policy                     May 2024

   [I-D.ietf-bess-mvpn-evpn-aggregation-label]
              Zhang, Z. J., Rosen, E. C., Lin, W., Li, Z., and I.
              Wijnands, "MVPN/EVPN Tunnel Aggregation with Common
              Labels", Work in Progress, Internet-Draft, draft-ietf-
              bess-mvpn-evpn-aggregation-label-14, 4 October 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
              mvpn-evpn-aggregation-label-14>.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
              May 2000, <https://www.rfc-editor.org/info/rfc2827>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

Appendix A.  Illustration of SR P2MP Policy and P2MP Tree

   Consider the following topology:

                                  R3------R6
                            PCE--/         \
                         R1----R2----R5-----R7
                                 \         /
                                  +--R4---+

                             Figure 2: 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.

   For SRv6, the reader is expected to be familiar with SRv6 Network
   Programming [RFC8986] to follow the examples.  This document re-uses
   SID allocation scheme, reproduced below, from Illustrations in SRv6
   Network Programming [I-D.filsfils-spring-srv6-net-pgm-illustration]

   *  2001:db8::/32 is an IPv6 block allocated by a RIR to the operator

   *  2001:db8:0::/48 is dedicated to the internal address space

Voyer, Ed., et al.       Expires 7 November 2024               [Page 13]
Internet-Draft               SR P2MP Policy                     May 2024

   *  2001:db8:cccc::/48 is dedicated to the internal SRv6 SID space

   *  We assume a location expressed in 64 bits and a function expressed
      in 16 bits

   *  node k has a classic IPv6 loopback address 2001:db8::k/128 which
      is advertised in the IGP

   *  node k has 2001:db8:cccc:k::/64 for its local SID space.  Its SIDs
      will be explicitly assigned from that block

   *  node k advertises 2001:db8:cccc:k::/64 in its IGP

   *  Function :1:: (function 1, for short) represents the End function
      with PSP support

   *  Function :Cn:: (function Cn, for short) represents the End.X
      function to node n

   *  Function :C1n: (function C1n for short) represents the End.X
      function to node n with USD

   Each node k has:

   *  An explicit SID instantiation 2001:db8:cccc:k:1::/128 bound to an
      End function with additional support for PSP

   *  An explicit SID instantiation 2001:db8:cccc:k:Cj::/128 bound to an
      End.X function to neighbor J with additional support for PSP

   *  An explicit SID instantiation 2001:db8:cccc:k:C1j::/128 bound to
      an End.X function to neighbor J with additional support for USD

   Assume a PCE is provisioned with 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

Voyer, Ed., et al.       Expires 7 November 2024               [Page 14]
Internet-Draft               SR P2MP Policy                     May 2024

   The PCE is responsible for computing a P2MP tree instance of the
   Candidate Path.  In this example, we assume one active instance of
   P2MP tree with Instance-ID I-ID1.  Assume PCE instantiates P2MP trees
   by signalling Replication segments i.e. Replication-ID of these
   Replication segments is <Root, Tree-ID, Instance-ID>.. All
   Replication segments use the Tree-SID T-SID1 as Replication-SID.  For
   SRv6, assume the Replication-SID at node k, bound to an End.Replicate
   function, is 2001:db8:cccc:k:FA::/128.

A.1.  P2MP Tree with non-adjacent Replication Segments

   Assume PCE computes a P2MP tree instance with Root node R1,
   Intermediate and Leaf node R2, and Leaf nodes R6 and R7.  The PCE
   instantiates the instance 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.

A.1.1.  SR-MPLS

   The Replication segment state at nodes R1, R2, R6 and R7 is shown
   below.

   Replication segment at R1:

   Replication segment <R1,T-ID,I-ID1,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,I-ID1,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.

Voyer, Ed., et al.       Expires 7 November 2024               [Page 15]
Internet-Draft               SR P2MP Policy                     May 2024

   Replication segment at R6:

   Replication segment <R1,T-ID,I-ID1,R6>:
    Replication-SID: T-SID1
    Replication State:
      R6: <Leaf>

   Replication segment at R7:

   Replication segment <R1,T-ID,I-ID1,R7>:
    Replication-SID: T-SID1
    Replication State:
      R7: <Leaf>

   When a packet is steered into the active instance Candidate Path 1 of
   SR P2MP Policy at R1:

   *  Since R1 is directly connected to R2, R1 performs PUSH operation
      with just <T-SID1> label for the replicated copy and sends it to
      R2 on interface L12.

   *  R2, as Leaf, performs NEXT operation, pops T-SID1 label and
      delivers the payload.  For replication to R6, R2 performs a PUSH
      operation of N-SID6, to send <N-SID6,T-SID1> label stack to R3.
      R3 is the penultimate hop for N-SID6; it performs penultimate hop
      popping, which corresponds to the NEXT operation and the packet is
      then sent to R6 with <T-SID1> in the label stack.  For replication
      to R7, R2 performs a PUSH operation of N-SID7, to send
      <N-SID7,T-SID1> label stack to R4, one of IGP ECMP nexthops
      towards R7.  R4 is the penultimate hop for N-SID7; it performs
      penultimate hop popping, which corresponds to the NEXT operation
      and the packet is then sent to R7 with <T-SID1> in the label
      stack.

   *  R6, as Leaf, performs NEXT operation, pops T-SID1 label and
      delivers the payload.

   *  R7, as Leaf, performs NEXT operation, pops T-SID1 label and
      delivers the payload.

A.1.2.  SRv6

   For SRv6, the replicated packet from R2 to R7 has to traverse R4
   using a SR-TE policy, Policy27.  The policy has one SID in segment
   list: End.X function with USD of R4 to R7 . The Replication segment
   state at nodes R1, R2, R6 and R7 is shown below.

   Policy27: <2001:db8:cccc:4:C17::>

Voyer, Ed., et al.       Expires 7 November 2024               [Page 16]
Internet-Draft               SR P2MP Policy                     May 2024

   Replication segment at R1:

   Replication segment <R1,T-ID,I-ID1,R1>:
    Replication-SID: 2001:db8:cccc:1:FA::
    Replication State:
      R2: <2001:db8:cccc:2:FA::->L12>

   Replication to R2 steers packet directly to the node on interface
   L12.

   Replication segment at R2:

   Replication segment <R1,T-ID,I-ID1,R2>:
    Replication-SID: 2001:db8:cccc:2:FA::
    Replication State:
      R2: <Leaf>
      R6: <2001:db8:cccc:6:FA::>
      R7: <2001:db8:cccc:7:FA:: -> Policy27>

   R2 is a Bud node.  It performs role of Leaf as well as a transit node
   replicating to R6 and R7.  Replication to R6, steers packet via IGP
   shortest path to that node.  Replication to R7, via SR-TE policy,
   first encapsulates the packet using H.Encaps and then steers the
   outer packet to R4.  End.X USD on R4 decapsulates outer header and
   sends the original inner packet to R7.

   Replication segment at R6:

   Replication segment <R1,T-ID,I-ID1,R6>:
    Replication-SID: 2001:db8:cccc:6:FA::
    Replication State:
      R6: <Leaf>

   Replication segment at R7:

   Replication segment <R1,T-ID,I-ID1,R7>:
    Replication-SID: 2001:db8:cccc:7:FA::
    Replication State:
      R7: <Leaf>

   When a packet (A,B2) is steered into the active instance of Candidate
   Path 1 of SR P2MP Policy at R1 using H.Encaps.Replicate behavior:

   *  Since R1 is directly connected to R2, R1 sends replicated copy
      (2001:db8::1, 2001:db8:cccc:2:FA::) (A,B2) to R2 on interface L12.

   *  R2, as Leaf removes outer IPv6 header and delivers the payload.
      R2, as a bud node, also replicates the packet.

Voyer, Ed., et al.       Expires 7 November 2024               [Page 17]
Internet-Draft               SR P2MP Policy                     May 2024

   *  -  For replication to R6, R2 sends (2001:db8::1,
         2001:db8:cccc:6:FA::) (A,B2) to R3.  R3 forwards the packet
         using 2001:db8:cccc:6::/64 packet to R6.

      -  For replication to R7 using Policy27, R2 encapsulates and sends
         (2001:db8::2, 2001:db8:cccc:4:C17::) (2001:db8::1,
         2001:db8:cccc:7:FA::) (A,B2) to R4.  R4 performs End.X USD
         behavior, decapsulates outer IPv6 header and sends
         (2001:db8::1, 2001:db8:cccc:7:FA::) (A,B2) to R7.

   *  R6, as Leaf, removes outer IPv6 header and delivers the payload.

   *  R7, as Leaf, removes outer IPv6 header and delivers the payload.

A.2.  P2MP Tree with adjacent Replication Segments

   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 instance 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.

A.2.1.  SR-MPLS

   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,I-ID1,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,I-ID1,R2>:
    Replication-SID: T-SID1
    Replication State:
      R2: <Leaf>
      R3: <T-SID1->L23>
      R5: <T-SID1->L25>

Voyer, Ed., et al.       Expires 7 November 2024               [Page 18]
Internet-Draft               SR P2MP Policy                     May 2024

   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,I-ID1,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,I-ID1,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,I-ID1,R6>:
    Replication-SID: T-SID1
    Replication State:
      R6: <Leaf>

   Replication segment at R7:

   Replication segment <R1,T-ID,I-ID1,R7>:
    Replication-SID: T-SID1
    Replication State:
      R7: <Leaf>

   When a packet is steered into the SR P2MP Policy at R1:

   *  Since R1 is directly connected to R2, R1 performs PUSH operation
      with just <T-SID1> label for the replicated copy and sends it to
      R2 on interface L12.

   *  R2, as Leaf, performs NEXT operation, pops T-SID1 label and
      delivers the payload.  It also performs PUSH operation on T-SID1
      for replication to R3 and R5.  For replication to R6, R2 sends
      <T-SID1> label stack to R3 on interface L23.  For replication to
      R5, R2 sends <T-SID1> label stack to R5 on interface L25.

Voyer, Ed., et al.       Expires 7 November 2024               [Page 19]
Internet-Draft               SR P2MP Policy                     May 2024

   *  R3 performs NEXT operation on T-SID1 and performs a PUSH operation
      for replication to R6 and sends <T-SID1> label stack to R6 on
      interface L36.

   *  R5 performs NEXT operation on T-SID1 and performs a PUSH operation
      for replication to R7 and sends <T-SID1> label stack to R7 on
      interface L57.

   *  R6, as Leaf, performs NEXT operation, pops T-SID1 label and
      delivers the payload.

   *  R7, as Leaf, performs NEXT operation, pops T-SID1 label and
      delivers the payload.

A.2.2.  SRv6

   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,I-ID1,R1>:
    Replication-SID: 2001:db8:cccc:1:FA::
    Replication State:
      R2: <2001:db8:cccc:2:FA::->L12>

   Replication to R2 steers packet directly to the node on interface
   L12.

   Replication segment at R2:

   Replication segment <R1,T-ID,I-ID1,R2>:
    Replication-SID: 2001:db8:cccc:2:FA::
    Replication State:
      R2: <Leaf>
      R3: <2001:db8:cccc:3:FA::->L23>
      R5: <2001:db8:cccc:5:FA::->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:

Voyer, Ed., et al.       Expires 7 November 2024               [Page 20]
Internet-Draft               SR P2MP Policy                     May 2024

   Replication segment <R1,T-ID,I-ID1,R3>:
    Replication-SID: 2001:db8:cccc:3:FA::
    Replication State:
      R6: <2001:db8:cccc:6:FA::->L36>

   Replication to R6, steers packet directly to the node on L36.

   Replication segment at R5:

   Replication segment <R1,T-ID,I-ID1,R5>:
    Replication-SID: 2001:db8:cccc:5:FA::
    Replication State:
      R7: <2001:db8:cccc:7:FA::->L57>

   Replication to R7, steers packet directly to the node on L57.

   Replication segment at R6:

   Replication segment <R1,T-ID,I-ID1,R6>:
    Replication-SID: 2001:db8:cccc:6:FA::
    Replication State:
      R6: <Leaf>

   Replication segment at R7:

   Replication segment <R1,T-ID,I-ID1,R7>:
    Replication-SID: 2001:db8:cccc:7:FA::
    Replication State:
      R7: <Leaf>

   When a packet (A,B2) is steered into the active instance of Candidate
   Path 1 of SR P2MP Policy at R1 using H.Encaps.Replicate behavior:

   *  Since R1 is directly connected to R2, R1 sends replicated copy
      (2001:db8::1, 2001:db8:cccc:2:FA::) (A,B2) to R2 on interface L12.

   *  R2, as Leaf, removes outer IPv6 header and delivers the payload.
      R2, as a bud node, also replicates the packet.  For replication to
      R3, R2 sends (2001:db8::1, 2001:db8:cccc:3:FA::) (A,B2) to R3 on
      interface L23.  For replication to R5, R2 sends (2001:db8::1,
      2001:db8:cccc:5:FA::) (A,B2) to R5 on interface L25.

   *  R3 replicates and sends (2001:db8::1, 2001:db8:cccc:6:FA::) (A,B2)
      to R6 on interface L36.

   *  R5 replicates and sends (2001:db8::1, 2001:db8:cccc:7:FA::) (A,B2)
      to R7 on interface L57.

Voyer, Ed., et al.       Expires 7 November 2024               [Page 21]
Internet-Draft               SR P2MP Policy                     May 2024

   *  R6, as Leaf, removes outer IPv6 header and delivers the payload.

   *  R7, as Leaf, removes outer IPv6 header and delivers the payload.

Authors' Addresses

   Daniel Voyer (editor)
   Bell Canada
   Montreal
   Canada
   Email: daniel.voyer@bell.ca

   Clarence Filsfils
   Cisco Systems, Inc.
   Brussels
   Belgium
   Email: cfilsfil@cisco.com

   Rishabh Parekh
   Cisco Systems, Inc.
   San Jose,
   United States of America
   Email: riparekh@cisco.com

   Hooman Bidgoli
   Nokia
   Ottawa
   Canada
   Email: hooman.bidgoli@nokia.com

   Zhaohui Zhang
   Juniper Networks
   Email: zzhang@juniper.net

Voyer, Ed., et al.       Expires 7 November 2024               [Page 22]