<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1195 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1195.xml">

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2966 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2966.xml">

<!ENTITY RFC5302 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5302.xml">
<!ENTITY RFC5305 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml">
<!ENTITY RFC5308 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5308.xml">
<!ENTITY RFC5120 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5120.xml">

]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC): -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references: -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space: 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of popular PIs -->
<rfc category="info" docName="draft-litkowski-isis-ip-route-preference-issue-00"
     ipr="trust200902">
  <front>
    <title abbrev="isis-route-pref-pb">IP Route preference specification issue</title>

    <author fullname="Stephane Litkowski" initials="S" surname="Litkowski">
      <organization>Orange Business Service</organization>

      <address>
        <!-- postal><street/><city/><region/><code/><country/></postal -->

        <!-- <phone/> -->

        <!-- <facsimile/> -->

        <email>stephane.litkowski@orange.com</email>

        <!-- <uri/> -->
      </address>
    </author>

   
    <date year="2014"/>

    <area/>

    <workgroup>ISIS Working Group</workgroup>

    <!-- <keyword/> -->

    <!-- <keyword/> -->

    <!-- <keyword/> -->

    <!-- <keyword/> -->

    <abstract>
      <t>This document details a potential specification issue in IP route preference in ISIS.
	  As a consequence, some implementations does not interoperate correctly and leads to routing loops.
	  Authors tries to analyse if we need to fix current specification.
	  </t>
	</abstract>
	
	<note title="Requirements Language">
      <t>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 <xref
      target="RFC2119"/>.</t>
  </note>
  
  </front>

  <middle>
    <section anchor="introduction" title="Problem statement">
	<figure>
	<artwork>
        L2       L2       L2     L2|L2      L2	               
 10/8 - R0 ----- R1 ----- R2 ----- R3 ----- R4 ---- 10/8
                                   |
                Figure 1
	</artwork>
	</figure>
	<t>
	Considering the figure 1, both R0 and R4 are advertising the prefix 10/8.
	Two ISIS L2 process are running on R3 to separate network.
	R3 is performing route-leaking and advertise prefix from R4 to the other L2 process.
	The network is using extended metrics (TLV135 defined in <xref target="RFC5305"/>).
	Considering that R0 is advertising 10/8 with metric 2000 and R3 with metric 100, 
	and all the links have a metric of 1. When advertising route in L2, R3 set the down bit,
	according to <xref target="RFC5305"/>.
	</t>
	<t>
	During interoperability testings, authors observed some routing loops in this scenario.
	</t>
	<t>
	R1, R2 and R3 are from three different vendors (R1->Vendor1, R2->Vendor2, R3->Vendor3).
	<list style="symbols">
	<t>R2 has two possible paths to reach 10/8, L2 up route with metric 2002 (from R0), and L2 down route with metric 101 (from R3). 
	R2 selects R1 as nexthop to 10/8 because it is an Up route.</t>
	<t>R3 has two possible paths to reach 10/8, L2 up route with metric 2002 from R1, L2 up metric 101 from R4. R3 selects R4 as nexthop due to lowest metric.</t>
	<t>R1 has two possible paths to reach 10/8, L2 up route with metric 2001 from R0, L2 down metric 102 from R2. R1 selects R2 as nexthop due to lowest metric.</t>
	</list>
	</t>
	<t>When R1 or R2 try to send traffic to 10/8, packets are looping due to inconsistent routing decision between R1 and R2.</t>
	</section>
	
	<section anchor="spec" title="Specification analysis">
	<t>
	<xref target="RFC5305"/> defines IP extended reachability (TLV135), it also defines the notion of "Up/Down bit" that did not exist in 
	<xref target="RFC1195"/> :
	</t>
	<figure>
	<artwork>
  "The existing IP reachability TLVs (TLV type 128 and TLV type 130,
   defined in [RFC1195]) carry IP prefixes in a format that is analogous
   to the IS neighbor TLV from ISO 10589 [ISO-10589].  They carry four
   metrics, of which only the default metric is commonly used.  The
   default metric has a possible range of 0-63.  We would like to remove
   this restriction.

   In addition, route redistribution (a.k.a. route leaking) has a key
   problem that was not fully addressed by the existing IP reachability
   TLVs.  [RFC1195] allows a router to advertise prefixes upwards in the
   level hierarchy.  Unfortunately, there were no mechanisms defined to
   advertise prefixes downwards in the level hierarchy.

   To address these two issues, the proposed extended IP reachability
   TLV provides for a 32-bit metric and adds one bit to indicate that a
   prefix has been redistributed 'down' in the hierarchy."
	</artwork>
	</figure>
	
	<t>
	<xref target="RFC5305"/> does not provide any rule for taking into account up/down bit
	in route preference.
	</t>
	<t>
	<xref target="RFC5302"/> replaces <xref target="RFC2966"/> and defines extension to support
	optimal routing in multi-level environment. It especially defines up/down bit for IP prefix semantics
	defined in <xref target="RFC1195"/> (aka TLV 128,TLV130). Section 3.2 of <xref target="RFC5302"/> clearly 
	specifies the order of preference between IP route types in ISIS.
	
	<figure>
	<artwork>
	
   "Based on these assumptions, this document defines the following route
   preferences.

   1.  L1 intra-area routes with internal metric; L1 external routes
       with internal metric

   2.  L2 intra-area routes with internal metric; L2 external routes
       with internal metric; L1->L2 inter-area routes with internal
       metric; L1->L2 inter-area external routes with internal metric

   3.  L2->L1 inter-area routes with internal metric; L2->L1 inter-area
       external routes with internal metric

   4.  L1 external routes with external metric

   5.  L2 external routes with external metric; L1->L2 inter-area
       external routes with external metric

   6.  L2->L1 inter-area external routes with external metric"
   	</artwork>
	</figure>
	
	It is quite clear that for IP Reachability defined in <xref target="RFC1195"/>, up routes are prefered over down routes.
	It sounds that <xref target="RFC5302"/> does not apply to TLV defined in <xref target="RFC5305"/> : section 5 of <xref target="RFC5302"/>
	describes <xref target="RFC5305"/> as another proposal to deal with the issues described.
	</t>	
	</section>
	
	<section anchor="spec-other" title="IPv6 and MT extensions cases">
	<t>
	<xref target="RFC5308"/> defines IPv6 Reachability extension for ISIS (TLV 236). Section 5 of the RFC
	clearly defines the order of preference between route types :
	<figure>
	<artwork>
	"The order of preference between paths for a given prefix MUST be
   modified to consider the up/down bit.  The new order of preference is
   as follows (from best to worst).

      1.  Level 1 up prefix

      2.  Level 2 up prefix

      3.  Level 2 down prefix

      4.  Level 1 down prefix

   If multiple paths have the same best preference, then selection
   occurs based on metric.  Any remaining multiple paths SHOULD be
   considered for equal-cost multi-path routing if the router supports
   this; otherwise, the router can select any one of the multiple paths."
	</artwork>
	</figure>
	
	</t>
	<t>
	<xref target="RFC5120"/> defines Multitopology extension for ISIS and new IPv4 and IPv6 reachability TLVs (TLV 235 and 237). 
	No guideline are provided in this RFC for route type preference but as MT extensions are based on basic TLVs (135 and 236), we expect
	the same behavior as for the associated TLVs.
	</t>
	</section>
	
	<section anchor="enhance" title="Enhancing the RFC5305">
	<t>
	<xref target="RFC5305"/> lacks of text regarding order of route preference compared to <xref target="RFC5308"/> and <xref target="RFC5302"/>.
	<xref target="RFC5302"/> does not seem to apply to TLV135 defined in <xref target="RFC5305"/>.
	As <xref target="RFC5302"/> and <xref target="RFC5308"/> are already aligned in term of behavior, authors propose to enhance <xref target="RFC5305"/>
	with a clear text stating the route preference order with the same behavior described in the two other specifications.
	</t>
	</section>
	
	<section anchor="Security" title="Security Considerations">
	<t>
	There is no security consideration.
	</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
	<t>

	</t>
	</section>

    <section anchor="IANA" title="IANA Considerations">
     <t>
	 There is no IANA consideration.
	 </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC1195;
	  &RFC2119;
	  &RFC2966;
	  &RFC5302;
	  &RFC5305;
	  &RFC5308;
	  &RFC5120;
    </references>

  </back>
</rfc>
