Internet DRAFT - draft-ginsberg-isis-fs-lsp

draft-ginsberg-isis-fs-lsp






Networking Working Group                                     L. Ginsberg
Internet-Draft                                                S. Previdi
Intended status: Standards Track                                 Y. Yang
Expires: December 18, 2013                                 Cisco Systems
                                                           June 16, 2013


                       IS-IS Flooding Scope LSPs
                   draft-ginsberg-isis-fs-lsp-01.txt

Abstract

   Intermediate System To Intermediate System (IS-IS) provides efficient
   and reliable flooding of information to its peers.  However the
   current flooding scopes are limited to either area wide scope or
   domain wide scope.  There are existing use cases where support of
   other flooding scopes are desirable.  This document defines new
   Protocol Data Units (PDUs) which provide support for new flooding
   scopes as well as additional space for advertising information
   targeted for the currently supported flooding scopes.

   The protocol extensions defined in this document are not backwards
   compatible with existing implementations and so must be deployed with
   care.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 18, 2013.




Ginsberg, et al.        Expires December 18, 2013               [Page 1]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

























Ginsberg, et al.        Expires December 18, 2013               [Page 2]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Definition of New PDUs . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Flooding Scoped LSP Format . . . . . . . . . . . . . . . .  5
     2.2.  Flooding Scoped CSNP Format  . . . . . . . . . . . . . . .  8
     2.3.  Flooding Scope PSNP Format . . . . . . . . . . . . . . . .  9
   3.  Flooding Scope Update Process Operation  . . . . . . . . . . . 11
     3.1.  Scope Types  . . . . . . . . . . . . . . . . . . . . . . . 11
     3.2.  Operation on Point-to-Point Circuits . . . . . . . . . . . 11
     3.3.  Operation on Broadcast Circuits  . . . . . . . . . . . . . 12
     3.4.  Use of Authentication  . . . . . . . . . . . . . . . . . . 12
     3.5.  Priority Flooding  . . . . . . . . . . . . . . . . . . . . 12
   4.  Deployment Considerations  . . . . . . . . . . . . . . . . . . 12
   5.  Graceful Restart Interactions  . . . . . . . . . . . . . . . . 13
   6.  Multi-instance Interactions  . . . . . . . . . . . . . . . . . 13
   7.  Circuit Scoped Flooding  . . . . . . . . . . . . . . . . . . . 13
   8.  Extending LSP Set Capacity . . . . . . . . . . . . . . . . . . 14
   9.  Domain Scoped Flooding . . . . . . . . . . . . . . . . . . . . 14
   10. Announcing Support for Flooding Scopes . . . . . . . . . . . . 15
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     14.2. Informational References . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
























Ginsberg, et al.        Expires December 18, 2013               [Page 3]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


1.  Introduction

   The Update Process as defined by [IS-IS] provides reliable and
   efficient flooding of information to all routers in a given flooding
   scope.  Currently the protocol supports two flooding scopes and
   associated Protocol Data Units (PDUs).  Level 1 (L1) Link State PDUs
   (LSPs) are flooded to all routers in an area.  Level 2 (L2) LSPs are
   flooded to all routers in the Level 2 sub-domain.  The basic
   operation of the Update Process can be applied to any subset of the
   routers in a given topology so long as that topology is not
   partitioned.  It is therefore possible to introduce new PDUs in
   support of other flooding scopes and utilize the same Update Process
   machinery to provide the same reliability and efficiency which the
   Update Process currently provides for L1 and L2 scopes.  This
   document defines these new PDUs and the modified Update Process rules
   which are to be used in supporting new flooding scopes.

   New deployment cases have introduced the need for reliable and
   efficient circuit scoped flooding.  For example, Appointed Forwarder
   information as defined in [RFC6326] needs to be flooded reliably and
   efficiently to all RBridges on a broadcast circuit.  Currently, only
   Intermediate System to Intermediate System Hellos (IIHs) have the
   matching scope - but IIHs are unreliable i.e. individual IIHs may be
   lost without affecting correct operation of the protocol.  To provide
   reliability in cases where the set of information to be flooded
   exceeds the carrying capacity of a single PDU requires sending the
   information periodically even when no changes in the content have
   occurred.  When the information content is large this is inefficient
   and still does not provide a guarantee of reliability.  This document
   defines circuit scoped flooding in order to provide a solution for
   such cases.

   Another existing limitation of [IS-IS] is the carrying capacity of an
   LSP set.  It has been noted in [RFC5311] that the set of LSPs that
   may be originated by a system at each level is limited to 256 LSPs
   and the maximum size of each LSP is limited by the minimum Maximum
   Transmission Unit (MTU) of any link used to flood LSPs.  [RFC5311]
   has defined a backwards compatible protocol extension which can be
   used to overcome this limitation if needed.  While the [RFC5311]
   solution is viable, in order to be interoperable with routers which
   do not support the extension it imposes some restrictions on what
   can/cannot be advertised in the Extended LSPs and requires allocation
   of multiple unique system IDs to a given router.  A more flexible and
   less constraining solution is possible if interoperability with
   legacy routers is not a requirement.  As the introduction of new PDUs
   required to support new flooding scopes is by definition not
   interoperable with legacy routers, it is possible to simultaneously
   introduce an alternative solution to the limited LSP set carrying



