<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.2.3) -->
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-many-lsr-power-group-00" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.30.0 -->
  <front>
    <title abbrev="IS-IS PG">Using IS-IS To Advertise Power Group Membership</title>
    <seriesInfo name="Internet-Draft" value="draft-many-lsr-power-group-00"/>
    <author initials="C." surname="Barth" fullname="Colby Barth">
      <organization>HPE</organization>
      <address>
        <postal>
          <country>USA</country>
        </postal>
        <email>cbarth@juniper.net</email>
      </address>
    </author>
    <author initials="T." surname="Li" fullname="Tony Li">
      <organization>HPE</organization>
      <address>
        <postal>
          <country>USA</country>
        </postal>
        <email>tli@juniper.net</email>
      </address>
    </author>
    <author initials="V. P." surname="Beeram" fullname="Vishnu Pavan Beeram">
      <organization>HPE</organization>
      <address>
        <postal>
          <country>USA</country>
        </postal>
        <email>vbeeram@juniper.net</email>
      </address>
    </author>
    <author initials="R." surname="Bonica" fullname="Ron Bonica">
      <organization>HPE</organization>
      <address>
        <postal>
          <country>USA</country>
        </postal>
        <email>rbonica@juniper.net</email>
      </address>
    </author>
    <date year="2025" month="July" day="30"/>
    <area>Internet</area>
    <workgroup>LSR WG</workgroup>
    <keyword>ISIS</keyword>
    <abstract>
      <?line 54?>

<t>This document introduces Power Groups.  A Power Group is a hierarchical abstraction of power 
consumed by hardware components. In IS-IS, interfaces can reference the Power Group to which
they belong. Therefore, Power Groups provide a method of organizing
interfaces into groups by power characteristics.</t>
      <t>The TE path placement algorithm can use Power Group membership 
information to implement TE policy. Power Group information is particularly useful
when implementing TE policies that support power-savings and sustainability.</t>
    </abstract>
  </front>
  <middle>
    <?line 65?>

<section anchor="intro">
      <name>Introduction</name>
      <t>This document introduces Power Groups.  A Power Group is a hierarchical abstraction of 
power consumed by hardware components. In IS-IS, interfaces can reference the Power Group to which
they belong. Therefore, Power Groups provide a  method of organizing
interfaces into groups by power characteristics.</t>
      <t>The TE path placement algorithm can use Power Group membership 
information to implement TE policy. Power Group information is particularly useful
when implementing TE policies that support power-savings and sustainability.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

</section>
    <section anchor="example-architecture">
      <name>Example Architecture</name>
      <figure anchor="lc1">
        <name>Line Card 1</name>
        <artwork><![CDATA[
                           *------------*
                           |     LC1    |
                           |  100 watts |
                           *------------*
                               /    \
                  -------------      -------------
                  |                               |
           *------------*                  *------------*
           |    FE1     |                  |    FE2     |
           |  300 watts |                  |  300 watts |
           *------------*                  *------------*
          /              \                /              \
         /                \              /                \
    *----------*    *----------*    *----------*    *----------* 
    | INTCOMP1 |    | INTCOMP2 |    | INTCOMP3 |    | INTCOMP4 |
    | 15 watts |    | 20 watts |    | 15 watts |    | 20 watts | 
    | 400 Gbps |    | 800 Gbps |    | 400 Gbps |    | 800 Gbps |
    | (optics  |    | (no      |    | (optics  |    | (no      |
    | included)|    |  optics) |    | included)|    |  optics) |
    *----------*    *----------*    *----------*    *----------*    
     /       \            |            /     \             |
    /         \           |           /       \            |       
 INT1        INT2       INT3      INT4       INT5        INT6
 0 watts     0 watts    5 watts   0 watts    0 watts     5 watts
 No optics   No optics  Optics    No optics  No optics   Optics

Line Card 1 (LC1) consumes 100 watts
]]></artwork>
      </figure>
      <t><xref target="lc1"/> depicts a line card (LC1). LC1 contains two forwarding engines (FE1 and FE2) and four 
interface complexes (INTCOMP1 through INTCOMP4). INTCOMP1 supports in two interfaces (INT1 and INT2). 
Likewise, INTCOMP3 supports in two interfaces (INT4 and INT5). INTCOMP2 and INTCOMP4 support one interface
each (INT3 and INT6).</t>
      <t>An interface complex includes PHY, MAC, encryption, gearbox, and other related circuitry. 
INTCOMP1 and INTCOMP3 also contain optics. INTCOMP2 and INTCOMP4 do not contain optics. Therefore, the interfaces that they support have their own optics.</t>
      <t>INTCOMP1 and INTCOMP3 provide 400 Gbps of forwarding capacity each, while INCOMP2 and INTCOMP4 provide 800 Gbps of forwarding capacity each.</t>
      <t>Each hardware component consumes power. LC1 consumes 100 watts while FE1 and FE2 consume 300 watts
