Internet DRAFT - draft-zzhang-mpls-mldp-rsvp-p2mp-srv6

draft-zzhang-mpls-mldp-rsvp-p2mp-srv6







mpls                                                            Z. Zhang
Internet-Draft                                                 P. Beeram
Intended status: Standards Track                        Juniper Networks
Expires: 9 August 2024                                         R. Parekh
                                                                   Cisco
                                                             I. Wijnands
                                                                  Arrcus
                                                                 R. Chen
                                                                     ZTE
                                                         6 February 2024


                 mLDP/RSVP-TE P2MP Tunnel with SRv6 SID
                draft-zzhang-mpls-mldp-rsvp-p2mp-srv6-02

Abstract

   This document specifies extensions to mLDP and RSVP-TE P2MP protocols
   to set up mLDP and RSVP-TE P2MP tunnels with SRv6 SIDs intead of MPLS
   labels.

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 9 August 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



Zhang, et al.             Expires 9 August 2024                 [Page 1]

Internet-Draft             SRv6 mLDP/RSVP P2MP             February 2024


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  mLDP P2MP Procedures  . . . . . . . . . . . . . . . . . . . .   4
     2.1.  SRv6 SIDs Constructed from Signaled Labels  . . . . . . .   4
     2.2.  Explicitly Signaled SRv6 SIDs . . . . . . . . . . . . . .   4
     2.3.  mLDP over Targeted Sessions . . . . . . . . . . . . . . .   6
     2.4.  Multi-topology and FlexAlgo Considerations  . . . . . . .   6
   3.  RSVP-TE P2MP Procedures . . . . . . . . . . . . . . . . . . .   6
     3.1.  SRv6 SIDs Constructed from Signaled Labels  . . . . . . .   6
     3.2.  Explicitly Signaled SRv6 SIDs . . . . . . . . . . . . . .   6
       3.2.1.  Hello Extension . . . . . . . . . . . . . . . . . . .   6
       3.2.2.  Label Object for SRv6 SID . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   [I-D.ietf-spring-sr-replication-segment] specifies an SR replication
   segment as a logical construct which connects a Replication Node to a
   set of Downstream Nodes.  A replicaiton segment is identified by
   <replication-id, node-id> in control plane.

   SR replication segments are building blocks of SR-P2MP replication
   trees.  As specified in [I-D.ietf-pim-sr-p2mp-policy], an SR-P2MP
   tree is the concatenation of replication segments installed on tree
   nodes (the packets carried by the tree do not carry a concatenation
   of replication SIDs for those segments).  A controller calculates the
   P2MP tree, and signals individual replication segments onto tree
   nodes via PCEP [I-D.ietf-pce-sr-p2mp-policy], BGP
   [I-D.ietf-idr-sr-p2mp-policy]
   [I-D.ietf-bess-bgp-multicast-controller], Netconf [RFC6241] or other
   means.

   Each tree is identified by a <root-id, tree-id> tuple and has a
   corresponing SR P2MP Policy, which may have multiple candidate paths.
   As such, the replication-id of a replication segment is a <root-id,
   tree-id, candidate-path-id> tuple.





Zhang, et al.             Expires 9 August 2024                 [Page 2]

