<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced. 
    An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?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="4"?>
<!-- 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 list of popular I-D processing instructions -->
<rfc category="std" docName="draft-shishio-ospf-ospfv3-stub-03" ipr="trust200902" updates="3137">
 <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    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>OSPFv3 Stub Router Advertisement</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Shishio Tsuchiya" initials="S.T." role="editor"
            surname="Tsuchiya">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>Shinjuku Mitsui Building, 2-1-1, Nishi-Shinjuku</street>
          <city>Shinjuku-Ku</city>
          <region>Tokyo</region>
          <code>163-0409</code>
          <country>Japan</country>
        </postal>
        <phone>+81 3 6434 6543</phone>
        <email>shtsuchi@cisco.com</email>
      </address>
    </author>

    <author fullname="Gunter Van de Velde" initials="G.V" surname="Van de Velde">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>Pegasus Parc</street>
          <city>De kleetlaan 6a</city>
          <region>DIEGEM,</region>
          <code>BRABANT 1831</code>
          <country>BELGIUM</country>
        </postal>
        <phone>+32 2 704 5473</phone>
        <email>gunter@cisco.com</email>
      </address>
    </author>

    <author fullname="Tomohiro Yamagata" initials="T.Y." surname="Yamagata">
      <organization>KDDI Corporation</organization>
      <address>
        <postal>
          <street>Garden Air Tower,3-10-10, Iidabashi</street>
          <city>Chiyoda-Ku</city>
          <region>Tokyo</region>
          <code>102-8460</code>
          <country>Japan</country>
        </postal>
        <phone>+81 3 6678 3089</phone>
        <email>to-yamagata@kddi.com</email>
      </address>
    </author>

    <date month="January" year="2011" />

    <!-- 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>ospf</area>

    <workgroup>Internet Engineering Task Force</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. -->

    <keyword>template</keyword>

    <!-- 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>OSPFv3 accommodates for the possibility to indicate 
      through the R-bit if a router is an active router and should be taken 
      into consideration as a transit device. Another method available is 
      the v6-bit indicating if a router or link should be excluded from IPv6
      routing calculations.         
      </t>

      <t>A direct result is that OSPFv3 has "no transit capability" potentially 
      based upon the setting of R-bit and V6-bit, unlike the stub OSPFv2 router 
      functionality. This feature proposal has as purpose to re-introduce 
      existing OSPFv2 stub router behavior into OSPFv3 to keep the operational 
      service provider experience used to deploy, troubleshoot and be familiar 
      with OSPFv2 stub routing.
      </t>

      <t>OSPFv3 has similar metric field information field of all of LSAs, with exception 
      of the Link-LSA, so RFC3137 method can be re-utilized in OSPFv3.
      </t>

      <t>To drive consistency between OSPFv2 and OSPFv3, there should be next to 
      supporting both R-bit and v6-bit be support for"max-metric".</t>

    </abstract>
  </front>

  <middle>
    <section title="Motivation">
      <t><xref target="RFC3137"> OSPF Stub Router Advertisement</xref> 
      describes a set of situations when the Service provider has a desire to utilize 
      this functionality.</t>

      <t><list style="symbols">
          <t>The router is in a critical condition  resulting in either a very high
          CPU load, or not enough memory to store all LSAs, or doesn't succeed to 
          build the routing table
          </t>

          <t>Graceful introduction or removal of a router to or from the
          network
          </t>

          <t>Other (administrative or traffic engineering) reasons
          </t>

        </list>
       </t>

      <t>Even if the network will be moved or migrated towards from IPv4 in combination with OSPFv2 
      towards IPv6 using OSPFv3 <xref target="OSPFv3"></xref> technology, it remains important 
      that the operational behaviour remains similar between routing protocols.
      </t>
    </section>

    <section 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">RFC 2119</xref>.</t>
    </section>

    <section title="OSPFv2 operation">
      <t><xref target="RFC3137">RFC3137</xref> describes in section 2 in detail the behavior of link cost 
      metrics. i.e. Router X announces its Router LSA to the neighbor with costs of all non-stub links 
      which are set to LSInfinity(0xFFFF), while stub links are announced with interface cost.</t>

      <t>Often the operator will check interface metric of ospf database assuming he would like to confirm whether the router is announcing LSInfinity.</t>

      <t>Many service provider operators are using OSPF stub router advertisement <xref target="RFC3137"></xref> for 
      OSPFv2 <xref target="OSPFv2"></xref>. This feature is supported by majority of OSPFv2 implementations.
      Use cases are below;
      </t>

      <section title="Wait for BGP during booting">
        <figure align="center" anchor="fig1">
          <preamble></preamble>

          <artwork align="left">
            |R1|--|R2|---|R4|---internet
             |             |
             +----|R3|-----+
        </artwork>

          <postamble></postamble>
        </figure>

        <t>In this example R2 can be assumed it is the best path towards the Internet from R1. 
        When R2 reloads it would result that R3 would be best path for going towards
        Internet. From the moment R2 is reloaded and OSPF has converged, there may be a 
        situation when BGP is still not converged to the full. If in this situation R1 should not send 
        traffic towards R2 just yet. R2 should send LSInfinity(0xFFFF) to indicate that R1 should wait 
        for R2's BGP converge. Once BGP is fully converged, R2 LSA's out with correct interface metric 
        value in OSPFv2 area which will result in R2 being reintroduced as the primary path.
        </t>
      </section>

      <section title="LDP Synchronization">
        <figure align="center" anchor="fig2">
          <preamble></preamble>

          <artwork align="left">
            |R1|--|R2|---|R4|
             |            |
             +----|R3|----+
            </artwork>

          <postamble></postamble>
        </figure>

        <t>Assume that from R1 the best path to R4 is via R2 in this MPLS network. When R2 is 
        reloaded, then R3 is the only and hence also the best path. At some point in time R2 is 
        fully successfully reloaded resulting that OSPF has converged also. This does not 
        necessary mean LDP has fully converged either. In this situation R1 should not send traffic to R2 
        immediately. In that case R2 could send LSInfinity(0xFFFF) resulting in a situation where R1
        must wait for R2 to be fully be available and transit states have been passed. From the moment LDP 
        converged on R2, it can distribute the traditional Interface OSPF metric value. This operation 
        will result that OSPF and LDP have a converged behaviour. The importance and the description of this behaviour can be found in <xref target="LDP-Sync"></xref>.</t>
      </section>

      <section title="Configuration change">
        <figure align="center" anchor="fig3">
          <preamble></preamble>

          <artwork align="left">
           |R1|--|R2|---|R4|
            |             |
            +----|R3|-----+
           </artwork>

          <postamble></postamble>
        </figure>

        <t>When operator needs R2 configuration change,R2 sends
        LSInfinity(0xFFFF) for traffic engineering. R2 configuration
        completed,R2 sends correct metric value in OSPFv2 area.</t>
      </section>
    </section>

    <section title="OSPFv3 operation">
      <section title="R-bit and v6-bit">
        <t><xref target="OSPFv3"></xref> explains at section 2.7 the following: If 
        the "R-bit" is clear, an OSPF speaker can participate in OSPF topology distribution without being
        used to forward transit traffic. The V6-bit specializes the R-bit; if
        the V6-bit is clear, an OSPF speaker can participate in OSPF topology
        distribution without being used to forward IPv6 datagrams. If the
        R-bit is set and the V6-bit is clear, IPv6 datagrams are not forwarded
        but datagrams belonging to another protocol family may be
        forwarded.</t>

        <t>This protocol implementation is useful in multi address family
        environment such as <xref target="OSPFv3-AF"></xref>. But Service Provider operators 
        have to check both the "R-bit" and "v6-bit" during their operation and introduce both training 
        and operational changes to make this a true usable technology. Operators have believe that a 
        useful approach would be to rely upon successful IPv4 OSPFv2 behaviour and to add a "OSPFv2 compatibility mode" in IPv6 only environment to mimic OSPFv2 behavior in this environment.
        </t>

       <t>The functionality of the R-bit and v6-bit operations is described in <xref target="OSPFv3"></xref>'s Errata 2078 more detail.
       </t>

       <t>A Router should support a "R-bit" know with a clear wait for BGP or waiting-before-becoming-active time on start-up 
       same as <xref target="RFC3137"></xref> indicates.</t>
      </section>

      <section title="OSPFv2 compatibility mode">
        <t>An OSPFv3 routing device has through the area scope LSAs metric information of all of devices.
        As result the router can announce the interface metric LSInfinity(0xFFFF). This is simple
        implementation model not requiring operational service provider changes.</t>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This document is based on <xref target="RFC3137">RFC3137</xref> and <xref target="OSPFv3">RFC5340</xref>Errata 2078.
