Network Working Group                                              Z. Li
Internet-Draft                                                     Z. Hu
Intended status: Standards Track                                 J. Dong
Expires: September 8, 2022                           Huawei Technologies
                                                                S. Zhang
                                                                   J. Li
                                                            China Unicom
                                                           March 7, 2022


                          Intent-based Routing
                  draft-li-apn-intent-based-routing-00

Abstract

   This document defines the intent-based routing mechanism through
   which the packet can carry the intent information and the network
   node can enforce the policy according to the intent information
   (typically steering the packet into the SR policy or the underlay
   slice which can meet the intent).  The intent-based routing mechanism
   provides a simple and scalable solution to meet the different service
   requirements for the inter-domain routing.

Requirements Language

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

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 September 8, 2022.






Li, et al.              Expires September 8, 2022               [Page 1]


Internet-Draft            Intent-based Routing                March 2022


Copyright Notice

   Copyright (c) 2022 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminologies . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Intent-based Routing  . . . . . . . . . . . . . . . . . . . .   3
   4.  Illustration  . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  IPv6 Encapsulation  . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Application-aware Networking (APN) is introduced in
   [I-D.li-apn-framework] and [I-D.li-apn-problem-statement-usecases].
   APN conveys an attribute with data packets in the network and makes
   the network aware of fine-grain requirements at the user group and
   application group levels.  This document defines the intent-based
   routing mechanism in which intent can be seen as the APN parameter to
   specify the service requirements.

   [I-D.hegde-spring-mpls-seamless-sr] describes the requirements for
   end-to-end intent-based paths spanning multi-domain networks.
   [I-D.kaliraj-idr-bgp-classful-transport-planes] specifies the BGP
   based mechanisms to signal the packet paths which span multiple
   domains and provide different SLA characteristics.  Since these SR
   paths need to setup according to the pair <color, endpoint>, it means
   more SR paths are introduced and this will cause more challenges on
   scalability.




Li, et al.              Expires September 8, 2022               [Page 2]


Internet-Draft            Intent-based Routing                March 2022


   In order to reduce the challenge of scalability introduced by the
   inter-domain routing with different service requirements, this
   document proposes the intent-based routing mechanism through which
   the packet can carry the intent information and the network node can
   steer the packet into the SR policy to satisfy the service
   requirement (that is, meet the specific intent).  With the intent-
   based routing mechanism, network nodes do not need to maintain the
   fine-granularity connection state for each destination in the control
   plane, which can improve the scalability of the end- to-end routing
   significantly.

   Besides steering the packet into the SR policy, the intent-based
   routing mechanism can also be used to steer the traffic into the
   underlay network slice to meet the specific intent or enforce policy
   for other intents such as network measurement, security, etc.  Since
   the same intent can be satisfied by different solutions in the
   different network domain, the intent-based routing also improve the
   flexibility to satisfying the service requirement through the
   combined solutions for the same intent.

2.  Terminologies

   The following terminologies are used in this document.

   SR: Segment Routing

   SRv6: Segment Routing over IPv6

3.  Intent-based Routing

   The Intent-based routing mechanism introduces the concept of intent
   as the information carried in the data plane to represent the
   specific service requirement for the destination on the network.  The
   intent can be associated with a series of service attributes, such as
   low latency and high bandwidth.  The value can be allocated by the
   administrator.  The allocation of values of the intent in the
   multiple domain must be consistent.

   [I-D.ietf-spring-segment-routing-policy] defines the color used for
   the SR policy.  The color is a 32-bit numerical value that associates
   the SR Policy with an intent (e.g. low-latency).  There can be the
   mapping as follows between the color and the intent.  If the intent
   and the color can be designed and allocated consistently, the value
   of the color can be the same as that of the intent and the mapping
   between the color and the intent can be saved in the data plane.






Li, et al.              Expires September 8, 2022               [Page 3]