Ginsberg, et al.        Expires December 18, 2013               [Page 4]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


   capacity as part of the extensions defined in this document.  This
   capability is also defined in this document.

   The PDU type field in the common header for all IS-IS PDUs is a 5 bit
   field.  The possible PDU types supported by the protocol are
   therefore limited to a maximum of 32.  In order to minimize the need
   to introduce additional PDU types in the future, the new PDUs
   introduced in this document are defined so as to allow multiple
   flooding scopes to be associated with the same PDU type.  This means
   if new flooding scopes are required in the future the same PDU type
   can be used.


2.   Definition of New PDUs

   In support of new flooding scopes the following new PDUs are
   required:

   o  Flooding Scoped LSPs (FS-LSPs)

   o  Flooding Scoped Complete Sequence Number PDUs (FS-CSNPs)

   o  Flooding Scoped Partial Sequence Number PDUs (FS-PSNPs)

   Each of these PDUs is intentionally defined with a header as similar
   in format as possible to the corresponding PDU types currently
   defined in [IS-IS].  Although it might have been possible to
   eliminate or redefine PDU header fields in a new way the existing
   formats are retained in order to allow maximum reuse of existing PDU
   processing logic in an implementation.

   Note that in the case of all FS PDUs, the Maximum Area Addresses
   field in the header of the corresponding standard PDU has been
   replaced with a Scope field.  The maximum area addresses checks
   specified in [IS-IS] are therefore not performed on FS PDUs.

2.1.  Flooding Scoped LSP Format

   An FS-LSP has the following format:

                                         No. of octets
              +-------------------------+
              | Intradomain Routeing    |     1
              | Protocol Discriminator  |
              +-------------------------+
              | Length Indicator        |     1
              +-------------------------+
              | Version/Protocol ID     |     1



Ginsberg, et al.        Expires December 18, 2013               [Page 5]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


              | Extension               |
              +-------------------------+
              | ID Length               |     1
              +-------------------------+
              |R|R|R| PDU Type          |     1
              +-------------------------+
              |  Version                |     1
              +-------------------------+
              |  Reserved               |     1
              +-------------------------+
              |P|  Scope                |     1
              +-------------------------+
              |  PDU Length             |     2
              +-------------------------+
              |  Remaining Lifetime     |     2
              +-------------------------+
              |   FS LSP ID             |     ID Length + 2
              +-------------------------+
              | Sequence Number         |     4
              +-------------------------+
              | Checksum                |     2
              +-------------------------+
              |Reserved|LSPDBOL|IS Type |     1
              +-------------------------+
              : Variable Length Fields  :     Variable
              +-------------------------+

   Intradomain Routeing Protocol Discriminator - 0x83
   (as defined in [IS-IS])

   Length Indicator - Length of the Fixed Header in octets

   Version/Protocol ID Extension - 1

   ID Length - As defined in [IS-IS]

   PDU Type - 10 (Subject to assignment by IANA) Format as
   defined in [IS-IS]

   Version - 1

   Reserved - transmitted as zero, ignored on receipt

   Scope - Bits 1-7 define the flooding scope.
     The value 0 is reserved
     and MUST NOT be used. Received FS-LSPs with a scope of 0 MUST
     be ignored.
     P - Bit 8 - Priority Bit. If set to 1 this LSP SHOULD be flooded



