Internet DRAFT - draft-lu-isis-transaction-tlv

draft-lu-isis-transaction-tlv





Network Working Group                                              W. Lu
Internet-Draft                                                   A. Tian
Intended status: Standards Track                                Ericsson
Expires: September 6, 2012                                 March 5, 2012


                          ISIS Transaction TLV
                    draft-lu-isis-transaction-tlv-00

Abstract

   ISIS local updates may require multiple LSPs to convey.  Receiving
   routers, whose decision processes are without such knowledge, may
   generate incorrect routing table updates based on the partial set of
   LSPs it receives and hence the traffic outage before they are
   corrected by another run of the decision process.  This memo
   describes a method that makes the decision process more informed so
   that the interim results can be minimized or avoided.

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 September 6, 2012.

Copyright Notice

   Copyright (c) 2012 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



Lu & Tian               Expires September 6, 2012               [Page 1]

Internet-Draft            ISIS Transaction TLV                March 2012


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
     1.2.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3.  Implicit Purging . . . . . . . . . . . . . . . . . . . . .  3
     1.4.  PDU Transaction Knowledge  . . . . . . . . . . . . . . . .  4
   2.  Transaction TLV  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  LSP Transaction Set  . . . . . . . . . . . . . . . . . . .  5
     2.2.  TLV Format . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  T-TLV Count  . . . . . . . . . . . . . . . . . . . . . . .  6
     2.4.  Transaction ID . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Originator . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Receiver . . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.2.1.  Opening the Transaction  . . . . . . . . . . . . . . .  7
       3.2.2.  Invalid Transaction  . . . . . . . . . . . . . . . . .  8
       3.2.3.  Processing T-TLV . . . . . . . . . . . . . . . . . . .  8
       3.2.4.  Closing the Transaction  . . . . . . . . . . . . . . .  8
       3.2.5.  Aborting the Transaction . . . . . . . . . . . . . . .  9
       3.2.6.  Exit Transaction . . . . . . . . . . . . . . . . . . .  9
       3.2.7.  Timer Expiry . . . . . . . . . . . . . . . . . . . . .  9
       3.2.8.  TID Wrap . . . . . . . . . . . . . . . . . . . . . . .  9
   4.  Multiple Transaction Sets  . . . . . . . . . . . . . . . . . .  9
   5.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Avoid Unwanted Purging . . . . . . . . . . . . . . . . . . 10
     5.2.  Allow reordering of TLVs in GR case  . . . . . . . . . . . 10
     5.3.  Help Precise SPF Scheduling  . . . . . . . . . . . . . . . 10
     5.4.  Other than SPFs  . . . . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12











Lu & Tian               Expires September 6, 2012               [Page 2]

Internet-Draft            ISIS Transaction TLV                March 2012


1.  Introduction

   Link state protocols run on the knowledge of the entire topology.
   Incomplete topology information, even temporary, can result in
   traffic outage or routing loop.  While transitional routing changes
   are inevitable and common to both OSPF [RFC2328] and ISIS
   [RFC1195][ISO.10589.1992], impacts to unchanged network connectivity
   are unnecessary and should be minimized if not totally avoidable.

1.1.  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].

1.2.  Acronyms

   IS-IS -  Intermediate System to Intermediate System

   OSPF  -  Open Shortest Path First

   TLV   -  Type Length Value

   PDU   -  Protocol Data Unit

   LSP   -  Link State PDU

   SPF   -  Shortest Path First

1.3.  Implicit Purging

   Compared to OSPF, these impacts are unique to ISIS.  There are two
   reasons.  One is that ISIS LSPs use implicit TLV purging.  Although
   LSPs do have age field which can be used for purging purpose, ISIS
   does not have the age granularity down to TLV level which is the
   atomic unit of ISIS link state information.  If for some reason a TLV
   needs to be relocated to a different LSP fragment (e.g.  TLV-B in
   Figure 1 and Figure 2), this TLV can be perceived as being purged
   from the original LSP fragment.  And if the receiving ISIS starts its
   decision process before it sees the second LSP fragment, the
   reachability via this TLV, if any, will be lost.










Lu & Tian               Expires September 6, 2012               [Page 3]