<xref target="RFC3137">RFC3137</xref> done by Alvaro Retana,Liem Nguyen,Russ White,Alex Zinin and Danny McPherson.
<xref target="OSPFv3">RFC5340</xref> done by Rob Coltun,Dennis Ferguson,John Moy and Acee Lindem.
Balaji Ganesh  pointed out problem of Section 4.8.1<xref target="OSPFv3">RFC5340</xref>on Errata 2046.
Michael Barnes brought up the fact,Acee Lindem reported on Errata 2078.
Tsuyoshi Momose advised us about how to write internet-draft.
Fred Baker was reviewed this document in initial stage.
Cisco OSPF coder's are gave comments about this document.
Especially Peter Psenak did deep discussion about both modes.
Michael Barnes pointed out Errata 2078 exists.
The authors would like to thank all of them for their activity,comments and help.
 </t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This document has no actions for IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The technique described in this document does not introduce any new
      security issues into OSPFv3 protocol.</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 title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->

      &RFC2119;
     <reference anchor="OSPFv2" target="http://tools.ietf.org/html/rfc2328">
        <front>
          <title>"OSPF Version 2"</title>
          <author initials="J." surname="Moy">
            <organization></organization>
          </author>
          <date month="April" year="1998" />
        </front>
        <seriesInfo name='RFC' value='2328' />
        <seriesInfo name='STD' value='54' />
      </reference>

   <reference anchor="OSPFv3" target="http://tools.ietf.org/html/rfc5340">
        <front>
          <title>"OSPF for IPv6"</title>
          <author initials="R." surname="Coltun">
          <organization></organization>
          </author>
          <author initials="D." surname="Ferguson">
          <organization></organization>
          </author> 
          <author initials="J." surname="Moy">
          <organization></organization>
          </author>
          <author initials="A." surname="Lindem">
          <organization></organization> 
          </author>
         
          <date month="July" year="2008" />
        </front>
       <seriesInfo name='RFC' value='5340' />
      </reference>

      <reference anchor="OSPFv3-AF" target="http://tools.ietf.org/html/rfc5838">        <front>
          <title>"Support of Address Families in OSPFv3"</title>
        <author initials="A." surname="Lindem">
        <organization></organization>  
        </author>
        <author initials="S." surname="Mirtorabi">
        <organization></organization>  
        </author>
       <author initials="A." surname="Roy">
          </author>
       <author initials="M." surname="Barnes">
        <organization></organization>  
        </author>
       <author initials="R." surname="Aggarwal">
         <organization></organization> 
         </author>
          <date month="Apri" year="2010" />
        </front>
       <seriesInfo name='RFC' value='5838' />
      </reference>
     </references>