Internet-Draft             SRv6 mLDP/RSVP P2MP             February 2024


   With MPLS data plane, the forwarding state for a replication segment
   is identical to the forwarding state on mLDP/RSVP-TE P2MP tree nodes
   ([RFC6388], [RFC4875]), i.e., in the form of "incoming label ->
   (labeled) replication branches".  In other words, the only difference
   between mLDP/RSVP-TE P2MP and SR-MPLS P2MP is in the control plane -
   instead of hop-by-hop signaling, SR-P2MP signaling is from a
   controller and with a different control plane identification.

   With SRv6 data plane, while SRv6 SID instead of MPLS labels are used,
   the FUNCT bits in the LOC:FUNCT:ARG format of SID encoding [RFC8986]
   are the equivalent of MPLS label, while the LOC bits get the packet
   to local or downstream nodes.  Nonetheless, for operators who does
   not use MPLS data palne, SRv6 P2MP is a natural choice.

   However, even an SRv6-only operator may want to use another option to
   set up its P2MP trees, instead of using controller-based signaling
   with <root-id, tree-id, candidate-path-id> identification.

   Consider an existing MVPN deployment with PE-PE mLDP or RSVP-TE P2MP
   tunnels and the provider network is being transitioned from MPLS to
   SRv6 part by part incrementally.  Considering the following three
   factors:

   *  The MVPN PE-PE tunnel is mLDP/RSVP-TE P2MP so during the
      transition it is ideal to keep using mLDP FEC or RSVP-TE P2MP
      Session Object to identify the tunnel in the control plane

   *  The are some border nodes between the MPLS part and SRv6 part of
      the network to do MPLS-SRv6 interworking

   *  Even after the entire network is converted to SRv6, hop-by-hop
      mLDP/RSVP-TE signaling may still be preferred because controller-
      based tree calculation and signaling may not be needed or desired
      for certain reasons

   Therefore, it is desired to have P2MP trees identified by mLDP FEC or
   RSVP Session Object in the control plane but with SRv6 data plane,
   and there are two options for that:

   *  Use controller to signal mLDP/RSVP-TE trees with SRv6 SIDs

   *  Extend mLDP/RSVP-TE P2MP protocol to support SRv6 SIDs

   The first option will be specified in
   [I-D.ietf-bess-bgp-multicast-controller] and [I-D.li-pce-multicast]
   for BGP and PCEP signaling respectively, and this document specifies
   the second option.




Zhang, et al.             Expires 9 August 2024                 [Page 3]

Internet-Draft             SRv6 mLDP/RSVP P2MP             February 2024


2.  mLDP P2MP Procedures

   There are two options to use mLDP protocol and procedures to signal
   mLDP tunnels for SRv6 data plane, as specified in the following two
   sections.

2.1.  SRv6 SIDs Constructed from Signaled Labels

   In this simpliest option, no protocol extension is needed.  MPLS
   labels in various mLDP messages are treated as the FUNCT bits of the
   LOC:FUNCT:ARG format of SRv6 SID encoding.

   All tree nodes MUST have the following provisioned:

   *  Whether the signaled labels to/from all neighbors are real MPLS
      labels or FUNCT bits of SRv6 SIDs, or,

   *  Whether the signaled labels to/from each neighbor are real MPLS
      labels or FUNCT bits of SRv6 SIDs.  This allows a node to
      interwork between MPLS and SRv6 parts of the network.

   *  If the FUNCT bits of SRv6 SIDs are more than 20-bit, each node
      MUST be provisioned with a consitent FUNCT "prefix" to be combined
      with signaled "label".

   With the above provisioning, a node determines if a signaled label is
   a real MPLS label for MPLS data planes, or is to be treated as the
   FUNCT bits of an SRv6 SID, and installs forwarding state accordingly.

2.2.  Explicitly Signaled SRv6 SIDs

   With this options, mLDP signaling is extended as following.

   A new V-bit is defined in the P2MP Capability TLV to indicate that
   this node uses SRv6 SIDs:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|0| P2MP Capability (0x0508)  |      Length (= 1)             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S|V| Reserved  |
     +-+-+-+-+-+-+-+-+

   An SRv6 SID TLV is defined to signal the SRv6 SID instead of a label:






Zhang, et al.             Expires 9 August 2024                 [Page 4]

