<?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' ?>
<?rfc strict="no" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc rfcedstyle="yes" ?>
<?rfc subcompact="no" ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-lsr-isis-yang-augmentation-v1-04" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.13.1 -->
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

  <title abbrev="ISIS YANG Augments V1">IS-IS YANG Model Augmentations for Additional Features - Version 1 </title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-lsr-isis-yang-augmentation-v1-04"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Acee Lindem" initials="A." surname="Lindem">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>301 Midenhall Way</street>
          <city>Cary, NC 27513</city>
        </postal>
        <email>acee@cisco.com</email>
      </address>
    </author>
    <author fullname="Stephane Litkowski" initials="S." surname="Litkowski">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <city/>
        </postal>
        <email>slitkows.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Yingzhen Qu" initials="Y" surname="Qu">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <city>Santa Clara</city>
          <region>CA</region>
          <code>95050</code>
          <country>USA</country>
        </postal>
        <phone/>
        <email>yingzhen.qu@futurewei.com</email>
      </address>
    </author>
    <date/>
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
   in the current day and month for you. If the year is not the current one, it is 
   necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
   purpose of calculating the expiry date).  With drafts it is normally sufficient to 
   specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>
    <workgroup>Internet</workgroup>
    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
   If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This document defines YANG data modules augmenting the IETF IS-IS YANG
      model to provide support for IS-IS Minimum Remaining Lifetime
      as defined in RFC 7987, IS-IS Application-Specific Link Attributes as
      defined in RFC 8919, and IS-IS Flexible Algorithm. </t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Overview</name>
      <t>YANG <xref target="RFC7950" format="default"/> is a data definition language 
      used to define the contents of a conceptual data store 
      that allows networked devices to be managed using NETCONF 
      <xref target="RFC6241" format="default"/>.  YANG is proving relevant beyond its 
      initial confines, as bindings to other interfaces (e.g., ReST) and 
      encodings other than XML (e.g., JSON) are being defined.  Furthermore, 
      YANG data models can be used as the basis for implementation of other 
      interfaces, such as CLI and programmatic APIs.</t>
      <t>This document defines YANG data modules augmenting the IETF IS-IS 
      YANG model <xref target="I-D.ietf-isis-yang-isis-cfg" format="default"/>, which itself augments 
      <xref target="RFC8349" format="default"/>, to provide support for configuration and
      operational state for the following IS-IS features:
      </t>
      <dl newline="false" spacing="normal">
        <dt>RFC7987:</dt>
        <dd>IS-IS Minimum Remaining Lifetime<xref target="RFC7987" format="default"/>.</dd>
        <dt>RFC8919:</dt>
        <dd>IS-IS Application-Specific Link Attributes<xref target="RFC8919" format="default"/>.</dd>
        <dt>RFCxxxx:</dt>
        <dd>IGP Flexible Algorithm <xref target="I-D.ietf-lsr-flex-algo" format="default"/>.</dd>
      </dl>
      <t>The augmentations defined in this document requires support for the 
        IS-IS base model<xref target="I-D.ietf-isis-yang-isis-cfg" format="default"/> which defines 
        basic IS-IS configuration and state. The IS-IS YANG model augments the 
        ietf-routing YANG model defined in <xref target="RFC8349" format="default"/>.
      </t>
      <section numbered="true" toc="default">
        <name>Requirements Language</name>
        <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 BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/>
        when, and only when, they appear in all capitals, as shown here.</t>
      </section>
      <section anchor="tree-info" toc="default" numbered="true">
        <name>Tree diagram</name>
        <t>Tree diagrams used in this document follow the notation defined in
        <xref target="RFC8340" format="default"/>.</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>YANG Module for IS-IS Minimum Remaining Lifetime</name>
      <t>This document defines a YANG module for IS-IS Minimum Remaining Lifetime
      as defined in <xref target="RFC7987" format="default"/>. It is an augmentation of the IS-IS 
      base model. </t>
      <artwork align="left" name="" type="" alt=""><![CDATA[  
module: ietf-isis-remaining-lifetime

  notifications:
    +---n corrupt-remaining-lifetime
       +--ro routing-protocol-name?   -> /rt:routing
                                         /control-plane-protocols
                                         /control-plane-protocol/name
       +--ro isis-level?              level
       +--ro lsp-id?                  isis:lsp-id                                              

      ]]></artwork>
      <sourcecode name="ietf-isis-remaining-lifetime@2021-12-22.yang" type="" markers="true"><![CDATA[
module ietf-isis-remaining-lifetime {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-isis-remaining-lifetime";

  prefix isis-remaining-lifetime;

  import ietf-isis {
    prefix "isis";
  }

  organization
    "IETF LSR - Link State Routing Working Group";

  contact
     "WG Web:   <http://tools.ietf.org/wg/lsr>
      WG List:  <mailto:lsr@ietf.org>

      Author:   Yingzhen Qu
                <mailto:yqu@futurewei.com>
      Author:   Acee Lindem
                <mailto:acee@cisco.com>
      Author:   Stephane Litkowski
                <mailto:slitkows.ietf@gmail.com>";

  description
    "This YANG module defines the configuration and operational 
     state for IS-IS Minimum Remaining Lifetime feature as defined 
     in RFC 7987.

     Copyright (c) 2021 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX;
     see the RFC itself for full legal notices.";

  reference "RFC XXXX";

  revision 2021-12-22 {
    description
      "Initial version";
    reference
      "RFC XXXX: A YANG Data Model for IS-IS Minimum Remaining
                 Lifetime";
  }

  notification corrupt-remaining-lifetime {
    uses isis:notification-instance-hdr;
    leaf lsp-id {
      type isis:lsp-id;
      description "LSP ID";
    }
    description
      "This notification is sent when the system
       detects corrupted lifetime of an LSP.";
    reference "RFC 7987: IS-IS Minimum Remaining Lifetime";
  }
}
  ]]></sourcecode>
    </section>
    <section numbered="true" toc="default">
      <name>YANG Module for IS-IS Application-Specific Link Attributes</name>
      <t>This document defines a YANG module for IS-IS Application-Specific Link
    Attributes <xref target="RFC8919" format="default"/>. It is an augmentation of the IS-IS 
      base model. </t>
      <artwork align="left" name="" type="" alt=""><![CDATA[  
module: ietf-isis-link-attr
  augment /rt:routing/rt:control-plane-protocols
          /rt:control-plane-protocol/isis:isis/isis:interfaces
          /isis:interface:
    +--rw isis-link-attr
       +--rw (link-attr-op-mode)
          +--:(legacy)
          |  +--rw legacy?         empty
          +--:(transition)
          |  +--rw transition?     empty
          +--:(app-specific)
             +--rw app-specific?   empty
  augment /rt:routing/rt:control-plane-protocols
          /rt:control-plane-protocol/isis:isis/isis:database
          /isis:levels/isis:lsp/isis:extended-is-neighbor
          /isis:neighbor/isis:instances/isis:instance:
    +--ro application-specific-link-attributes-sub-tlvs
       +--ro asla-sub-tlvs* []
          +--ro l-flag?         boolean
          +--ro sabm-length?    uint8
          +--ro r-flag?         boolean
          +--ro udabm-length?   uint8
          +--ro sabm
          |  +--ro sabm-bits*   identityref
          +--ro udabm
          +--ro unknown-tlvs
             +--ro unknown-tlv* []
                +--ro type?     uint16
                +--ro length?   uint16
                +--ro value?    yang:hex-string
  augment /rt:routing/rt:control-plane-protocols
          /rt:control-plane-protocol/isis:isis/isis:database
          /isis:levels/isis:lsp/isis:mt-is-neighbor/isis:neighbor
          /isis:instances/isis:instance:
    +--ro application-specific-link-attributes-sub-tlvs
       +--ro asla-sub-tlvs* []
          +--ro l-flag?         boolean
          +--ro sabm-length?    uint8
          +--ro r-flag?         boolean
          +--ro udabm-length?   uint8
          +--ro sabm
          |  +--ro sabm-bits*   identityref
          +--ro udabm
          +--ro unknown-tlvs
             +--ro unknown-tlv* []
                +--ro type?     uint16
                +--ro length?   uint16
                +--ro value?    yang:hex-string
  augment /rt:routing/rt:control-plane-protocols
          /rt:control-plane-protocol/isis:isis/isis:database
          /isis:levels/isis:lsp:
    +--ro application-specific-srlg-tlv
       +--ro as-srlg-tlvs* []
          +--ro neighbor-system-id?   isis:system-id
          +--ro pseudo-node-id?       uint8
          +--ro l-flag?               boolean
          +--ro sabm-length?          uint8
          +--ro r-flag?               boolean
          +--ro udabm-length?         uint8
          +--ro sabm
          |  +--ro sabm-bits*   identityref
          +--ro udabm
          +--ro length-of-sub-tlvs?   uint8
          +--ro link-id-sub-tlvs
          |  +--ro link-local-remote-ids
          |  |  +--ro link-local-id?    union
          |  |  +--ro link-remote-id?   union
          |  +--ro ipv4-interface-addr
          |  |  +--ro ipv4-int-addr?   inet:ipv4-address
          |  +--ro ipv4-neighbor-addr
          |  |  +--ro ipv4-neighbor-addr?   inet:ipv4-address
          |  +--ro ipv6-interface-addr
          |  |  +--ro ipv6-int-addr?   inet:ipv6-address
          |  +--ro ipv6-neighbor-addr
          |     +--ro ipv6-neighbor-addr?   inet:ipv6-address
          +--ro srlgs
             +--ro srlg*   uint32                                          
      ]]></artwork>
      <sourcecode name="ietf-isis-link-attr@2022-03-06.yang" type="" markers="true"><![CDATA[
module ietf-isis-link-attr {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-isis-link-attr";

  prefix isis-link-attr;

  import ietf-inet-types {
    prefix inet;
    reference "RFC 6991 - Common YANG Data Types";
  }

  import ietf-routing {
    prefix "rt";
  }

  import ietf-isis {
    prefix "isis";
  }

  organization
    "IETF LSR - Link State Routing Working Group";

  contact
     "WG Web:   <http://tools.ietf.org/wg/lsr>
      WG List:  <mailto:lsr@ietf.org>

      Author:   Yingzhen Qu
                <mailto:yqu@futurewei.com>
      Author:   Acee Lindem
                <mailto:acee@cisco.com>
      Author:   Stephane Litkowski
                <mailto:slitkows.ietf@gmail.com>";

  description
    "This YANG module defines the configuration and operational 
     state for IS-IS application specific link attributes feature as 
     defined in RFC 8919.

     This YANG model conforms to the Network Management
     Datastore Architecture (NMDA) as described in RFC 8342.

     Copyright (c) 2022 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX;
     see the RFC itself for full legal notices.

     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 BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.";

  reference "RFC XXXX";

  revision 2022-03-06 {
    description
      "Initial version";
    reference
      "RFC XXXX: A YANG Data Model for IS-IS Application-Specific Link
       Attributes.";
  }

  identity sabm-bit {
    description
      "Base identity for sabm bits.";
    reference "RFC 8919: IS-IS Application-Specific Link Attributes";
  }

  identity rsvp-te-bit {
    base sabm-bit;
    description
      "R bit, RSVP-TE.";
  }

  identity sr-policy-bit {
    base sabm-bit;
    description
      "S bit, Segment Routing Policy.";
  }

  identity lfa-bit {
    base sabm-bit;
    description
      "F bit, Loop Free Alternate (LFA). Includes all LFA types.";
  }

  grouping application-identifier-bit-mask {
    description
      "Identification of the set of applications associated with link
       attribute advertisements";

    leaf l-flag {
      type boolean;
      description
        "Legacy Flag. When set, all of the applications 
         specified in the bit mask MUST use the legacy 
         advertisements.";
    }    
    leaf sabm-length {
      type uint8;
      description 
        "Standard Application Identifier Bit Mask Length in
         octets.";
    }     
    leaf r-flag {
      type boolean;
      default false;
      description
        "Reserved.";
    }
    leaf udabm-length {
      type uint8;
      description
      "User Defined Application Identifier Bit Mask Length
      in octets.";
    }
    container sabm {
      leaf-list sabm-bits {
        type identityref {
          base sabm-bit;
        }
        description
          "SABM bits list. This list will contain
           identities for the bits which are set in the
           SABA bits.";
      }
      description 
        "Standard Application Identifier Bit Mask.";
    }
    container udabm {
      description
        "User Defined Application Identifier Bit Mask.
         This container is to be augmented by user defined
         applications.";
    }
  }

  grouping application-specific-link-attributes-sub-tlv {
    description
      "Grouping for specification of the applications and 
       application-specific attribute values.";

    container application-specific-link-attributes-sub-tlvs {
      list asla-sub-tlvs {
        uses application-identifier-bit-mask;
        uses isis:unknown-tlvs;
        description
          "List of application specific link attributes sub-tlvs.";
      }
      description
        "Application specific link attributes sub-tlv.";
    }
  }

  grouping application-specific-srlg-tlv {
    description
      "Grouping of a TLV to advertise application-specific 
       SRLGs for a given link.";
    container application-specific-srlg-tlv {
      list as-srlg-tlvs {
        leaf neighbor-system-id {
          type isis:system-id;
          description
            "Neighbor System-ID.";
        }
        leaf pseudo-node-id {
          type uint8;
          description
            "Pseudo-node ID.";
        }
        uses application-identifier-bit-mask;
        leaf length-of-sub-tlvs {
          type uint8;
          description 
            "Length of sub-tlvs.";
        }

        container link-id-sub-tlvs {
          description
            "Link Identifier sub-TLVs.";
          container link-local-remote-ids {
            description
              "Link local/remote identifier sub-tlv.";
            leaf link-local-id {
              type union {
                type inet:ipv4-address;
                type uint32;
              }
              description
                "Local identifier of the link.
                 It could be an IPv4 address or a local identifier.";
            }
            leaf link-remote-id {
              type union {
                type inet:ipv4-address;
                type uint32;
              }
              description
                "Remote identifier of the link.
                It could be an IPv4 address or a remotely learned
                identifier.";
            }
          }
          container ipv4-interface-addr {
            leaf ipv4-int-addr {
              type inet:ipv4-address;
              description
                "IPv4 address for the interface.";
            }
            description
              "IPv4 interface address sub-tlv.";
          }
          container ipv4-neighbor-addr {
            leaf ipv4-neighbor-addr {
              type inet:ipv4-address;
              description
                "IPv4 address for a neighboring router
                on this link.";
            }
            description
              "IPv4 neighbor address sub-tlv.";
          }
          container ipv6-interface-addr {
            leaf ipv6-int-addr {
              type inet:ipv6-address;
              description
                "IPv6 address for the interface.";
            }
            description
              "IPv6 interface address sub-tlv.";
          }
          container ipv6-neighbor-addr {
            leaf ipv6-neighbor-addr {
              type inet:ipv6-address;
              description
                "IPv6 address for a neighboring router
                on this link.";
            }
            description
              "IPv6 neighbor address sub-tlv.";
          }
        }

        container srlgs {
          description "List of SRLGs.";
          leaf-list srlg {
            type uint32;
            description
              "SRLG value of the link.";
          }
        }

        description
          "List of application specific SRLG tlvs.";
      }
      description
        "Application specific SRLG tlv.";
    }
  }

  augment "/rt:routing/" +
          "rt:control-plane-protocols/rt:control-plane-protocol"+
          "/isis:isis/isis:interfaces/isis:interface" {
    when "/rt:routing/rt:control-plane-protocols/"+
                     "rt:control-plane-protocol/rt:type = 'isis:isis'" {
      description
        "This augment ISIS routing protocol when used.";
    }
    description
      "This augments ISIS protocol configuration
       with TE attributes per application.";

    container isis-link-attr {
      choice link-attr-op-mode {
        mandatory "true";
        leaf legacy {
          type empty;
          description
            "Only send legacy advertisements.";
        }
        leaf transition {
          type empty;
          description
            "Send both application-specific and legacy advertisements.";
        }
        leaf app-specific{
          type empty;
          description
            "Only send application-specific advertisements.";
        }
        description
          "Link attributes mode";
      }
      description
        "Link attributes operation mode.";
    }
  }

  /* TLV 22 */
  augment "/rt:routing/" +
          "rt:control-plane-protocols/rt:control-plane-protocol"+
          "/isis:isis/isis:database/isis:levels/isis:lsp"+
          "/isis:extended-is-neighbor/isis:neighbor"+
          "/isis:instances/isis:instance" {
    when "/rt:routing/rt:control-plane-protocols/"+
         "rt:control-plane-protocol/rt:type = 'isis:isis'" { 
      description
        "This augment ISIS routing protocol when used";
    }
    description
      "This augments ISIS protocol LSDB TLV22.";

       uses application-specific-link-attributes-sub-tlv;
  }

  /* TLV 223 */
  augment "/rt:routing/" +
          "rt:control-plane-protocols/rt:control-plane-protocol"+
          "/isis:isis/isis:database/isis:levels/isis:lsp"+
          "/isis:mt-is-neighbor/isis:neighbor"+
          "/isis:instances/isis:instance" {
    when "/rt:routing/rt:control-plane-protocols/"+
         "rt:control-plane-protocol/rt:type = 'isis:isis'" { 
      description
        "This augment ISIS routing protocol when used";
    }
    description
      "This augments ISIS protocol LSDB TLV223.";

       uses application-specific-link-attributes-sub-tlv;
  }
  
  /* application-specific SRLG TLV 238 */
  augment "/rt:routing/" +
          "rt:control-plane-protocols/rt:control-plane-protocol"+
          "/isis:isis/isis:database/isis:levels/isis:lsp" {
    when "/rt:routing/rt:control-plane-protocols/"+
         "rt:control-plane-protocol/rt:type = 'isis:isis'" { 
      description
        "This augment ISIS routing protocol when used";
    }
    description
      "This augments ISIS protocol LSDB.";
   
    uses application-specific-srlg-tlv;
  }

}
  ]]></sourcecode>
    </section>
    <section numbered="true" toc="default">
      <name>YANG Module for IS-IS Flexible Algorithm</name>
      <t>This document defines a YANG module for IS-IS Flexible
      Algorithm <xref target="I-D.ietf-lsr-flex-algo" format="default"/>. It is an augmentation of the IS-IS 
      base model. </t>
      <artwork align="left" name="" type="" alt=""><![CDATA[  
module: ietf-isis-flex-algo
  augment /rt:routing/rt:control-plane-protocols
          /rt:control-plane-protocol/isis:isis:
    +--rw isis-flex-algo
       +--rw flex-algo* [algo-number]
          +--rw algo-number             uint8
          +--rw advertise-definition?   boolean
          +--rw admin-groups {te-types:extended-admin-groups,
                              te-types:named-extended-admin-groups}?
          |  +--rw exclude-admin-groups*   -> /te:te/globals
                                              /named-admin-groups
                                              /named-admin-group/name
          |  +--rw include-any-admin-groups*   -> /te:te/globals
                                              /named-admin-groups
                                              /named-admin-group/name
          |  +--rw include-all-admin-groups*   -> /te:te/globals
                                              /named-admin-groups
                                              /named-admin-group/name
          +--rw exclude-srlgs*   -> /te:te/globals
                                    /named-srlgs/named-srlg/name 
                                    {te-types:named-srlg-groups}?
          +--rw fast-reroute?           boolean
          +--rw metric-type?            identityref
          +--rw microloop-avoidance?    boolean
          +--rw prefix-metric!
          +--rw priority?               uint8
  augment /rt:routing/rt:control-plane-protocols
          /rt:control-plane-protocol/isis:isis/isis:database
          /isis:levels/isis:lsp/isis:router-capabilities:
    +--ro fad-tlvs
       +--ro fad-tlv* []
          +--ro flex-algo?              uint8
          +--ro metric-type?            identityref
          +--ro calc-type?              uint8
          +--ro priority?               uint8
          +--ro fa-ex-ag-sub-tlv
          |  +--ro extended-admin-groups*   uint64
          +--ro fa-in-any-ag-sub-tlv
          |  +--ro extended-admin-groups*   uint64
          +--ro fa-in-all-ag-sub-tlv
          |  +--ro extended-admin-groups*   uint64
          +--ro fad-flags-sub-tlv
          |  +--ro fad-flags*   identityref
          +--ro fa-ex-srlg-sub-tlv
          |  +--ro srlgs*   uint32
          +--ro unknown-tlvs
             +--ro unknown-tlv* []
                +--ro type?     uint16
                +--ro length?   uint16
                +--ro value?    yang:hex-string
  augment /rt:routing/rt:control-plane-protocols
          /rt:control-plane-protocol/isis:isis/isis:database
          /isis:levels/isis:lsp/isis:extended-ipv4-reachability
          /isis:prefixes:
    +--ro fapm-sub-tlvs
       +--ro fapm-sub-tlv* []
          +--ro flex-algo?   uint8
          +--ro metric?      uint32
  augment /rt:routing/rt:control-plane-protocols
          /rt:control-plane-protocol/isis:isis/isis:database
          /isis:levels/isis:lsp/isis:mt-extended-ipv4-reachability
          /isis:prefixes:
    +--ro fapm-sub-tlvs
       +--ro fapm-sub-tlv* []
          +--ro flex-algo?   uint8
          +--ro metric?      uint32
  augment /rt:routing/rt:control-plane-protocols
          /rt:control-plane-protocol/isis:isis/isis:database
          /isis:levels/isis:lsp/isis:ipv6-reachability/isis:prefixes:
    +--ro fapm-sub-tlvs
       +--ro fapm-sub-tlv* []
          +--ro flex-algo?   uint8
          +--ro metric?      uint32
  augment /rt:routing/rt:control-plane-protocols
          /rt:control-plane-protocol/isis:isis/isis:database
          /isis:levels/isis:lsp/isis:mt-ipv6-reachability
          /isis:prefixes:
    +--ro fapm-sub-tlvs
       +--ro fapm-sub-tlv* []
          +--ro flex-algo?   uint8
          +--ro metric?      uint32

  notifications:
    +---n flex-algo-not-supported
       +--ro routing-protocol-name?   -> /rt:routing
                                         /control-plane-protocols
                                         /control-plane-protocol/name
       +--ro isis-level?              level
       +--ro flex-algo-number?        uint8

      ]]></artwork>
      <sourcecode name="ietf-isis-flex-algo@2022-03-06.yang" type="" markers="true"><![CDATA[
module ietf-isis-flex-algo {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-isis-flex-algo";
  prefix isis-flex-algo;

  import ietf-routing {
    prefix rt;
    reference "RFC 8349: A YANG Data Model for Routing
               Management (NMDA Version)";
  }

  import ietf-te-types {
    prefix te-types;
    reference
      "RFC8776: Common YANG Data Types for Traffic Engineering.";
  }

  import ietf-isis {
    prefix "isis";
  }

  import ietf-te {
    prefix "te";
  }

  import ietf-isis-link-attr {
    prefix "isis-link-attr";
  }

  organization
    "IETF LSR - Link State Routing Working Group";
  contact
    "WG Web:   <https://tools.ietf.org/wg/spring/>
     WG List:  <mailto:spring@ietf.org>


     Author:    Yingzhen Qu
               <mailto:yingzhen.qu@futurewei.com>
     Author:    Acee Lindem
               <mailto:acee@cisco.com>
     Author:    Stephane Litkowski
               <mailto:slitkows.ietf@gmail.com>
    ";

  description
    "The YANG module defines the configuration and operational
     state for ISIS Flexible Algorithm as defined in RFC xxxx.

     This YANG model conforms to the Network Management
     Datastore Architecture (NMDA) as described in RFC 8342.

     Copyright (c) 2022 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX;
     see the RFC itself for full legal notices.

     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 BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.";


  reference "RFC XXXX: YANG Data Model for ISIS Flexible Algorithm.";

  revision 2022-03-06 {
    description
      "Initial Version";
    reference "RFC XXXX: YANG Data Model for ISIS Flexible Algorithm.";
  }

  /* Identities */

  identity metric-type {
    description
      "Base identity for route metric types.";
  }

  identity igp-metric {
    base metric-type;
    description
      "Identity for the IGP metric type.";
  }

  identity min-uni-delay {
    base metric-type;
    description
      "Min unidirectional link delay metric type.";
    reference
      "RFC 8570 - IS-IS Traffic Engineering (TE) Metric Extensions";
  }

  identity te-metric {
    base metric-type;
    description
      "Traffic engineering metric type.";
    reference
      "RFC 5305 - IS-IS Extensions for Traffic Engineering (TE)";
  }

  identity fad-flags {
    description
      "Base identity for ISIS FAD flags.";
  }

  identity m-bit {
    base fad-flags;
    description
      "M bit, when set, the flex-algo specific prefix and ASBR
       metric MUST be used for inter-area and external prefix
       calculation.";
  }

  /* Identity augmentation */
  identity flex-algo-bit {
    base isis-link-attr:sabm-bit;
    description
      "X bit, flexible algorithm.";
  }

  /* Groupings */
  grouping fa-ex-ag-sub-tlv {
    container fa-ex-ag-sub-tlv {
      leaf-list extended-admin-groups {
        type uint64;
        description
          "Extended administrative group as defined in RFC 7308.";
      }
      description
        "The flex-algo exclude admin group sub-tlv.";
    }
    description
      "The flex-algo exclude admin group sub-tlv.";
  }

  grouping fa-in-any-ag-sub-tlv {
    container fa-in-any-ag-sub-tlv {
      leaf-list extended-admin-groups {
        type uint64;
        description
          "Extended administrative group as defined in RFC 7308.";
      }
      description
        "The flex-algo include-any admin group sub-tlv."; 
    }
    description
      "The flex-algo include-any admin group sub-tlv.";
  }

  grouping fa-in-all-ag-sub-tlv {
    container fa-in-all-ag-sub-tlv {
      leaf-list extended-admin-groups {
        type uint64;
        description
          "Extended administrative group as defined in RFC 7308.";
      }
      description
        "The flex-algo include-all admin group sub-tlv.";
    }
    description
      "The flex-algo include-all admin group sub-tlv.";
  }

  grouping fad-flags-sub-tlv {
    container fad-flags-sub-tlv {
      leaf-list fad-flags {
        type identityref {
          base fad-flags;
        }
        description
          "Flex-algo definition flags list.";
      }
      description
        "ISIS flex-algo definition flags.";
    }
    description
      "The flex-algo definition flags sub-tlv.";
  }

  grouping fa-ex-srlg-sub-tlv {
    container fa-ex-srlg-sub-tlv {
      leaf-list srlgs {
        type uint32;
        description
          "SRLG value as defined in RFC 4203.";
      }
      description
        "The flex-algo exclude SRLG sub-tlv.";
    }
    description
      "The flex-algo exclude SRLG sub-tlv.";
  }

  grouping fad-tlvs {
    container fad-tlvs {
      list fad-tlv {
        leaf flex-algo {
          type uint8;
          description
            "Flex-algo number, value between 128 and 255 inclusive.";
        }
        leaf metric-type {
          type identityref {
            base metric-type;
          }
            description
              "Type of metric to be used during the calculation.";
        }
        leaf calc-type {
          type uint8 {
            range "0..127";
          }
          description
            "IGP algorithm types, value from 0 to 127 as
            defined under 'Interior Gateway Protocol (IGP)
            Parameter' by IANA.";
        }
        leaf priority {
          type uint8;
            description
              "Priority of the advertisement.";
        }

        uses fa-ex-ag-sub-tlv;
        uses fa-in-any-ag-sub-tlv;
        uses fa-in-all-ag-sub-tlv;
        uses fad-flags-sub-tlv;
        uses fa-ex-srlg-sub-tlv;
        uses isis:unknown-tlvs;

        description
          "List of flex-algo definition TLVs.";
      }
      description
        "ISIS Flexible Algorithm Definition TLV.";
    }
    description
      "ISIS Flexible Algorithm Definition (FAD) TLV.";
  }

  grouping fapm-sub-tlvs {
    container fapm-sub-tlvs {
      list fapm-sub-tlv {
        leaf flex-algo {
          type uint8;
          description
            "Flex-algo number, value between 128 and 255
             inclusive.";
        }
        leaf metric {
          type uint32;
          description
            "Prefix metric.";
        }
        description
          "List of flex-algo prefix sub-tlvs.";
      }
      description
        "Flex-algo prefix metric sub-tlvs.";
    }
    description
      "Flexible Algorithm Prefix Metric (FAPM) sub TLVs.";
  }


  /* Configurations */

  augment "/rt:routing/" +
          "rt:control-plane-protocols/rt:control-plane-protocol"+
          "/isis:isis" {
    when "/rt:routing/rt:control-plane-protocols/"+
                 "rt:control-plane-protocol/rt:type = 'isis:isis'" {
      description
        "This augment ISIS routing protocol when used";
    }
    description
      "This augments ISIS protocol configuration
       with flexible algorithm.";

    container isis-flex-algo {
      list flex-algo {
        key "algo-number";

        leaf algo-number {
          type uint8 {
            range "128..255";
          }
          description
            "An identifier in the range 128-255 that's associated 
            with the Flexible Algorithm Definition.";
        }

        leaf advertise-definition {
          type boolean;
          default true;
          description
            "Enable to advertise the flex-algo definition.";
        }

        container admin-groups {
          if-feature "te-types:extended-admin-groups";
          if-feature "te-types:named-extended-admin-groups";
          leaf-list exclude-admin-groups {
            type leafref {
              path "/te:te/te:globals/te:named-admin-groups/"
                 + "te:named-admin-group/te:name";
            }
            description
              "Exclude rule used during the flex-algo 
              path computation.";
          }
          leaf-list include-any-admin-groups {
            type leafref {
              path "/te:te/te:globals/te:named-admin-groups/"
                 + "te:named-admin-group/te:name";
            }
            description
              "Include-any rule used during the flex-algo 
              path computation.";
          }          
          leaf-list include-all-admin-groups {
            type leafref {
              path "/te:te/te:globals/te:named-admin-groups/"
                 + "te:named-admin-group/te:name";
            }
            description
              "Include-all rule used during the flex-algo 
              path computation.";
          }
          description
            "Specify links for the flex-algo path computation.";
        }

        leaf-list exclude-srlgs {
          if-feature "te-types:named-srlg-groups";
          type leafref {
            path "/te:te/te:globals/te:named-srlgs/te:named-srlg/"
               + "te:name";
          }
          description
            "Shared Risk Link Groups (SRLGs) to be excluded during
            the flex-algo path computation.";
        }

        leaf fast-reroute {
          type boolean;
          default true;
          description
            "Enable fast reroute.";
        }

        leaf metric-type {
          type identityref {
            base metric-type;
          }
          description
            "Type of metric to be used during the calculation.";
        }

        leaf microloop-avoidance {
          type boolean;
          default true;
          description
            "Enable microloop avoidance.";
        }

        container prefix-metric {
          presence
            "Use flex-algo specific prefix metric.";
          description
            "Use flex-algo prefix metric.";
        }

        leaf priority {
          type uint8;
          description
            "Priority of the advertisement.";
        }

        description
          "List of flex-algo configurations.";
      }
      description 
        "Flexible Algorithm configuration.";
    }
  }

  /* Database */

  augment "/rt:routing/" +
          "rt:control-plane-protocols/rt:control-plane-protocol"+
          "/isis:isis/isis:database/isis:levels/isis:lsp"+
                      "/isis:router-capabilities" {
          when "/rt:routing/rt:control-plane-protocols/"+
                     "rt:control-plane-protocol/rt:type = 'isis:isis'" {
      description
        "This augment ISIS routing protocol when used";
    }
          description
            "This augments ISIS protocol LSDB router capability.";

          uses fad-tlvs;
  }

  augment "/rt:routing/" +
          "rt:control-plane-protocols/rt:control-plane-protocol"+
          "/isis:isis/isis:database/isis:levels/isis:lsp"+
                      "/isis:extended-ipv4-reachability/isis:prefixes" {
                when "/rt:routing/rt:control-plane-protocols/"+
                     "rt:control-plane-protocol/rt:type = 'isis:isis'" {
      description
        "This augment ISIS routing protocol when used";
    }
                description
            "This augments ISIS protocol LSDB prefix.";
             uses fapm-sub-tlvs;
  }
 
  augment "/rt:routing/" +
          "rt:control-plane-protocols/rt:control-plane-protocol"+
          "/isis:isis/isis:database/isis:levels/isis:lsp"+
                "/isis:mt-extended-ipv4-reachability/isis:prefixes" {
                when "/rt:routing/rt:control-plane-protocols/"+
                     "rt:control-plane-protocol/rt:type = 'isis:isis'" {
      description
        "This augment ISIS routing protocol when used";
    }
                description
            "This augments ISIS protocol LSDB prefix.";
          uses fapm-sub-tlvs;
  }

  augment "/rt:routing/" +
          "rt:control-plane-protocols/rt:control-plane-protocol"+
          "/isis:isis/isis:database/isis:levels/isis:lsp"+
                      "/isis:ipv6-reachability/isis:prefixes" {
                when "/rt:routing/rt:control-plane-protocols/"+
                     "rt:control-plane-protocol/rt:type = 'isis:isis'" {
      description
        "This augment ISIS routing protocol when used";
    }
                description
            "This augments ISIS protocol LSDB prefix.";
          uses fapm-sub-tlvs;
  }

  augment "/rt:routing/" +
          "rt:control-plane-protocols/rt:control-plane-protocol"+
          "/isis:isis/isis:database/isis:levels/isis:lsp"+
                      "/isis:mt-ipv6-reachability/isis:prefixes" {
                when "/rt:routing/rt:control-plane-protocols/"+
                     "rt:control-plane-protocol/rt:type = 'isis:isis'" {
      description
        "This augment ISIS routing protocol when used";
    }
                description
            "This augments ISIS protocol LSDB prefix.";
        uses fapm-sub-tlvs;
  }

  /* notification */

  notification flex-algo-not-supported {
    uses isis:notification-instance-hdr;
    leaf flex-algo-number {
      type uint8 {
        range "128..255";
      }
      description
        "Flex-algo identifier which is not supported by the IS-IS
         instance.";
    }
    description
      "This notification is sent when an IS-IS instance does not
       support this flex-algo.";
  }
}
    ]]></sourcecode>
    </section>
    <section numbered="true" toc="default">
      <name>IS-IS MSD</name>
      <t>This document defines a module for Signaling Maximum SID Depth (MSD)
        using IS-IS <xref target="RFC8491" format="default"/>.  It is an
        augmentation of the IS-IS base model.</t>
      <t>The figure below describes the overall structure of the isis-msd
      YANG module:</t>
      <figure align="left">
      <artwork align="left">