Internet-Draft            Intent-based Routing                March 2022


         +------------+    +-----------+
         |  Intent x  |--->|  Color y  |
         +------------+    +-----------+

    Figure 1  Mapping between Intent and Color


                  Figure 1: Figure 1: Reference Topology

   In the scenario of the inter-domain routing, the SR policy group for
   a specific Endpoint shown in the Figure 2 can be set up in the data
   plane in the local network domain.  That is, it is not necessary to
   advertise the pair <color, endpoint> to set up the end-to-end SR
   path.  When the packet carrying the intent information arrives at the
   edge node of the network domain, the edge node can search the SR
   policy group according to the destination, then steer the packet into
   the corresponding SR policy according to the mapping between the
   color and the intent and the mapping between the color and the SR
   policy.

         [Endpoint]
         +-----------------------------------+
         | +------------+    +-------------+ |
         | |   Color 1  |--->| SR Policy 1 | |
         | +------------+    +-------------+ |
         | +------------+    +-------------+ |
         | |   Color 2  |--->| SR Policy 2 | |
         | +------------+    +-------------+ |
                 ...               ...

         | +------------+    +-------------+ |
         | |   Color n  |--->| SR Policy n | |
         | +------------+    +-------------+ |
         +-----------------------------------+


                    Figure 2: Figure 2: SR Policy Group

   In the scenario of the inter-domain network slicing, the following
   mapping between the color and the local underlay network slice can be
   set up in the data plane in the local network domain.  When the
   packet carrying the intent information arrives at the edge node of
   the network domain, the edge node can steer the packet into the local
   underlay network slice according to the mapping between the color and
   the intent and the mapping between the color and the local underlay
   network slice.





Li, et al.              Expires September 8, 2022               [Page 4]


Internet-Draft            Intent-based Routing                March 2022


         +----------------------------------------+
         | +------------+    +------------------+ |
         | |   Color 1  |--->| Underlay Slice 1 | |
         | +------------+    +------------------+ |
         | +------------+    +------------------+ |
         | |   Color 2  |--->| Underlay Slice 2 | |
         | +------------+    +------------------+ |
                 ...               ...

         | +------------+    +------------------+ |
         | |   Color n  |--->| Underlay Slice n | |
         | +------------+    +------------------+ |
         +----------------------------------------+



   Figure 3: Figure 3: Mapping between Color and Underlay Network Slice

   Since the same Intent may be satisfied by the SR policy or the
   underlay network slice, the local network domain can choose the
   different solutions flexibly without the need of coordination with
   other network domains.  This can also improve the flexibility of the
   inter-domain routing.

   Besides steering the packet into the SR policy or the underlay
   network slice, the network node can also enforce the policy for other
   possible intents such as network measurement, security, etc.  This
   will be defined in the future version of the draft.

4.  Illustration





















Li, et al.              Expires September 8, 2022               [Page 5]


Internet-Draft            Intent-based Routing                March 2022


        SRv6 Policy 12:                                      SRv6 Policy 22:
           Endpoint A3:1::/64                                     Endpoint A3:1::/64
           Color: 20                                            Color: 20
        SRv6 Policy 11:                                      SRv6 Policy 21:
           Endpoint A3:1::/64                                     Endpoint A3:1::/64
           Color: 10                                            Color: 10
          |-------------------------------------|             |-----------------|

        [CSG1]------------[ASG1]-------------[ASBR1]-------[ASBR3]------------[PE1]  Locator: A3:1::/64
        / |                 |                   |    \   /    |                 |  \ VPN SID: A3:1::B100
       /  |                 |                   |     \ /     |                 |   \
  [CE1]   |     M1:AS1      |       M2: AS1     |      X      |   Core: AS2     |   [CE2]
       \  |                 |                   |     / \     |                 |   /
        \ |                 |                   |    /   \    |                 |  /
        [CSG2]-----------[ASG2]--------------[ASBR2]-------[ASBR4]------------[PE2]

     +-------------+      +-------------+       +-------------+    +-------------+
     | A3:1::B100  |      |  Seg list   |       | A3:1::B100  |    |  Seg list   |
     +-------------+      +-------------+       +-------------+    +-------------+
     |    Intent   |      | A3:1::B100  |       |    Intent   |    |  A3:1::B100 |
     +-------------+      +-------------+       +-------------+    +-------------+
     |  Payload    |      |    Intent   |       |  Payload    |    |    Intent   |
     +-------------+      +-------------+       +-------------+    +-------------+
                          |  Payload    |                          |  Payload    |
                          +-------------+                          +-------------+

   Figure 4: Figure 4: Illustration of Intent-based Inter-domain Routing

   Figure 4 shows an example of a service provider network that
   comprises of two Autonomous systems, AS1 and AS2.  The customer
   requests a leased line that requires bandwidth guarantee from CSG1 to
   PE1.  Assume that the following is applied in the network shown in
   the Figure 4:

   o  Independent ISIS instance in core (C) region.

   o  Independent ISIS instance in Metro1 (M1) region.

   o  Independent ISIS instance in Metro2 (M2) region.

   o  BGP between ASBRs

   o  PE1`s locator is A3:1::/64, and VPN SID is A3:1::B100.

   o  Core`s aggregated routes are redistributed from Core to M (M1 and
      M2).





