<?xml version="1.0" encoding="US-ASCII"?>
<?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-fu-computing-resource-notification-domain-00"
     ipr="trust200902" obsoletes="" sortRefs="true" submissionType="IETF"
     symRefs="true" tocDepth="3" tocInclude="true" updates="" version="3"
     xml:lang="en">
  <!-- xml2rfc v2v3 conversion 3.15.1 -->

  <front>
    <title abbrev="draft-fu-computing- notification-domain-00">Computing
    resource notification domain in network</title>

    <seriesInfo name="Internet-Draft"
                value="draft-fu-computing- notification-domain -00"/>

    <author fullname="Yuexia Fu" initials="Y." surname="Fu">
      <organization>China mobile</organization>

      <address>
        <postal>
          <street>No.32 XuanWuMen West Street</street>

          <city>Beijing</city>

          <code>100053</code>

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

        <email>fuyuexia@chinamobile.com</email>
      </address>
    </author>

    <date year="2022"/>

    <area>Routing Area</area>

    <workgroup>Inter-Domain Routing</workgroup>

    <abstract>
      <t>This document introduces the requirements of notification domain
      definition and the process of service scheduling decision based on the
      notification domain in the network.</t>
    </abstract>

    <note>
      <name>Requirements Language</name>

      <t>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 <xref format="default"
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>

      <t>In the existing computing information notification schemes, computing
      information status notification is made by extending BGP (Border Gateway
      Protocol) to the whole network, without defining the scope of the
      notification, so that all the routers on the whole network need to
      maintain the service computing information of the whole network, and the
      routing table is too large, which causes the burden to the network and
      routers. The shortcoming of the existing technology is that the existing
      computing information notification scheme increases the amount of
      information notification in the network.</t>

      <t>This document introduces the requirements of notification domain
      definition and the process of service scheduling decision based on the
      notification domain in the network.</t>
    </section>

    <section numbered="true" toc="default">
      <name>Requirements of the partitioning and adjustment of the
      notification domain</name>

      <t>The CAN system contains the control plane and the forwarding plane.
      The control plane in the CAN network needs to obtain the computing
      information of the servers for a service, and monitor the tunnel/ policy
      statuses to the potential Egresses for the service. As described in
      [I-D.liu-dyncast-reqts], the representation and encoding of computing
      metric is crucial, which is conveyed to CAN system to support the CAN
      components to act upon. The representation needs to express the
      capabilities of computing resources accurately, the requirements
      contains several aspects as described below. o Support to determine the
      notification domain based on the computing service topology. o Support
      the notification domain is the division of adjacent domains into a
      notification domain based on geographical location, and/or the division
      of areas with the same service deployment into a notification domain
      based on service dimension. o Support that the notification domain is
      divided according to the geographical location and then the
      advertisement relationship between each autonomous domain is determined
      according to the existing AS domain in the IP protocol. o Support that
      when the size of the notification domain is determined, according to the
      network status information, the notification domain is expanded when the
      network status is good, and the notification domain is reduced when the
      network status is bad. o Support that when the notification domain is
      divided according to services, the size of the notification domain is
      determined according to the number of nodes deployed in the notification
      domain.</t>
    </section>

    <section numbered="true" toc="default">
      <name>Process of service scheduling decision based on the notification
      domain</name>

      <t>The computing information notification method is proposed to reduce
      the amount of computing notification information.</t>

      <t>Step 1: The central controller determines the notification domain</t>

      <t>Option 1: The central controller could determine the notification
      domain based on the computing service topology. The generation of
      computing service topology includes the identification information of
      computing service and the location information of computing service
      deployment, and advertising the service topology information; and then
      advertises service status information on the established service
      topology. During implementation, the computing service topology is
      generated based on the network topology and computing node topology
      generated by BGP-LS; and the service topology information is advertised
      through BGP-LS and DHCP by adding computing service information to the
      node attribute field.</t>

      <t>Option 2: The central controller obtains the AS autonomous domain
      division strategy of the whole network and determines the size of the
      notification domain by combining the network status information of
      different regions. The network status information is reported by nodes
      to the central controller.</t>

      <t>Option 3: The central controller receives the inter-domain router
      network state information, service deployment information, as well as
      generating capacity after list, according to the different domain
      partition strategy to subscribe to the node network status information
      or services generated after the deployment information, and distributed
      to the inter-domain router for its configuration.</t>

      <t>Step 2: The central controller advertises the notification domain
      partitioning policy. The notification domain partitioning policy carried
      through Netconf and Yang management protocol is delivered. In practice,
      the notification domain is identified as follows:</t>

      <t>&amp;#61548; The number of AS through which the computational update
      information passes is set, and the hop limit is set to identify it.
      Or,</t>

      <t>&amp;#61548; Routers in the same advertisement domain are divided
      into the same community by using the BGP community attribute to identify
      the advertisement domain</t>

      <t>Step 3: The central controller advertises computing information to
      nodes in the notification domain.</t>

      <t>Step 4: When the central controller schedules service requests, it
      selects the computing nodes that need to obtain real-time service status
      information through the generated computing service topology and sends
      the detection packet of service status information.</t>

      <t>Step 5: The notification domain adjustment policy generation When
      adjusting the size of the notification field, it further includes: The
      notification domain adjustment policy carried through Netconf and Yang
      management protocol is delivered based on one or a combination of the
      network status information, service scheduling result feedback
      information, and service deployment.</t>
    </section>

    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>

      <t>TBD</t>
    </section>

    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>

      <t>TBD</t>
    </section>

    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>

      <t>TBD</t>
    </section>
  </middle>

  <back>
    <references>
      <name>Normative References</name>

      <reference anchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement
          Levels</title>

          <author fullname="S. Bradner" initials="S." surname="Bradner">
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