Ginsberg, et al.        Expires December 18, 2013               [Page 6]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


     at high priority.

   PDU Length - Entire Length of this PDU, in octets, including the
   header.

   Remaining Lifetime - Number of seconds before this FS-LSP is
   considered expired.

   FS LSP ID - the system ID of the source of the FS-LSP. One of
   the following two formats is used:

     FS LSP ID Standard Format

              +-------------------------+
              |   Source ID             |     ID Length
              +-------------------------+
              | Pseudonode ID           |     1
              +-------------------------+
              | FS LSP Number           |     1
              +-------------------------+

     FS LSP ID Extended Format

              +-------------------------+
              |   Source ID             |     ID Length
              +-------------------------+
              | Extended FS LSP Number  |     2
              +-------------------------+

     Which format is used is specific to the Scope and MUST be defined
     when the specific flooding scope is defined.

   Sequence Number - sequence number of this FS-LSP

   Checksum - Checksum of contents of FS-LSP from Source ID to end.
   Checksum is computed as defined in [IS-IS].

   Reserved/LSPDBOL/IS Type

      Bits 4-8 are reserved, which means they are transmitted as 0 and
      ignored on receipt.

      LSPDBOL - Bit 3 - A value of 0 indicates no FS-LSP Database
      Overload and a value of 1 indicates that the FS-LSP Database is
      overloaded. The overload condition is specific to FS-LSPs with the
      scope specified in the scope field.

      IS Type - Bits 1 and 2. The type of Intermediate System as defined



Ginsberg, et al.        Expires December 18, 2013               [Page 7]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


      in [IS-IS].

   Variable Length Fields which are allowed in an FS-LSP are specific to
   the defined scope.