each.  INTCOMP1 and INTCOMP3 consume 15 watts each, while INTCOMP2 and INTCOMP4 consume 20 watts each.
INT3 and INT6 contain optics that consume 5 watts each. INT1, 
INT2, INT4 and INT5 do not do separate optics. Therefore, they do not consume power beyond what is consumed by the complex.</t>
      <t>INT1 and INT2 depend upon INTCOMP1. If INTCOMP1 fails, so do INT1 and INT2. Likewise, INT3 
depends upon INTCOMP2. If INTCOMP2 fails, so does INT3.</t>
      <t>INTCOMP1 and INTCOMP2 depend on FE1. If FE1 fails, so do INTCOMP1, INTCOMP2, INT1, INT2, and INT3. Likewise, 
INTCOMP3 and INTCOMP4 depend on FE2. If FE2 fails, so do INTCOMP3, INTCOMP4, INT4, INT5, and INT6.</t>
      <t>FE1 and FE2 depend on LC1. If LC1 fails, so do all of the forwarding engines, interface complexes, 
and interfaces in the diagram.</t>
    </section>
    <section anchor="power-groups">
      <name>Power Groups</name>
      <t>A Power Group is a hierarchical abstraction of power consumed by
hardware components.  Each Power Group, except for the one at the top
of the hierarchy, has exactly one parent.  The Power Group at the top
of the hierarchy does not have a parent.  Many Power Groups can have
the same parent.</t>
      <t>Each Power Group has one or more components and each component
consumes power.  The power consumed by a Power Group is equal to the
sum of the power consumed by each of its components.  The power
consumed by a Power Group does not include the power consumed by its
ancestors or by its children.</t>
      <t>The parent-child relationship reflects dependency.  One Power Group
is the child of another if any one of the child components depends
upon any one of the parent components.</t>
      <t>A network device's power consumption characteristics can be described
by any number of equivalent Power Group hierarchies.  The paragraphs below
demonstrate how two equivalent Power Group hierarchies can describe the power
consumption characteristics of the line card in Figure 1.</t>
      <table anchor="lcpg">
        <name>A Granular Power Group Hierarchy</name>
        <thead>
          <tr>
            <th align="left">Identifier</th>
            <th align="left">Parent</th>
            <th align="left">Power Consumption</th>
            <th align="left">Hardware Components</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">1</td>
            <td align="left">None</td>
            <td align="left">100 watts</td>
            <td align="left">LC1</td>
          </tr>
          <tr>
            <td align="left">2</td>
            <td align="left">1</td>
            <td align="left">300 watts</td>
            <td align="left">FE1</td>
          </tr>
          <tr>
            <td align="left">3</td>
            <td align="left">1</td>
            <td align="left">300 watts</td>
            <td align="left">FE2</td>
          </tr>
          <tr>
            <td align="left">4</td>
            <td align="left">2</td>
            <td align="left">15 watts</td>
            <td align="left">INTCOMP1</td>
          </tr>
          <tr>
            <td align="left">5</td>
            <td align="left">2</td>
            <td align="left">20 watts</td>
            <td align="left">INTCOMP2</td>
          </tr>
          <tr>
            <td align="left">6</td>
            <td align="left">3</td>
            <td align="left">15 watts</td>
            <td align="left">INTCOMP3</td>
          </tr>
          <tr>
            <td align="left">7</td>
            <td align="left">3</td>
            <td align="left">20 watts</td>
            <td align="left">INTCOMP4</td>
          </tr>
          <tr>
            <td align="left">8</td>
            <td align="left">5</td>
            <td align="left">5 watts</td>
            <td align="left">INT3</td>
          </tr>
          <tr>
            <td align="left">9</td>
            <td align="left">7</td>
            <td align="left">5 watts</td>
            <td align="left">INT6</td>
          </tr>
        </tbody>
      </table>
      <t><xref target="lcpg"/> describes the power consumption characteristics of the line card
in <xref target="lc1"/> using a granular Power Group hierarchy.  We call it
granular because each Power Group contains only one component.  The
power consumed by each Power Group is equal to the power consumed by
its component.</t>
      <t>In <xref target="lcpg"/>, Power Group 7 is the child of Power Group 3 because INTCOMP4
