<?xml version="1.0"?>
<!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">
<!ENTITY RFC2328 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml">
<!ENTITY RFC4271 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC2328 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml">
<!ENTITY RFC5580 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5880.xml">
<!ENTITY RFC5580 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5882.xml">
<!ENTITY RFC5580 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7938.xml">
<!ENTITY RFC4957 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4957.xml">
]>

<?rfc comments="yes"?>
<?rfc compact="no"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="5"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>

<rfc category="info" docName="draft-dt-rtgwg-dcrouting-requirements-00"
     ipr="trust200902">

  <front>

    <title abbrev="">Requirements for the DataCenter Routing </title>

       <author fullname="Jeff Tantsura" initials="J"
            surname="Tantsura">
      <organization>Individual</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <country>USA</country>
          <code></code>
        </postal>
        <phone></phone>
        <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>

      <author fullname="Dmitry Afanasiev" initials="D"
            surname="Afanasiev">
      <organization>YANDEX</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <country>RU</country>
          <code></code>
        </postal>
        <phone></phone>
        <email>dmitry.afanasiev@gmail.com</email>
      </address>
    </author>




   <author fullname="Keyur Patel" initials="K"
            surname="Patel">
      <organization>Arccus</organization>
      <address>
        <postal>
          <street></street>
          <city>San Jose</city>
          <country>USA</country>
          <code></code>
        </postal>
        <phone></phone>
        <email>keyur@arrcus.com</email>
      </address>
    </author>



    <author fullname="Petr Lapukhov" initials="P"
            surname="Lapukhov">
      <organization>Facebook</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <country>USA</country>
          <code></code>
        </postal>
        <phone></phone>
        <email>petr@fb.com</email>
      </address>
    </author>


    <author fullname="Tony Przygienda" initials="P"
            surname="Przygienda">
      <organization>Juniper</organization>
      <address>
        <postal>
          <street>1137 Innovation Way</street>
          <city>Sunnyvale, CA</city>
          <country>USA</country>
          <code></code>
        </postal>
        <phone></phone>
        <email>prz@juniper.net</email>
      </address>
    </author>




    <author fullname="Russ White" initials="R"
            surname="White">
      <organization>LinkedIn</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <country>USA</country>
          <code></code>
        </postal>
        <phone></phone>
        <email>russ@riw.us</email>
      </address>
    </author>

    <author fullname="Yingzhen Qu" initials="Y"
            surname="Qu">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street></street>
          <city>Santa Clara</city>
          <country>USA</country>
          <code></code>
        </postal>
        <phone></phone>
        <email>yingzhen.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Jim Uttaro" initials="J"
            surname="Uttaro">
      <organization>ATT</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <country>USA</country>
          <code></code>
        </postal>
        <phone></phone>
        <email>juttaro@ieee.org</email>
      </address>
    </author>

    <date month="October" year="2017" />

    <area>Routing</area>

    <workgroup>RTGWG</workgroup>
    
    <abstract>
      <t>
	This document describes list of functional requirments towards
	a Routing Protocol for Data Center Networks.
      </t>
    </abstract>

  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>
	It is common to host and build a network of more than tens of thousands of 
	end points inside a data center. Data Center Networks of such size have unique set of
	requirements with emphasis on scale, convergence, network stability and
	opertional simplicity. Existing or new set of protocols and routing infrastructure
	needs to be augmented to support higher scale, faster convergence with
	increased optional simplicity in order to address the requirements of these
	networks. 
      </t>

      <t>
	This document describes list of functional requirements that are 
	required towards addressing scale, convergence and operational 
	maintainance of such scaled networks. The requirements described
	in this document can be used to augment existing solutions or used
	to design a new set of solutions.
      </t>
    </section>


    <section title="Requirements Language">
      <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 target="RFC2119"/> only when they appear in all upper
	case.  They may also appear in lower or mixed case as English
	words, without any normative meaning.</t>
    </section>


    <section anchor="reco" title="Recommended Reading">
      <t>
	This document assumes knowledge of existing data center networks and data center
	network topologies <xref target="CLOS"/>,<xref target="RFC7938"/>. 
	This document also assumes knowledge of data center routing protocols like
	BGP <xref target="RFC4271"/>, OSPF <xref target="RFC2328"/> and BFD <xref target="RFC5880"/> as well as
	data center layer 2 link layer protocols like LLDP <xref target="RFC4957"/>.
      </t>


    </section>


    <section anchor="goals" title="Goals and Requirements">
      <t>
	Following are general requirements for the Data Center Network Fabric and its Routing Protocols:
      </t>

     
      <t>
      <list style="symbols">
	<t>
	The Fabric provides basic connectivity, with possibility to carry one or more overlays.<vspace></vspace>
	The Fabric provides no domain separation, if needed, to be handled by an overlay.<vspace></vspace>
	The Fabric MAY provide interconnect facility for other fabrics.<vspace></vspace>
	The Fabric MUST support non equidistant end-points.</t>
      </list></t>

     
      <t>
      <list style="symbols">
	<t>
	The Fabric MUST support Spine and Leaf <xref target="CLOS"/> + isomorphic topologies within its network.<vspace></vspace>
	The Fabric MAY support non Spine and Leaf topologies</t>
      </list></t>

      <t>
      <list style="symbols">
	<t>
	The KPI's below are single-dimensional and expected to be changed, as the document progresses, baseded on more feedback, we ask community to communicate their views.
	Combination of # of routes vs # of paths vs desired convergence time will be discussed in a later version.<vspace blankLines="1"/>
	The Fabric SHOULD support 250k routes @ 5k fabric nodes with convergence time below 250ms.<vspace></vspace>
	The Fabric SHOULD support 500k routes @ 7.5k fabric nodes with convergence time below 500ms.<vspace></vspace>
	The Fabric SHOULD support 1M routes @ 10k fabric nodes with convergence time below 1s.
	</t>
      </list></t>

      <t>
      <list style="symbols">
	<t>
	The Fabric routing protocol MUST support load balancing using ECMP, wECMP and UCMP.<vspace></vspace> 
	The Fabric routing protocol MAY support any custom or adaptive load balancing algorithms.<vspace></vspace>
	The Fabric routing protocol MUST support and provide facility for topology-specific algorithms that enable correct operations in that specific topology.
	  
	</t>
      </list></t>

      <t>
      <list style="symbols">
	<t>
	The Fabric routing protocol SHOULD support route scale and convergence times of a Fabric mentioned above.<vspace></vspace>
	The Fabric routing protocol SHOULD support ECMP as wide as 256 paths.
	</t>
      </list></t>

      <t>
      <list style="symbols">
	<t>
	  The Fabric routing protocol MUST support various address families that covers IP as well as MPLS forwarding.<vspace></vspace> 
	  The Fabric routing protocol MUST support extensions to carry 3rd party data and Opaque data.
	</t>
      </list></t>

      <t>
      <list style="symbols">
	<t>
	The Fabric routing protocol MUST support Traffic Engineering paths that are host and/or router based paths.<vspace></vspace>
	The Fabric routing protocol MUST provide facility to address constituents in an ECMP bundle.
	</t>
      </list></t>

      <t>
      <list style="symbols">
	<t>
	  The Fabric routing protocol MUST support inband as well as out of band management. 
	</t>
      </list></t>

      <t>
      <list style="symbols">
	<t>
	The Fabric routing protocol MUST support Zero Touch Provisioning (ZTP). <vspace></vspace>
	The Fabric routing protocol MUST support Neighbor Discovery to facilitate ZTP. 
	</t>
      </list></t>

      <t>
      <list style="symbols">
	<t>
	The Fabric routing protocol MUST be able to leverage BFD <xref target="RFC5880"/> for neighbor state. <vspace></vspace>
	The Fabric routing protocol SHOULD be capable of bootstrapping a BFD session <xref target="RFC5882"/>.
	</t>
      </list></t>

      <t>
      <list style="symbols">
	<t>
	  The Fabric routing protocol MUST be able to support real time state notifications of routes
	  and its neighbors state to facilitate control plane telemetry.<vspace></vspace>
	  The Fabric routing protocol MUST be able to support on-demand snapshots of protocol state and real time state notifications of routes  and its neighbors state to remote node(s) to facilitate control plane telemetry.
	</t>
      </list></t>

      <t>
      <list style="symbols">
	<t>
	  The Fabric routing protocol MUST be able handle commission/decommission of a node as well as
	  any node restart with a minimal data plane impact.
	</t>
      </list></t>
