<?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="std"
     docName="draft-chen-lsr-ctr-availability-08"
     ipr="trust200902">
  <front>
    <title abbrev="IGP for Network HA">IGP for Network High Availability</title>
     <author initials="H" surname="Chen" fullname="Huaimo Chen">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <street></street>
          <city>Boston, MA</city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>hchen.ietf@gmail.com</email>
      </address>
    </author>

    <author initials="M" fullname="Mehmet Toy" 
            surname="Toy">
      <organization> Verizon </organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <country>USA</country>
        </postal>
        <email>mehmet.toy@verizon.com</email>
      </address>
     </author>

     <author initials="A" fullname="Aijun Wang" 
            surname="Wang">
      <organization>China Telecom</organization>
      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>
          <city>Beijing</city>
          <region> </region>
          <code>102209</code>
          <country>China</country>
        </postal>
        <email>wangaj3@chinatelecom.cn</email>
      </address>
    </author>

   <author initials="L" fullname="Lei Liu" 
            surname="Liu">
      <organization>Fujitsu</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>liulei.kddi@gmail.com</email>
      </address>
    </author>

   <author initials="X" fullname="Xufeng Liu" 
            surname="Liu">
      <organization>IBM Corporation</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region> </region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>xufeng.liu.ietf@gmail.com</email>
      </address>
    </author>


    <date year="2024"/>


    <abstract>
      <t>This document describes protocol extensions to OSPF and IS-IS
      for improving the reliability or availability of a network 
      controlled by a controller cluster.</t>

      <t/>
    </abstract>

    <note 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">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">	
     <t>More and more networks are controlled by 
     central controllers or controller clusters.
     A controller cluster is a single controller externally.
     It normally consists of two or more controllers internally
     working together to control a network, i.e., every network element
     (NE) in the network. 
     The reliability or availability of a network is heavily 
     dependent on its controller cluster. 
     The issues or failures in the controller cluster may impact 
     the reliability or availability of the network greatly.</t>

     <t>For a controller cluster comprising two or more controllers 
     (i.e., primary controller, secondary controller, and so on), 
     the failures in the cluster may split the cluster into a few of 
     separated controller groups. These groups do not know each other 
     and may be out of synchronization. 
     Two or more groups may be elected to control the network at the 
     same time, which may cause some issues.</t>

     <t>This document proposes some procedures and extensions to OSPF and IS-IS
     for the separated controllers or controller groups to know each other 
     thus elect one new primary controller or controller group correctly 
     when the cluster is split because of failures in the cluster.</t>  
    </section> <!-- Introduction -->


    <section title="Terminologies">
    <t>The following terminologies are used in this document.
     <list style="hanging">
       <t hangText="IGP:">Interior Gateway Protocol</t>
       <t hangText="OSPF:">Open Shortest Path First</t>
       <t hangText="IS-IS:">Intermediate System to Intermediate System</t>
       <t hangText="LSA:">Link State Advertisement in OSPF</t>
       <t hangText="LSP:">Link State Protocol PDU in IS-IS</t>
       <t hangText="PDU:">Protocol Data Unit</t>
       <t hangText="LS:">Link Sate, which is LSA in OSPF or LSP in IS-IS</t>
       <t hangText="NE:">Network Element</t>
       <t hangText="CE:">Customer Edge</t>
       <t hangText="PE:">Provider Edge</t>
      </list>
     </t>
    </section> <!-- Terminologies -->


    <section title="IGP for Controller Cluster Reliability">
    <t>This section briefs the mechanism of controller cluster 
    reliability or availability using IGP, and illustrates 
    some details through a simple example.</t>

    <section title="Overview of Mechanism">
    <t>When a cluster of controllers is split into a few of separated
    groups because of failures in the cluster, 
    the live controllers are still actually connected to the 
    network (i.e., network elements). 
    Through some of these connections, each group can get 
    the information about the other groups. 
    A new primary controller or controller group is correctly elected
    to control the network based on the information.</t>

    <t>Each controller may comprise an IGP as an information proxy, 
    called IGP information proxy or IGP for short. 
    The IGP has an IGP adjacency relation with each of 
    a given number of NEs (such as one NE) in the network.
    When one adjacency is broken, a new adjacency is created and 
    maintained if possible. The given number of adjacency relations 
    is retained.</t>

    <t>In normal operations, the cluster has all its controllers connected.
    They are the primary controller controlling the network, the secondary 
    controller, and so on. They have current position 1, 2, and so on respectively.
    The primary controller advertises the information about the controllers 
    via its IGP adjacencies. The extensions to IGP below is used.</t>

    <t>When the cluster is split into a few separated groups, 
    each group elects an intent primary controller, 
    secondary controller and so on from the group, 
    which have intent position 1, 2, and so on respectively.
    The intent primary controller advertises the information about 
    the controllers in the group.</t>

    <t>The information advertised by the (intent) primary controller 
    includes its current (intent) position, its old position, 
    its priority to become a primary controller, the number of controllers,
    and the IDs of the controllers which are ordered according to their
    (intent) positions. In addition, a flag C indicating that 
    whether it is Controlling the network (i.e., it is the primary 
    controller or intent primary controller) is included.</t>
    </section> <!-- Overview -->

    <section title="Example">
    <t><xref target = "cluster-2-controllers"/> 
    shows a controller cluster comprising two controllers: 
    the primary controller and the secondary controller. 
    Each controller includes an IGP as an information proxy.  