depends upon FE2.  Likewise, Power Group 3 is the child of Power
Group 1 because FE2 depends on LC1. Furthermore, Power Group 8 is the child of Power Group 5 because INT3
depends upon INCOMP2.  Likewise, Power Group 9 is the child of Power
Group 7 because INT6 depends on INTCOMP4.</t>
      <table anchor="lcpgmed">
        <name>A Less Granular Power Group Hierarchy</name>
        <thead>
          <tr>
            <th align="left">Identifier</th>
            <th align="left">Parent</th>
            <th align="left">Power Consumption</th>
            <th align="left">Hardware Components</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">1</td>
            <td align="left">None</td>
            <td align="left">700 watts</td>
            <td align="left">LC1, FE1, FE2</td>
          </tr>
          <tr>
            <td align="left">2</td>
            <td align="left">1</td>
            <td align="left">15 watts</td>
            <td align="left">INTCOMP1</td>
          </tr>
          <tr>
            <td align="left">3</td>
            <td align="left">1</td>
            <td align="left">20 watts</td>
            <td align="left">INTCOMP2</td>
          </tr>
          <tr>
            <td align="left">4</td>
            <td align="left">1</td>
            <td align="left">15 watts</td>
            <td align="left">INTCOMP3</td>
          </tr>
          <tr>
            <td align="left">5</td>
            <td align="left">1</td>
            <td align="left">20 watts</td>
            <td align="left">INTCOMP4</td>
          </tr>
          <tr>
            <td align="left">6</td>
            <td align="left">1</td>
            <td align="left">5 watts</td>
            <td align="left">INT3</td>
          </tr>
          <tr>
            <td align="left">7</td>
            <td align="left">1</td>
            <td align="left">5 watts</td>
            <td align="left">INT6</td>
          </tr>
        </tbody>
      </table>
      <t><xref target="lcpgmed"/> describes the power consumption characteristics of the line card
in <xref target="lc1"/> using a less granular Power Group hierarchy.  We call it
less granular because Power Group 1 contains three components (LC1,
FE1 and FE2).  Its power consumption is equal to the sum of the power
consumed by LC1, FE1 and FE2 (i.e., 700 watts).</t>
      <t>Power Group 2 and Power Group 3 are children of Power Group 1 because
INTCOMP1 and INTCOMP2 depend on FE1.  Likewise, Power Group 4 and Power Group 5
are children of Power Group 1 because INTCOMP3 and INTCOMP4 depend on FE2. Finally,
Power Group 5 and Power Group 7
are children of Power Group 1 because INT3 and INT6 depend on INCOMP2 and INCOMP4..</t>
      <t><xref target="mod"/> describes how a network device's power-save capability
determines which of the equivalent Power Group hierarchies it should
advertise.</t>
      <t><xref target="pwr"/> describes how IS-IS advertises Power Group information.</t>
    </section>
    <section anchor="interfaces-and-power-groups">
      <name>Interfaces and Power Groups</name>
      <t>An interface is not part of a Power Group, even if it contains
optics and consumes power. However, an interface can reference
a Power Group. When it references a Power Group, it <bcp14>MUST</bcp14> reference the
Power Group that contains the interface complex that supports it.
See <xref target="mem"/>.</t>
      <t>Therefore, Power Groups can be used to associate interfaces that depend
on a common set of hardware components and have common power
consumption characteristics.</t>
      <t>A Link Aggregation Group (LAG) interface requires support from multiple
interface complexes. Therefore a LAG interface references every Power Group
that contains an interface complex that supports it.</t>
      <t><xref target="pwr"/> describes how an interface can advertise the power that it
consumes.</t>
    </section>
    <section anchor="mod">
      <name>Power-Save Capability and Power Group Hierarchies</name>
      <t>A network device <bcp14>SHOULD</bcp14> advertise the least granular Power Group
hierarchy that can exercise its complete power-savings capability.</t>
      <t>Assume that a network contains line cards that are
power-save capable. Those line cards contain forwarding
engines and interface complexes that are also power-save
capable. This means that the line cards, forwarding 
engines and interface complexes can be powered on
and off independently of the chassis.</t>
      <t>In order to exercise its complete power savings capability, 
information regarding line card, forwarding engine and interface complex 
dependencies  is required. Therefore,
the line card must advertise the granular Power Group hierarchy 
in <xref target="lcpg"/>.</t>
      <t>Now assume that another network contains line cards that are
power-save capable. Those line cards contain interface 
complexes that are also power-save capable. However, the forwarding
engines are not power-save capable.</t>
      <t>In order to exercise its complete power savings capability,<br/>
