<?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-hegde-lsr-asla-any-app-01"
     ipr="trust200902">
  <front>
    <title abbrev="ASLA Any Application Bit">The Application Specific Link
    Attribute (ASLA) Any Application Bit</title>

    <author fullname="Shraddha Hegde" initials="S." surname="Hegde">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street>Exora Business Park</street>

          <city>Bangalore</city>

          <region>KA</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>shraddha@juniper.net</email>
      </address>
    </author>

    <author fullname="Ron Bonica" initials="R." surname="Bonica">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street>2251 Corporate Park Drive</street>

          <city>Herndon</city>

          <code>20171</code>

          <region>Virginia</region>

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

        <email>rbonica@juniper.net</email>
      </address>
    </author>

    <author fullname="Chris Bowers" initials="C." surname="Bowers">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <email>cbowers@juniper.net</email>
      </address>
    </author>
	<author fullname='Robert Raszuk' initials='R' surname='Raszuk'>
    <organization>NTT Network Innovations</organization>
    <address>

        <email>robert@raszuk.net</email>
    </address>
</author>
<author fullname='Zenbin' initials='Z' surname='Li'>
    <organization>Huawei Technologies</organization>
    <address>

        <email>lizhenbin@huawei.com</email>
    </address>
</author>
	<author fullname='Dan Voyer' initials='D' surname='Voyer'>
    <organization>Bell Canada</organization>
    <address>

        <email>daniel.voyer@bell.ca</email>
    </address>
</author>


    <date day="7" month="February" year="2022"/>

    <area>Routing</area>

    <workgroup>LSR</workgroup>

    <keyword>IS-IS</keyword>

    <keyword>OSPF</keyword>

    <keyword>IGP</keyword>

    <keyword>ASLA</keyword>

    <abstract>
      <t>RFC 8919 and RFC 8920 define Application Specific Link Attributes
      (ASLA). Each ASLA includes an Application Identifier Bit Mask. The
      Application Identifier Bit Mask includes a Standard Application Bit Mask
      (SABM) and a User Defined Application Bit Mask (UDABM). The SABM and
      UDABM determine which applications can use the ASLA as an input.</t>

      <t>This document introduces a new bit to the Standard Application Identifier Bit
      Mask. This bit is called the Any Application Bit (i.e., the A-bit). If
      the A-bit is set, the link attribute can be used by any application.
      This includes currently defined applications as well as applications to
      be defined in the future.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="sec_introduction" title="Introduction">
      <t><xref target="RFC8919"/> and <xref target="RFC8920"/> define
      Application Specific Link Attributes (ASLA). Each ASLA includes an
      Application Identifier Bit Mask. The Application Identifier Bit Mask
      includes a Standard Application Bit Mask (SABM) and a User Defined
      Application Bit Mask (UDABM).</t>

      <t>Each bit in the SABM represents a standard application while each bit
      in the UDABM represents a user defined application. If a bit in the SABM
      or UDABM is set, the corresponding application can use the ASLA as an
      input. If a bit in the SABM or UDABM is not set, the corresponding
      application cannot use the associated ASLA as an input.</t>

      <t>According to <xref target="RFC8919"/>:</t>

      <t>"If link attributes are advertised associated with zero-length
      Application Identifier Bit Masks for both standard applications and
      user-defined applications, then any standard application and/or any
      user-defined application is permitted to use that set of link attributes
      so long as there is not another set of attributes advertised on that
      same link that is associated with a non-zero-length Application
      Identifier Bit Mask with a matching Application Identifier Bit set."</t>

      <t>This restriction introduces complexity. For example, assume that a
      network runs many applications. All applications use Attribute 1 as an
      input. So, it would be convenient to advertise Attribute 1 with a
      zero-length SABM / UDABM. </t>

      <t>However, Applications X and Y also use Attribute 2 as an input.
      Because Applications X and Y required unique values for Attribute 2,
      Attribute 2 cannot be advertised with a zero-length SABM. Therefore,
      Attribute 1 cannot be advertised with a zero-length SABM / UDABM either,
      because Applications X and Y require it. This would result in having to set the
	  application X and application Y bits on attribute 1 in the entire network
	  on each link and is operationally complex.</t>

      <t>This document reduces operational complexity by introducing a new bit
      to the Standard Application Identifier Bit Mask. This bit is called the Any
      Application Bit (i.e., the A-bit). If the A-bit is set, the link
      attribute can be used by any application. This includes currently
      defined applications as well as applications to be defined in the
      future.</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 title="The Any Application Bit">
      <t>A new bit is defined in the Standard Application Identifier Bit Mask. This bit
      is called the Any Application Bit (i.e., the A-bit). If the A-bit is
      set, the link attribute can be used by any application. This includes
      currently defined applications as well as applications to be defined in
      the future.</t>

      <t>If a link advertises an ASLA twice, once with the A-bit set and once
      with a more specific Application Identifier Bit set, the indicated
      application MUST use the value from the ASLA with the more specific
      Application Indicator Bit set.</t>

      <section title="IS-IS">
        <t>IS-IS uses Bit 4 of the SABM to encode the A-bit.</t>
      </section>

      <section title="OSPF">
        <t>OSPF uses Bit 4 of the SABM to encode the A-bit.</t>
      </section>
    </section>

    <section anchor="backward_compatibility" title="Backward Compatibility">
      <t>The solution described in this document is backward compatible with
      <xref target="RFC8919"/> and <xref target="RFC8920"/>. An implementation that
      does not recognize the A-bit will process the SABM as specified in <xref
      target="RFC8919"/> and <xref target="RFC8920"/>.</t>
	  <t> Implementations MAY advertise attributes under both A bit and with SABM and
	  UDABM length set to zero for backward compatibility reasons. 
	  When same attributes are received with A bit set as well as in
	  ASLA with SABM and UDABM set to zero, the attributes MUST be used from the ASLA
	  with SABM and UDABM set to zero and procedures described in RFC 8919 sec 6.2 MUST be
	  followed.</t>
    </section>

    <section anchor="sec-con" title="Security Considerations">
      <t>The security considerations discussed in <xref target="RFC8919"/> and
      <xref target="RFC8920"/> are applicable to this document. This document
      does not introduce any new security risks.</t>
    </section>

    <section title="IANA Considerations">
      <t>This document requests that IANA add the following entry to the
      registry titled "Link Attribute Application Identifiers" under the
      "Interior Gateway Protocol (IGP) Parameters" registry:</t>

      <t><list style="symbols">
          <t>Bit: 4</t>

          <t>Name: Any Application (A-bit)</t>

          <t>Reference: This document</t>
        </list></t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>TBD</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.8919'?>

      <?rfc include='reference.RFC.8920'?>
    </references>
  </back>
</rfc>