Internet-Draft            ISIS Transaction TLV                March 2012


               LSP-Foo.00-00                     LSP-Foo.00-01
     --------------------------------   -------------------------------
     | ............ | TLV-A | TLV-B |   | ........... | TLV-X | ----- |
     --------------------------------   -------------------------------

                       Figure 1: Frag 00 Almost Full


               LSP-Foo.00-00                     LSP-Foo.00-01
     --------------------------------   -------------------------------
     | ............ | TLV-A     | - |   | ........... | TLV-X | TLV-B |
     --------------------------------   -------------------------------

                      Figure 2: TLV-A grow out TLV-B

   The second reason is that operating directly on data link layer, ISIS
   cannot extend the LSP size beyond the MTU limit as opposed to OSPF
   which can leverage the IP fragmentation capability to extend its LSU
   size.  The consequence is that when an LSP fragment is full or nearly
   full, if some of its TLVs need to expand, they will have to be
   relocated to other LSP fragment.  Alternatively some other TLVs can
   be moved out of this LSP fragment to make room for the needy.  Either
   way an implicit purge condition is created.

1.4.  PDU Transaction Knowledge

   The above issues can be mitigated if the receiving routers are
   provided with LSP transaction information.  In other words, if the
   receivers know how many LSPs they should expect from a particular
   originating Intermediate System, so that they acquire complete
   topology updates from that System, the receivers should be able to
   avoid running their decision process based on the incomplete
   transitional link state information.

   There can be many ways to accomplish the purpose.  However to be
   practical the solution should meet following requirements:

   1.  It must be backward compatible.  Adding a new TLV can easily
       fulfill this;

   2.  The TLV should be simple and short, that it does not take
       significant LSP space;

   3.  The solution should be fallback-able.  That is, in case of errors
       or mistakes, it can fallback to the operation state without such
       solution;





Lu & Tian               Expires September 6, 2012               [Page 4]

Internet-Draft            ISIS Transaction TLV                March 2012


   4.  It can be implemented easily without adding much burden on the
       originator and its update process.  In particular it should not
       delay or change the timing of LSP flooding;

   5.  On the receiver side, the new logic should be simple and can be
       easily integrated to the existing logic, such as SPF scheduler.
       Performance wise, the new addition should be negligible.

   This document describes a transaction knowledge based TLV that can be
   used by the receiving routers to make informed decision.


2.  Transaction TLV

   A new TLV is introduced to indicate that the carrying LSP needs
   additional LSPs to complement.  For example, in Figure 2 LSPs "00"
   and "01" both have to be included in the SPF to reflect the correct
   change.  If the receiver kicks off its SPF right after receiving LSP
   "00" and before seeing LSP "01", the reachability pertaining to TLV-B
   will be incorrectly removed, cause temporary traffic loss.  The TLV
   is called Transaction TLV as it provides the transaction knowledge of
   the changes in which a set of LSPs are involved.

2.1.  LSP Transaction Set

   LSPs which are coherent in contents are called LSP Transaction Set.
   These LSPs must be processed atomically by the receiver's decision
   process to avoid incorrect result.  In Figure 2, LSPs "00" and "01"
   form the LSP transaction set.

   The LSP transaction set is a subset of all LSPs originated by an IS.
   In other words, the transaction set belongs to a single IS, and
   shares the same LSP ID which is the System ID plus the pseudo node
   ID.

2.2.  TLV Format

   Figure 3 describes the Transaction TLV data fields:













Lu & Tian               Expires September 6, 2012               [Page 5]

Internet-Draft            ISIS Transaction TLV                March 2012


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type         |     Len     |         TID                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Count        |
     +-+-+-+-+-+-+-+-+

                     Figure 3: Transaction TLV Format

   Type
      1 byte, value TBD (T-TLV);

   Len
      1 byte, 4 or 5;

   TID
      4 bytes, Transaction ID;

   Count
      1 byte, optional.

      The TLV can appear at most once in an LSP (fragment).  Each LSP in
      an LSP transaction set is encoded with the same TLV except the
      last LSP which MUST include the "count" in this TLV to tell the
      total number LSPs in this transaction set.

2.3.  T-TLV Count

   The count field is of 1 byte size, same as the size for LSP number
   field.  The first "count-1" LSPs use the shorter T-TLV which has
   length 4.  The last LSP use the longer T-TLV which contains the count
   field which counts in itself.  This design is to make the originator
   easy to encode the TLV without having to know the count beforehand.

2.4.  Transaction ID

   Along the time, an IS may generate and flood a number of LSP
   transaction sets.  To differentiate one set from another, a
   monotonically increased Transaction ID (TID) is used.  Each IS
   maintains and manages its TID.  If an IS is also a DIS in one or more
   of its interfaces, each pseudo node has its own TID which is
   independent of the TID of the non-pseudo node, or other pseudo node.

   In case of TID conflict (due to race condition in flooding, or
   errors), the higher TID invalidates the lower TID.  When a TID
   reaches the maximum, the TID wrap mechanism is used, which is
   detailed in Section 3.2.8.