</section>


 <section anchor="study" title="For further study">
      <t>
	Following topics have been identified to be studied at a later time:  
      </t>
	<t>
	  <list style="symbols">
	    <t>
              gRPC/THRIFT/similar encodings.
	    </t>
	</list></t>
	<t>
	  <list style="symbols">
	    <t>
	      Ability to function as an overlay. 	      
	    </t>
	</list></t>
	<t>
	  <list style="symbols">
	    <t>
	      Flowlets signaling.	      
	    </t>
	</list></t>
	<t>
	  <list style="symbols">
	    <t>
	      Multicast.	      
	    </t>
	</list></t>
	<t>
	  <list style="symbols">
	    <t>
	      State representation NB.	      
	    </t>
	</list></t>
	<t>
	  <list style="symbols">
	    <t>
	      Integration with PCE/SDNc.	      
	    </t>
	</list></t>
      </section>


    <section anchor="topo" title="Network Topologies">
      <t>

      </t>
      </section>

    <section anchor="IANA" title="IANA Considerations">
      
      <t>

      </t>
      
    </section>
    
    <section anchor="Security" title="Security Considerations">
      <t>
	This document describes list of functional requirements towards
	a routing protocol for Data Center Networks. It does not raise
	any security concerns or issues in addition to ones common to
	a routing protocol for Data Center Networks.
      </t>
      
    </section>
    
    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
      </t>
    </section>
    
    <section anchor="log" title="Change Log">
      <t><list style="hanging">
          <t hangText="Initial Version:">October 31 2017</t>
      </list></t>
    </section>
  </middle>
  
  <back>

    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>


   </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.4271"?>
      <?rfc include="reference.RFC.2328"?>
      <?rfc include="reference.RFC.5880"?>
      <?rfc include="reference.RFC.4957"?>
      <?rfc include="reference.RFC.5882"?>
      <?rfc include="reference.RFC.7938"?>

      <reference anchor="CLOS" target="">
        <front>
          <title>A Study of Non-Blocking Switching Networks</title>

	  <author initials="" surname="">
            <organization></organization>
          </author>
          <date month='March' year='1953' />
        </front>
        <seriesInfo name='' value='The Bell System Technical Journal, Vol. 32(2),
				   DOI 10.1002/j.1538-7305.1953.tb01433.x' />
      </reference>

    </references>
  </back>
</rfc>