information regarding line card, and interface complex
dependencies is required.
However, information regarding forwarding engine dependencies
is not required. Therefore, the line card could advertise
either the granular Power Group hierarchy in <xref target="lcpg"/> or the less 
granular Power Group hierarchy in <xref target="lcpgmed"/>.</t>
    </section>
    <section anchor="link-state-database-elements">
      <name>Link State Database Elements</name>
      <section anchor="the-power-group-tlv">
        <name>The Power Group TLV</name>
        <t>The Power Group is a top level TLV that describes a Power Group.</t>
        <figure anchor="pg">
          <name>Power Group TLV</name>
          <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      |     Length    |      Power Group Identifier
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Power Group Identifier (cont.)|            Power
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Power (cont.)        |         Parent Identifier
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Parent Identifier (cont.)   |C|  Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>Where:</t>
        <ul spacing="normal">
          <li>
            <t>Type: 1 octet, value TBD1</t>
          </li>
          <li>
            <t>Length: 1 octet, unsigned integer.  Value 13.</t>
          </li>
          <li>
            <t>Power Group Identifier: 4 octets, selector.  <bcp14>MUST NOT</bcp14> be equal to 0.</t>
          </li>
          <li>
            <t>Power: 4 octets, unsigned integer.  The power consumed by the Power Group, in milliwatts.</t>
          </li>
          <li>
            <t>Parent Identifier: 4 octets, selector.</t>
          </li>
          <li>
            <t>C: 1 bit.  Indicates that every component in the Power Group is power-save capable.</t>
          </li>
          <li>
            <t>Reserved: 7 bits.  <bcp14>MUST</bcp14> be set to 0 by the sender and <bcp14>MUST</bcp14> be ignored by the receiver.</t>
          </li>
        </ul>
        <t>The Power Group Identifier has node-local significance.  If the
Parent Identifier is equal to 0, the Power Group has no parent (i.e.,
it is the root of a Power Group hierarchy).  Otherwise, the Parent
Identifier <bcp14>MUST NOT</bcp14> be set to 0.</t>
      </section>
      <section anchor="interface-extensions">
        <name>Interface Extensions</name>
        <section anchor="mem">
          <name>The Power Group Member Sub-TLV</name>
          <t>This sub-TLV is found in TLVs for advertising neighbor information.</t>
          <t>This sub-TLV advertises a Power Group to which the interface belongs.
Because a LAG interface can belong to many Power Groups, many instances
of this sub-TLV may be advertised.</t>
          <figure anchor="pgm">
            <name>Power Group Member Sub-TLV</name>
            <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      |     Length    |      Power Group Identifier
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Power Group Identifier (cont.)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:</t>
          <ul spacing="normal">
            <li>
              <t>Type: 1 octet, value TBD2</t>
            </li>
            <li>
              <t>Length: 1 octet, unsigned integer. Value 4,</t>
            </li>
            <li>
              <t>Power Group Identifier: 4 octets, selector.</t>
            </li>
          </ul>
        </section>
        <section anchor="pwr">
          <name>The Interface Power Sub-TLV</name>
          <t>This sub-TLV is found in TLVs for advertising neighbor information.</t>
          <t>This sub-TLV advertises the power consumed by an interface.
A dynamic value might cause unnecessary churn in the Link State
Database (LSDB), so a static value should be used.</t>
          <figure anchor="ips">
            <name>Interface Power Sub-TLV</name>
            <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      |     Length    |            Power
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Power (cont.)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:</t>
          <ul spacing="normal">
            <li>
              <t>Type: 1 octet, value TBD3</t>
            </li>
            <li>
              <t>Length: 1 octet, unsigned integer. Value 4</t>
            </li>
            <li>
              <t>Power: 4 octets, unsigned integer.  The power consumed by the interface, in milliwatts.</t>
            </li>
          </ul>
        </section>
        <section anchor="unidirectional-sleeping-bandwidth-sub-tlv">
          <name>Unidirectional Sleeping Bandwidth Sub-TLV</name>
          <t>This sub-TLV is found in TLVs for advertising neighbor information.</t>
          <t>This sub-TLV advertises the sleeping bandwidth between two directly connected IS-IS neighbors.  The sleeping bandwidth advertised by this sub-TLV <bcp14>MUST</bcp14> be the sleeping bandwidth from the system originating the Link State Advertisement (LSA) to its neighbor.</t>
          <figure anchor="usb">
            <name>Unidirectional Sleeping Bandwidth Sub-TLV</name>
            <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      |     Length    |      Sleeping Bandwidth
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Sleeping Bandwidth            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:</t>
          <ul spacing="normal">
            <li>
              <t>Type:  1 octet, value TBD4</t>
            </li>
            <li>
              <t>Length:  1 octet, unsigned integer. Value 4.</t>
            </li>
            <li>
              <t>Sleeping Bandwidth:  4 octets, IEEE floating-point format measured in bytes per second.</t>
            </li>
          </ul>
          <t>The Sleeping bandwidth field carries the sleeping bandwidth on a link, forwarding adjacency <xref target="RFC4206"/>, or bundled link.  For a link or forwarding adjacency, sleeping bandwidth is defined as the maximum bandwidth <xref target="RFC5305"/> minus the bandwidth currently allocated to RSVP-TE label switched paths that was transitioned to power-sleep.  For a bundled link, sleeping bandwidth is defined to be the sum of the component link sleeping bandwidths.</t>
        </section>
        <section anchor="the-power-sleep-capable-bit">
          <name>The Power-Sleep Capable Bit</name>
          <t>This is a bit in the Link Attribute Sub-TLV (19).  Presence of this