Lu & Tian               Expires September 6, 2012               [Page 6]

Internet-Draft            ISIS Transaction TLV                March 2012


3.  Operation

3.1.  Originator

   When an IS decides that its update process will have to use multiple
   LSPs to convey some information atomically, it labels these LSPs with
   the T-TLV and follows the procedures below:

   1.  The T-TLV should be used for SPF-sensitive changes only;

   2.  It starts a new TID number which is per LSP ID based.  How to
       choose the initial TID number is a local decision though the
       natural choice would be 1.  The number MUST be incremented from
       the existing one, and monotonically increased ever since;

   3.  T-TLV is recommended to be added to the end of an LSP.  The TID
       is stored in the LSP set space (containing all LSP fragments), as
       opposed to the individual LSP space;

   4.  Repeat step 3 until there is no more to pack, at which time a
       T-TLV with count field is inserted to this last LSP in the
       transaction set.

3.2.  Receiver

   Per ISIS protocol nature, if the receiver does not understand and
   support the T-TLV, the TLV is silently ignored.  This ensures the
   backward compatibility.

   Otherwise the receiving IS enters into the transaction procedure.

   An IS will not engage its decision process into such procedure for
   T-TLVs whose carrying LSPs are already installed in the database.  In
   other words, the procedure is activated only upon the receiving of
   the T-TLVs whose carrying LSPs are new.

3.2.1.  Opening the Transaction

   When a T-TLV is received, the receiving IS enters the LSP transaction
   procedure.

   Type
      The TID is recorded to indicate that the current TID is active;

   Len
      A protection timer is started to prevent the error case where the
      transaction cannot close in time;




Lu & Tian               Expires September 6, 2012               [Page 7]

Internet-Draft            ISIS Transaction TLV                March 2012


   TID
      LSPs in a transaction set may not arrive in the order they are
      sent.  Whichever arrives the first opens the transaction;

   Count
      The transaction record (TID/count/status) is maintained under the
      LSP set space (SystemID + PseudoNodeID).

3.2.2.  Invalid Transaction

   The transaction is invalid, and MUST be aborted (exit) if:

   Type
      TID is outdated.  This occurs if a higher TID is found, or the
      same TID is closed in the past transaction;

   Len
      more than one T-TLV is found in an LSP;

   TID
      more than one T-TLV with count field is found in an LSP
      transaction set;

3.2.3.  Processing T-TLV

   When a T-TLV is received, following rules apply:

   Type
      Open the transaction if not yet, also increment the corresponding
      local count.  If the received TLV contains the count, note down
      the announced count.

   Len
      If the local count equals the announced count, close the
      transaction.

3.2.4.  Closing the Transaction

   If the received T-TLV causes the local count to match the announced
   count:

   Type
      Change the current transaction TID from active to closed;

   Len
      Cancel the protection timer;





Lu & Tian               Expires September 6, 2012               [Page 8]

Internet-Draft            ISIS Transaction TLV                March 2012


   Len
      Exit the transaction.

   Note that any T-TLV can close the transaction as long as it causes
   the match of counters.  Implementation should not assume that the
   T-TLV with count field comes the last.

3.2.5.  Aborting the Transaction

   Any error condition can abort the current transaction.  The handling
   procedure is the same as the one in Section 3.2.4.

3.2.6.  Exit Transaction

   A transaction can be terminated normally (closing) or abnormally due
   to error conditions.

   Closing and aborting the transaction are technically the same
   operation.  The difference is that closing the transaction fulfills
   the purpose of T-TLVs for avoiding unnecessary packet loss.

   Either way after the transaction is terminated, the decision process
   MUST no longer block its SPF and should start the computation
   immediately or follow whatever SPF scheduling mandates.

3.2.7.  Timer Expiry

   The expiry of the protection timer indicates that some transaction
   error has occurred.  The receiving IS MUST abort the transaction.

   The length of the timer is a local decision.

3.2.8.  TID Wrap

   When a TID reaches the maximum (0xFFFFFFFF), the originating IS will
   have to refrain from using T-TLV for LSP maximum age (21 minutes
   usually).  The logic is similar to that of LSP sequence number
   wrapping.


4.  Multiple Transaction Sets

   The count field is of 1 byte size, same as the size for LSP number
   field.  The first "count-1" LSPs use the shorter T-TLV which has
   length 4.  The last LSP use the longer T-TLV which contains the count
   field which counts in itself.  This design is to make the originator
   easy to encode the TLV without having to know the count beforehand.