Li, et al.              Expires September 8, 2022               [Page 6]


Internet-Draft            Intent-based Routing                March 2022


   o  SRv6 policy group is set up in the AS1 between the CSG1 and ASBR1.
      It includes two SRv6 policies with the same Endpoint A3:1::/64 and
      color 10 and 20 respectively.

   o  SRv6 policy group is set up in the AS2 between the ASBR3 and PE1.
      It includes two SRv6 policies with the same Endpoint A3:1::/64 and
      color 10 and 20 respectively.

   PE1 advertises the VPN route with color 10 to CSG1.  After CSG1
   receive the VPN route, it maps color to the Intent and installs the
   VPN route with VPN SID A3:1::B100 and the corresponding intent.  When
   CSG1 receives a packet from CE1, assume that CE1 finds the VPN route
   and the forwarding process is as follows:

   1.  CE1 encapsulates a new IPv6 header to the packet with the
   destination IPv6 address set as VPN SID A3:1::B100 and the Intent in
   the packet.

   2.  CE1 can search the forwarding entry according to the destination
   IPv6 address A3:1::B100 and the Intent.

   3.  After CE1 finds the SRv6 Policy 11 with the color 10, it
   encapsulates the new IPv6 header with the corresponding segment list
   to the packet.

   4.  The packet is forwarded to ASBR1 and the segment list is
   decapsulated at ASBR1.

   5.  ASBR1 can send the packet to ASBR3 according to the destination
   address A3:1::B100 by IPv6 forwarding process.

   6.  ASBR3 searches the forwarding entry according to the destination
   IP address A3:1::B100 and the Intent.

   7.  ASBR3 finds the SRv6 policy 21 with the color 10 and encapsulates
   the new IPv6 header with the corresponding segment list to the
   packet.

   8.  The packet is forwarded to PE1 and the segment list is
   decapsulated at PE1.

   9.  The packet is forwarding in the corresponding VPN instance
   identifed by the destination IPv6 address A3:1::B100.








Li, et al.              Expires September 8, 2022               [Page 7]


Internet-Draft            Intent-based Routing                March 2022


5.  IPv6 Encapsulation

   The intent can be encapsulated in the different data plane.  This
   document firstly define the IPv6 encapsulation for the intent.

   In order to support the intent-based routing, one new option, the
   Intent option, is defined.

   The Intent option has the following format:

    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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |    Opt Type   |  Opt Data Len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Intent                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 5. Intent Option



   where:

   o Opt Type: Type value is TBD. 8-bit unsigned integer.  Identifier of
   the type of this Intent Option.

   o Opt Data Len: 8-bit unsigned integer.  Length of the Option Data
   field of this option, that is, length of the Intent.

   o Option Data: Option-Type-specific data.  It carries the Intent.  A
   32-bit identifier.

   The Intent option can be placed in several locations in the IPv6
   packet header depending upon the scenarios and implementation
   requirements.

   1.  Hop-by-Hop Options Header (HBH)

   The Intent option can be carried in the Hop-by-Hop Options Header as
   the new option.  By using the HBH Options Header, the intent
   information carried can be read by every node along the path.

   2.  Destination Options Header (DOH)

   The Intent option can be carried in the Destination Options Header as
   the new option.  By using the DOH Options Header, the intent




Li, et al.              Expires September 8, 2022               [Page 8]


Internet-Draft            Intent-based Routing                March 2022


   information carried can be read by the destination node along the
   path.

   Besides the Intent option, the intent can also be carried combining
   with Application-aware Networking ([I-D.li-apn-framework]).
   [I-D.li-apn-header] and [I-D.li-apn-ipv6-encap] defines that the
   intent can be carried in the APN header which is encapsulated in the
   APN option in the IPv6 data plane.

6.  Security Considerations

   TBD

7.  IANA Considerations

   This document requests IANA to assign a new option type from
   "Destination Options and Hop-by-Hop Options" registry.

   Value Description Reference

   -----------------------------------------------------

   TBD Intent Option this document