2.2.  Flooding Scoped CSNP Format

   An FS-CSNP has the following format:
                                            No. of octets
                 +-------------------------+
                 | Intradomain Routeing    |     1
                 | Protocol Discriminator  |
                 +-------------------------+
                 | Length Indicator        |     1
                 +-------------------------+
                 | Version/Protocol ID     |     1
                 | Extension               |
                 +-------------------------+
                 | ID Length               |     1
                 +-------------------------+
                 |R|R|R| PDU Type          |     1
                 +-------------------------+
                 |  Version                |     1
                 +-------------------------+
                 |  Reserved               |     1
                 +-------------------------+
                 |R|  Scope                |     1
                 +-------------------------+
                 |  PDU Length             |     2
                 +-------------------------+
                 |  Source ID              |     ID Length + 1
                 +-------------------------+
                 |  Start FS-LSP ID        |     ID Length + 2
                 +-------------------------+
                 |  End FS-LSP ID          |     ID Length + 2
                 +-------------------------+
                 : Variable Length Fields  :     Variable
                 +-------------------------+

      Intradomain Routeing Protocol Discriminator - 0x83
      (as defined in [IS-IS]

      Length Indicator - Length of the Fixed Header in octets

      Version/Protocol ID Extension - 1




Ginsberg, et al.        Expires December 18, 2013               [Page 8]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


      ID Length - As defined in [IS-IS]

      PDU Type - 11 (Subject to assignment by IANA) Format as defined in
      [IS-IS]

      Version - 1

      Reserved - transmitted as zero, ignored on receipt

      Scope - Bits 1-7 define the flooding scope.
        The value 0 is reserved
        and MUST NOT be used. Received FS-CSNPs with a scope of 0 MUST
        be ignored.
        Bit 8 is Reserved which means it is transmitted as 0 and
        ignored on receipt.

      PDU Length - Entire Length of this PDU, in octets, including the
      header.

      Source ID - the system ID of the Intermediate System
      (with zero Circuit ID) generating this Sequence Numbers PDU

      Start FS-LSP ID - The FS-LSP ID of the first FS-LSP with the
      specified scope in the range covered by this FS-CSNP.

      End FS-LSP ID - The FS-LSP ID of the last FS-LSP with the
      specified scope in the range covered by this FS-CSNP.

      Variable Length Fields which are allowed in an FS-CSNP are
      limited to those TLVs which are supported by standard CSNP.



2.3.  Flooding Scope PSNP Format

   An FS-PSNP has the following format:
                                            No. of octets
                 +-------------------------+
                 | Intradomain Routeing    |     1
                 | Protocol Discriminator  |
                 +-------------------------+
                 | Length Indicator        |     1
                 +-------------------------+
                 | Version/Protocol ID     |     1
                 | Extension               |
                 +-------------------------+
                 | ID Length               |     1
                 +-------------------------+



Ginsberg, et al.        Expires December 18, 2013               [Page 9]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


                 |R|R|R| PDU Type          |     1
                 +-------------------------+
                 |  Version                |     1
                 +-------------------------+
                 |  Reserved               |     1
                 +-------------------------+
                 |U|  Scope                |     1
                 +-------------------------+
                 |  PDU Length             |     2
                 +-------------------------+
                 |  Source ID              |     ID Length + 1
                 +-------------------------+
                 : Variable Length Fields  :     Variable
                 +-------------------------+

      Intradomain Routeing Protocol Discriminator - 0x83
      (as defined in [IS-IS]

      Length Indicator - Length of the Fixed Header in octets

      Version/Protocol ID Extension - 1

      ID Length - As defined in [IS-IS]

      PDU Type - 12 (Subject to assignment by IANA) Format
      as defined in [IS-IS]

      Version - 1

      Reserved - transmitted as zero, ignored on receipt

      Scope - Bits 1-7 define the flooding scope.
        The value 0 is reserved
        and MUST NOT be used. Received FS-PSNPs with a scope of 0 MUST
        be ignored.
        U - Bit 8 - A value of 0 indicates that the specified
        flooding scope is supported. A value of 1 indicates
        that the specified flooding scope is unsupported. When
        U = 1, variable length fields other than authentication
        MUST NOT be included in the PDU.

      PDU Length - Entire Length of this PDU, in octets, including
      the header.

      Source ID - the system ID of the Intermediate System
      (with zero Circuit ID) generating this Sequence Numbers PDU

      Variable Length Fields which are allowed in an FS-PSNP are



Ginsberg, et al.        Expires December 18, 2013              [Page 10]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


      limited to those TLVs which are supported by standard PSNPs.



3.  Flooding Scope Update Process Operation

   The Update Process as defined in [IS-IS] maintains a Link State
   Database (LSDB) for each level supported.  Each level specific LSDB
   contains the full set of LSPs generated by all routers operating in
   that level specific scope.  The introduction of FS-LSPs creates
   additional LSDBs (FS-LSDBs) for each additional scope supported.  The
   set of FS-LSPs in each FS-LSDB consists of all FS-LSPs generated by
   all routers operating in that scope.  There is therefore an
   additional instance of the Update Process for each supported flooding
   scope.

   Operation of the scope specific Update Process follows the Update
   Process specification in [IS-IS].  The circuit(s) on which FS-LSPs
   are flooded are limited to those circuits which are participating in
   the given scope.  Similarly the sending/receiving of FS-CSNPs and FS-
   PSNPs is limited to the circuits participating in the given scope.

   Consistent support of a given flooding scope on a circuit by all
   routers operating on that circuit is required.

3.1.  Scope Types

   A flooding scope may be limited to a single circuit (circuit scope).
   Circuit scopes may be further limited by level (L1 circuit scope/L2
   circuit scope).

   A flooding scope may be limited to all circuits enabled for L1
   routing (area scope).

   A flooding scope may be limited to all circuits enabled for L2
   routing (L2 sub-domain scope).

   Additional scopes may be defined which include all circuits enabled
   for either L1 or L2 routing (domain-wide scope).

3.2.  Operation on Point-to-Point Circuits

   When a new adjacency is formed, synchronization of all FS-LSDBs
   supported on that circuit is required.  Therefore FS-CSNPs for all
   supported scopes MUST be sent when a new adjacency reaches the UP
   state.  Send Receive Message (SRM) bit MUST be set for all FS-LSPs
   associated with the scopes supported on that circuit.  Receipt of an
   FS-PSNP with the U bit equal to 1 indicates that the neighbor does



Ginsberg, et al.        Expires December 18, 2013              [Page 11]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


   not support that scope (although it does support FS PDUs).  This MUST
   cause SRM bit to be cleared for all FS-LSPs with the matching scope
   which are currently marked for flooding on that circuit.

3.3.  Operation on Broadcast Circuits

   FS PDUs are sent to the same destination address(es) as standard PDUs
   for the given protocol instance.  For specification of the defined
   destination addresses consult [IS-IS], [IEEEaq], [RFC6822], and
   [RFC6325].

   The Designated Intermediate System (DIS) for a broadcast circuit has
   the responsibility to generate periodic scope specific FS-CSNPs for
   all supported scopes.  A scope specific DIS is NOT elected as all
   routers on a circuit MUST support a consistent set of flooding
   scopes.

   It is possible that a scope may be defined which is not level
   specific.  In such a case the DIS for each level enabled on a
   broadcast circuit MUST independently send FS PDUs for that scope to
   the appropriate level specific destination address.  This may result
   in redundant flooding of FS-LSPs for that scope.

3.4.  Use of Authentication

   Authentication TLVs MAY be included in FS PDUs.  When authentication
   is in use, the scope is first used to select the authentication
   configuration that is applicable.  The authentication check is then
   performed as normal.  Although scope specific authentication MAY be
   used, sharing of authentication among multiple scopes and/or with the
   standard LSP/CSNP/PSNP PDUs is considered sufficient.

3.5.  Priority Flooding

   When the FS LSP ID Extended Format is used the set of LSPs generated
   by an IS may be quite large.  It may be useful to identify those LSPs
   in the set which contain information of higher priority.  Such LSPs
   will have the P bit set to 1 in the Scope field in the LSP header.
   Such LSPs SHOULD be flooded at a higher priority than LSPs with the P
   bit set to 0.  This is a suggested behavior on the part of the
   originator of the LSP.  When an LSP is purged the original state of
   the P bit MUST be preserved.


4.  Deployment Considerations

   Introduction of new PDU types is incompatible with legacy
   implementations.  Legacy implementations do not support the FS



Ginsberg, et al.        Expires December 18, 2013              [Page 12]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


   specific Update process(es) and therefore flooding of the FS-LSPs
   throughout the defined scope is unreliable when not all routers in
   the defined scope support FS PDUs.  Further, legacy implementations
   will likely treat the reception of an FS PDUs as an error.  Even when
   all routers in a given scope support FS PDUs, if not all routers in
   the flooding domain for a given scope support that scope flooding of
   the FS-LSPs may be compromised.  Therefore all routers in the
   flooding domain for a given scope SHOULD support both FS PDUs and the
   specified scope before use of that scope can be enabled.

   The U bit in FS-PSNPs provides a means to suppress retransmissions of
   unsupported scopes.  Routers which support FS PDUs SHOULD support the
   sending of PSNPs with the U bit equal to 1 when an FS-LSP is received
   with a scope which is unsupported.  Routers which support FS PDUs
   SHOULD trigger management notifications when FS PDUs are received for
   unsupported scopes and when PSNPs with the U bit equal to 1 are
   received.


5.  Graceful Restart Interactions

   [RFC5306] defines protocol extensions in support of graceful restart
   of a routing instance.  Synchronization of all supported FS-LSDBs is
   required in order for database synchronization to be complete.  This
   involves the use of additional T2 timers.  Receipt of a PSNP with the
   U bit equal to 1 will cause FS-LSDB synchronization with that
   neighbor to be considered complete for that scope.  See [RFC5306] for
   further details.


6.  Multi-instance Interactions

   In cases where FS-PDUs are associated with a non-zero instance the
   use of IID-TLVs in FS-PDUs follows the rules for use in LSPs, CSNPs,
   PSNPs as defined in [RFC6822].


7.  Circuit Scoped Flooding

   This document defines two circuit scoped flooding identifiers:

   o  Level 1 circuit scope (L1CS)

   o  Level 2 circuit scope (L2CS)

   FS-LSPs with the scope field set to one of these values contain
   information specific to the circuit on which they are flooded.  When
   received, such FS-LSPs MUST NOT be flooded on any other circuit.  The



Ginsberg, et al.        Expires December 18, 2013              [Page 13]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


   FS LSP ID Extended format is used in these PDUs.  The FS-LSDB
   associated with circuit scoped FS-LSPs consists of the set of FS-LSPs
   which both have matching circuit scope and are transmitted(locally
   generated) or received on a specific circuit.

   The set of TLVs which may be included in such FS-LSPs is specific to
   the given use case and is outside the scope of this document.


8.  Extending LSP Set Capacity

   The need for additional space in the set of LSPs generated by a
   single IS has been articulated in [RFC5311].  When legacy
   interoperability is not a requirement, the use of FS-LSPs meets that
   need without requiring the assignment of alias system-ids to a single
   IS.  Two flooding scopes are defined for this purpose:

   o  Level 1 Scoped FS-LSPs (L1-FS-LSP)

   o  Level 2 Scoped FS-LSPs (L2-FS-LSP)

   The FS LSP ID Extended format is used in these PDUs.  This provides
   64K of additional LSPs which may be generated by a single system at
   each level.

   Lx-FS-LSPs are used by the level specific Decision Process (defined
   in [IS-IS]) in the same manner as standard LSPs (i.e. as additional
   information sourced by the same IS) subject to the following
   restrictions:

   o  A valid version of LSP #0 from the same IS at the corresponding
      Level MUST be present in the LSDB in order for the FS-LSP set to
      be usable

   o  Information in an Lx-FS-LSP (e.g.  IS-Neighbor information) which
      supports using the originating IS as a transit node MUST NOT be
      used when the Overload bit is set in LSP #0

   o  Existing TLVs which are restricted to LSP #0 MUST NOT appear in
      Lx-FS-LSPs.

   There are no further restrictions as to what TLVs may be advertised
   in FS-LSPs.


9.  Domain Scoped Flooding

   Existing support for flooding information domain wide (i.e. to L1



Ginsberg, et al.        Expires December 18, 2013              [Page 14]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


   routers in all areas as well as to routers in the Level 2 sub-domain)
   requires the use of leaking procedures between levels.  For further
   details see [RFC4971].  This is sufficient when the data being
   flooded domain-wide consists of individual TLVs.  If it is desired to
   retain the identity of the originating IS for the complete contents
   of a PDU, then support for flooding the unchanged PDU is desirable.
   This document therefore defines a domain-wide flooding scope.  FS-
   LSPs with this scope MUST be flooded on all circuits regardless of
   what level(s) are supported on that circuit.

   The FS LSP ID Extended format is used in these PDUs.

   Use of information in FS-LSPs for a given scope depends on
   determining the reachability to the IS originating the FS-LSP.  This
   presents challenges for FS-LSPs with domain-scopes because no single
   IS has the full view of the topology across all areas.  It is
   therefore necessary for the originator of domain scoped FS-LSPs to
   advertise an identifier which will allow an IS who receives such an
   FS-LSP to determine whether the source of the FS-LSP is currently
   reachable.  The identifier required depends on what "address-
   families" are being advertised.

   When IS-IS is deployed in support of Layer 3 routing for IPv4 and/or
   IPv6 then FS-LSP #0 with domain-wide scope MUST include at least one
   of the following TLVs:

   o  IPv4 Traffic Engineering Router ID (TLV 134)

   o  IPv6 Traffic Engineering Router ID (TLV 140)

   When IS-IS is deployed in support of Layer 2 routing, current
   standards (e.g.  [RFC6325]) only support a single area.  Therefore
   domain-wide scope is not yet applicable.  When the Layer 2 standards
   are updated to include multi-area support the identifiers which can
   be used to support inter-area reachability will be defined - at which
   point the use of domain-wide scope for Layer 2 can be fully defined.


10.  Announcing Support for Flooding Scopes

   Announcements of support for flooding scope may be useful in
   validating that full support has been deployed and/or in isolating
   the reasons for incomplete flooding of FS-LSPs for a given scope.

   ISs supporting FS-PDUs MAY announce supported scopes in IIH PDUs.  To
   do so a new TLV is defined.





Ginsberg, et al.        Expires December 18, 2013              [Page 15]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


   Scoped Flooding Support
   Type:   243 (suggested - to be assigned by IANA)
   Length: 1 - 127
   Value
                                    No of octets
          +----------------------+
          |R| Supported Scope    |   1
          +----------------------+
          :                      :
          +----------------------+
          |R| Supported Scope    |   1
          +----------------------+

       A list of the circuit scopes supported on this circuit and
       other non-circuit flooding scopes supported.
       R bit MUST be 0 and is ignored on receipt.

       In a Point-Point IIH L1, L2 and domain-wide scopes MAY
       be advertised.
       In Level 1 LAN IIHs L1 and domain-wide scopes MAY be advertised.
       In Level 2 LAN IIHs L2 and domain-wide scopes MAY be advertised.


   Information in this TLV MUST NOT be considered in adjacency
   formation.

   Whether information in this TLV is used to determine when FS-LSPs
   associated with a locally supported scope are flooded is an
   implementation choice.


11.  IANA Considerations

   This document requires the definition of three new PDU types that
   need to be reflected in the ISIS PDU registry.  Values below are
   suggested values subject to assignment by IANA.

    Value  Description
    ----  ---------------------
     10    FS-LSP
     11    FS-CSNP
     12    FS-PSNP

   This document requires that a new IANA registry be created to control
   the assignment of scope identifiers in FS-PDUs.  The registration
   procedure is "Expert Review" as defined in [RFC5226].  Suggested
   registry name is "LSP Flooding Scoped Identifier Registry".  A scope
   identifier is a number from 1-127 inclusive.  The following scope



Ginsberg, et al.        Expires December 18, 2013              [Page 16]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


   identifiers are defined by this document.  Values are suggested
   values subject to assignment by IANA.

   Value    Description                         FS LSP ID Format
   -----    ------------------------------      ----------------
   1        Level 1 Circuit Flooding Scope      Extended
   2        Level 2 Circuit Flooding Scope      Extended
   3        Level 1 Flooding Scope              Extended
   4        Level 2 Flooding Scope              Extended
   5        Domain-wide Flooding Scope          Extended


   This document requires the definition of a new IS-IS TLV to be
   reflected in the "IS-IS TLV Codepoints" registry:

   Type  Description                       IIH LSP SNP Purge
   ----  ------------                      --- --- --- -----
   243   Circuit Scoped Flooding Support    Y   N   N    N



12.  Security Considerations

   Security concerns for IS-IS are addressed in [IS-IS], [RFC5304], and
   [RFC5310].

   The new PDUs introduced are subject to the same security issues
   associated with their standard LSP/CSNP/PSNP counterparts.  To the
   extent that additional PDUs represent additional load for routers in
   the network this increases the opportunity for denial of service
   attacks.


13.  Acknowledgements

   The authors wish to thank Ayan Banerjee, Donald Eastlake, and Mike
   Shand for their comments.


14.  References

14.1.  Normative References

   [IEEEaq]   "Standard for Local and metropolitan area networks: Media
              Access Control (MAC) Bridges and Virtual Bridged Local
              Area Networks - Amendment 20: Shortest Path Bridging",
              IEEE Std 802.1aq-2012, 29 June 2012.", 2012.




Ginsberg, et al.        Expires December 18, 2013              [Page 17]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


   [IS-IS]    "Intermediate system to Intermediate system intra-domain
              routeing information exchange protocol for use in
              conjunction with the protocol for providing the
              connectionless-mode Network Service (ISO 8473), ISO/IEC
              10589:2002, Second Edition.", Nov 2002.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4971]  Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate
              System to Intermediate System (IS-IS) Extensions for
              Advertising Router Information", RFC 4971, July 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
              Authentication", RFC 5304, October 2008.

   [RFC5306]  Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS",
              RFC 5306, October 2008.

   [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
              and M. Fanto, "IS-IS Generic Cryptographic
              Authentication", RFC 5310, February 2009.

   [RFC6822]  Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D.
              Ward, "IS-IS Multi-Instance", RFC 6822, December 2012.

14.2.  Informational References

   [RFC5311]  McPherson, D., Ginsberg, L., Previdi, S., and M. Shand,
              "Simplified Extension of Link State PDU (LSP) Space for
              IS-IS", RFC 5311, February 2009.

   [RFC6325]  Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
              Ghanwani, "Routing Bridges (RBridges): Base Protocol
              Specification", RFC 6325, July 2011.

   [RFC6326]  Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A.
              Ghanwani, "Transparent Interconnection of Lots of Links
              (TRILL) Use of IS-IS", RFC 6326, July 2011.








Ginsberg, et al.        Expires December 18, 2013              [Page 18]

Internet-Draft      draft-ginsberg-isis-fs-lsp-01.txt          June 2013


Authors' Addresses

   Les Ginsberg
   Cisco Systems
   510 McCarthy Blvd.
   Milpitas, CA  95035
   USA

   Email: ginsberg@cisco.com


   Stefano Previdi
   Cisco Systems
   Via Del Serafico 200
   Rome  0144
   Italy

   Email: sprevidi@cisco.com


   Yi Yang
   Cisco Systems
   7100-9 Kit Creek Road
   Research Triangle Park, North Carolina  27709-4987
   USA

   Email: yiya@cisco.com
























Ginsberg, et al.        Expires December 18, 2013              [Page 19]