<?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. --> version='1.0' encoding='utf-8'?>

<!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 RFC3906 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3906.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.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 --> "rfc2629-xhtml.ent">

<rfc number="8687" xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true"
     docName="draft-ietf-ospf-xaf-te-07" ipr="trust200902" obsoletes=""
     submissionType="IETF" updates="5786" xml:lang="en">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" --> xml:lang="en" tocInclude="true"
     symRefs="true" sortRefs="true" version="3">

  <!-- ***** 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 abbrev="OSPF Routing with Cross-AF TE tunnels">OSPF Tunnels">OSPF Routing with
    Cross-Address Family Traffic Engineering Tunnels</title>

<seriesInfo name="RFC" value="8687" />

    <author fullname="Anton Smirnov" initials="A." surname="Smirnov">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>De Kleetlaan 6a</street>
          <city>Diegem</city>
          <region/>
          <code>1831</code>
          <country>Belgium</country>
        </postal>
        <email>as@cisco.com</email>
      </address>
    </author>
    <author fullname="Alvaro Retana" initials="A." surname="Retana">
      <organization>Futurewei Technologies, Inc.</organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <city>Santa Clara</city>
          <region>CA</region>
          <code>95050</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>alvaro.retana@futurewei.com</email>
      </address>
    </author>
    <author fullname="Michael Barnes" initials="M." surname="Barnes">
      <organization/>
      <address>
        <postal>
          <street/>
        </postal>
        <email>michael_barnes@usa.net</email>
      </address>
    </author>
    <date year=""/>

    <!-- Meta-data Declarations --> month="November" year="2019"/>

    <area>Routing</area>
    <workgroup>LSR</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>OSPF IPv4 IPv6 TE MPLS</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. -->