module: ietf-isis-msd
  augment /rt:routing/rt:control-plane-protocols
          /rt:control-plane-protocol/isis:isis/isis:database
          /isis:levels/isis:lsp/isis:router-capabilities:
    +--ro node-msd-tlv
       +--ro node-msds* [msd-type]
          +--ro msd-type     identityref
          +--ro msd-value?   uint8
  augment /rt:routing/rt:control-plane-protocols
          /rt:control-plane-protocol/isis:isis/isis:database
          /isis:levels/isis:lsp/isis:extended-is-neighbor
          /isis:neighbor:
    +--ro link-msd-sub-tlv
       +--ro link-msds* [msd-type]
          +--ro msd-type     identityref
          +--ro msd-value?   uint8
  augment /rt:routing/rt:control-plane-protocols
          /rt:control-plane-protocol/isis:isis/isis:database
          /isis:levels/isis:lsp/isis:mt-is-neighbor/isis:neighbor:
    +--ro link-msd-sub-tlv
       +--ro link-msds* [msd-type]
          +--ro msd-type     identityref
          +--ro msd-value?   uint8
                                   
      </artwork>
      </figure> 
      <section title="IS-IS MSD YANG Module">
      <figure>
      <artwork><![CDATA[
<CODE BEGINS> file "ietf-isis-msd@2022-09-05.yang"
module ietf-isis-msd {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-isis-msd";
  prefix isis-msd;

  import ietf-routing {
    prefix rt;
    reference
      "RFC 8349: A YANG Data Model for Routing
       Management (NMDA Version)";
  }
  import ietf-isis {
    prefix isis;
  }
  import ietf-mpls-msd {
    prefix mpls-msd;
  }

  organization
    "IETF LSR - LSR Working Group";
  contact
    "WG Web:   <https://tools.ietf.org/wg/mpls/>
     WG List:  <mailto:mpls@ietf.org>

     Author:    Yingzhen Qu
               <mailto:yingzhen.qu@futurewei.com>
     Author:    Acee Lindem
               <mailto:acee@cisco.com>
     Author:    Stephane Litkowski
               <mailto:slitkows.ietf@gmail.com>
     Author:    Jeff Tantsura
               <mailto:jefftant.ietf@gmail.com>
     
    ";
  description
    "The YANG module augments the base ISIS model to
     manage different types of MSDs.

     This YANG model conforms to the Network Management
     Datastore Architecture (NMDA) as described in RFC 8342.

     Copyright (c) 2022 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
     for full legal notices.

     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 BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.";
  reference
    "RFC XXXX: YANG Data Model for ISIS MSD";

  revision 2022-09-05 {
    description
      "Initial Version";
    reference
      "RFC XXXX: YANG Data Model for ISIS MSD.";
  }

  grouping link-msd-sub-tlv {
    description
      "Link Maximum SID Depth (MSD) grouping for an interface.";
    container link-msd-sub-tlv {
      list link-msds {
        key "msd-type";
        leaf msd-type {
          type identityref {
            base mpls-msd:msd-base-type;
          }
          description
            "MSD-Types";
        }
        leaf msd-value {
          type uint8;
          description
            "MSD value, in the range of 0-255.";
        }
        description
          "List of link MSDs";
      }
      description
        "Link MSD sub-tlvs.";
    }
  }

  /* Node MSD TLV */

  augment "/rt:routing/"
        + "rt:control-plane-protocols/rt:control-plane-protocol"
        + "/isis:isis/isis:database/isis:levels/isis:lsp"
        + "/isis:router-capabilities" {
    when "derived-from-or-self(../../../../../rt:type, 'isis:isis')" {
      description
        "This augment ISIS routing protocol when used";
    }
    description
      "This augments ISIS protocol LSDB router capability.";
    container node-msd-tlv {
      list node-msds {
        key "msd-type";
        leaf msd-type {
          type identityref {
            base mpls-msd:msd-base-type;
          }
          description
            "MSD-Types";
        }
        leaf msd-value {
          type uint8;
          description
            "MSD value, in the range of 0-255.";
        }
        description
          "Node MSD is the smallest link MSD supported by
           the node.";
      }
      description
        "Node MSD is the number of SIDs supported by a node.";
      reference
        "RFC 8491: Signaling Maximum SID Depth (MSD) Using IS-IS";
    }
  }

  /* link MSD sub-tlv */

  augment "/rt:routing/"
        + "rt:control-plane-protocols/rt:control-plane-protocol"
        + "/isis:isis/isis:database/isis:levels/isis:lsp"
        + "/isis:extended-is-neighbor/isis:neighbor" {
    when "derived-from-or-self(../../../../../../rt:type,"
          + "'isis:isis')" {
      description
        "This augment ISIS routing protocol when used";
    }
    description
      "This augments ISIS protocol LSDB neighbor with
       Link MSD sub-TLV.";
    uses link-msd-sub-tlv;
  }

  augment "/rt:routing/"
        + "rt:control-plane-protocols/rt:control-plane-protocol"
        + "/isis:isis/isis:database/isis:levels/isis:lsp"
        + "/isis:mt-is-neighbor/isis:neighbor" {
    when "derived-from-or-self(../../../../../../rt:type,"
          + "'isis:isis')" {
      description
        "This augment ISIS routing protocol when used";
    }
    description
      "This augments ISIS protocol LSDB neighbor.";
    uses link-msd-sub-tlv;
  }
}
<CODE ENDS>
      ]]></artwork>
      </figure>      
      </section>        
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The YANG modules specified in this document define a schema for 
       data that is designed to be accessed via network
       management protocols such as NETCONF <xref target="RFC6241" format="default"/> or
       RESTCONF <xref target="RFC8040" format="default"/>. The lowest NETCONF layer is the secure transport
       layer, and the mandatory-to-implement secure transport is Secure Shell (SSH)
       <xref target="RFC6242" format="default"/>. The lowest RESTCONF layer is HTTPS, and the
       mandatory-to-implement secure transport is TLS <xref target="RFC8446" format="default"/>.</t>
      <t>The NETCONF access control model <xref target="RFC8341" format="default"/> provides the 
      means to restrict access for particular NETCONF or RESTCONF users to a
      pre-configured subset of all available NETCONF or RESTCONF protocol 
      operations and content.</t>
      <t>There are a number of data nodes defined in the modules
      that are writable/creatable/deletable (i.e., config true, which is the default). 
      These data nodes may be considered sensitive or vulnerable in some network 
      environments. Write operations (e.g., edit-config) to these data nodes without 
      proper protection can have a negative effect on network operations. These correspond
      to the following schema nodes:
      </t>
      <ul empty="true" spacing="normal">
        <li>/isis:isis/isis:interfaces/isis:interface/isis-link-attr - Modification 
          of link attributes operation mode could result in traffic being 
          redirected or DoS attack.</li>
      </ul>
      <t>Some of the readable data nodes in the modules
      may be considered sensitive or vulnerable in some network environments. It is thus 
      important to control read access (e.g., via get, get-config, or notification)
      to these data nodes. The exposure of the Link State Database (LSDB) will
      expose the detailed topology of the network. This may be undesirable since
      both due to the fact that exposure may facilitate other attacks. Additionally, 
      network operators may consider their topologies to be sensitive confidential
      data.These correspond to the following schema nodes:
      </t>
      <ul empty="true" spacing="normal">
        <li>/isis:isis/isis:database/isis:levels/isis:lsp/isis:mt-is-neighbor/isis:neighbor/isis:instances/isis:instance/application-specific-link-attributes-sub-tlvs </li>
        <li>/isis:isis/isis:database/isis:levels/isis:lsp/application-specific-srlg-tlv </li>
        <li>/isis:router-capabilities/node-msd-tlv</li>
        <li>/isis:isis/isis:database/isis:levels/isis:lsp//isis:extended-is-neighbor/isis:neighbor/link-msd-sub-tlv</li>
        <li>/isis:isis/isis:database/isis:levels/isis:lsp//isis:mt-is-neighbor/isis:neighbor/link-msd-sub-tlv</li>
      </ul>
    </section>
    <section numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document registers URIs in the IETF XML registry 
   <xref target="RFC3688" format="default"/>.  Following the format in <xref target="RFC3688" format="default"/>, 
   the following registrations is requested to be made:
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[  
   URI: urn:ietf:params:xml:ns:yang:ietf-isis-remaining-lifetime
   Registrant Contact: The IESG.
   XML: N/A, the requested URI is an XML namespace.
   ]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[  
   URI: urn:ietf:params:xml:ns:yang:ietf-isis-link-attr
   Registrant Contact: The IESG.
   XML: N/A, the requested URI is an XML namespace.
   ]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[  
   URI: urn:ietf:params:xml:ns:yang:ietf-isis-flex-algo
   Registrant Contact: The IESG.
   XML: N/A, the requested URI is an XML namespace.
   ]]></artwork>
     <artwork name="" type="" align="left" alt=""><![CDATA[  
   URI: urn:ietf:params:xml:ns:yang:ietf-isis-msd
   Registrant Contact: The IESG.
   XML: N/A, the requested URI is an XML namespace
   ]]></artwork>
      <t>This document registers the YANG modules in the YANG Module Names
   registry <xref target="RFC6020" format="default"/>.
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[  
   name: ietf-isis-remaining-lifetime
   namespace: urn:ietf:params:xml:ns:yang:ietf-isis-remaining-lifetime
   prefix: isis-remaining-lifetime
   reference: RFC XXXX
   ]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[  
   name: ietf-isis-link-attr
   namespace: urn:ietf:params:xml:ns:yang:ietf-isis-link-attr
   prefix: isis-link-attr
   reference: RFC XXXX
   ]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[  
   name: ietf-isis-flex-algo
   namespace: urn:ietf:params:xml:ns:yang:ietf-isis-flex-algo
   prefix: isis-flex-algo
   reference: RFC XXXX
   ]]></artwork>
     <artwork name="" type="" align="left" alt=""><![CDATA[  
   name: ietf-isis-msd
   namespace: urn:ietf:params:xml:ns:yang:ietf-isis-msd
   prefix: isis-msd
   reference: RFC XXXX
   ]]></artwork>
    </section>
    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>This document was produced using Marshall Rose's xml2rfc tool.</t>
      <t>The YANG model was developed using the suite of YANG tools written 
         and maintained by numerous authors.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <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="RFC3688" target="https://www.rfc-editor.org/info/rfc3688" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml">
          <front>
            <title>The IETF XML Registry</title>
            <author fullname="M. Mealling" initials="M." surname="Mealling"/>
            <date month="January" year="2004"/>
            <abstract>
              <t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="81"/>
          <seriesInfo name="RFC" value="3688"/>
          <seriesInfo name="DOI" value="10.17487/RFC3688"/>
        </reference>
        <reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6020" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml">
          <front>
            <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="October" year="2010"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6020"/>
          <seriesInfo name="DOI" value="10.17487/RFC6020"/>
        </reference>
        <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices.  It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages.  The NETCONF protocol operations are realized as remote procedure calls (RPCs).  This document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6241"/>
          <seriesInfo name="DOI" value="10.17487/RFC6241"/>
        </reference>
        <reference anchor="RFC6242" target="https://www.rfc-editor.org/info/rfc6242" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml">
          <front>
            <title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
            <author fullname="M. Wasserman" initials="M." surname="Wasserman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t>This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem.  This document obsoletes RFC 4742. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6242"/>
          <seriesInfo name="DOI" value="10.17487/RFC6242"/>
        </reference>
        <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="August" year="2016"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols.  This document describes the syntax and semantics of version 1.1 of the YANG language.  YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification.  There are a small number of backward incompatibilities from YANG version 1.  This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
        </reference>
        <reference anchor="RFC7987" target="https://www.rfc-editor.org/info/rfc7987" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7987.xml">
          <front>
            <title>IS-IS Minimum Remaining Lifetime</title>
            <author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
            <author fullname="P. Wells" initials="P." surname="Wells"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="T. Przygienda" initials="T." surname="Przygienda"/>
            <author fullname="H. Gredler" initials="H." surname="Gredler"/>
            <date month="October" year="2016"/>
            <abstract>
              <t>Corruption of the Remaining Lifetime field in a Link State Protocol Data Unit (LSP) can go undetected.  In certain scenarios, this may cause or exacerbate flooding storms.  It is also a possible denial-of-service attack vector.  This document defines a backwards-compatible solution to this problem.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7987"/>
          <seriesInfo name="DOI" value="10.17487/RFC7987"/>
        </reference>
        <reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8040" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml">
          <front>
            <title>RESTCONF Protocol</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <date month="January" year="2017"/>
            <abstract>
              <t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8040"/>
          <seriesInfo name="DOI" value="10.17487/RFC8040"/>
        </reference>
        <reference anchor="RFC8341" target="https://www.rfc-editor.org/info/rfc8341" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml">
          <front>
            <title>Network Configuration Access Control Model</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <date month="March" year="2018"/>
          </front>
          <seriesInfo name="RFC" value="8341"/>
          <seriesInfo name="DOI" value="10.17487/RFC8341"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <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>
        <reference anchor="RFC8349" target="https://www.rfc-editor.org/info/rfc8349" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8349.xml">
          <front>
            <title>A YANG Data Model for Routing Management (NMDA Version)</title>
            <author fullname="L. Lhotka" initials="L." surname="Lhotka"/>
            <author fullname="A. Lindem" initials="A." surname="Lindem"/>
            <author fullname="Y. Qu" initials="Y." surname="Qu"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.</t>
              <t>The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8349"/>
          <seriesInfo name="DOI" value="10.17487/RFC8349"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
          </front>
        </reference>
        <reference anchor="RFC8491" target="https://www.rfc-editor.org/info/rfc8491" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8491.xml">
          <front>
            <title>Signaling Maximum SID Depth (MSD) Using IS-IS</title>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <author fullname="U. Chunduri" initials="U." surname="Chunduri"/>
            <author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
            <author fullname="L.Ginsberg" initials="L." surname="Ginsberg"/>
            <date month="November" year="2018"/>
          </front>
        </reference>
        <reference anchor="RFC8919" target="https://www.rfc-editor.org/info/rfc8919" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8919.xml">
          <front>
            <title>IS-IS Application-Specific Link Attributes</title>
            <author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
            <author fullname="P. Psenak" initials="P." surname="Psenak"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <date month="October" year="2020"/>
            <abstract>
              <t>Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments.  Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined.  In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link.  This document introduces new link attribute advertisements that address both of these shortcomings.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8919"/>
          <seriesInfo name="DOI" value="10.17487/RFC8919"/>
        </reference>
        <reference anchor="I-D.ietf-isis-yang-isis-cfg" target="https://www.ietf.org/archive/id/draft-ietf-isis-yang-isis-cfg-42.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-isis-yang-isis-cfg.xml">
          <front>
            <title>YANG Data Model for IS-IS Protocol</title>
            <author fullname="Stephane Litkowski">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Derek Yeung">
              <organization>Arrcus, Inc</organization>
            </author>
            <author fullname="Acee Lindem">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Jeffrey Zhang">
              <organization>Juniper Networks</organization>
            </author>
            <author fullname="Ladislav Lhotka">
              <organization>CZ.NIC</organization>
            </author>
            <date day="15" month="October" year="2019"/>
            <abstract>
              <t>This document defines a YANG data model that can be used to configure and manage the IS-IS protocol on network elements.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-isis-yang-isis-cfg-42"/>
        </reference>
        <reference anchor="I-D.ietf-lsr-flex-algo" target="https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-21.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-lsr-flex-algo.xml">
          <front>
            <title>IGP Flexible Algorithm</title>
            <author fullname="Peter Psenak">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Shraddha Hegde">
              <organization>Juniper Networks, Inc.</organization>
            </author>
            <author fullname="Clarence Filsfils">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Ketan Talaulikar">
              <organization>Arrcus, Inc</organization>
            </author>
            <author fullname="Arkadiy Gulko">
              <organization>Edward Jones</organization>
            </author>
            <date day="5" month="September" year="2022"/>
            <abstract>
              <t>IGP protocols traditionally compute best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE based or Segment Routing based Traffic Engineering to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lsr-flex-algo-21"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <!-- Here we use entities that we defined at the beginning. -->
      <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8340" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml">
          <front>
            <title>YANG Tree Diagrams</title>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>This document captures the current syntax used in YANG module tree diagrams.  The purpose of this document is to provide a single location for this definition.  This syntax may be updated from time to time based on the evolution of the YANG language.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="215"/>
          <seriesInfo name="RFC" value="8340"/>
          <seriesInfo name="DOI" value="10.17487/RFC8340"/>
        </reference>
      </references>
    </references>
  </back>
</rfc>