Internet-Draft             SRv6 mLDP/RSVP P2MP             February 2024


      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|0| SRv6 SID (TBD)            |        Length (24)            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~              SRv6 SID Value                                   ~
     +---------------------------------------------------------------+
     |     SRv6 Endpoint Behavior    |        RESERVED               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Locator Block | Locator Node  | Function      | Argument      |
     | Length        | Length        | Length        | Length        |
     +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The SRv6 SID TLV is used in place of Generic Label TLV if and only if
   the neighbor has indicated via the V-bit in the P2MP Capability TLV
   that it uses SRv6 SIDs.

   SRv6 SID Value (16 octets):  This field encodes an SRv6 SID, as
      defined in [RFC8986].

   SRv6 Endpoint Behavior (2 octets):  This field encodes the SRv6
      Endpoint Behavior codepoint value that is associated with the SRv6
      SID.  The codepoints used are from IANA's "SRv6 Endpoint
      Behaviors" subregistry under the "Segment Routing" registry that
      was introduced by [RFC8986].  The opaque SRv6 Endpoint Behavior
      (i.e., value 0xFFFF) MAY be used when the advertising router
      wishes to abstract the actual behavior of its locally instantiated
      SRv6 SID.

   RESERVED (2 octet):  This field MUST be set to 0 by the sender and
      ignored by the receiver.

   Locator Block Length (1 octet):  This field contains the length of
      the SRv6 SID Locator Block in bits.

   Locator Node Length (1 octet):  This field contains the length of the
      SRv6 SID Locator Node in bits.

   Function Length (1 octet):  This field contains the length of the
      SRv6 SID Function in bits.

   Argument Length (1 octet):  This field contains the length of the
      SRv6 SID Argument in bits.

   The choice of SRv6 Endpoint Behavior of the SRv6 SID is entirely up
   to the originator of the TLV.  While this document expects
   End.Replicate [I-D.ietf-spring-sr-replication-segment], the reception
   of other SRv6 Endpoint Behaviors (e.g., new behaviors that may be



Zhang, et al.             Expires 9 August 2024                 [Page 5]

Internet-Draft             SRv6 mLDP/RSVP P2MP             February 2024


   introduced in the future) is not considered an error.  An
   unrecognized SRv6 Endpoint Behavior MUST NOT be considered invalid by
   the receiver.  An implementation MAY log a rate-limited warning when
   it receives an unexpected behavior.

2.3.  mLDP over Targeted Sessions

   To be added.

2.4.  Multi-topology and FlexAlgo Considerations

   To be added.

3.  RSVP-TE P2MP Procedures

   Similarly, there are two options to use RSVP-TE P2MP protocol and
   procedures to signal RSVP-TE P2MP tunnels for SRv6 data plane, as
   specified in the following two sections.

3.1.  SRv6 SIDs Constructed from Signaled Labels

   This is the same as Section 2.1.

3.2.  Explicitly Signaled SRv6 SIDs

   Similar to Section 2.2, RSVP-TE P2MP signaling is extended as
   following:

3.2.1.  Hello Extension

   This is to indicate a node uses SRv6 SIDs.  To be expanded.

3.2.2.  Label Object for SRv6 SID

   A new C-type (TBD) is defined for the Label Object to indicate an
   IPv6 address as SRv6 SID:

               0             1              2             3
        +-------------+-------------+-------------+-------------+
        |       Length (28)         |  Class (16) | C-Type (TBD)|
        +-------------+-------------+-------------+-------------+
        //                SRv6 SID Value                       //
        +-------------+-------------+-------------+-------------+
        |   SRv6 Endpoint Behavior  |       RESERVED            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Locator     | Locator Node| Function    | Argument    |
        | Block Length| Length      | Length      | Length      |
        +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+



Zhang, et al.             Expires 9 August 2024                 [Page 6]

Internet-Draft             SRv6 mLDP/RSVP P2MP             February 2024


   The C-Type TBD Label Object is used in place of C-Type 1 Label Object
   if and only if the neighbor has indicated via Hello that it uses SRv6
   SIDs.

   SRv6 SID Value (16 octets):  This field encodes an SRv6 SID, as
      defined in [RFC8986].

   SRv6 Endpoint Behavior (2 octets):  This field encodes the SRv6
      Endpoint Behavior codepoint value that is associated with the SRv6
      SID.  The codepoints used are from IANA's "SRv6 Endpoint
      Behaviors" subregistry under the "Segment Routing" registry that
      was introduced by [RFC8986].  The opaque SRv6 Endpoint Behavior
      (i.e., value 0xFFFF) MAY be used when the advertising router
      wishes to abstract the actual behavior of its locally instantiated
      SRv6 SID.

   RESERVED (2 octet):  This field MUST be set to 0 by the sender and
      ignored by the receiver.

   Locator Block Length (1 octet):  This field contains the length of
      the SRv6 SID Locator Block in bits.

   Locator Node Length (1 octet):  This field contains the length of the
      SRv6 SID Locator Node in bits.

   Function Length (1 octet):  This field contains the length of the
      SRv6 SID Function in bits.

   Argument Length (1 octet):  This field contains the length of the
      SRv6 SID Argument in bits.

   The choice of SRv6 Endpoint Behavior of the SRv6 SID is entirely up
   to the originator of the TLV.  While this document expects
   End.Replicate [I-D.ietf-spring-sr-replication-segment], the reception
   of other SRv6 Endpoint Behaviors (e.g., new behaviors that may be
   introduced in the future) is not considered an error.  An
   unrecognized SRv6 Endpoint Behavior MUST NOT be considered invalid by
   the receiver.  An implementation MAY log a rate-limited warning when
   it receives an unexpected behavior.