bit indicates that the link may be put into power-sleep mode.
The position of this bit is TBD5.</t>
        </section>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TBD</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is requested to add the following entry to the IS-IS Top-Level TLV Codepoints registry (https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#tlv-codepoints):</t>
      <table anchor="i1">
        <name>IS-IS Top-Level TLV Codepoints</name>
        <thead>
          <tr>
            <th align="left">Value</th>
            <th align="left">Name</th>
            <th align="left">IIH</th>
            <th align="left">LSP</th>
            <th align="left">SNP</th>
            <th align="left">Purge</th>
            <th align="left">MP</th>
            <th align="left">Status Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">TBD1</td>
            <td align="left">Power Group</td>
            <td align="left">N</td>
            <td align="left">Y</td>
            <td align="left">N</td>
            <td align="left">N</td>
            <td align="left">N</td>
            <td align="left">This document</td>
          </tr>
        </tbody>
      </table>
      <t>IANA is also requested to add the following entry to the IS-IS Sub-TLVs for TLVs Advertising Neighbor Information registry 
(https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-neighbor-information):</t>
      <table>
        <name>IS-IS Sub-TLVs for TLVs Advertising Neighbor Information</name>
        <thead>
          <tr>
            <th align="left">Type</th>
            <th align="left">Description</th>
            <th align="left">22</th>
            <th align="left">23</th>
            <th align="left">25</th>
            <th align="left">141</th>
            <th align="left">222</th>
            <th align="left">223</th>
            <th align="left">MP</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">TBD2</td>
            <td align="left">Power Group Member</td>
            <td align="left">Y</td>
            <td align="left">Y</td>
            <td align="left">Y(s)</td>
            <td align="left">Y</td>
            <td align="left">Y</td>
            <td align="left">Y</td>
            <td align="left">N</td>
            <td align="left">This document</td>
          </tr>
          <tr>
            <td align="left">TBD3</td>
            <td align="left">Interface Power</td>
            <td align="left">Y</td>
            <td align="left">Y</td>
            <td align="left">Y(s)</td>
            <td align="left">Y</td>
            <td align="left">Y</td>
            <td align="left">Y</td>
            <td align="left">N</td>
            <td align="left">This document</td>
          </tr>
          <tr>
            <td align="left">TBD4</td>
            <td align="left">Unidirectional Sleeping Bandwith</td>
            <td align="left">Y</td>
            <td align="left">Y</td>
            <td align="left">Y(s)</td>
            <td align="left">Y</td>
            <td align="left">Y</td>
            <td align="left">Y</td>
            <td align="left">N</td>
            <td align="left">This document</td>
          </tr>
        </tbody>
      </table>
      <t>IANA is also requested to add the following entry to the IS-IS Neighbor Link-Attribute Bit Values registry 
(https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-19of22):</t>
      <table anchor="i3">
        <name>IS-IS Neighbor Link-Attribute Bit Values</name>
        <thead>
          <tr>
            <th align="left">Value</th>
            <th align="left">Name</th>
            <th align="left">L2BM</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">TBD5</td>
            <td align="left">Power-Sleep Capable</td>
            <td align="left">N</td>
            <td align="left">This document</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>TBD</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-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"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC4206">
          <front>
            <title>Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)</title>
            <author fullname="K. Kompella" initials="K." surname="Kompella"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="October" year="2005"/>
            <abstract>
              <t>To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct).</t>
              <t>This document describes the mechanisms to accomplish this. [PROPOSED STANDARD]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4206"/>
          <seriesInfo name="DOI" value="10.17487/RFC4206"/>
        </reference>
        <reference anchor="RFC5305">
          <front>
            <title>IS-IS Extensions for Traffic Engineering</title>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="H. Smit" initials="H." surname="Smit"/>
            <date month="October" year="2008"/>
            <abstract>
              <t>This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5305"/>
          <seriesInfo name="DOI" value="10.17487/RFC5305"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+087XLbOJL/8RS4+MfZOUmxJDsfqr3dkx0ncZXj+CwnU6nZ
