[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                     Olivier Bonaventure
INTERNET DRAFT                                          Pierre Francois
                                                              UCLouvain
                                        Mike Shand
                                                        Stefano Previdi
                                                                  cisco
                                                         February, 2006
                                                   Expires August, 2006


                ISIS extensions for ordered FIB updates
                <draft-bonaventure-isis-ordered-00.txt>

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on August 30, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document proposes extensions to allow IS-IS to support the
   ordered convergence defined in [RTG-OFIB] that allows to avoid
   transient forwarding loops during the FIB updates that follow a non-
   urgent topology change.



Bonaventure/Francois/Previdi                                    [Page 1]


draft-bonaventure-isis-ordered-00.txt    February 2006


1   Introduction


   In large ISP networks, topology changes are frequent events. When a
   link metric changes, the router responsible for the changing link
   floods a new LSP and forces all routers to recompute their routing
   table and update their FIB. This routing convergence is that it can
   lead to packet losses due to transient forwarding loops [RTG-OFIB].

   There are various types of topology changes in IP networks. Sudden
   failures of unprotected links are urgent and should be handled by
   using a normal, fast, convergence of the link state routing protocol.
   However, there are frequent topology changes that are non-urgent. For
   example, operators often need to enable or disable links for short
   periods of time during maintenance operations. Another example are
   the IP networks where traffic engineering is performed by changing
   the ISIS link metrics.  These events are non-urgent and they should
   not cause packet losses or transient forwarding loops. Transient
   forwarding loops can be avoided by forcing the routers to orderly
   update their FIB as proposed in [RTG-OFIB]

   In this document, we propose IS-IS extensions allowing IS-IS routers
   to implement the ordered FIB update described in [RTG-OFIB]. We first
   describe the considered topology changes in section 2. Section 3
   defines the new IS-IS TLVs that are used to support [RTG-OFIB].

2.  Graceful topology changes

   In this section, we describe two types of graceful topology changes.
   The first one is the change of a link metric (increase or decrease).
   The second one is the change of the settings of the overload bit (Set
   to Unset or Unset to Set).

 2.1 Change in link metric

   The first change that we consider is a modification of the metric
   associated to a link. This change can be a metric increase or a
   metric decrease.  A non-urgent link shutdown can be converted into a
   weight change by doing the topology change in two steps. First, the
   metric of the link is set to the highest possible value. This
   triggers an ordered FIB update.  After the FIB update, the link can
   be safely removed without risking transient loops. Similarly, a
   failure of a protected link [IPFRR] [MPLSFRR] can be handled as a
   non-urgent failure.

 2.2 Overload status change

   The second change that we consider is the transition of the overload



Bonaventure/Francois/Previdi                                    [Page 2]


draft-bonaventure-isis-ordered-00.txt    February 2006


   from Set to Unset or from Unset to Set.

3. Extensions to IS-IS

   In this section, we describe the IS-IS extensions that are required
   to support ordered FIB updates that allow to avoid transient loops.
   There are two types of new TLVs. First, we define a capability sub-
   TLV to allow a router to advertise its ability to support ordered FIB
   updates. Second, we define a TLVs to be used inside the IS-IS Hello
   PDUs to implement the completion messages defined in [RTG-OFIB].

 3.1 Ordered FIB capability sub-TLV

   We define a FIB capability sub-TLV (advertised in the IS-IS
   CAPABILITY TLV defined in [ISIS-CAP] ) to allow routers to determine
   which routers in the network support the ordered FIB updates. The FIB
   capability sub-TLV is composed of 1 octet for the type, 1 octet
   specifying the TLV length and a value field. The FIB capability TLV
   is used to advertise the type of ordered FIB updates supported by
   this router. The FIB capability sub-TLV shall only be flooded inside
   the current area.

       TYPE: TBD (Ordered FIB capability sub-TLV)
       LENGTH: 1 byte
       VALUE: Indicates the version of the ordered FIB update supported
   by the router. This document defines version 1.

   This ordered FIB capability sub-TLV must be sent in a router
   capability TLV where the S bit is set to 0x0 and the D bit is set to
   0x0 according to the leaking rules defined in [ISISCAP].


 3.2 Completion message TLV

   We define a new type of TLV to encode inside the IS-IS Hello PDUs the
   completion messages proposed in [RTG-OFIB]. A IS-IS Hello PDU may
   carry several completion messages. Each completion message is encoded
   as a sub-TLV inside the completion message TLV.

       Type   TBD (Completion TLV)
       Length # of bytes in the value field (variable)
       Value : one or several sub-TLVs defined below

   This document defines three types of sub-TLVs for the completion
   messages.

 3.2.1 Metric change sub-TLV




Bonaventure/Francois/Previdi                                    [Page 3]


draft-bonaventure-isis-ordered-00.txt    February 2006


   The metric change sub-TLV shall be used as a completion message when
   the metric of a link changes. This happens when a metric is changed
   manually.  It is also possible to use the mechanisms defined in [RTG-
   OFIB] and this document for link failures. For example, when a link
   is shutdown manually, the router could first advertise the link with
   metric maxmetric-1 as a non-urgent change to let all routers apply
   the ordered FIB update. Later, the link can be safely removed without
   risking transient loops. A router could use the same technique when
   one of its protected links fails.

   We define two types of metric changes sub-TLV that are used inside
   the completion TLV. The first one is used with wide metrics and the
   second one with normal metrics. We expect that most deployments will
   use wide metrics.

   Type   TBD (Wide Metric change sub-TLV)
   Length # of bytes in the value field (21)
   Value
                                       No. of bytes
                +-----------------------+
                | 0  0  0  0 0 0 0 |Ack |     1
                +-----------------------+
                | Upstream Node Id      |     7
                +-----------------------+
                | Downstream Node Id    |     7
                +-----------------------+
                | Old metric            |     3
                +-----------------------+
                | New metric            |     3
                +-----------------------+
     Figure 1: New sub-TLV for (wide) metric change completion message

   In the Wide metric change sub-TLV, the rightmost bit of the first
   byte is used to indicate whether it corresponds to a completion
   message (value 0) or an acknowledgment (value 1).  The upstream and
   downstream node Ids are the system identifiers of the link whose
   metric changes. "Old metric" is the previous value of the wide metric
   for this link and "New metric" the current value.

   A similar sub-TLV is also defined for the normal metric. As current
   implementations of IS-IS only support the default metric, we do not
   consider changes in the delay, error or expense metrics.

   Type   TBD (Normal Metric change sub-TLV)
   Length # of bytes in the value field (17)
   Value
                                        No. of bytes
                +-----------------------+



Bonaventure/Francois/Previdi                                    [Page 4]


draft-bonaventure-isis-ordered-00.txt    February 2006


                | 0  0  0  0 0 0 0 |Ack |     1
                +-----------------------+
                | Upstream Node Id      |     7
                +-----------------------+
                | Downstream Node Id    |     7
                +-----------------------+
                | Old Default metric    |     1
                +-----------------------+
                | New Default metric    |     1
                +-----------------------+

    Figure 2: New sub-TLV for (normal) metric change completion message


   The Default metric shall be encoded as in normal LSPs.


 3.2.2 Overload change sub-TLV

   The overload change sub-TLV is used to encode the changes to the
   Overload Bit.

   Type   TBD (Overload change sub-TLV)
   Length # of octets in the value field (10)
   Value
                                      No. of bytes

                +-----------------------+
                |Old|New| 0 0 0 0 0 Ack |     1
                +-----------------------+
                | Node Id               |     7
                +-----------------------+

               Figure 3: New sub-TLV for Overload bit change

   The first octet contains three useful bits. The leftmost bit is the
   old value of the overload bit, the next bit is the new value of the
   overload bit and rightmost bit is the acknowledgment bit. The Node Id
   is the system identifier of the node whose overload bit change
   gracefully.

 3.3 Utilization of the completion messages

   The TLVs defined in sections 3.2 and 3.3 allow to implement the
   completion messages specified in [RTG-OFIB]. Each sub-TLV corresponds
   to a completion message for one topological change. The completion
   TLV in one HELLO PDU may carry several sub-TLVs and thus several
   completion messages. A router supporting the ordered FIB update



Bonaventure/Francois/Previdi                                    [Page 5]


draft-bonaventure-isis-ordered-00.txt    February 2006


   defined in this document SHOULD send HELLO PDUs containing the
   completion messages according to the rules defined in [RTG-OFIB].

   To ensure a reliable delivery of the completion messages, an
   acknowledgment scheme is used. Upon reception of a HELLO PDU
   containing a completion message (rightmost bit of the first byte set
   to 0 in the sub-TLV), a router MUST ensure that the next HELLO PDU
   that it will send to this neighbor will contain, in the completion
   TLV, the same sub-TLV but with the rightmost bit of the first byte
   set to one. This sub-TLV is used to acknowledge the completion
   message. A router MAY send a HELLO PDU immediately in response to a
   receive completion message or wait for the next scheduled Hello
   transmission. A router MAY retransmit the same completion message in
   several HELLO PDUs to ensure that they are correctly received by the
   neighbour.

5. Security considerations

   This document raises no new security issues for IS-IS. For the
   ordered FIB capability sub-TLV, the discussion in [ISISCAP] is
   applicable.  The authentication mechanisms defined in [RFC] can be
   used to authenticate the Hello PDUs that carry the completion
   messages if required.


6. IANA considerations

   IANA will assign a new IS-IS sub-TLV code-point for the order FIB
   capability sub-TLV that can appear inside the Router Capability TLV
   defined in [ISISCAP].

   IANA will assign a new IS-IS TLV code-point for the completion TLV.
   This TLV can only appear inside Hello PDUs.

   Name                                  Value  IIH   LSP  SNP
   ----------------------                -----  ---   ---  ---
   Completion messages TLV                TBD    y     n    n

   IANA will maintain a registry with the sub-TLVs defined for the
   completion messages TLV. This document defines three sub-TLVs :

   Name                                  Value
   ----------------------                -----
   Normal metric change sub-TLV           TBD
   Wide metric change sub-TLV             TBD
   Overload change sub-TLV                TBD





Bonaventure/Francois/Previdi                                    [Page 6]


draft-bonaventure-isis-ordered-00.txt    February 2006


7.   Conclusion

   In this document, we have proposed a set of IS-IS TLVs that allows
   routers using IS-IS to support the ordered FIB convergence
   and the completion messages proposed in [RTG-OFIB].

References

   [IS-IS]   "Intermediate system to Intermediate system 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.
   [IPFRR]   M. Shand, S. Bryant, IP Fast Reroute Framework,
             draft-ietf-rtgwg-ipfrr-framework-04.txt, October 2005
   [MPLSFRR] Pan, P. et al, "Fast Reroute Extensions to
             RSVP-TE for LSP Tunnels", RFC 4090.
   [PFOB05]  P. Francois, O. Bonaventure. Avoiding transient loops
             during IGP convergence. IEEE INFOCOM 2005, March 2005,
             Miami, Fl., USA
   [RTG-OFIB] P. Francois, O. Bonaventure, M. Shand, S. Previdi, S. Bryant,
           Loop-free convergence using ordered FIB updates, Internet draft,
           draft-francois-ordered-fib-00.txt, work in progress, February 2006
   [ISISCAP]  J.-P. Vasseur, S. Previdi, M. Shand, IS-IS extensions for
   advertising router capabilities, Internet draft,
   draft-vasseur-isis-caps-06.txt, February 2004, work in progress
   [RFC3567] T. Li, R. Atkinson, Intermediate System to Intermediate
   System (IS-IS), Cryptographic Authentication, July 2003, RFC3567


Authors Addresses

   Olivier Bonaventure, Pierre Francois
   Universite catholique de Louvain
   Email: FirstName.LastName@uclouvain.be
   URL  : http://www.info.ucl.ac.be/people/OBO/

   Stefano Previdi, Mike Shand
   Cisco Systems
   Email: {sprevidi,mshand}@cisco.com


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights



Bonaventure/Francois/Previdi                                    [Page 7]


draft-bonaventure-isis-ordered-00.txt    February 2006


   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.













Bonaventure/Francois/Previdi                                    [Page 8]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/