<figure anchor="cluster-2-controllers" 
 title="Controller Cluster of 2 Controllers">
  <artwork> <![CDATA[
   +---------------------------------------------------+
   | Controller Cluster                                |
   |                                                   |
   |    +------------+               +------------+    |
   |    |Controller A|  Synchronize  |Controller B|    |
   |    |(Primary)   +---------------+(Secondary) |    |
   |    |       [IGP]|               |       [IGP]|    |
   |    ++-----------+               +-----------++    |
   |     |     ^                                 |     |
   |     |     |_______________                  |     |
   |     |                    |                  |     |
   |     |                    v                  |     |
   +-----|------------Control Channels-----------|-----+
         |               /       \               |
         |IGP Adj       /         \____          |
         \             /           \   \____     |IGP Adj
          \____       /\  .---. .---+       \    |
               \     |  \(     '    |'.---. |    |
                \    |---\  Network |      '+.   |
                NE1 (o    \         |       | ) /
                     (     |        |       o) NE4
                      (    |        |       )
                       (   o NE2    o NE3.-'
                        '               )
                         '---._.-.     )
                                  '---']]></artwork>
</figure>
 
    The IGP in a controller has one IGP adjacency relation 
    with one NE in the network. 
    In <xref target = "cluster-2-controllers"/>,
    the IGP in controller A has IGP adjacency with NE1, 
    the IGP in B has IGP adjacency with NE4.</t>

    <t>In normal operations, the IGP of the primary controller
    originates link state (LS) containing 
    the information about the controllers connected to it.  
    The LS originated by Controller A (Primary)
    in <xref target = "cluster-2-controllers"/>
    having the following contents:</t>

    <t>C = 1, A's current Position = 1, A's OldPosition = 1, 
    A's Priority, NoControllers = 2, A's ID, B's ID</t>

<!--
    <t>The LS originated by Controller B (Secondary)
     in <xref target = "cluster-2-controllers"/> having the contents below:</t>

    <t>C = 0, B's current Position = 2, NoControllers = 2, B's OldPosition = 2, 
    B's Priority, A's ID, B's ID</t>
-->

    <t>When failures happen in the cluster, the live controllers act as follows:</t>

    <t>For the Secondary Controller (e.g., B) alive, 
    if the primary controller is dead,
    it promotes itself as the new primary controller; 
    if the primary controller is alive but separated from the secondary controller, 
    the secondary controller will not promote itself to be a new primary controller.</t>

    <t>For the Primary Controller (e.g., A), 
    if it is alive, it continues to be the primary controller.</t>

    <t>With the extensions to IGP, the secondary controller can determine 
    the status of the primary controller through using IGP  
    and obtaining the information about the primary controller. 
    The conditions that the primary controller is alive but separated from 
    the secondary controller (i.e., condition a: the connection between the primary 
    controller and the secondary controller in the cluster failed, 
    but condition b: the two controllers are alive) can be determined 
    by the secondary controller as follows:</t>

    <t>For condition a, when the heartbeat from the primary stops, 
    the secondary knows that the connection between the primary and 
    secondary controller failed.</t>

    <t>For condition b, it checks its link state database (LSDB) in 
    the IGP to see whether the IGP for the primary controller 
    is connected to some network elements and advertises 
    the LS. 
    If so, the primary controller is alive; otherwise, it is dead.</t>
	    
    </section> <!-- Example -->  
    </section> <!-- IGP for Controller Cluster Reliability --> 


    <section title="Extensions to IGP">
      <t>This section describes extensions to OSPF and IS-IS.</t>

    <section title="Extensions to OSPF">
      <t>A new TLV, called OSPF Controllers TLV, is defined. 
      When OSPF acts as a proxy of a controller in a cluster, 
      it may advertise the information about the controllers such as 
      the number of controllers connected to it (including itself) 
      in its router information LSA, which contains a Controllers TLV 
      of the following format.

<figure anchor="OSPF-controllers-tlv" 
        title="OSPF Controllers TLV">
<artwork> <![CDATA[  
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Type (TBD1)         |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Flags     |C|    Position   |  OldPosition  |   Priority    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                 Reserved                      | NoControllers |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Controller 1 ID                         |
 :                              :                                |
 |                       Controller n ID                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
</figure>
</t>
<t>
     <list style="hanging">
       <t hangText="Type:">TBD1 is to be assigned by IANA.</t>
       <t hangText="Length:">It indicates the length of the value portion in octets.</t>
       <t hangText="Flag (8 bits):">One flag bit, C-bit, is defined. When set, 
          it indicates that the position is the position of the current active primary 
          controller. In this case, C = 1 and Position = 1, which indicate 
          that the controller is the current active primary controller controlling 
          the network.</t>
       <t hangText="Position (8 bits):">It indicates the current/intent position 
          of the controller in the controller cluster or group. 
          1: primary (first) controller, 2: secondary controller, 3: third controller,
          and so on (i.e., Controller Position of value n: n-th controller 
          in the cluster or group).</t>
       <t hangText="OldPosition (8 bits):">It indicates the old position of 
          the controller in the controller cluster before it is split.</t>
       <t hangText="Priority (8 bits):">It indicates the priority of the 
          controller to be elected as a primary controller.</t>
       <t hangText="Reserved (24 bits):">Reserved field, must set to zero for 
          transmission and ignored for reception.</t>
       <t hangText="NoControllers (8 bits):">It indicates the number of controllers 
          connected to the controller advertising the TLV.</t>
       <t hangText="Controller i ID (32 bits):">It represents the identifier (ID)
          of controller i at position i (i = 1, ..., n) in the cluster or group.</t>
      </list>
</t>
      <t>When the information about the controllers is changed, 
      OSPF
      of a primary controller originates an OSPF Router Information Opaque LSA, 
      which includes a OSPF Controllers TLV.</t>
    </section> <!-- Extensions to OSPF -->


    <section title="Extensions to IS-IS">
      <t>Similar to OSPF, a new TLV, called IS-IS Controllers TLV, 
      is defined. 
      When IS-IS acts as a proxy of a controller in a cluster, 
      it may advertise the information about the cluster such as 
      the number of controllers connected to it (including itself) 
      in its LSP, which contains an IS-IS Controllers TLV of the 
      following format.

<figure anchor="is-is-controllers-tlv" 
        title="IS-IS Controllers TLV">
<artwork> <![CDATA[  
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Type (TBD2)  |    Length     | Flags       |C|    Position   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  OldPosition  |    Priority   | NoControllers |    Reserved   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Controller 1 ID                         |
 :                              :                                |
 |                       Controller n ID                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</t>
<t>
     <list style="hanging">
       <t hangText="Type (8 bits):">TBD2 is to be assigned by IANA.</t>
       <t hangText="Length (8 bits):">It indicates the length of the value 
          portion in octets.</t>
       <t hangText="All other fields:">The meaning of each of the other fields 
          is the same as the one of the corresponding field in 
          the OSPF Controllers TLV defined above.</t> 
      </list>
</t>
      <t>When the information about the controllers is changed, the IS-IS
      of a primary controller originates an LSP, 
      which includes an IS-IS Controllers TLV.</t>
    </section> <!-- Extensions to IS-IS -->
    </section>  <!-- Extensions to IGP -->


    <section title="Recovery Procedure">
    <t>This section describes the recovery procedure for 
    a controller cluster of n (n > 2) controllers, which are 
    the primary controller A, the secondary controller B, ..., 
    the n-th controller N.</t> 

    <t>When failures happen in the cluster, it may be split 
    into a few separated groups of controllers. 
    In one policy, the group with the maximum number of controllers 
    is responsible for controlling the network as the primary group of 
    the cluster, in which the new primary controller, secondary controller, 
    and so on are elected.</t>

    <t>For each separated group of controllers,
    the intent primary controller, secondary controller, and so on are elected.
    The intent primary controller of the group advertises the information 
    about the group through its IGP. 
    The information includes its intent position, its old position,
    its priority to become a primary controller,
    the number of controllers in the group, and 
    identifiers of the controllers in the group. 
    The identifiers of the controllers are ordered according to their positions. 
    The identifier of the intent primary controller, which has position 1, 
    is the first one; 
    The identifier of the intent secondary controller, which has position 2, 
    is the second one; and so on. 
    Thus every separated group has the information about the other groups and 
    can determine which group has the maximum number of controllers. </t>

    <t>In the case of tie (i.e., two or more groups have the same maximum number 
    of controllers), the group with the highest priority controller wins 
    in one policy. 
    In another policy, the group with the highest old position controller 
    (e.g., the old primary controller) wins.</t>

    <t>Some details of the recovery procedures 
    in the current and intent primary controller  
    in a controller cluster or group are as follows.</t>

    <t>In normal operations, it advertises Controllers TLV containing:</t> 

    <t>C = 1, Position = 1, Old Position = 1, 
    Primary Controller's priority, NoControllers = n, Primary Controller's ID, 
    secondary controller's ID, ..., and n-th Controller's ID.</t>

    <t>When failures cause the cluster split, it advertises Controllers TLV 
    containing:</t>

    <t>C = 0, Position = 1, 
    Old Position = 1, Intent Primary Controller's priority,
    NoControllers = m (m is the number of controllers in the group 
    that the primary controller is connected after the failures), 
    Intent Primary Controller's ID, IDs of the other controllers connected.</t>
 
    <t>Then after a given time, it checks if the group is elected as the primary 
    group. If so, it advertises Controllers TLV containing:</t>

    <t>C = 1, Position = 1, Old Position = 1, its Priority, NoControllers = m, 
    the IDs of the controllers in the group.</t>

    <t>One example is that failures split the cluster into two separated groups:
    group 1 comprising A and C, group 2 consisting of B and N. 
    Each group elects its intent primary controller, secondary controller, 
    and so on. 
    Suppose that controller A and C are elected as the intent primary and 
    secondary controller respectively in group 1; 
    controller B and N are elected as the intent primary and secondary 
    controller respectively in group 2.</t>

    <t>Each of the intent primary controllers A and B advertises 
    the information about the controllers in its group. 
    The information advertised by A includes:</t>
 
    <t>C = 0, Position = 1, OldPosition = 1, 
    A's Priority, NoControllers = 2, A's ID, C's ID.</t>

    <t>The information advertised by B includes:</t>
 
    <t>C = 0, Position = 1, OldPosition = 2, 
    B's Priority, NoControllers = 2, B's ID, N's ID.</t>

    <t>Group 1 and 2 have the same number of controllers, which is 2. 
    But OldPosition in group 1 is higher than that in group 2. 
    Group 1 is elected as the primary group, and 
    the intent primary controller A in the primary group is determined 
    as the current primary controller. 
    After the determination, the information about the controllers 
    in group 1 (i.e., the primary group) is changed. 
    The updated information advertised by A includes:</t>

    <t>C = 1, Position = 1, OldPosition = 1, 
    A's Priority, NoControllers = 2, A's ID, C's ID.</t>

    </section> <!-- Recovery Procedures -->

 
    <section anchor="IANA" title="IANA Considerations">
      <t>TBD</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBD</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
    <reference anchor="ISO10589">
       <front>
	 <title>
	   Intermediate System to Intermediate System
	   Intra-Domain Routing Exchange Protocol for use in Conjunction
	   with the Protocol for Providing the Connectionless-mode Network
	   Service (ISO 8473)
	 </title>
	 <author>
	   <organization abbrev="ISO">
	     International Organization for Standardization
	   </organization>
	 </author>
	 <date year="2002" month="November"/>
       </front>
       <seriesInfo name="ISO/IEC" value="10589:2002"/>
     </reference>

      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.2328"?>

      <?rfc include="reference.RFC.5305"?>
      <?rfc include="reference.RFC.5329"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.4970"?>
    </references>

  </back>

</rfc>