qSuIhCRs+LUEaUUX513uWe7JrhsgQICkbHkmM3VVu56yQwLobqC/0N0Ap9/v
kyANRbKc0LJY9F/Wb7LPZCAEIYUoIj6hHyW00/NZ/3xGb1I6DW95XgjJ6VW6
5jl9m6dlRt/zeM5zuRIZYfN5zm8nFcTVWxKmQcJiwBTmbFH0Y5Zs+pHM+xnC
95cI3z88JAEr+DLNNxMqi5AQWbAk/C8WpQlAbrgkmZjQn4s06FGZ5kXOFxKe
NrF+CNI45kkhfyFEZPmEFnkpi9Hh4avDEWE5ZzCdpOB5wguyhkVezK7pT2/J
l/VEr0I9nc/OZ4Swslil+YRQ2odfSkUiJ/R0cMLyYqUa9FpO02i+oXVrmgPa
d1dn6iVIy6TAlXycTVUDj5mIJjSY4/j/+FuZiIznA5yNR+ZmQC+EQ+QmTTam
ZScCRSS2Y/80oFcDesJ5zmKHyCchV0lJr9gtS9zenQjezhXAdqLXQDFNRMAc
itdp4jbuRCifKwCPEEnSPGaFuOUorus3p6Ph8FX1+HL44mgCypAsGmOORofP
q8fj8eExPBLS7/cpm8siZwFgvVkJSUFpS9QoWEWRp2EZcOkqvBxQOvUsAGAY
XQngRh6sYKaRxShguemCKnWnYGeJBMwhBfVZsTxcg3qi+mag6KDAA1BUbTo9
JM3zBUPSAcgGNJ3nPAk4LVa+9RUpXQPNFYGODZ1zMJrlgN6sYDgsn/e8mdMs
T29FyGG6MQddD3FyIAOWiP8GSycOVXhM6VJDwXT1CgKYNayK50IWIpADZBin
N2c0Y8WKZhFAKsaxCKxZFKtYTb5sOIzYOgxaCwkYBQRFnEUaBSJNIxFsBj6r
nfHA9gyMSgRlxPJog3QWZUTWK57UiNCBGVwC1lWsWEFlmWXgSPSq+pLdwiiQ
YRJCDzgfkbC5iESxGWj9iEUYRpyQPfQkSiMU/W97SkG+/25qQyqu/z9Sm3/q
zY56A8pymia3iAnEp8a85guRCPWuGfAFWL9O81DSJ+8/zm6e9PS/9PKDer4+
+8+P59dnr/F59m56cWEfSDVi9u7Dx4vX9VMNefrh/fuzy9caGFqp10SevJ9+
hh6c1ZMPVzfnHy6nF0+ASbBMV5NR0YC7c64VK8t5AWrIJAm5DHIxhxeAOTm9
+t//GR7Rb9/+pXLE379XL+iK4QVZq6mlCTBcv6LmEZZlnOWIhUURSD0TBYtg
U2eSylW6TihqJLDz6c/ImV8m9E/zIBse/blqwAV7jYZnXqPiWbulBayZ2NHU
QcZy02tvcNqf7/Sz92747jT+6S+RSDjtD1/+5c9Khc6+MlRIOkUPUfCgKHPw
Q/T+n6d95+fpQ6Pv1N+L06F62WH08PCQrllRyIdHP24m+PMM//x1y0gXW7+j
aQvY3QM0W8vwp90GuH9Zitybs+E22lX/qJs29I5rBndCj7cL4DfN/Jn/+tcm
cLOf3Nfbgm/3W/injTk/6t1iuaPnlzdgeldDzTf7Pmq8jxvvRw4f7+jw2GX+
HR0d+u/39DtYjkBGb+eZHfWy8b6930Gyn2a4XVIzaD9JTdcD/Q4SkQRRGfLw
oBpENdCBAdre/2PkAz+1ohgl8HTD0/Jn7X5nJrUSuSNcBPdS0HhA7EPTA8+j
+nFsn47qxmNn7HONwYi88XxsH51Gd2w1QCO5TKmRn/v8wbS5je5YPUDvAhe4
XZxCTEiHdB98+IEJFmXtpsm3Cd2LgiFVSf2/P3FgnkDs+u0b9MEeHfJMBAWG
pGoPCnCAQjlQmwPgxQAHAqF1SiGWgiAUiwaUJ0sYLuk+ejzc4cGzHaiHRVrm
tA4NVcQa8a841hpqsYLobLmylgjEbF8VbEkVlgBRJ8jcVyJEIig/ACIX4gtf
CwmBqzXyB+CPDPxxTXRk2rRbMOEexNk1NOEsWCkMYzP6+QFEKNOEttZqjAsS
gXefe/T99LQHDAvyTYZRYI8uIfaZp1+r0AgCohxC9ohhkBWIPCgFpMOwOMsS
Z3ZAPJKpEUulHdsWEqY0SYvWYCfcx/zAYZCKdlVqYHiwYrcqixA5xbCsQkG2
zM0kDNbNQb7gKA3EeSyAOJkiL3uYiUCMc37ZMXOD6OUOiGA2Zyibdo5UW4WK
3K1GNyylmoijyWZQvecq8Q8o7V63GW43CX+BXbIxIHYf0Uvx9KshOS0eA+iS
Ugow7CmVGfWop+ZGC+AfySEBAjXbogkbR2EUCZ3FzfkmBVxrJA5ZgpuWovpU
Oq91orZOdCwcnksQheUazHNRs3DBBMb8oM5A1wPGophj2GNKNDbpoRu56EYe
OhAvwm1RVDs5wAVSV2hQ+s0JKUDrWjRj9fuoZ/CN3bkSqxG+HTrURhW1USe1
saV2pMWo/h5bas9hRa6e1phBtRVmVHEPMyZYYD0oqrb/7rWdFzYSxO9l9wo+
FGyZs3iAKYpbKAAv+GsKY44mkc4CB1V27WAGN/o14FmBK1EzQhetXRYkrBmp
1mlIb3rgFMBCvgJlyD9xMBgA4AbUN43KyD1YtD6hYShvyGok71my8UsmWMDA
UVhgoZLFlmLlpFySODecE6wlTr2lK/mqDce2kaYvUytoV4pYUxL87yUIANJ5
mBGBYUYZ2qCKIPSKQvpisJTIdkqWR9Xet4UG4AblAp0q0lziynUbBT2JQmBU
VSPSTOurVr03YvkES0DgryKOAYtWfdhWYaukHxJPmkRI7ZsUPCyJJXqbFfio
NaFigx7isL7yNER5msZgPS2XOaj6CYc4I/8CkLci4P8qvWWrLb9ZCVNqMgeD
MvUUgvwEWkmJtS4kB2ITtyxCcp7OGKviVjCAGawyW0lVz1uDq4yBcqEc/Spd
qyDoYWxqSmY+tfDIfauouFIHjuAn3ohlCbo8xFoYpFohVsIWQAaC8SvNvbtq
CqcO5jv6zjiA01oUkFrdQTJxB4hs5I5R/SWKRCVlh26YrTurkoZOICBPcwGH
5mHcAWhy9wpw/AjAkQt45AKOLIbjBpybuDrQx53QoyZVN811oJ+7A8Y70B67
0C86oe+hfeRCv3QHHNcPXcAe2Vdu54v7AZ9bOJ3eZEuT30xBp1mCtV1Pxd8Z
L26Snmypsh6t6LLlpnbTdMhvqMmgSnVayuiyi7zdRMBaf0JY2I1FQezYOQ8Y
Frx5c3OwiZcqnaLCW6+jDb/jlKCFpOH+O/Zdz9djuKTXhUzyDgNALk2f6vaO
7UKMZvgRm4p7nEDJh+3ETHTv0GKu4x1pA543ZY5+PW6eXYAy3jfdY3e642Zw
WcWWW6b76t7pvnAxP3fnaxjzhzjGF92OsYdOrqc4ud037uKp6H0+chdnRTt8
5S4zGDcQHHci2MVl0Q6PaRE84LVoh798APa5B2ucF1qh9V8XXMqdnRhA/k5+
LMJpPMaZ+QBG/11At460yrkX6mKxqecmNQeYZhddUVTTnTWjWS88Nepuc6V9
MeCDXm0aWL1xJ6kTdN8zqYykCk2bTsR6pt1yzC3u5KhF9ZjsRJXulGu+EQlI
adMjvvtr0nyxO02nPFHT8os42s+ho/v2LU59PcWIlG0JmfFolavijj5PBccM
qhurQqM6tjbS3iGcFQWeJJZRSJi5vjTA+WTrvDUffW/JjpP+HlofIevz3fM6
L26wUTbKgUJnRHjqrJKQRip7iwfPmG5Z6yBVoQfxNvO9d/APTBBLAW7S7h73
E4/CgP6kjraLeoBszgE61Xmqd2PA0xVTczLWyzvKne4hOXJ+QGZg4yB7Hn//
rjO6zvsFVRYEihWiSTMp00Bg2tIsSWpFI5iQqXtf8CC54mlH3UBxT2Xq1dAH
ExmVxV2I5AudLpc5X+r7Anr9+xfTtwfOmnPUvRwmZiqkizyNaVxGhQBedNW9
nTIbTB/QedisZFC4XjGB+KxnXYXmNue3qHhLaay2OzuHwibqUkNd6OnPkJ+n
1jJbDuSdY3rf9tDo25kxrU7VfdIRZ7Lo3G9IXYHRrIBpA0PzAEFN4BqBi2hc
zKgdCApWqlKmQlD7HctVuxNWmgaqRJq+KOIowlRyd7QpzdY1NWLORLzimXP+
YQjoEn5NhThUwGXEnCV1Kd6h2XMLeA9Sq4xLkeHopFVRL12Aw0lM7URVxUwd
BMxPgLKqHCDNQ9SH9D5+0za/e/4NHTQlPVu7iF67CNm9AlPyBeNAnUJfWple
6NatiV+AiEvQJV+/7o9kqImAMOMBdblEW3FVpioc/XjFqVdMHlaRGp/dBvyC
bq0OAKw2nQ7Y3ybaHWTbKUlfkK4ciV1MN+a2qrioSLW9dqlFoy4VYCBQ6wXh
Qgl1B/VwtINWNWcV7pJd4VScjoED+lK1x8wK3OJes4LNGXD/TF88g9hhb69d
lr65+KQroq36epFmMJVbHuEYs00al+8HAsQcX7d/hh1to462sUExhO4xRK3H
kDm9gDT71WPaFJJ/6//G/4hOqvDnZpNxk2ThzwXoSbGq3z221Tn3D5zHNhJ0
Hw19cODdctCVgh9J3EdtiNaZp+3WJYbfiQUd+J2p3J3CPK655PktbETmXsfj
aWHSXNf7GlaCmTEGvDmfEPJUKcYElDCFKK/oUUgWSk5vTl4PoU8ridNbJlIs
E65911IdrnxSAMPxAMZ3C3gCyq3g8aSN45lEioDmeiLuvTZZPbRoXKgOst1n
Oo1bvOguaSyiSKg8VuFusr9zdjDwFJc9F1hDPE9CgV9gVLuOjj/rs/PqzK/h
dzq2FcBqhDvB+pdQZ0aKD8ADjNORA2YdEv13rnYKMwSYkOb1SnMecAGTGbQd
n6NeeHiWpCHvRykeMCInoSPAsyVc20InMi2tdEsIh73WCjVWc86jKwZEFKbk
l6dpO5OrvT5WLj7gzqLTfIVcYSLODFwFMcxRiaWTWdKzrwUH7VBXhvegp8kI
/fENnZXzPnp/iLgh1aoupMuqER4Xaal2ZDQQqQ5NzR6Ie2rCxXI1T/NGiush
cZJif9HmJnkjJdRXykEnT6qKQTPj0WEpDkIUcfMAtaebIMIq1DGhPox1JhQz
vLdezyusdrffvrn9c29rO/YH9rbdaFWOO+7y3L4ioxPXPpyiE9/qxUfYuYMb
1178qIfDH+HFSW10tUlq+NriMMv+nS2u+wjdTeUHkGSHm4TFIqi4EwMFTJXR
9sokAV8qJUPHvirzxDj1Og4lNg7dv5i9PjlQt0YYBesrLEpdRzOVGuTOP6jB
OTbxRwZxj7AykUljZVs0tzaxey1s/DgLswb2q+Mbq9Kt6EbZIv2YiBCyPHWF
CLbvWcR5hiZ1ApHEWoQgp2qBf4BNSkN8bonPebHmXN841fOMMJhCA8RrnbrC
bEiZqxsdeOp9TTPGmYQJl7bMQNUhVd9GFjyGbFVAyszUF02+zdcf9KqvfcDw
pwfqa6pC2in+A1t5W7V+qLF3aK7z8xhjL+XcGPvO1uGbv7b+DvM/ctKkHcwf
c4A2TQCtncH52dkZXUSpUsh+lgIKqu0NC56yzPVHZfMNJiQZlqA4mE9YJQGz
Dn0XHC9usTwX281SnRhEoPle3ZGFfwNHkwQb+nP1efAvPXUXDfxEBPNAADDR
N+gp1At2dsH3umjil3T4yZ/6ZE5NLGZfRVzGzpifq2+RfwFPl5R6VN0blHmu
i7MswvSm0Ocj17NPV/2bMxoxCKCpXIsiWEEPfkxZ5XBrJJgzEBMqgoaqMjac
p12Tu9CH1qA/BGwct9ZpomJPG4Px2zZx6SsR6iOEiNMTYT67VsWsuSi82GRa
FLmYl+CrTMC1P3yF6dVVDqkmnlNVeQHRkF4mW9X+vphcISsL/X2qwwoaQ+44
0HcNU80ug1JPRqIZHOsTvxkHieCpB97MEJC+MvM158lrdSI4vZy2+lRjVe3k
shIhC8OqcAuCXevCZgHRWXWgbf6XC1n/wlb2TmGiylwQ1VJIHL6/KopMTp49
W6/XA8ESNkjz5TMs4C8TVUx8Bnub7BfRbT+w4F1tg6+rIo72/MaDCd5Q0aZ9
Ry/xEusdPT9/h3dIZlfwd3aJf6/KfIk971UTbCygx9f2HPHO3lDBqou926Lj
b8AKv5+rf82v9zm1Dmfs1yv3cwa9muG3qpw/numVnun4QD1MnSDh0gQJ536h
WouD/Gh5dPT0nZilb3bpvhOzaKmp3e2OvlaVYHOFaISfwo3w+7fRMd5UORqq
RtWqmpUIt8hu1JBdlbFp8anfffVV2WfntyVNWiFDYs3A9NdhOoKO+3c9cGOP
Ro1KNxz5Svd4zfgB6mjRojvs1+4Q/Ka2TPkHq9/wVboYjTpdw8Xo5P12/Tk2
+tPYAbYLQIx9ATzMC2T4Hp0GX5J0Dfva0pyoKP+sfv4PhkwZ5f5GAAA=

-->

</rfc>