<keyword>OSPF</keyword>
<keyword>IPv4</keyword>
<keyword>IPv6</keyword>
<keyword>TE</keyword>
<keyword>MPLS</keyword>

    <abstract>
      <t>When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6
      network, the Multiprotocol Label Switching (MPLS) TE Label Switched
      Paths
      Path (LSP) infrastructure may be duplicated, even if the destination
      IPv4 and IPv6 addresses belong to the same remote router.

      In order to
      achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be
      computed over MPLS TE tunnels created using information propagated in
      another OSPF instance. This issue is solved by advertising cross-address
      family (X-AF) OSPF TE information.</t>

      <t>This document describes an update to RFC5786 RFC 5786 that allows for the easy
      identification of a router's local X-AF IP addresses.</t>

    </abstract>
  </front>
  <middle>
    <section title="Introduction" toc="default"> toc="default" numbered="true">
      <name>Introduction</name>
      <t>TE Extensions extensions to <xref target="RFC3630">OSPFv2</xref> target="RFC3630"
      format="default">OSPFv2</xref>
      and <xref
      target="RFC5329">OSPFv3</xref> target="RFC5329" format="default">OSPFv3</xref> have been
      described to support intra-area
      TE in IPv4 and IPv6 networks, respectively. In both cases, the TE
      database provides a tight coupling between the routed protocol and
      advertised TE signaling information. In other words, any use of the TE
      database is limited to IPv4 for <xref target="RFC2328"> target="RFC2328" format="default"> OSPFv2</xref>
      and IPv6 for <xref target="RFC5340">OSPFv3 target="RFC5340" format="default">OSPFv3 </xref>.</t>

      <t>In a dual stack dual-stack network, it may be desirable to set up common MPLS TE
      LSPs to carry traffic destined to addresses from different address
      families on a router. The use of common LSPs eases potential scalability
      and management concerns by halving the number of LSPs in the
      network.  Besides, it allows operators to group traffic based on
   business
      characteristics and/or applications or characteristics, class of service, and/or applications;
   the operators are not constrained by the network protocol used.</t> used.

      </t>

      <t>For example, an LSP created based on MPLS TE information propagated
      by an OSPFv2 instance can be used to transport both IPv4 and IPv6
      traffic, as opposed to using both OSPFv2 and OSPFv3 to provision a
      separate LSP for each address family. Even if if, in some cases cases, the address
      family-specific address-family-specific traffic is to be separated, calculation from a common TE
      database may prove to be operationally beneficial.</t>

      <t>During the SPF calculation on the TE tunnel
      head-end router, OSPF
      computes shortcut routes using TE tunnels. A commonly used algorithm for
      computing shortcuts is defined in <xref target="RFC3906"/>. target="RFC3906" format="default"/>. For that, that or
      any similar, similar algorithm to work with a common MPLS TE infrastructure in a
      dual-stack network, a requirement is to reliably map the X-AF addresses
      to the corresponding tail-end router. This mapping is a challenge
      because the LSAs Link State Advertisements (LSAs) containing the routing
      information are carried in one
      OSPF instance instance, while the TE calculations may be done using a TE database
      from a different OSPF instance.</t>

      <t>A simple solution to this problem is to rely on the Router ID to
      identify a node in the corresponding OSPFv2 and OSPFv3 link state
      databases Link State
      Databases (LSDBs). This solution would mandate both instances on the
      same router to be configured with the same Router ID. However, relying
      on the correctness of configuration puts additional burden and cost on
      the operation of the network. The network becomes even more difficult to
      manage if OSPFv2 and OSPFv3 topologies do not match exactly, for example example,
      if area borders are chosen differently in the two protocols. Also, if
      the routing processes do fall out of sync (e.g., having different Router
      IDs for local administrative reasons), there is no defined way for other
      routers to discover such misalignment and to take corrective measures
      (such as to avoid routing traffic through affected TE tunnels or
      alerting the network administrators). The use of misaligned Router IDs
      may result in delivering the traffic to the wrong tail-end router, which
      could lead to suboptimal routing or even traffic loops.</t>

      <t>This document describes an update to <xref target="RFC5786"/> target="RFC5786" format="default"/> that
      allows for the easy identification of a router's local X-AF IP
      addresses. <xref target="RFC5786"/> target="RFC5786" format="default"/> defined the Node IPv4 Local Address
      and Node IPv6 Local Address sub-TLVs of the Node Attribute TLV for a
      router to advertise additional local IPv4 and IPv6 addresses. However,
      <xref target="RFC5786"/> target="RFC5786" format="default"/> did not describe the advertisement and usage of
      these sub-TLVs when the address family of the advertised local address
      differed from the address family of the OSPF traffic engineering
      protocol.</t>

      <t>This document updates <xref target="RFC5786"/> target="RFC5786" format="default"/> so that a router can
      also announce one or more local X-AF addresses using the corresponding
      Local Address sub-TLV. Routers using the <xref target="RFC5786">Node target="RFC5786" format="default">Node
      Attribute TLV</xref> can include non-TE enabled non-TE-enabled interface addresses in
      their OSPF TE advertisements, advertisements and also use the same sub-TLVs to carry
      X-AF information, facilitating the mapping described above.</t>

      <t>The method specified in this document can also be used to compute the
      X-AF mapping of the egress Label Switching Router (LSR) for sub-LSPs of
      a Point-to-Multipoint LSP <xref target="RFC4461"/>. target="RFC4461" format="default"/>. Considerations of
      using Point-to-Multipoint MPLS TE for X-AF traffic forwarding is outside
      the scope of this document.</t>
    </section>
    <section title="Requirements Language" toc="default">
      <t>The toc="default" numbered="true">
      <name>Requirements Language</name>

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
      "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 BCP&nbsp;14 <xref format="default" pageno="false" target="RFC2119"/>
    <xref
      format="default" pageno="false" target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t> here.
        </t>

    </section>
    <section title="Operation" toc="default"> toc="default" numbered="true">
      <name>Operation</name>
      <t>To implement the X-AF routing technique described in this document,
      OSPFv2 will advertise the Node IPv6 Local Address sub-TLV and OSPFv3
      will advertise the Node IPv4 Local Address sub-TLV, possibly in addition
      to advertising other IP addresses as documented by <xref
      target="RFC5786"/>.</t> target="RFC5786" format="default"/>.</t>
      <t>Multiple instances of OSPFv3 are needed if it is used for both IPv4
      and IPv6 <xref target="RFC5838"/>. target="RFC5838" format="default"/>. The operation in this section is
      described with OSPFv2 as the protocol used for IPv4; that is the most
      common case. The case of OSPFv3 being used for IPv4 follows the same
      procedure as what is indicated for OSPFv2 below.</t>

      <t>On a node that implements X-AF routing, each OSPF instance
      advertises, using the Node Local Address sub-TLV, all X-AF IPv6 (for
      OSPFv2 instance) or IPv4 (for OSPFv3) addresses local to the router that
      can be used by the Constrained SPF Shortest Path First (CSPF) to calculate MPLS TE LSPs: <list
          hangIndent="10" style="empty">
          <t>OSPF </t>

      <ul spacing="normal">
        <li>The OSPF instance MUST <bcp14>MUST</bcp14> advertise the IP address listed in the Router
          Address TLV <xref target="RFC3630"/>, target="RFC3630" format="default"/> <xref target="RFC5329"/> target="RFC5329" format="default"/> of
          the X-AF instance maintaining the TE database.</t>

          <t>OSPF database.</li>
        <li>The OSPF instance SHOULD <bcp14>SHOULD</bcp14> include additional local addresses
          advertised by the X-AF OSPF instance in its Node Local Address
          sub-TLVs.</t>

          <t>An
          sub-TLVs.</li>
        <li>An implementation MAY <bcp14>MAY</bcp14> advertise other local X-AF addresses.</t>
        </list></t> addresses.</li>
      </ul>

      <t>When TE information is advertised in an OSPF instance instance, both natively
      (i.e.
      (i.e., as per RFC <xref target="RFC3630"/> target="RFC3630" format="default"/> or <xref target="RFC5329"/>) target="RFC5329" format="default"/>)
      and as XAF X-AF Node Attribute TLV TLV, it is left to local configuration to
      determine which TE database is used to compute routes for the OSPF
      instance.</t>
      <t>On Area Border Routers (ABR), (ABRs), each advertised X-AF IP address MUST <bcp14>MUST</bcp14> be
      advertised into into, at most most, one area. If OSPFv2 and OSPFv3 area border
      routers ABRs coincide
      (i.e., the areas for all OSPFv2 and OSPFv3 interfaces
      are the same), then the X-AF addresses MUST <bcp14>MUST</bcp14> be advertised into the same
      area in both instances. This allows other ABRs connected to the same set
      of areas to know with which area to associate computed MPLS TE
      tunnels.</t>
      <t>During the X-AF routing calculation, X-AF IP addresses are used to
      map locally created LSPs to tail-end routers in the Link State Database
      (LSDB).
      LSDB. The mapping algorithm can be described as: <list hangIndent="10"
          style="empty">
          <t>Walk </t>

      <ul empty="true" spacing="normal">
        <li>Walk the list of all MPLS TE tunnels for which the computing
          router is a head-end. head end. For each MPLS TE tunnel T:</t>
        </list> <list style="numbers">
          <t>If T:</li>
 <li>
      <ol spacing="normal" type="1">
        <li>If T's destination address is from the same address family as the
          OSPF instance associated with the LSDB, then the extensions defined
          in this document do not apply.</t>

          <t>Otherwise apply.</li>
        <li>Otherwise, it is a X-AF MPLS TE tunnel. Note the tunnel's destination
          IP address.</t>

          <t>Walk address.</li>
        <li>Walk the X-AF IP addresses in the LSDBs of all connected areas.
          If a matching IP address is found, advertised by router R in area A,
          then mark the tunnel T as belonging to area A and terminating on
          tail-end router R. Assign the intra-area SPF cost to reach router R
          within area A as the IGP cost of tunnel T.</t>
        </list></t> T.</li>
      </ol>
 </li>
      </ul>

      <t>After completing this calculation, each TE tunnel is associated with
      an area and tail-end router in terms of the routing LSDB of the
      computing OSPF instance and has a cost.</t>
      <t>The algorithm described above is to be used only if the Node Local
      Address sub-TLV include includes X-AF information.</t>

     <t>Note that that, for clarity of description description, the mapping algorithm is
     specified as a single calculation. Actual implementations for the
      efficiency  Implementations may choose to support equivalent mapping
     functionality without implementing the algorithm exactly as it is described.</t>

      <t>As an example, consider a router in a dual-stack network respectively
      using OSPFv2 and OSPFv3 for IPv4 and IPv6 routing. routing, respectively. Suppose the OSPFv2
      instance is used to propagate MPLS TE information and the router is
      configured to accept TE LSPs terminating at local addresses 198.51.100.1
      and 198.51.100.2. The router advertises in OSPFv2 the IPv4 address
      198.51.100.1 in the Router Address TLV, the additional local IPv4
      address 198.51.100.2 in the Node IPv4 Local Address sub-TLV, and other
      Traffic Engineering
      TE TLVs as required by <xref target="RFC3630"/>. target="RFC3630" format="default"/>. If the
      OSPFv3 instance in the network is enabled for X-AF TE routing (that is,
      to use MPLS TE LSPs computed by OSPFv2 for IPv6 routing), then the
      OSPFv3 instance of the router will advertise the Node IPv4 Local Address
      sub-TLV listing the local IPv4 addresses 198.51.100.1 and 198.51.100.2.
      Other routers in the OSPFv3 network will use this information to
      reliably identify this router as the egress LSR for MPLS TE LSPs
      terminating at either 198.51.100.1 or 198.51.100.2.</t>
    </section>

    <section title="Backward Compatibility" toc="default"> toc="default" numbered="true">
      <name>Backward Compatibility</name>
      <t>Only routers that serve as endpoints for one or more TE tunnels MUST <bcp14>MUST</bcp14>
      be upgraded to support the procedures described herein: <list
          style="symbols">
          <t>Tunnel tailend </t>
      <ul spacing="normal">
        <li>Tunnel tail-end routers advertise the Node IPv4 Local Address
          sub-TLV and/or the Node IPv6 Local Address sub-TLV.</t>

          <t>Tunnel headend sub-TLV.</li>
        <li>Tunnel head-end routers perform the X-AF routing calculation.</t>
        </list> calculation.</li>
      </ul>
      <t> Both the endpoints MUST <bcp14>MUST</bcp14> be upgraded before the tailend tail end starts
      advertising the X-AF information. Other routers in the network do not
      need to support X-AF procedures.</t>

      <section title="Automatically numbered="true" toc="default">
        <name>Automatically Switched Optical Networks"> Networks</name>
        <t><xref target="RFC6827"/> target="RFC6827" format="default"/> updates
        <xref target="RFC5786"/> target="RFC5786" format="default"/> by
        defining extensions to be used in an Automatically Switched Optical
        Network (ASON). The Local TE Router ID Sub-TLV sub-TLV is required for
        determining ASON reachability. The implication is that if the Local TE
        Router ID Sub-TLV sub-TLV is present in the Node Attribute TLV, then the
        procedures in <xref target="RFC6827"/> target="RFC6827" format="default"/> apply, regardless of whether
        any X-AF information is advertised.</t>
      </section>
    </section>

    <section title="Security Considerations" toc="default"> toc="default" numbered="true">
      <name>Security Considerations</name>
      <t>This document describes the use of the Local Address sub-TLVs to
      provide X-AF information. The advertisement of these sub-TLVs, in any
      OSPF instance, is not precluded by <xref target="RFC5786"/>. target="RFC5786" format="default"/>. As such, no
      new security threats are introduced beyond the considerations in <xref
      target="RFC2328">OSPFv2</xref>, target="RFC2328" format="default">OSPFv2</xref>, <xref target="RFC5340">OSPFv3</xref>, target="RFC5340" format="default">OSPFv3</xref>,
      and <xref target="RFC5786"/>.</t> target="RFC5786" format="default"/>.</t>

      <t>The X-AF information is not used for SPF computation or normal
      routing, so the mechanism specified here has no effect on IP routing.
      However, generating incorrect information, information or tampering with the
      sub-TLVs may have an effect on traffic engineering computations.
      Specifically, TE traffic may be delivered to the wrong tail-end router,
      which could lead to suboptimal routing, traffic loops, or even expose exposing
      the traffic to attacker inspection or modification. These threats are
      already present in other TE-related specifications, and their
      considerations apply here as well, including <xref target="RFC3630"/> target="RFC3630" format="default"/>
      and <xref target="RFC5329"/>.</t> target="RFC5329" format="default"/>.</t>
    </section>
    <section title="IANA Considerations" toc="default"> toc="default" numbered="true">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->
  <back>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml"/>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5329.xml"/>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5786.xml"/>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

      </references>

      <references>
        <name>Informative References</name>
<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"/>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3906.xml"/>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4461.xml"/>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5838.xml"/>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6827.xml"/>

</references>
    </references>
 <section title="Acknowledgements" toc="default"> anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Peter Psenak and Eric Osborne for
      early discussions and Acee Lindem for discussing compatibility with ASON
      extensions. Also, Eric Vyncke, Ben Kaduk Kaduk, and Roman Danyliw provided
      useful comments. </t>
      <t>We would also like to thank the authors of RFC5786 RFC 5786 for laying down
      the foundation for this work.</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"?-->

      <?rfc include="reference.RFC.2119.xml"?>

      <?rfc include="reference.RFC.3630.xml"?>

      <?rfc include="reference.RFC.5329.xml"?>

      <?rfc include="reference.RFC.5786.xml"?>

      <?rfc include="reference.RFC.8174.xml"?>
    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

      <?rfc include="reference.RFC.2328.xml"?>

      <?rfc include="reference.RFC.5838.xml"?>

      <?rfc include="reference.RFC.3906.xml"?>

      <?rfc include="reference.RFC.4461.xml"?>

      <?rfc include="reference.RFC.5340.xml"?>

      <?rfc include="reference.RFC.6827.xml"?>
    </references>

  </back>
</rfc>