8.  References

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

   [RFC7356]  Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
              Scope Link State PDUs (LSPs)", RFC 7356,
              DOI 10.17487/RFC7356, September 2014,
              <https://www.rfc-editor.org/info/rfc7356>.

   [RFC7490]  Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
              So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
              RFC 7490, DOI 10.17487/RFC7490, April 2015,
              <https://www.rfc-editor.org/info/rfc7490>.

   [RFC8400]  Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang,
              "Extensions to RSVP-TE for Label Switched Path (LSP)
              Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June
              2018, <https://www.rfc-editor.org/info/rfc8400>.




Li, et al.              Expires September 8, 2022               [Page 9]


Internet-Draft            Intent-based Routing                March 2022


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

   [RFC8665]  Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
              H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
              Extensions for Segment Routing", RFC 8665,
              DOI 10.17487/RFC8665, December 2019,
              <https://www.rfc-editor.org/info/rfc8665>.

   [RFC8667]  Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
              Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
              Extensions for Segment Routing", RFC 8667,
              DOI 10.17487/RFC8667, December 2019,
              <https://www.rfc-editor.org/info/rfc8667>.

   [RFC8679]  Shen, Y., Jeganathan, M., Decraene, B., Gredler, H.,
              Michel, C., and H. Chen, "MPLS Egress Protection
              Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019,
              <https://www.rfc-editor.org/info/rfc8679>.

8.2.  Informative References

   [I-D.hegde-spring-mpls-seamless-sr]
              Hegde, S., Bowers, C., Xu, X., Gulko, A., Bogdanov, A.,
              Uttaro, J., Jalil, L., Khaddam, M., Alston, A., and L. M.
              Contreras, "Seamless SR Problem Statement", draft-hegde-
              spring-mpls-seamless-sr-06 (work in progress), September
              2021.

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
              P. Mattes, "Segment Routing Policy Architecture", draft-
              ietf-spring-segment-routing-policy-19 (work in progress),
              March 2022.

   [I-D.kaliraj-idr-bgp-classful-transport-planes]
              Vairavakkalai, K., Venkataraman, N., Rajagopalan, B.,
              Mishra, G., Khaddam, M., Xu, X., Szarecki, R. J., and D.
              J. Gowda, "BGP Classful Transport Planes", draft-kaliraj-
              idr-bgp-classful-transport-planes-13 (work in progress),
              January 2022.








Li, et al.              Expires September 8, 2022              [Page 10]


Internet-Draft            Intent-based Routing                March 2022


   [I-D.li-apn-framework]
              Li, Z., Peng, S., Voyer, D., Li, C., Liu, P., Cao, C.,
              Mishra, G., Ebisawa, K., Previdi, S., and J. N. Guichard,
              "Application-aware Networking (APN) Framework", draft-li-
              apn-framework-04 (work in progress), October 2021.

   [I-D.li-apn-header]
              Li, Z. and S. Peng, "Application-aware Networking (APN)
              Header", draft-li-apn-header-00 (work in progress),
              October 2021.

   [I-D.li-apn-ipv6-encap]
              Li, Z. and S. Peng, "Application-aware IPv6 Networking
              (APN6) Encapsulation", draft-li-apn-ipv6-encap-00 (work in
              progress), October 2021.

   [I-D.li-apn-problem-statement-usecases]
              Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Qin, Z.,
              Mishra, G., Ebisawa, K., Previdi, S., and J. N. Guichard,
              "Problem Statement and Use Cases of Application-aware
              Networking (APN)", draft-li-apn-problem-statement-
              usecases-05 (work in progress), December 2021.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <https://www.rfc-editor.org/info/rfc5226>.

   [RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
              Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
              2009, <https://www.rfc-editor.org/info/rfc5462>.

Authors' Addresses

   Zhenbin Li
   Huawei Technologies
   Beijing  100095
   China

   Email: lizhenbin@huawei.com










Li, et al.              Expires September 8, 2022              [Page 11]


Internet-Draft            Intent-based Routing                March 2022


   Zhibo Hu
   Huawei Technologies
   Beijing  100095
   China

   Email: huzhibo@huawei.com


   Jie Dong
   Huawei Technologies
   Beijing  100095
   China

   Email: jie.dong@huawei.com


   Shuai Zhang
   China Unicom
   Beijing
   China

   Email: zhangs366@chinaunicom.cn


   Jianfe Li
   China Unicom
   Beijing
   China

   Email: lijf299@chinaunicom.cn





















Li, et al.              Expires September 8, 2022              [Page 12]