<references title="Informative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->

 <reference anchor="RFC3137" target="http://tools.ietf.org/html/rfc3137">
        <front>
          <title>"OSPF Stub Router Advertisement"</title>
        <author initials="A." surname="Retana">
        <organization></organization> 
         </author>
        <author initials="L." surname="Nguyen">
        <organization></organization> 
         </author>
        <author initials="R." surname="White">
        <organization></organization>  
        </author>
        <author initials="A." surname="Zinin">
        <organization></organization>  
        </author>
        <author initials="D." surname="McPherson">
        <organization></organization>  
        </author>
      
         <date month="June" year=" 2001" />
        </front>
 <seriesInfo name='RFC' value='3137' />
      </reference>

     
      <reference anchor="LDP-Sync" target="http://tools.ietf.org/html/rfc5443">
        <front>
          <title>"LDP IGP Synchronization"</title>
          <author initials="M." surname="Jork">
          <organization></organization>
          </author>

          <author initials="A." surname="Atlas">
         <organization></organization>
          </author>
         <author initials="L." surname="Fang">
         <organization></organization>
          </author>

         <date month="March" year="2009" />
        </front>
 <seriesInfo name='RFC' value='5443' />
      </reference>
</references>


    <section anchor="app-additional" title="Additional Stuff">
      <t>This becomes an Appendix.</t>
    </section>

    <!-- Change Log

v00 2006-03-15  EBD   Initial version

v01 2006-04-03  EBD   Moved PI location back to position 1 -
                      v3.1 of XMLmind is better with them at this location.
v02 2007-03-07  AH    removed extraneous nested_list attribute,
                      other minor corrections
v03 2007-03-09  EBD   Added comments on null IANA sections and fixed heading capitalization.
                      Modified comments around figure to reflect non-implementation of
                      figure indent control.  Put in reference using anchor="DOMINATION".
                      Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH     Major changes: shortened discussion of PIs,
                      added discussion of rfc include.
v05 2007-03-10 EBD    Added preamble to C program example to tell about ABNF and alternative 
                      images. Removed meta-characters from comments (causes problems).  -->
  </back>
</rfc>