Lu & Tian               Expires September 6, 2012               [Page 9]

Internet-Draft            ISIS Transaction TLV                March 2012


5.  Use Cases

   The count field is of 1 byte size, same as the size for LSP number
   field.  The first "count-1" LSPs use the shorter T-TLV which has
   length 4.  The last LSP use the longer T-TLV which contains the count
   field which counts in itself.  This design is to make the originator
   easy to encode the TLV without having to know the count beforehand.

5.1.  Avoid Unwanted Purging

   The unwanted purging described in Section 1.3 can be avoided using
   T-TLVs.  The originator can add T-TLV to LSP-Foo.00-00 and T-TLV
   (count=2) to LSP-Foo.00-01.  The receivers will withhold the SPF till
   both LSPs are received.  The missing TLV-B in the first LSP as shown
   in Figure 2 will not be treated as an implicit purging, as it will be
   found in the second LSP.

5.2.  Allow reordering of TLVs in GR case

   If an IS advertises lots of redistributed routes in its LSPs, it is
   not trivial to maintain its TLV (like TLV 135) orders.

   This is especially true when an IS has just gone through the graceful
   restart process.  Because the RIB does not necessary supply the
   redistributed routes the same order in the Pre-Restart time,
   reconstruct LSPs will result in LSPs with TLVs reordered.

   And if the number of redistributed routes is high, they spread over
   multiple LSPs.  When the set of LSPs reaches other ISes, the same
   issue of 5.1 can arise, even if there is no change to redistributed
   routes at all.

   It is not impossible for the originating IS to use sophisticated
   means to keep those TLVs in their original order.  Nevertheless this
   issue can easily be addressed with the T-TLVs.

   The restarting IS can add T-TLVs to all LSPs that are subject to TLV
   reordering, and transmit them upon exit of its graceful restart
   process.  Thus the receiving ISes will not mistakenly purge some IS
   external reachability prefixes.

5.3.  Help Precise SPF Scheduling

   As a link state protocol, ISIS has to two conflict goals.  One is to
   be fast responsive to the network changes.  The other is the network
   stability.

   If the SPF is scheduled too swiftly, the system (and even the



Lu & Tian               Expires September 6, 2012              [Page 10]

Internet-Draft            ISIS Transaction TLV                March 2012


   network) can melt down for some storm activities.  On the other hand
   if there is lot of delays, the network becomes too slow adapting
   changes.

   For example, if an IS receives a burst of redistributed routes from
   BGP, it may send out dozens of LSPs for advertising all those routes.
   The receiving ISes, upon received first several LSPs, usually start
   the decision process to compute the new routing table.  The routing
   table is incomplete and will be soon overwritten by another SPF run.

   If the number of routes (and hence LSPs) is high, most such SPF runs
   will be useless and wasteful.  Only the last SPF will contribute to
   the final and correct routing table.

   The T-TLV if used will provide guidance to the receiving ISes to run
   SPF only when all LSPs are in place.  This SPF is equivalent to the
   final SPF mentioned above.  Therefore it saves a lot of SPF runs and
   network churns.  What is more is that the T-TLV driven SPF can be
   kick started immediately, compared to the final SPF which usually has
   some amount of delay.

5.4.  Other than SPFs

   The T-TLV may also be used for some non-SPF related operation.  For
   example, the receiving ISes may choose to defer its TE database
   uploading process until all LSPs that carry the TE information are
   received.


6.  Security Considerations

   This proposal does not introduce additional issues on security
   condition.


7.  IANA Considerations

   A new ISIS T-TLV is introduced.  The type is TBD by IANA.


8.  Acknowledgements

   TBD


9.  References





Lu & Tian               Expires September 6, 2012              [Page 11]

Internet-Draft            ISIS Transaction TLV                March 2012


9.1.  Normative References

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

9.2.  Informative References

   [ISO.10589.1992]
              International Organization for Standardization,
              "Intermediate system to intermediate system intra-domain-
              routing routine information exchange protocol for use in
              conjunction with the protocol for providing the
              connectionless-mode Network Service (ISO 8473)",
              ISO Standard 10589, 1992.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.


Authors' Addresses

   Wenhu Lu
   Ericsson
   300 Holger Way
   San Jose, California  95134
   USA

   Email: Wenhu.Lu@ericsson.com


   Albert Tian
   Ericsson
   300 Holger Way
   San Jose, California  95134
   USA

   Email: Albert.Tian@ericsson.com












Lu & Tian               Expires September 6, 2012              [Page 12]