4.  Security Considerations

   To be added.

5.  IANA Considerations

   To be added.




Zhang, et al.             Expires 9 August 2024                 [Page 7]

Internet-Draft             SRv6 mLDP/RSVP P2MP             February 2024


6.  References

6.1.  Normative References

   [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-19, 28 August 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              sr-replication-segment-19>.

   [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Functional Description",
              RFC 3471, DOI 10.17487/RFC3471, January 2003,
              <https://www.rfc-editor.org/info/rfc3471>.

   [RFC4875]  Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
              Yasukawa, Ed., "Extensions to Resource Reservation
              Protocol - Traffic Engineering (RSVP-TE) for Point-to-
              Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
              DOI 10.17487/RFC4875, May 2007,
              <https://www.rfc-editor.org/info/rfc4875>.

   [RFC6388]  Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
              Thomas, "Label Distribution Protocol Extensions for Point-
              to-Multipoint and Multipoint-to-Multipoint Label Switched
              Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
              <https://www.rfc-editor.org/info/rfc6388>.

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

6.2.  Informative References

   [I-D.ietf-bess-bgp-multicast-controller]
              Zhang, Z. J., Raszuk, R., Pacella, D., and A. Gulko,
              "Controller Based BGP Multicast Signaling", Work in
              Progress, Internet-Draft, draft-ietf-bess-bgp-multicast-
              controller-12, 30 December 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
              bgp-multicast-controller-12>.






Zhang, et al.             Expires 9 August 2024                 [Page 8]

Internet-Draft             SRv6 mLDP/RSVP P2MP             February 2024


   [I-D.ietf-idr-sr-p2mp-policy]
              Bidgoli, H., Voyer, D., Stone, A., Parekh, R., Krier, S.,
              and S. Agrawal, "Advertising p2mp policies in BGP", Work
              in Progress, Internet-Draft, draft-ietf-idr-sr-p2mp-
              policy-00, 27 May 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
              p2mp-policy-00>.

   [I-D.ietf-pce-sr-p2mp-policy]
              Bidgoli, H., Voyer, D., Rajarathinam, S., Budhiraja, A.,
              Saad, T., and S. Sivabalan, "PCEP extensions for p2mp sr
              policy", Work in Progress, Internet-Draft, draft-ietf-pce-
              sr-p2mp-policy-04, 23 October 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-
              p2mp-policy-04>.

   [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-07, 11 October 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-
              p2mp-policy-07>.

   [I-D.li-pce-multicast]
              Li, H., Wang, A., Zhang, Z. J., Chen, H., and R. Chen,
              "Multicast Tree Setup via PCEP", Work in Progress,
              Internet-Draft, draft-li-pce-multicast-02, 20 September
              2022, <https://datatracker.ietf.org/doc/html/draft-li-pce-
              multicast-02>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

Authors' Addresses

   Zhaohui Zhang
   Juniper Networks
   Email: zzhang@juniper.net


   Vishnu Pavan Beeram
   Juniper Networks
   Email: vbeeram@juniper.net





Zhang, et al.             Expires 9 August 2024                 [Page 9]

Internet-Draft             SRv6 mLDP/RSVP P2MP             February 2024


   Rishabh Parekh
   Cisco
   Email: riparekh@cisco.com


   IJsbrand Wijnands
   Arrcus
   Email: ice@braindump.be


   Ran Chen
   ZTE
   Email: chen.ran@zte.com.cn






































Zhang, et al.             Expires 9 August 2024                [Page 10]