<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-wang-idr-cpr-03" ipr="trust200902">
  <front>
    <title abbrev="BGP CPR for SRv6 Service">BGP Colored Prefix Routing (CPR)
    for SRv6 based Services</title>

    <author fullname="Haibo Wang" initials="H." surname="Wang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <email>rainsword.wang@huawei.com</email>
      </address>
    </author>

    <author fullname="Jie Dong" initials="J." surname="Dong">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <email>jie.dong@huawei.com</email>
      </address>
    </author>

    <author fullname="Ketan Talaulikar" initials="K." surname="Talaulikar ">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>India</country>
        </postal>

        <email>ketant.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Tao Han" initials="T." surname="Han">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country>China</country>
        </postal>

        <email>hantao@huawei.com</email>
      </address>
    </author>

    <author fullname="Ran Chen" initials="R." surname="Chen">
      <organization>ZTE Corporation</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <email>chen.ran@zte.com.cn</email>
      </address>
    </author>

    <author fullname="Jingrong Xie" initials="J." surname="Xie">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <email>xiejingrong@huawei.com</email>
      </address>
    </author>

    <author fullname="Xinjun Chen" initials="X." surname="Chen">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <email>ifocus.chen@huawei.com</email>
      </address>
    </author>

    <date day="20" month="October" year="2023"/>

    <area>Routing Area</area>

    <workgroup>Interdomain Routing Working Group</workgroup>

    <abstract>
      <t>This document describes a mechanism to advertise IPv6 prefixes in BGP
      which are associated with Color Extended Communities to establish
      end-to-end intent-aware paths for SRv6 services. Such IPv6 prefixes are
      called "Colored Prefixes", and this mechanism is called Colored Prefix
      Routing (CPR). In SRv6 networks, the Colored prefixes are the SRv6
      locators associated with different intent. SRv6 services (e.g. SRv6 VPN
      services) with specific intent could be assigned with SRv6 SIDs under
      the corresponding SRv6 locators, which are advertised as Colored
      prefixes. This allows the SRv6 service traffic to be steered into
      end-to-end intent-aware paths simply based on the longest prefix
      matching of SRv6 Service SIDs to the Colored prefixes. In data plane,
      dedicated transport label or SID for the inter-domain path is not
      needed, thus the encapsulation efficiency could be optimized. The
      existing IPv6 Address Family could be used for the advertisement of IPv6
      Colored prefixes, thus this mechanism is easy to interoperate and can be
      deployed incrementally in multi-domain networks.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>With the trend of using one common network to carry multiple types of
      services, each service type can have different requirements on the
      network. Such requirements are usually considered as the "intent" of the
      service or customer, and is represented as an abstract notion called
      "color".</t>

      <t>In network scenarios where the services are delivered across multiple
      network domains, there is need to provide the services with different
      end-to-end paths to meet the intent. <xref
      target="I-D.hr-spring-intentaware-routing-using-color"/> describes the
      problem statements and requirements for inter-domain intent-aware
      routing.</t>

      <t>The inter-domain path can be established using either MPLS or IP data
      plane. In MPLS based networks, the traditional inter-domain approach is
      to establish an end-to-end LSP based on the BGP-LU mechanisms as defined
      in <xref target="RFC8277"/>. Each domain or area border node needs to
      perform label swapping for the end-to-end BGP-LU LSP, and encapsulate
      the label stack which are used for the intra-domain LSP within the
      subsequent network domain or area.</t>

      <t/>

      <t>While in IP based networks, the IP reachability information can be
      advertised to network nodes in different domains using BGP, so that all
      the domain or area border nodes have the routes to the IP prefixes of
      the destination node in other domains. With the introduction of SRv6
      <xref target="RFC8402"/> <xref target="RFC8754"/> <xref
      target="RFC8986"/>, BGP services are assigned with SRv6 Service SIDs
      <xref target="RFC9252"/>, which are routable in the network according to
      its SRv6 locator prefix. Thus, the inter-domain path can be established
      simply based on the inter-domain prefix routes, and the BGP-LU
      inter-domain LSP mechanism is not necessary for IPv6 and SRv6 based
      networks.</t>

      <t>This document describes a mechanism to advertise IPv6 prefixes which
      are associated with Color Extended Community to establish end-to-end
      intent-aware paths for SRv6 services. The color value in the Color
      Extended Community indicate the intent <xref target="RFC9256"/>. Such
      IPv6 prefixes are called "Colored Prefixes", and this mechanism is
      called Colored Prefix Routing (CPR). In SRv6 networks, the Colored
      prefixes are the SRv6 locators associated with different intent. BGP
      services over SRv6 (e.g. SRv6 VPN services) <xref target="RFC9252"/>
      with specific intent could be assigned with SRv6 SIDs under the
      corresponding SRv6 locators, which are advertised as Colored prefixes.
      This allows the SRv6 service traffic to be steered (as specified in
      <xref target="RFC9252"/>) into end-to-end intent-aware paths simply
      based on the longest prefix matching of SRv6 Service SIDs to the Colored
      prefixes. In data plane, the dedicated transport label or SID for the
      inter-domain path is not needed, thus the encapsulation efficiency could
      be optimized. The existing IPv6 Address Family could be used for the
      advertisement of IPv6 Colored prefixes, which makes this mechanism easy
      to interoperate and can be deployed incrementally in multi-domain
      networks.</t>
    </section>

    <section title="BGP CPR">
      <t>This section describes the BGP CPR mechanisms. More specifically,
      section 2.1 describes the allocation of the IPv6 Colored prefixes,
      section 2.2 describes the advertisement of Colored prefixes in BGP,
      section 2.3 describes the resolution of CPR routes to the intra-domain
      paths, and section 2.4 describes the steering of BGP SRv6 services to
      CPR routes.</t>

      <section title="Colored Prefix Allocation">
        <t>In SRv6 networks, an SRv6 locator needs to be allocated for each
        node. In order to distinguish N different intent, a PE node needs to
        be allocated with N SRv6 locators, each of which is associated a
        different intent that is identified by a color value. One way to
        achieve this is by splitting the base SRv6 locator of the node into N
        sub-locators, and these sub-locators are Colored prefixes associated
        with different intents.</t>

        <t>For example, node PE2 is allocated with the base SRv6 Locator
        2001:db8:aaaa:1::/64. In order to provide 16 different intents, this
        base SRv6 Locator is split into 16 sub-locators from
        2001:db8:aaaa:1:0000::/68 to 2001:db8:aaaa:1:F000::/68, each of these
        sub-locators is associated with a different intent, such as low-delay,
        high-bandwidth, etc.</t>
      </section>

      <section title="Colored Prefix Advertisement">
        <t>After the allocation of Colored prefixes on a PE node, routes to
        these Colored prefixes need to be advertised both in the local domain
        and also to other domains using BGP, so that the BGP SRv6 services
        routes could be resolved using the corresponding CPR route.</t>

        <t>In a multi-domain IPv6 network, the IPv6 unicast Address
        Family/Subsequent Address Family (AFI/SAFI = 2/1) <xref
        target="RFC2545"/> is used for the advertisement of the Colored prefix
        routes. The color extended community <xref target="RFC9012"/> is
        carried with the Colored prefix route with the color value indicating
        the intent <xref target="RFC9256"/>. The procedure of Colored prefix
        advertisement is described using an example with the following
        topology:</t>

        <t><figure>
            <artwork><![CDATA[
                       Consistent Color Domain:
                               C1, C2, ...
     +--------------+        +--------------+        +-------------+
     |              |        |              |        |             |
     |        [ASBR11]---[ASBR21]      [ASBR23]---[ASBR31]         |
 --[PE1] [P1]       |  X     |    [P2]      |   X    |     [P3]  [PE3]--
     |        [ASBR12]---[ASBR22]      [ASBR24]---[ASBR32]         |
     |              |        |              |        |             |
     +--------------+        +--------------+        +-------------+
           AS1                     AS2                     AS3

  Colored Prefixes of PE3:
  Low delay: 2001:db8:aaaa:1:1000::/68
  high bandwidth: 2001:db8:aaaa:1:2000::/68
  ...   
        Figure 1. Example Topology for CPR Route Illustration
]]></artwork>
          </figure></t>

        <t>Assume PE3 is provisioned with two different Colored prefixes CLP-1
        and CLP-2 for two different intent such as "low-delay" and
        "high-bandwidth" respectively. In this example, It is assumed that the
        color representing a specific intent is consistent through all the
        domains.</t>

        <t><list style="symbols">
            <t>PE3 originates BGP IPv6 unicast (AFI/SAFI=2/1) route for the
            Colored prefixes PE3:CL1:: and PE3:CL2::. Each route should carry
            the corresponding color extended community C1 or C2. PE3 also
            advertises a route for the base SRv6 Locator prefix PE3:BL, and
            there is no color extended community carried with this route.</t>

            <t>ASBR31 and ASBR32 receive the CPR routes of PE3, and advertise
            the CPR routes further to ASBR23 and ASBR24 with next-hop set to
            itself.</t>

            <t>ASBR23 and ASBR24 receive the CPR routes of PE3. Since the
            color-to-intent mapping in AS2 is consistent with that in AS3, the
            Color Extended Community in the received CPR routes are kept
            unchanged. ASBR23 and ASBR 24 advertise the CPR routes further in
            AS2 with the next-hop set to itself.</t>

            <t>The behavior of ASBR21 and ASBR22 are similar to the behavior
            of ASBR31 and ASBR32.</t>

            <t>The behavior of ASBR11 and ASBR12 are similar to the behavior
            of ASBR31 and ASBR32.</t>
          </list></t>

        <t>In normal case, the color value in the color extended community
        associated with the CPR route is consistent through all the domains.
        While in some special cases, one intent may be represented as
        different color value in different domains, then the Color Extended
        Community in the CPR routes may be updated at the border nodes of the
        domains based on the color-mapping policy.</t>

        <t>In network scenarios where some of the intermediate network domains
        are MPLS based, the CPR routes may still be advertised using the IPv6
        unicast address family (AFI/SAFI=2/1) in the MPLS-based intermediate
        domains, and at the MPLS domain border nodes, some route resolution
        policy could be used to make the CPR routes resolved to intra-domain
        intent-aware MPLS LSPs. Another possible mechanism is to use the IPv6
        LU address family (AFI/SAFI=2/4) to advertise the CPR routes in the
        MPLS domains, the detailed procedure is described in Section 7.1.2.1
        of <xref target="I-D.agrawal-spring-srv6-mpls-interworking"/>.</t>

        <t/>
      </section>

      <section title="CPR to Intra-domain Path Resolution">
        <t>A domain border node which receives a CPR route can resolve the CPR
        route to an intra-domain color-aware path based on the tuple (N, C),
        where N is the next-hop of the CPR route, and C is the color extended
        community of the CPR route. The intra-domain color-aware path could be
        built with any of the following mechanisms:</t>

        <t><list style="symbols">
            <t>SRv6 or SR-MPLS Policy</t>

            <t>SRv6 or SR-MPLS Flex-Algo</t>

            <t>RSVP-TE</t>
          </list></t>

        <t>For example, PE1 receives a CPR route to PE3:CL1 with color C1 and
        next-hop ASBR11, it can resolve the CPR routes to an intra-domain SRv6
        Policy based on the tuple (ASBR11, C1).</t>

        <t>The intra-domain path resolution scheme could be based on any
        existing tunnel resolution policy, and new tunnel resolution
        mechanisms could be introduced if needed.</t>
      </section>

      <section title="SRv6 Service Route Advertisement">
        <t>For an SRv6 service which is associated with a specific intent, the
        SRv6 Service SID could be allocated under the corresponding Colored
        locator prefix. For example, on PE3 in the example topology, an SRv6
        VPN service with the low delay intent can be allocated with the SRv6
        End.DT4 SID 2001:db8:aaaa:1:1000::0100, where
        2001:db8:aaaa:1:1000::/68 is the SRv6 Colored prefix for low delay
        service.</t>

        <t>The SRv6 service routes are advertised using the mechanism defined
        in <xref target="RFC9252"/>. The inter-domain VPN Option C is used,
        which means the next-hop of the SRv6 service route is set to the
        originating PE and not changed. Since the intent of the service is
        embedded in the SRv6 service SID, the SRv6 service route does not need
        to carry the color extended community.</t>
      </section>

      <section title="SRv6 Service Steering">
        <t>With the CPR routing mechanism, the ingress PE node which receives
        the SRv6 service routes follows the behavior of SRv6 shortest path
        forwarding (refer to Section 5 and 6 of <xref target="RFC9252"/>). The
        SRv6 service SID carried in the service route is used as the
        destination address in the outer IPv6 header encapsulated to the
        service packet. If the corresponding CPR route has been received and
        installed, longest prefix matching of SRv6 service SIDs to the Colored
        prefixes is performed, then the intra-domain color-aware paths in each
        network domain which the CPR route is resolved to are used for
        forwarding the SRv6 service traffic.</t>
      </section>
    </section>

    <section title="Encapsulation and Forwarding Processes">
      <t>This section describes the encapsulation and forwarding process of
      data packets which are matched with the corresponding CPR route.</t>

      <section title="CPR over SRv6 Intra-Domain Paths">
        <t>Following is an illustration of the packet encapsulation and
        forwarding process of CPR over SRv6 Policy. The abstract
        representation of IPv6 and SRH in section 6 of <xref
        target="RFC8754"/> is used.</t>

        <t>PE3 is provisioned with a Colored prefix PE3:C1 for
        "low-delay".</t>

        <t>In AS1, the SRv6 Policy for (ASBR11, C1) is represented with SID
        list (P1, BR11).</t>

        <t>In AS2, the SRv6 Policy for (ASBR23, C1) is represented with the
        SID list (P2, BR23).</t>

        <t>In AS3, the SRv6 Policy for (PE3, C1) is represented with the SID
        list (P3, PE3).</t>

        <t>For packets which belong to an SRv6 VPN service associated with the
        SRv6 Service SID PE3:CL1.DT, the packet encapsulation and forwarding
        process is shown as below:</t>

        <t><figure>
            <artwork><![CDATA[PE1 ->P1  : (PE1, P1)(PE3:CL1.DT, BR11; SL=2)(C-pkt)
P1  ->BR11: (PE1, BR11)(PE3:CL1.DT, BR11; SL=1)(C-pkt)
BR11->BR21: (PE1, PE3:CL1.DT)(C-pkt)
BR21->P2  : (PE1, P2)(PE3:CL1.DT, BR23; SL=2)(C-pkt)
P2  ->BR23: (PE1, BR23)(PE3:CL1.DT, BR23; SL=1)(C-pkt)
BR23->BR31: (PE1, PE3:CL1.DT)(C-pkt) 
BR31->P3  : (PE1, P3)(PE3:CL1.DT, PE3; SL=2)(C-pkt) 
P3  ->PE3 : (PE1, PE3)(PE3:CL1.DT, PE3; SL=1)(C-pkt)
]]></artwork>
          </figure></t>

        <t>In some network domains, SRv6 Flex-Algo may be used to provide
        intent-aware intra-domain path. The encapsulation is similar to the
        case with SRv6 Policy.</t>
      </section>

      <section title="CPR over MPLS Intra-Domain Paths">
        <t>In network scenarios where some of the network domains use MPLS
        based data plane, the CPR route can be resolved over a color-aware
        intra-domain MPLS LSP. Such intra-domain MPLS LSP may be established
        using SR-MPLS Policy, SR-MPLS Flex-Algo or RSVP-TE.</t>

        <t>The encapsulation and forwarding of SRv6 service packets (which are
        actually IPv6 packets) over an intra-domain MPLS LSP is based on the
        MPLS mechanisms as defined in <xref target="RFC3031"/> <xref
        target="RFC3032"/> and <xref target="RFC8660"/>. The behavior is
        similar to that of 6PE <xref target="RFC4798"/>.</t>

        <t>In AS1, the SR-MPLS Policy for (ASBR11, C1) is represented with
        Label-stack (P1, BR11).</t>

        <t>In AS2, the SR-MPLS Flex-Algo for (ASBR23, C1) is represented with
        Label-stack (BR23).</t>

        <t>In AS3, the SR-MPLS Policy for (PE3, C1) is represented with
        Label-stack (P3, PE3).</t>

        <t>For packets which belong to an SRv6 VPN service associated with the
        SRv6 Service SID PE3:CL1.DT, the packet encapsulation and forwarding
        process is shown as below:</t>

        <t><figure>
            <artwork><![CDATA[PE1 ->P1  : Label-stack (P1, BR11) (PE1, PE3:CL1.DT)(C-pkt)
P1  ->BR11:     Label-stack (BR11) (PE1, PE3:CL1.DT)(C-pkt)
BR11->BR21:                        (PE1, PE3:CL1.DT)(C-pkt)
BR21->P2  :     Label-stack (BR23) (PE1, PE3:CL1.DT)(C-pkt)
P2  ->BR23:     Label-stack (BR23) (PE1, PE3:CL1.DT)(C-pkt)
BR23->BR31:                        (PE1, PE3:CL1.DT)(C-pkt)
BR31->P3  :  Label-stack (P3, PE3) (PE1, PE3:CL1.DT)(C-pkt)
P3  ->PE3 :      Label-stack (PE3) (PE1, PE3:CL1.DT)(C-pkt)
]]></artwork>
          </figure></t>
      </section>
    </section>

    <section title="Operational Considerations">
      <t>When the Colored prefixes are assigned as the sub-locators of the
      node's base SRv6 locator, the IPv6 unicast route of the base locator
      prefix is the covering prefix of all the Colored locator prefixes. To
      make sure the Colored locator prefixes can be distributed to the ingress
      PE nodes along the border nodes, it is required that route aggregation
      be disabled for IPv6 unicast routes which carries the color extended
      community.</t>

      <t>All the border nodes and the ingress PE nodes needs to install the
      Colored locator prefixes into the RIB and FIB. For transit domains which
      support the CPR mechanism, the border nodes can use the tuple (N, C) to
      resolve the CPR routes to intent-aware intra-domain paths. For transit
      domains which do not support the CPR mechanism, the border nodes would
      ignore the color extended community and resolve the CPR routes over a
      best effort intra-domain path to the next-hop N, while the CPR route
      will be advertised further to the downstream domains with only the
      next-hop changed to itself. This allows the CPR routes to be resolved to
      intent-aware intra-domain paths in any network domains which support the
      CPR mechanism, while can fall back to resolve over best-effort
      intra-domain path in the legacy network domains.</t>

      <t>In this document, IPv6 Unicast address family is used for the
      advertisement of IPv6 Colored prefixes. The primary advantage of this
      approach is the improved interoperability with legacy networks that lack
      support for intent-aware paths, and the facilitation of incremental
      deployment of intent-aware routing mechanisms. One potential concern
      arises regarding the necessity of separating Colored prefixes from
      public IPv6 unicast routes. While as the IP prefixes and SRv6 locators
      of network infrastructure are usually advertised as part of the IP
      unicast routes, and appropriate filters are configured at the boundaries
      of network administration, this is not considered to be a significant
      issue. The proposal in <xref target="I-D.ietf-idr-bgp-car"/> provides a
      complementary solution that is also based on the notion of color
      indicating the intent and where the SRv6 Locator prefix itself signifies
      the intent, the difference is that a separate SAFI is used.</t>

      <t><xref target="I-D.ietf-idr-bgp-ct"/> describes another mechanism for
      intent-aware routing, in which the SRv6 service SIDs are not directly
      associated with the intent, while additional SRv6 transport SIDs are
      required for steering traffic to the inter-domain intent-aware paths,
      and an SRv6 operation similar to MPLS label swapping is needed on the
      border nodes of network domains.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The mechanism described in this document provide an approach for
      inter-domain intent-aware routing based on existing BGP protocol
      mechanisms. It does not introduce any additional security considerations
      than those described in <xref target="RFC4271"/> and <xref
      target="RFC4272"/>.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Shunwan Zhuang, Zhibo Hu, Zhenbin Li
      and Dhananjaya Rao for the review and valuable discussion.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.4271'?>

      <?rfc include='reference.RFC.2545'?>

      <?rfc include='reference.RFC.4272'?>

      <?rfc include='reference.RFC.8402'?>

      <?rfc include='reference.RFC.8754'?>

      <?rfc include='reference.RFC.8986'?>

      <?rfc include='reference.RFC.9012'?>

      <?rfc include='reference.RFC.9252'?>

      <?rfc include='reference.RFC.9256'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.hr-spring-intentaware-routing-using-color'?>

      <?rfc include='reference.I-D.agrawal-spring-srv6-mpls-interworking'?>

      <?rfc include='reference.I-D.ietf-idr-bgp-car'?>

      <?rfc include='reference.I-D.ietf-idr-bgp-ct'?>

      <?rfc include='reference.RFC.3031'?>

      <?rfc include='reference.RFC.3032'?>

      <?rfc include='reference.RFC.4798'?>

      <?rfc include='reference.RFC.8277'?>

      <?rfc include='reference.RFC.8660'?>
    </references>
  </back>
</rfc>
