rfc8687xml2.original.xml   rfc8687.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!-- 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 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.o
rg/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 -->
<rfc category="std" 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)" -->
<!-- ***** FRONT MATTER ***** --> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<front> <rfc number="8687" xmlns:xi="http://www.w3.org/2001/XInclude" category="std" con
<!-- The abbreviated title is used in the page header - it is only necessary sensus="true"
if the docName="draft-ietf-ospf-xaf-te-07" ipr="trust200902" obsoletes=""
full title is longer than 39 characters --> submissionType="IETF" updates="5786" xml:lang="en" tocInclude="true"
symRefs="true" sortRefs="true" version="3">
<title abbrev="OSPF Routing with Cross-AF TE tunnels">OSPF Routing with <!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="OSPF Routing with Cross-AF TE Tunnels">OSPF Routing with
Cross-Address Family Traffic Engineering Tunnels</title> Cross-Address Family Traffic Engineering Tunnels</title>
<seriesInfo name="RFC" value="8687" />
<author fullname="Anton Smirnov" initials="A." surname="Smirnov"> <author fullname="Anton Smirnov" initials="A." surname="Smirnov">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>De Kleetlaan 6a</street> <street>De Kleetlaan 6a</street>
<city>Diegem</city> <city>Diegem</city>
<region/> <region/>
<code>1831</code> <code>1831</code>
<country>Belgium</country> <country>Belgium</country>
</postal> </postal>
<email>as@cisco.com</email> <email>as@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Alvaro Retana" initials="A." surname="Retana"> <author fullname="Alvaro Retana" initials="A." surname="Retana">
<organization>Futurewei Technologies, Inc.</organization> <organization>Futurewei Technologies, Inc.</organization>
<address> <address>
<postal> <postal>
<street>2330 Central Expressway</street> <street>2330 Central Expressway</street>
<city>Santa Clara</city> <city>Santa Clara</city>
<region>CA</region> <region>CA</region>
<code>95050</code> <code>95050</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>alvaro.retana@futurewei.com</email> <email>alvaro.retana@futurewei.com</email>
</address> </address>
</author> </author>
<author fullname="Michael Barnes" initials="M." surname="Barnes"> <author fullname="Michael Barnes" initials="M." surname="Barnes">
<organization/> <organization/>
<address> <address>
<postal> <postal>
<street/> <street/>
</postal> </postal>
<email>michael_barnes@usa.net</email> <email>michael_barnes@usa.net</email>
</address> </address>
</author> </author>
<date month="November" year="2019"/>
<date year=""/>
<!-- Meta-data Declarations -->
<area>Routing</area> <area>Routing</area>
<workgroup>LSR</workgroup> <workgroup>LSR</workgroup>
<!-- WG name at the upperleft corner of the doc, <keyword>OSPF</keyword>
IETF is fine for individual submissions. <keyword>IPv4</keyword>
If this element is not present, the default is "Network Working Group", <keyword>IPv6</keyword>
which is used by the RFC Editor as a nod to the history of the IETF. -- <keyword>TE</keyword>
> <keyword>MPLS</keyword>
<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. -->
<abstract> <abstract>
<t>When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 <t>When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6
network, the Multiprotocol Label Switching (MPLS) TE Label Switched network, the Multiprotocol Label Switching (MPLS) TE Label Switched
Paths (LSP) infrastructure may be duplicated, even if the destination Path (LSP) infrastructure may be duplicated, even if the destination
IPv4 and IPv6 addresses belong to the same remote router. In order to IPv4 and IPv6 addresses belong to the same remote router.
In order to
achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be
computed over MPLS TE tunnels created using information propagated in computed over MPLS TE tunnels created using information propagated in
another OSPF instance. This issue is solved by advertising cross-address another OSPF instance. This issue is solved by advertising cross-address
family (X-AF) OSPF TE information.</t> family (X-AF) OSPF TE information.</t>
<t>This document describes an update to RFC5786 that allows for the easy <t>This document describes an update to RFC 5786 that allows for the easy
identification of a router's local X-AF IP addresses.</t> identification of a router's local X-AF IP addresses.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction" toc="default"> <section toc="default" numbered="true">
<t>TE Extensions to <xref target="RFC3630">OSPFv2</xref> and <xref <name>Introduction</name>
target="RFC5329">OSPFv3</xref> have been described to support intra-area <t>TE extensions to <xref target="RFC3630"
format="default">OSPFv2</xref>
and <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 TE in IPv4 and IPv6 networks, respectively. In both cases, the TE
database provides a tight coupling between the routed protocol and database provides a tight coupling between the routed protocol and
advertised TE signaling information. In other words, any use of the TE advertised TE signaling information. In other words, any use of the TE
database is limited to IPv4 for <xref target="RFC2328"> OSPFv2</xref> database is limited to IPv4 for <xref target="RFC2328" format="default"> O
and IPv6 for <xref target="RFC5340">OSPFv3 </xref>.</t> SPFv2</xref>
and IPv6 for <xref target="RFC5340" format="default">OSPFv3 </xref>.</t>
<t>In a dual stack network, it may be desirable to set up common MPLS TE <t>In a dual-stack network, it may be desirable to set up common MPLS TE
LSPs to carry traffic destined to addresses from different address LSPs to carry traffic destined to addresses from different address
families on a router. The use of common LSPs eases potential scalability families on a router. The use of common LSPs eases potential scalability
and management concerns by halving the number of LSPs in the network. and management concerns by halving the number of LSPs in the
Besides, it allows operators to group traffic based on business network. Besides, it allows operators to group traffic based on
characteristics and/or applications or class of service, not constrained business characteristics, class of service, and/or applications;
by the network protocol used.</t> the operators are not constrained by the network protocol used.
</t>
<t>For example, an LSP created based on MPLS TE information propagated <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 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 traffic, as opposed to using both OSPFv2 and OSPFv3 to provision a
separate LSP for each address family. Even if in some cases the address separate LSP for each address family. Even if, in some cases, the address-
family-specific traffic is to be separated, calculation from a common TE family-specific traffic is to be separated, calculation from a common TE
database may prove to be operationally beneficial.</t> database may prove to be operationally beneficial.</t>
<t>During the SPF calculation on the TE tunnel head-end router, OSPF <t>During the SPF calculation on the TE tunnel
head-end router, OSPF
computes shortcut routes using TE tunnels. A commonly used algorithm for computes shortcut routes using TE tunnels. A commonly used algorithm for
computing shortcuts is defined in <xref target="RFC3906"/>. For that, or computing shortcuts is defined in <xref target="RFC3906" format="default"/
any similar, algorithm to work with a common MPLS TE infrastructure in a >. For that or
any 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 dual-stack network, a requirement is to reliably map the X-AF addresses
to the corresponding tail-end router. This mapping is a challenge to the corresponding tail-end router. This mapping is a challenge
because the LSAs containing the routing information are carried in one because the Link State Advertisements (LSAs) containing the routing
OSPF instance while the TE calculations may be done using a TE database information are carried in one
OSPF instance, while the TE calculations may be done using a TE database
from a different OSPF instance.</t> from a different OSPF instance.</t>
<t>A simple solution to this problem is to rely on the Router ID to <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 identify a node in the corresponding OSPFv2 and OSPFv3 Link State
databases (LSDBs). This solution would mandate both instances on the Databases (LSDBs). This solution would mandate both instances on the
same router to be configured with the same Router ID. However, relying same router to be configured with the same Router ID. However, relying
on the correctness of configuration puts additional burden and cost on on the correctness of configuration puts additional burden and cost on
the operation of the network. The network becomes even more difficult to the operation of the network. The network becomes even more difficult to
manage if OSPFv2 and OSPFv3 topologies do not match exactly, for example manage if OSPFv2 and OSPFv3 topologies do not match exactly, for example,
if area borders are chosen differently in the two protocols. Also, if 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 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 IDs for local administrative reasons), there is no defined way for other
routers to discover such misalignment and to take corrective measures routers to discover such misalignment and to take corrective measures
(such as to avoid routing traffic through affected TE tunnels or (such as to avoid routing traffic through affected TE tunnels or
alerting the network administrators). The use of misaligned Router IDs alerting the network administrators). The use of misaligned Router IDs
may result in delivering the traffic to the wrong tail-end router, which may result in delivering the traffic to the wrong tail-end router, which
could lead to suboptimal routing or even traffic loops.</t> could lead to suboptimal routing or even traffic loops.</t>
<t>This document describes an update to <xref target="RFC5786"/> that <t>This document describes an update to <xref target="RFC5786" format="def ault"/> that
allows for the easy identification of a router's local X-AF IP allows for the easy identification of a router's local X-AF IP
addresses. <xref target="RFC5786"/> defined the Node IPv4 Local Address addresses. <xref target="RFC5786" format="default"/> defined the Node IPv4 Local Address
and Node IPv6 Local Address sub-TLVs of the Node Attribute TLV for a and Node IPv6 Local Address sub-TLVs of the Node Attribute TLV for a
router to advertise additional local IPv4 and IPv6 addresses. However, router to advertise additional local IPv4 and IPv6 addresses. However,
<xref target="RFC5786"/> did not describe the advertisement and usage of <xref target="RFC5786" format="default"/> did not describe the advertiseme nt and usage of
these sub-TLVs when the address family of the advertised local address these sub-TLVs when the address family of the advertised local address
differed from the address family of the OSPF traffic engineering differed from the address family of the OSPF traffic engineering
protocol.</t> protocol.</t>
<t>This document updates <xref target="RFC5786"/> so that a router can <t>This document updates <xref target="RFC5786" format="default"/> so that a router can
also announce one or more local X-AF addresses using the corresponding also announce one or more local X-AF addresses using the corresponding
Local Address sub-TLV. Routers using the <xref target="RFC5786">Node Local Address sub-TLV. Routers using the <xref target="RFC5786" format="de
Attribute TLV</xref> can include non-TE enabled interface addresses in fault">Node
their OSPF TE advertisements, and also use the same sub-TLVs to carry Attribute TLV</xref> can include non-TE-enabled interface addresses in
their OSPF TE advertisements and also use the same sub-TLVs to carry
X-AF information, facilitating the mapping described above.</t> X-AF information, facilitating the mapping described above.</t>
<t>The method specified in this document can also be used to compute the <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 X-AF mapping of the egress Label Switching Router (LSR) for sub-LSPs of
a Point-to-Multipoint LSP <xref target="RFC4461"/>. Considerations of a Point-to-Multipoint LSP <xref target="RFC4461" format="default"/>. Consi derations of
using Point-to-Multipoint MPLS TE for X-AF traffic forwarding is outside using Point-to-Multipoint MPLS TE for X-AF traffic forwarding is outside
the scope of this document.</t> the scope of this document.</t>
</section> </section>
<section toc="default" numbered="true">
<name>Requirements Language</name>
<section title="Requirements Language" toc="default"> <t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in BCP 14 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
<xref format="default" pageno="false" target="RFC2119"/> <xref "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
format="default" pageno="false" target="RFC8174"/> when, and only when, "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
they appear in all capitals, as shown here.</t> to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
</section> <xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
<section title="Operation" toc="default"> </section>
<section toc="default" numbered="true">
<name>Operation</name>
<t>To implement the X-AF routing technique described in this document, <t>To implement the X-AF routing technique described in this document,
OSPFv2 will advertise the Node IPv6 Local Address sub-TLV and OSPFv3 OSPFv2 will advertise the Node IPv6 Local Address sub-TLV and OSPFv3
will advertise the Node IPv4 Local Address sub-TLV, possibly in addition will advertise the Node IPv4 Local Address sub-TLV, possibly in addition
to advertising other IP addresses as documented by <xref to advertising other IP addresses as documented by <xref target="RFC5786"
target="RFC5786"/>.</t> format="default"/>.</t>
<t>Multiple instances of OSPFv3 are needed if it is used for both IPv4 <t>Multiple instances of OSPFv3 are needed if it is used for both IPv4
and IPv6 <xref target="RFC5838"/>. The operation in this section is and IPv6 <xref target="RFC5838" format="default"/>. The operation in this section is
described with OSPFv2 as the protocol used for IPv4; that is the most 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 common case. The case of OSPFv3 being used for IPv4 follows the same
procedure as what is indicated for OSPFv2 below.</t> procedure as what is indicated for OSPFv2 below.</t>
<t>On a node that implements X-AF routing, each OSPF instance <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 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 OSPFv2 instance) or IPv4 (for OSPFv3) addresses local to the router that
can be used by Constrained SPF (CSPF) to calculate MPLS TE LSPs: <list can be used by the Constrained Shortest Path First (CSPF) to calculate MPL
hangIndent="10" style="empty"> S TE LSPs: </t>
<t>OSPF instance MUST advertise the IP address listed in the Router
Address TLV <xref target="RFC3630"/>, <xref target="RFC5329"/> of
the X-AF instance maintaining the TE database.</t>
<t>OSPF instance SHOULD include additional local addresses <ul spacing="normal">
<li>The OSPF instance <bcp14>MUST</bcp14> advertise the IP address liste
d in the Router
Address TLV <xref target="RFC3630" format="default"/> <xref target="RF
C5329" format="default"/> of
the X-AF instance maintaining the TE database.</li>
<li>The OSPF instance <bcp14>SHOULD</bcp14> include additional local add
resses
advertised by the X-AF OSPF instance in its Node Local Address advertised by the X-AF OSPF instance in its Node Local Address
sub-TLVs.</t> sub-TLVs.</li>
<li>An implementation <bcp14>MAY</bcp14> advertise other local X-AF addr
<t>An implementation MAY advertise other local X-AF addresses.</t> esses.</li>
</list></t> </ul>
<t>When TE information is advertised in an OSPF instance both natively <t>When TE information is advertised in an OSPF instance, both natively
(i.e. as per RFC <xref target="RFC3630"/> or <xref target="RFC5329"/>) (i.e., as per RFC <xref target="RFC3630" format="default"/> or <xref targe
and as XAF Node Attribute TLV it is left to local configuration to t="RFC5329" format="default"/>)
and as X-AF Node Attribute TLV, it is left to local configuration to
determine which TE database is used to compute routes for the OSPF determine which TE database is used to compute routes for the OSPF
instance.</t> instance.</t>
<t>On Area Border Routers (ABRs), each advertised X-AF IP address <bcp14>M
<t>On Area Border Routers (ABR), each advertised X-AF IP address MUST be UST</bcp14> be
advertised into at most one area. If OSPFv2 and OSPFv3 area border advertised into, at most, one area. If OSPFv2 and OSPFv3 ABRs coincide
routers coincide (i.e., the areas for all OSPFv2 and OSPFv3 interfaces (i.e., the areas for all OSPFv2 and OSPFv3 interfaces
are the same), then the X-AF addresses MUST be advertised into the same are the same), then the X-AF addresses <bcp14>MUST</bcp14> be advertised i
nto the same
area in both instances. This allows other ABRs connected to the same set 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 of areas to know with which area to associate computed MPLS TE
tunnels.</t> tunnels.</t>
<t>During the X-AF routing calculation, X-AF IP addresses are used to <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 map locally created LSPs to tail-end routers in the
(LSDB). The mapping algorithm can be described as: <list hangIndent="10" LSDB. The mapping algorithm can be described as: </t>
style="empty">
<t>Walk the list of all MPLS TE tunnels for which the computing
router is a head-end. For each MPLS TE tunnel T:</t>
</list> <list style="numbers">
<t>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 it is a X-AF MPLS TE tunnel. Note tunnel's destination
IP address.</t>
<t>Walk the X-AF IP addresses in the LSDBs of all connected areas. <ul empty="true" spacing="normal">
<li>Walk the list of all MPLS TE tunnels for which the computing
router is a head end. For each MPLS TE tunnel 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.</li>
<li>Otherwise, it is a X-AF MPLS TE tunnel. Note the tunnel's destinatio
n
IP 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, 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 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 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> within area A as the IGP cost of tunnel T.</li>
</list></t> </ol>
</li>
</ul>
<t>After completing this calculation, each TE tunnel is associated with <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 an area and tail-end router in terms of the routing LSDB of the
computing OSPF instance and has a cost.</t> 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 includes X-AF information.</t>
<t>The algorithm described above is to be used only if Node Local <t>Note that, for clarity of description, the mapping algorithm is
Address sub-TLV include X-AF information.</t> specified as a single calculation. Implementations may choose to support e
quivalent mapping
<t>Note that for clarity of description the mapping algorithm is functionality without implementing the algorithm as described.</t>
specified as a single calculation. Actual implementations for the
efficiency 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 <t>As an example, consider a router in a dual-stack network
using OSPFv2 and OSPFv3 for IPv4 and IPv6 routing. Suppose the OSPFv2 using OSPFv2 and OSPFv3 for IPv4 and IPv6 routing, respectively. Suppose t
he OSPFv2
instance is used to propagate MPLS TE information and the router is 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 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 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 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 address 198.51.100.2 in the Node IPv4 Local Address sub-TLV, and other
Traffic Engineering TLVs as required by <xref target="RFC3630"/>. If the TE TLVs as required by <xref target="RFC3630" format="default"/>. If the
OSPFv3 instance in the network is enabled for X-AF TE routing (that is, 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 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 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. 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 Other routers in the OSPFv3 network will use this information to
reliably identify this router as the egress LSR for MPLS TE LSPs 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> terminating at either 198.51.100.1 or 198.51.100.2.</t>
</section> </section>
<section title="Backward Compatibility" toc="default"> <section toc="default" numbered="true">
<t>Only routers that serve as endpoints for one or more TE tunnels MUST <name>Backward Compatibility</name>
be upgraded to support the procedures described herein: <list <t>Only routers that serve as endpoints for one or more TE tunnels <bcp14>
style="symbols"> MUST</bcp14>
<t>Tunnel tailend routers advertise the Node IPv4 Local Address be upgraded to support the procedures described herein: </t>
sub-TLV and/or the Node IPv6 Local Address sub-TLV.</t> <ul spacing="normal">
<li>Tunnel tail-end routers advertise the Node IPv4 Local Address
<t>Tunnel headend routers perform the X-AF routing calculation.</t> sub-TLV and/or the Node IPv6 Local Address sub-TLV.</li>
</list> Both the endpoints MUST be upgraded before the tailend starts <li>Tunnel head-end routers perform the X-AF routing calculation.</li>
</ul>
<t> Both the endpoints <bcp14>MUST</bcp14> be upgraded before the tail end
starts
advertising the X-AF information. Other routers in the network do not advertising the X-AF information. Other routers in the network do not
need to support X-AF procedures.</t> need to support X-AF procedures.</t>
<section title="Automatically Switched Optical Networks"> <section numbered="true" toc="default">
<t><xref target="RFC6827"/> updates <xref target="RFC5786"/> by <name>Automatically Switched Optical Networks</name>
<t><xref target="RFC6827" format="default"/> updates
<xref target="RFC5786" format="default"/> by
defining extensions to be used in an Automatically Switched Optical defining extensions to be used in an Automatically Switched Optical
Network (ASON). The Local TE Router ID Sub-TLV is required for Network (ASON). The Local TE Router ID sub-TLV is required for
determining ASON reachability. The implication is that if the Local TE determining ASON reachability. The implication is that if the Local TE
Router ID Sub-TLV is present in the Node Attribute TLV, then the Router ID sub-TLV is present in the Node Attribute TLV, then the
procedures in <xref target="RFC6827"/> apply, regardless of whether procedures in <xref target="RFC6827" format="default"/> apply, regardles
s of whether
any X-AF information is advertised.</t> any X-AF information is advertised.</t>
</section> </section>
</section> </section>
<section title="Security Considerations" toc="default"> <section toc="default" numbered="true">
<name>Security Considerations</name>
<t>This document describes the use of the Local Address sub-TLVs to <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 provide X-AF information. The advertisement of these sub-TLVs, in any
OSPF instance, is not precluded by <xref target="RFC5786"/>. As such, no OSPF instance, is not precluded by <xref target="RFC5786" format="default"
new security threats are introduced beyond the considerations in <xref />. As such, no
target="RFC2328">OSPFv2</xref>, <xref target="RFC5340">OSPFv3</xref>, new security threats are introduced beyond the considerations in <xref tar
and <xref target="RFC5786"/>.</t> get="RFC2328" format="default">OSPFv2</xref>, <xref target="RFC5340" format="def
ault">OSPFv3</xref>,
and <xref target="RFC5786" format="default"/>.</t>
<t>The X-AF information is not used for SPF computation or normal <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. routing, so the mechanism specified here has no effect on IP routing.
However, generating incorrect information, or tampering with the However, generating incorrect information or tampering with the
sub-TLVs may have an effect on traffic engineering computations. sub-TLVs may have an effect on traffic engineering computations.
Specifically, TE traffic may be delivered to the wrong tail-end router, Specifically, TE traffic may be delivered to the wrong tail-end router,
which could lead to suboptimal routing, traffic loops, or even expose which could lead to suboptimal routing, traffic loops, or exposing
the traffic to attacker inspection or modification. These threats are the traffic to attacker inspection or modification. These threats are
already present in other TE-related specifications, and their already present in other TE-related specifications, and their
considerations apply here as well, including <xref target="RFC3630"/> considerations apply here as well, including <xref target="RFC3630" format
and <xref target="RFC5329"/>.</t> ="default"/>
and <xref target="RFC5329" format="default"/>.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="IANA Considerations" toc="default"> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section title="Acknowledgements" toc="default">
<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 and Roman Danyliw provided
useful comments. </t>
<t>We would also like to thank the authors of RFC5786 for laying down
the foundation for this work.</t>
</section>
</middle> </middle>
<!-- *****BACK MATTER ***** --> <!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation librarie
s:
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.xm
l"?> 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. <references>
If you use the PI option, xml2rfc will, by default, try to find included fi <name>References</name>
les in the same <references>
directory as the including file. You can also define the XML_LIBRARY enviro <name>Normative References</name>
nment variable
with a value containing a set of directories to search. These can be eithe
r in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References"> <xi:include
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC. href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
2119.xml"?-->
<?rfc include="reference.RFC.2119.xml"?> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml"/>
<?rfc include="reference.RFC.3630.xml"?> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5329.xml"/>
<?rfc include="reference.RFC.5329.xml"?> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5786.xml"/>
<?rfc include="reference.RFC.5786.xml"?> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<?rfc include="reference.RFC.8174.xml"?> </references>
</references>
<references title="Informative References"> <references>
<!-- Here we use entities that we defined at the beginning. --> <name>Informative References</name>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"/>
<?rfc include="reference.RFC.2328.xml"?> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3906.xml"/>
<?rfc include="reference.RFC.5838.xml"?> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4461.xml"/>
<?rfc include="reference.RFC.3906.xml"?> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/>
<?rfc include="reference.RFC.4461.xml"?> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5838.xml"/>
<?rfc include="reference.RFC.5340.xml"?> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6827.xml"/>
<?rfc include="reference.RFC.6827.xml"?> </references>
</references> </references>
<section 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, and Roman Danyliw provided
useful comments. </t>
<t>We would also like to thank the authors of RFC 5786 for laying down
the foundation for this work.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 91 change blocks. 
253 lines changed or deleted 208 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/