<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-dunbar-neotec-net-adjust-cloud-scaling-00"
     ipr="trust200902" submissionType="IETF" updates="8342">
  <front>
    <title abbrev="Resource Abstraction">Dynamic Network Adjustments for Cloud Service Scaling</title>

    <author fullname="Linda Dunbar" initials="L." role="editor" surname="Dunbar">
      <organization>Futurewei</organization>

      <address>
        <postal>
        
          <country>USA</country>
        </postal>

        <email>ldunbar@futurewei.com</email>
      </address>
    </author>



    <author fullname="ChongFeng Xie" initials="C." surname="Xie">
      <organization>China Telecom</organization>

      <address>
        <postal>
        
          <country>China</country>
        </postal>
        <email>chongfeng.xie@foxmail.com</email>
      </address>
    </author>

    <author fullname="Qiang Sun" initials="Q." surname="Sun">
      <organization>China Telecom</organization>

      <address>
        <postal>
        
          <country>China</country>
        </postal>
        <email>sunqiong@chinatelecom.com</email>
      </address>
    </author>
	
    <date year="2024"/>

    <area>ops</area>

    <workgroup>NeoTec</workgroup>

    <keyword>Resource Abstraction</keyword>

    <abstract>
      <t>This document specifies a framework for dynamically adjusting network configurations in response to cloud service scaling events. As cloud services grow, increase traffic, or add resources, automatically adapting network configurations can improve performance and enable greater interoperability. Manual network adjustments are often slow, error-prone, and inadequate for the rapid changes of cloud services. The proposed framework, along with the associated YANG models, facilitates seamless interoperability among network controllers and equipment from various vendors, which is an essential requirement for Telecom Cloud providers operating in multi-vendor environments. </t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
	 <t>Cloud services have become increasingly dynamic, requiring real time adjustments to meet fluctuating workloads and user demand. As these services scale, whether due to increased traffic, new resource allocations, or expanded service delivery, network configurations must adapt accordingly to ensure performance. For example, scaling a cloud service may require adjustments in bandwidth, modifications to load balancers, or updates to access control lists (ACLs).</t>
	  
	<t>Traditionally, coordinating these network adjustment with cloud service scalling has involved manual intervention or reliance on proprietary solutions, both of which are slow, error-prone, and inefficient. 
	With the growing complexity of multi-vendor cloud orchestration systems and network controllers deployed in Telecom Cloud environment, there is a pressing need for a standardized, interoperable approach to managing dynamic network changes.</t>
    <t>The primary objective of this document is to propose a framework for automating network adjustments in response to cloud service scaling. By integrating cloud orchestration systems with network management via standardized YANG models, this framework ensures that network resources can scale flexibly and adapt swiftly to the evolving changes of cloud services. Furthermore, it enables seamless interoperability across controllers and equipment from different vendors, making it particularly valuable for Telecom Cloud providers operating in multi-vendor environments.</t>
     </section>

      <section title="Requirements Language">
        <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>

      <section title="Problem Statement">
	  <t>As cloud services continue to scale dynamically, network infrastructure must adjust in real time to support the changing demands of these services. In many Telcom Cloud Operations, this coordination between cloud service scaling and network reconfiguration is either manual or dependent on proprietary solutions, leading to several key challenges:</t>
	  
	  <t> - Lack of coordination between cloud service orchestration and network management leads to inefficiencies and delays in adapting network configurations to cloud service changes.</t>
	  <t> - Inconsistent and proprietary solutions limit the ability to manage and automate network resources across different vendors and multi-cloud environments.</t>
	  <t> - Delayed network adaptation to cloud service scaling can result in performance issues, traffic congestion, and service disruptions.</t>
	  <t> - Operational complexity increases in multi-cloud and multi-vendor environments due to the lack of standardized, vendor-agnostic frameworks.</t>
	  <t> - No standardized framework exists for automating network adjustments in response to cloud service scaling, limiting the ability to implement seamless, real-time network changes.</t>
	  
	  </section>
	<section title ="Framework for Dynamic Network Adjustments">
	<t>The Dynamic Network Adjustments Framework provides a vendor agnostic, standardized method for automating network changes in response to cloud service scaling events. The framework integrates cloud orchestration systems with network controllers, enabling seamless management of both cloud and network resources.</t>
	<section title = "Core Components">
	<t>The framework consists of three core components:</t>
	<t> - Unified Resource Model (URM): The URM abstracts network and cloud resources, providing a unified interface for managing them across multi-vendor environments.</t>
	<t> - Cloud Orchestration Systems: Platforms like Kubernetes or OpenStack detect changes in cloud services (e.g., increased traffic or resource scaling) and communicate these triggers to the network controllers.</t>
	<t> - Network Controllers: Software-Defined Networking (SDN) controllers or network orchestrators use YANG models to dynamically adjust network resources (e.g., bandwidth, load balancers, ACLs) based on cloud service needs.</t>
	</section>
	<section title = "Work Flow">	
	<t> - Cloud Service Trigger: A cloud orchestration system detects a service scaling event, such as increased traffic or the addition of new compute resources.</t>
	<t> - Trigger to Network Controller: The cloud orchestrator communicates with the network controller, requesting adjustments to network configurations (e.g., increasing bandwidth or reconfiguring the load balancer).</t>
	
	<t> - Network Adjustment via YANG Models: The network controller invokes YANG models, such as the Dynamic-Bandwidth YANG module or Dynamic-Load-Balancer YANG module, to modify the network infrastructure in real time.</t>

	<t> - Feedback Loop: Monitoring systems provide feedback on the effectiveness of the adjustments, ensuring that performance objectives are met.</t>
	
	</section> 
	</section>
 
	<section title = "Network Changes Triggered by Cloud Services">
	<t>This section demonstrates how a cloud service expansion trigger (e.g., scaling a service, increasing traffic, or adding new resources) can interact with a network YANG model to dynamically modify network configurations, such as increasing bandwidth, updating load balancer settings, or adjusting an access control list (ACL).</t>
	<section title = "Dynamic-Bandwidth YANG module" >
	<t>The Dynamic-Bandwidth YANG module, extending the ietf-network-topology YANG model [RFC8345], can be invoked by orchestration systems or controllers in response to events or triggers, such as cloud services scalling up that generates increased traffic.</t>
	<figure>
    <artwork><![CDATA[
  module dynamic-bandwidth {
  namespace "urn:ietf:params:xml:ns:yang:dynamic-bandwidth";
  prefix dbw;

  import ietf-network-topology {
    prefix nt;
  }

  organization "IETF";
  contact "IETF Routing Area";
  description 
	"YANG model for dynamically updating bandwidth.";

  revision "2024-10-18" {
    description "Initial version.";
  }

  augment "/nt:networks/nt:network/nt:link" {
    description
      "Augment the network topology YANG model to update 
	  the bandwidth dynamically.";

    leaf requested-bandwidth {
      type uint64;
      description "Requested bandwidth in Mbps.";
    }
   }
 }
	
	]]></artwork>
	</figure>

	<t>For instance, when a cloud orchestration system detects increased traffic, it can dynamically request an increase in bandwidth to 1000 Mbps (1 Gbps) on network link link-123. The cloud orchestration system can use the following JSON input to initiate the requested changes. </t>
	<figure>
    <artwork><![CDATA[
{
  "nt:networks": {
    "nt:network": [
      {
        "network-id": "cloud-network-1",
        "nt:link": [
          {
            "link-id": "link-123",
            "source-device": "device-1",
            "destination-device": "device-2",
            "requested-bandwidth": 1000  // 1000 Mbps bandwidth
          }
        ]
      }
    ]
  }
}

	]]></artwork>
	</figure>	
	</section>
	<section title = "Dynamic-Load-Balancer YANG Model">
	<t>When a cloud service scales, adjustments to the load balancer configuration may be required, such as adding new backend servers or modifying the load distribution method. The Dynamic-Load-Balancer YANG module defined here can be invoked by automated orchestration systems or controllers in response to specific events or triggers, enabling the load balancer to adapt dynamically to changing service demands.</t>
	
	<figure>
    <artwork><![CDATA[	
module dynamic-load-balancer {
  namespace "urn:ietf:params:xml:ns:yang:dynamic-load-balancer";
  prefix dlb;

  import ietf-inet-types {
    prefix inet;
  }

  organization "IETF";
  contact "IETF Routing Area";
  description
    "YANG model for dynamically managing load balancer config, 
     including backend server lists and load balancing algorithms.";

  revision "2024-10-18" {
    description "Initial revision.";
  }

  container load-balancer {
    description 
      "Container for defining and managing dynamic 
	  load balancer configurations.";

    list balancer {
      key "balancer-id";
      description 
        "List of load balancers, each identified 
		by a unique balancer ID.";
      
      leaf balancer-id {
        type string;
        description "Unique identifier for the 
		load balancer instance.";
      }
      
      leaf algorithm {
        type enumeration {
          enum round-robin {
            description "Distributes traffic evenly across 
			all servers in rotation.";
          }
          enum least-connections {
            description 
              "Sends requests to the server with the 
			  fewest active connections.";
          }
          enum ip-hash {
            description 
              "Distributes requests based on a hash 
			  of the client's IP address.";
          }
        }
        description "Load balancing algorithm to be 
		used by this balancer.";
      }

      list backend-servers {
        key "server-id";
        description 
          "List of backend servers associated with 
		  the load balancer.";

        leaf server-id {
          type string;
          description "Unique identifier for the backend server.";
        }

        leaf ip-address {
          type inet:ipv4-address;
          description "IPv4 address of the backend server.";
        }

        leaf port {
          type uint16;
          description "Port number that the 
		  backend server uses for communication.";
        }
      }
    }
  }
}
	
	]]></artwork>
	</figure>	

	<t>For example, when the cloud service expansion triggers the addition of a new backend server (server-3 with IP 192.168.1.12) to the load balancer lb-1, the cloud orchestration system can automatically trigger the change using the following JSON code. The system specifies the use of the least-connections load balancing algorithm, ensuring that traffic is evenly distributed among backend servers based on the number of active connections.</t>
	<figure>
    <artwork><![CDATA[	
{
  "load-balancer": {
    "balancer": [
      {
        "balancer-id": "lb-1",
        "algorithm": "least-connections",
        "backend-servers": [
          {
            "server-id": "server-1",
            "ip-address": "192.168.1.10",
            "port": 8080
          },
          {
            "server-id": "server-2",
            "ip-address": "192.168.1.11",
            "port": 8080
          },
          {
            "server-id": "server-3",  // New server added dynamically
            "ip-address": "192.168.1.12",
            "port": 8080
          }
        ]
      }
    ]
  }
}

	
	]]></artwork>
	</figure>		
	</section>
	<section title = "Dynamic-ACL YANG Model">
	<t>In response to cloud service expansion or changing security needs, an ACL might need to be modified (e.g., adding or removing IPs allowed to access certain services). The Dynamic-ACL YANG module defined here can be invoked by orchestration systems or controllers to make the desired changes.</t>
	<figure>
    <artwork><![CDATA[	
module dynamic-acl {
  namespace "urn:ietf:params:xml:ns:yang:dynamic-acl";
  prefix dacl;

  organization "IETF";
  contact "IETF Routing Area";
  description "YANG model for dynamically 
	updating access control lists (ACLs).";

  revision "2024-10-18" {
    description "Initial version.";
  }

  list acl {
    key "acl-id";
    leaf acl-id {
      type string;
      description "Identifier for the ACL.";
    }
    list rules {
      key "rule-id";
      leaf rule-id {
        type string;
        description "Identifier for the ACL rule.";
      }
      leaf action {
        type enumeration {
          enum permit;
          enum deny;
        }
        description "Action for this rule (permit or deny).";
      }
      leaf src-ip {
        type inet:ipv4-address;
        description "Source IP address.";
      }
      leaf dst-ip {
        type inet:ipv4-address;
        description "Destination IP address.";
      }
      leaf protocol {
        type enumeration {
          enum tcp;
          enum udp;
          enum icmp;
        }
        description "Protocol for this rule.";
      }
      leaf port {
        type uint16;
        description "Port number associated with this rule.";
      }
    }
  }
}
	
	]]></artwork>	
	</figure>	
	<t> Below is the JSON code to add a new rule (rule-3) to the ACL acl-123, allowing SSH traffic (port 22) from source IP 192.168.1.101 to destination IP 10.0.0.10. The existing rules, rule-1 and rule-2, control HTTPS (port 443) and block HTTP traffic (port 80), respectively.</t>
	<figure>
    <artwork><![CDATA[	
{
  "acl": [
    {
      "acl-id": "acl-123",
      "rules": [
        {
          "rule-id": "rule-1",
          "action": "permit",
          "src-ip": "192.168.1.100",
          "dst-ip": "10.0.0.10",
          "protocol": "tcp",
          "port": 443
        },
        {
          "rule-id": "rule-2",
          "action": "deny",
          "src-ip": "0.0.0.0",
          "dst-ip": "10.0.0.10",
          "protocol": "tcp",
          "port": 80
        },
        {
          "rule-id": "rule-3",  // New rule added dynamically
          "action": "permit",
          "src-ip": "192.168.1.101",
          "dst-ip": "10.0.0.10",
          "protocol": "tcp",
          "port": 22
        }
      ]
    }
  ]
}
	
	]]></artwork>	
	</figure>	
	</section>
	</section>
	
	<section title ="Security Considerations">
	<t>Security is a critical aspect when automating network adjustments in response to cloud service scaling. Several key areas should be addressed:</t>

	<t> - Authentication and Authorization: All communications between the cloud orchestration system and the network controllers must be authenticated and authorized to prevent unauthorized changes to network configurations. Strong access control mechanisms should be enforced to limit access to sensitive operations.</t>

	<t>Data Integrity: Configuration changes and adjustments made via YANG models must ensure data integrity during transmission. Mechanisms such as Transport Layer Security (TLS) should be employed to protect configuration data from tampering or unauthorized modifications.</t>

	<t>Monitoring and Auditing: Logs and records of configuration changes should be maintained for audit purposes. This helps in tracking who made changes, what changes were made, and when they were made. In case of misconfigurations or attacks, such records can be invaluable in diagnosing issues.</t>
	</section>
	
	<section title ="IANA Considerations">
	<t>IANA is requested to register the YANG module namespaces for dynamic-bandwidth, dynamic-load-balancer, and dynamic-acl under the "YANG Module Names" registry at https://www.iana.org/assignments/yang-parameters. These namespaces should be registered as follows:</t>
	<figure>
    <artwork><![CDATA[		
YANG Module           Namespace URI               Prefix   reference
------------          --------------              ------   ----------
dynamic-bandwidth     urn:ietf:params:xml:ns:yang  dbw   this document 
dynamic-load-balancer urn:ietf:params:xml:ns:yang  dlb   this document
dynamic-acl           urn:ietf:params:xml:ns:yang  dacl  this document

	]]></artwork>	
	</figure>	
	
	</section>	
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119.xml"?>
      <?rfc include="reference.RFC.8174.xml"?>
	  <?rfc include="reference.RFC.8345.xml"?>
   
    </references>

  

    <section anchor="Acknowledgements" numbered="no" title="Acknowledgements">
      <t>The authors would like to thank for following for discussions and
      providing input to this document: xxx.</t>
    </section>

    <section numbered="no" title="Contributors">
 
    </section>
  </back>
</rfc>
