<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc>
<?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-ginsberg-lsr-hello-capability-00"
     ipr="trust200902" submissionType="IETF" consensus="true">
  <front>
    <title abbrev="hello-capability">
      IS-IS Hello Capability
    </title>
    <author fullname="Les Ginsberg" initials="L" surname="Ginsberg">
      <organization>Cisco Systems</organization>
      <address>
        <email>ginsberg@cisco.com</email>
      </address>
    </author>
    <author fullname="Tony Przygienda" initials="T." surname="Przygienda">
      <organization>HPE</organization>

      <address>
        <email>antoni.przygienda@hpe.com</email>
      </address>
    </author>
    <date year="2026"/>
    <area>Routing Area</area>
    <workgroup>LSR Working Group</workgroup>
    <keyword>Hello</keyword>
    <keyword>Draft</keyword>
    <abstract>
      <t>
        Advertisement of capabilities in Hellos is useful to
	allow support of optional features in establishing and maintaining
	adjacencies. This document defines a new TLV to be sent in
	hellos to advertise such capabilities.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="Introduction" title="Introduction">
      <t>
        <xref target="RFC7981"/> defines the Router Capability TLV which
	is used to advertise capabilites of a router to other routers
	in an area/domain. This allows routers to advertise information
	necessary for a given router to participate in optional
	features in an area/domain.
      </t>
      <t>
	There is an analogous need to know what optional features
	a neighbor supports so as to determine whether those features
	can be used when establishing/maintaining adjacencies.
      </t>
      <t>
	This document defines a new TLV to be sent in Hello PDUs
	which supports advertisement of optional features.
      </t>
    </section>
      
    <section anchor="ReqLang" 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 <xref
      target="RFC2119">BCP 14</xref> <xref target="RFC8174"/> when, and only
      when, they appear in all capitals, as shown here.</t>
    </section>

    <section anchor="Hello cap" title="Hello Capability Definition">
      <t>
	The Hello Capability TLV provides the ability to advertise support
	for optional capabilities. The TLV MAY be included in the following
	PDU types:
	<list>
	  <t>
	    L1-LAN-HELLO-PDU (15)
	  </t>
	  <t>
	    L2_LAN-HELLO-PDU (16)
	  </t>
	  <t>
	    P2P-HELLO-PDU (17)
	  </t>
	</list>
      </t>
      <t>
	Two classes of information may be advertised in this TLV.
      </t>
      <t>
	Support for capabilities which require no additional information
	are indicated by setting a bit in a variable length bit mask.
      </t>
      <t>
	Support for capabilites which require additional information are
	indicated by advertising a sub-TLV.  Sub-TLVs are included following
	the variable length bit mask.
      </t>
    </section>
    <section anchor="TLV Definition" title="Hello Capability TLV Definition">
      <t>
	This section defines the format and constraints of the Hello
	Capability TLV.
      </t>
      
      <t> <figure>
	<artwork align="left">
         0 1 2 3 4 5 6 7
         +--+--+--+--+--+
	 | TLV Type     |
         +--+--+--+--+--+
	 | TLV Length   |
         +--+--+--+--+--+
	 | CB Length    |
         +--+--+--+--+--+...
         | CBs ...
         +--+--+--+--+--+...
	 | Optional sub-TLVs 
         +--+--+--+--+--+...
	</artwork>
      </figure></t>

      <t>
	TLV Type is TBA by IANA (1 octet)
      </t>
      <t>
	TLV Length is total length of the data which follows (1 octet)
      </t>
      <t>
	CB Length is length of the Capability Bits ((Number of bits + 7) / 8 octets (1 octet)
	May be 0.
      </t>
      <t>
      CBs are the Capability Bits starting with Bit #0.
      Bit definitions SHOULD be assigned in ascending bit order
      so as to minimize the number of bits which will need to be
      transmitted.
      </t>
      <t>
      Undefined bits MUST be transmitted as 0 and MUST be
      ignored on receipt.
      </t>
      <t>
      Bits which are NOT transmitted MUST be treated as if they are
      set to 0 on receipt.
      </t>
      <t>
      No capability bits are defined in this document.
      </t>
      <t>
	No sub-TLVs are defined in this document.
      </t>
      <t>
	Multiple Hello Capability TLVs MAY be advertised in a hello PDU.
	When multiple Hello Capability TLVs are present in a hello PDU
	only the bit mask in the first such TLV is considered.
      </t>
      <t>
	Subsequent TLVs in the same hello MUST specify a zero length
	bit mask. Non-zero length bit masks in other than the first
	Hello Capability TLV MUST be ignored on receipt.
      </t>
      <t>
	sub-TLVs MAY appear in any Hello Capability TLV.
      </t>
    </section>

    <section anchor="New Registries" title="New Registries">
      <t>
	Two new registries are defined by this document.
      </t>
      <t>
	IS-IS Bit Values for the Hello Capabilities TLV is a new registry
	which defines the bit values advertised in the Capability Flags
	of the Hello Capability TLV.
      </t>
      <t>
	IS-IS Sub-TLVs for the Hello Capabilites TLV is a new registry
	which defines the sub-TLV types which may be included in a
	Hello Capabiily TLV
      </t>
    </section>
      
    <section anchor="IANA" title="IANA Considerations">
      <section anchor="IANAISISTLV"
               title="IS-IS Hello Capability TLV">
	<t indent="0"> This document updates the "IS-IS Top-Level TLV Codepoints"
	registry as follows:</t>
	<table anchor="T1" align="center" pn="table-1">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">IIH</th>
              <th align="left" colspan="1" rowspan="1">LSP</th>
              <th align="left" colspan="1" rowspan="1">SNP</th>
              <th align="left" colspan="1" rowspan="1">Purge</th>
              <th align="left" colspan="1" rowspan="1">MP</th>
              <th align="left" colspan="1" rowspan="1">Status/Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">TBA</td>
              <td align="left" colspan="1" rowspan="1">Hello Capability</td>
              <td align="left" colspan="1" rowspan="1">Y</td>
              <td align="left" colspan="1" rowspan="1">N</td>
              <td align="left" colspan="1" rowspan="1">N</td>
              <td align="left" colspan="1" rowspan="1">N</td>
              <td align="left" colspan="1" rowspan="1">Y</td>
              <td align="left" colspan="1" rowspan="1">draft-ginsberg-lsr-hello-capability</td>
            </tr>
          </tbody>
	</table>
      </section>
      
      <section anchor="IANAISISRegistries"
              title="IS-IS Hello Capability TLV Registries">
	<t>
	  This document introduces a new registry for bit values in the
	  new Hello Capability TLV.  The registration policy is Expert
	  Review as defined in <xref target="RFC8126"/>. This registry is part of the
	  "IS-IS TLV Codepoints" registry. The name of the registry is
	  "IS-IS Bit Values for Hello Capability TLV Flags.  No bit values
	  are currently defined.
	</t>
	
	<t>
	  This document introduces a new registry for sub-TLVs in the
	  new Hello Capability TLV.  The registration policy is Expert
	  Review as defined in <xref target="RFC8126"/>. This registry
	  is part of the
	  "IS-IS TLV Codepoints" registry. The name of the registry is
	  "IS-IS Sub-TLVs for Hello Capability TLV.  No sub-TLVs
	  are currently defined.
	</t>
      </section>
    </section>
    
      <section anchor="Security" title="Security Considerations">
	<t>
	  Security concerns for IS-IS are addressed in
	  <xref target="RFC5304"/> and <xref target="RFC5310"/>.
	</t>
	
	<t>Advertisement of additional capability information may introduce
	new security concerns. Discussion of those security concerns is required
	in the future documents which defines those capabilities.
	</t>
      </section>
    </middle>
  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include='reference.RFC.5304'?> 
      <?rfc include='reference.RFC.5310'?> 
      <?rfc include='reference.RFC.7981'?> 
      <?rfc include='reference.RFC.8126'?> 
      <?rfc include='reference.RFC.8174'?> 
    </references>
  </back>
</rfc>
