draft-ietf-ospf-xaf-te-02.txt   rfc8687.txt 
LSR A. Smirnov Internet Engineering Task Force (IETF) A. Smirnov
Internet-Draft Cisco Systems, Inc. Request for Comments: 8687 Cisco Systems, Inc.
Updates: 5786 (if approved) A. Retana Updates: 5786 A. Retana
Intended status: Standards Track Huawei R&D USA Category: Standards Track Futurewei Technologies, Inc.
Expires: October 20, 2018 M. Barnes ISSN: 2070-1721 M. Barnes
Cisco Systems, Inc. November 2019
April 18, 2018
OSPF Routing with Cross-Address Family Traffic Engineering Tunnels OSPF Routing with Cross-Address Family Traffic Engineering Tunnels
draft-ietf-ospf-xaf-te-02
Abstract Abstract
When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6
the Multiprotocol Label Switching (MPLS) TE Label Switched Paths network, the Multiprotocol Label Switching (MPLS) TE Label Switched
(LSP) infrastructure may be duplicated, even if the destination IPv4 Path (LSP) infrastructure may be duplicated, even if the destination
and IPv6 addresses belong to the same remote router. In order to IPv4 and IPv6 addresses belong to the same remote router. In order
achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must
computed over MPLS TE tunnels created using information propagated in be computed over MPLS TE tunnels created using information propagated
another OSPF instance. This is solved by advertising cross-address in another OSPF instance. This issue is solved by advertising cross-
family (X-AF) OSPF TE information. address family (X-AF) OSPF TE information.
This document describes an update to RFC5786 that allows for the easy This document describes an update to RFC 5786 that allows for the
identification of a router's local X-AF IP addresses. easy identification of a router's local X-AF IP addresses.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on October 20, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8687.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operation
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5 4. Backward Compatibility
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4.1. Automatically Switched Optical Networks
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References
8.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.1. Normative References
8.2. Informative References . . . . . . . . . . . . . . . . . 7 7.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Acknowledgements
Authors' Addresses
1. Introduction 1. Introduction
TE Extensions to OSPFv2 [RFC3630] and to OSPFv3 [RFC5329] have been TE extensions to OSPFv2 [RFC3630] and OSPFv3 [RFC5329] have been
described to support intra-area TE in IPv4 and IPv6 networks, described to support intra-area TE in IPv4 and IPv6 networks,
respectively. In both cases the TE database provides a tight respectively. In both cases, the TE database provides a tight
coupling between the routed protocol and TE signaling information in coupling between the routed protocol and advertised TE signaling
it. In other words, any use of the TE link state database is limited information. In other words, any use of the TE database is limited
to IPv4 for OSPFv2 [RFC2328] and IPv6 for OSPFv3 [RFC5340]. to IPv4 for OSPFv2 [RFC2328] and IPv6 for OSPFv3 [RFC5340].
In a dual stack network it may be desirable to set up common MPLS TE 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 families on a router. The use of common LSPs eases potential
scalability and management concerns by halving the number of LSPs in scalability and management concerns by halving the number of LSPs in
the network. Besides, it allows operators to group traffic based on the network. Besides, it allows operators to group traffic based on
business characteristics and/or applications or class of service, not business characteristics, class of service, and/or applications; the
constrained by the network protocol which carries it. operators are not constrained by the network protocol used.
For example, an LSP created based on MPLS TE information propagated For example, an LSP created based on MPLS TE information propagated
by OSPFv2 instance can be defined to carry both IPv4 and IPv6 by an OSPFv2 instance can be used to transport both IPv4 and IPv6
traffic, instead of having 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 separate LSP for each address family. Even if, in some cases, the
address family-specific traffic is to be separated, the calculation address-family-specific traffic is to be separated, calculation from
from a common database may prove operationally beneficial. a common TE database may prove to be operationally beneficial.
A requirement when creating a common MPLS TE infrastructure is the During the SPF calculation on the TE tunnel head-end router, OSPF
ability to reliably map the X-AF family addresses to the computes shortcut routes using TE tunnels. A commonly used algorithm
corresponding advertising tail-end router. This mapping is a for computing shortcuts is defined in [RFC3906]. For that or any
challenge because the LSAs containing the routing information are similar algorithm to work with a common MPLS TE infrastructure in a
carried in one OSPF instance while the TE calculation may be done dual-stack network, a requirement is to reliably map the X-AF
using a TE database from a different instance. addresses to the corresponding tail-end router. This mapping is a
challenge because the Link State Advertisements (LSAs) containing the
routing information are carried in one OSPF instance, while the TE
calculations may be done using a TE database from a different OSPF
instance.
A simple solution to this problem is to rely on the Router ID to A simple solution to this problem is to rely on the Router ID to
identify a node in the corresponding OSPFv2 and OSPFv3 databases. identify a node in the corresponding OSPFv2 and OSPFv3 Link State
This solution would mandate both instances on the same router to be Databases (LSDBs). This solution would mandate both instances on the
configured with the same Router ID. However, relying on the same router to be configured with the same Router ID. However,
correctness of the configuration puts additional burden on network relying on the correctness of configuration puts additional burden
management and adds cost to the operation of the network. The and cost on the operation of the network. The network becomes even
network becomes even more difficult to manage if OSPFv2 and OSPFv3 more difficult to manage if OSPFv2 and OSPFv3 topologies do not match
topologies do not match exactly, for example if area borders are exactly, for example, if area borders are chosen differently in the
drawn differently in the two protocols. Also, if the routing two protocols. Also, if the routing processes do fall out of sync
processes do fall out of sync (having different Router IDs, even if (e.g., having different Router IDs for local administrative reasons),
for local administrative reasons), there is no defined way for other there is no defined way for other routers to discover such
routers to discover such misalignment and to take any corrective misalignment and to take corrective measures (such as to avoid
measures (such as to avoid routing through affected TE tunnels or routing traffic through affected TE tunnels or alerting the network
issuing warning to network management). The use of misaligned router administrators). The use of misaligned Router IDs may result in
IDs may result in delivering the traffic to the wrong tail-end delivering the traffic to the wrong tail-end router, which could lead
router, which could lead to suboptimal routing or even traffic loops. to suboptimal routing or even traffic loops.
This document describes an update to [RFC5786] that allows for the This document describes an update to [RFC5786] that allows for the
easy identification of a router's local X-AF IP addresses. Routers easy identification of a router's local X-AF IP addresses. [RFC5786]
using the Node Attribute TLV [RFC5786] can include non-TE enabled defined the Node IPv4 Local Address and Node IPv6 Local Address sub-
interface addresses in their OSPF TE advertisements, and also use the TLVs of the Node Attribute TLV for a router to advertise additional
same sub-TLVs to carry X-AF information, facilitating the mapping local IPv4 and IPv6 addresses. However, [RFC5786] did not describe
mentioned above. 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.
The method described in this document can also be used to compute This document updates [RFC5786] so that a router can also announce
X-AF mapping of egress LSR for sub-LSPs of a Point-to-Multipoint LSP one or more local X-AF addresses using the corresponding Local
(see [RFC4461]). Considerations of using Point-to-Multipoint MPLS TE Address sub-TLV. Routers using the Node Attribute TLV [RFC5786] can
for X-AF traffic forwarding is outside the scope of this include non-TE-enabled interface addresses in their OSPF TE
specification. advertisements and also use the same sub-TLVs to carry X-AF
information, facilitating the mapping described above.
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 [RFC4461]. Considerations of using
Point-to-Multipoint MPLS TE for X-AF traffic forwarding is outside
the scope of this document.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Operation 3. Operation
[RFC5786] defined the Node IPv4 Local Address and Node IPv6 Local To implement the X-AF routing technique described in this document,
Address sub-TLVs of the Node Attribute TLV for a router to advertise OSPFv2 will advertise the Node IPv6 Local Address sub-TLV and OSPFv3
additional local IPv4 and IPv6 addresses. To solve the problem will advertise the Node IPv4 Local Address sub-TLV, possibly in
outlined in [RFC5786] OSPFv2 would advertise and use only IPv4 addition to advertising other IP addresses as documented by
addresses and OSPFv3 would advertise and use only IPv6 addresses. [RFC5786].
This document updates [RFC5786] so that a router can also announce Multiple instances of OSPFv3 are needed if it is used for both IPv4
one or more local X-AF addresses using the corresponding Local and IPv6 [RFC5838]. The operation in this section is described with
Address sub-TLV. In other words, to implement the X-AF routing OSPFv2 as the protocol used for IPv4; that is the most common case.
technique proposed in this document, OSPFv2 will advertise the Node The case of OSPFv3 being used for IPv4 follows the same procedure as
IPv6 Local Address sub-TLV and OSPFv3 will advertise the Node IPv4 what is indicated for OSPFv2 below.
Local Address sub-TLV, possibly in addition to advertising other IP
addresses as documented by [RFC5786].
A node that implements X-AF routing SHOULD advertise in the On a node that implements X-AF routing, each OSPF instance
corresponding Node Local Address sub-TLV all X-AF IP addresses local advertises, using the Node Local Address sub-TLV, all X-AF IPv6 (for
to the router that can be used by Constrained SPF (CSPF) to calculate OSPFv2 instance) or IPv4 (for OSPFv3) addresses local to the router
MPLS TE LSPs. In general, OSPF SHOULD advertise the IP address that can be used by the Constrained Shortest Path First (CSPF) to
listed in the Router Address TLV of the X-AF instance maintaining calculate MPLS TE LSPs:
MPLS TE database plus any additional local addresses advertised by
the X-AF OSPF instance in its Node Local Address sub-TLV.
Implementation MAY advertise other local X-AF addresses.
If the Node Attribute TLV carries both the Node IPv4 Local Address * The OSPF instance MUST advertise the IP address listed in the
sub-TLV and the Node IPv6 Local Address sub-TLV, then the X-AF Router Address TLV [RFC3630] [RFC5329] of the X-AF instance
component must be considered for the consolidated calculation of MPLS maintaining the TE database.
TE LSPs. Both instances may carry the required information, it is
left to local configuration to determine which database is used.
On Area Border Routers (ABR), each advertised X-AF IP address MUST be * The OSPF instance SHOULD include additional local addresses
advertised into at most one area. If OSPFv2 and OSPFv3 area borders advertised by the X-AF OSPF instance in its Node Local Address
match (i.e. for each interface area number for OSPFv2 and OSPFv3 sub-TLVs.
instances is numerically equal), then the X-AF addresses MUST be
advertised into the same area in both instances. This allows other * An implementation MAY advertise other local X-AF addresses.
ABRs connected to the same set of areas to know with which area to
associate MPLS TE tunnels. When TE information is advertised in an OSPF instance, both natively
(i.e., as per RFC [RFC3630] or [RFC5329]) 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 instance.
On Area Border Routers (ABRs), each advertised X-AF IP address MUST
be advertised into, at most, one area. If OSPFv2 and OSPFv3 ABRs
coincide (i.e., the areas for all OSPFv2 and OSPFv3 interfaces are
the same), then the X-AF addresses MUST 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.
During the X-AF routing calculation, X-AF IP addresses are used to During the X-AF routing calculation, X-AF IP addresses are used to
map locally created LSPs to tail-end routers in the LSDB. The map locally created LSPs to tail-end routers in the LSDB. The
mapping algorithm can be described as: mapping algorithm can be described as:
Walk the list of all MPLS TE tunnels for which the computing Walk the list of all MPLS TE tunnels for which the computing
router is a head-end. For each MPLS TE tunnel T: router is a head end. For each MPLS TE tunnel T:
1. If T's destination IP address is from the same address family as 1. If T's destination address is from the same address family as
the computing OSPF instance, then the tunnel must have been the OSPF instance associated with the LSDB, then the
signaled based on MPLS TE information propagated in the same OSPF extensions defined in this document do not apply.
instance. Process the tunnel as per [RFC3630] or [RFC5329].
2. Otherwise it is a X-AF MPLS TE tunnel. Note tunnel's destination 2. Otherwise, it is a X-AF MPLS TE tunnel. Note the tunnel's
IP address. destination IP address.
3. Walk the X-AF IP addresses in the LSDBs of all connected areas. 3. Walk the X-AF IP addresses in the LSDBs of all connected
If a matching IP address is found, advertised by router R in area areas. If a matching IP address is found, advertised by
A, then mark the tunnel T as belonging to area A and terminating router R in area A, then mark the tunnel T as belonging to
on tail-end router R. Assign an intra-area SPF cost to reach area A and terminating on tail-end router R. Assign the
router R within area A as the IGP cost of tunnel T. intra-area SPF cost to reach router R within area A as the IGP
cost of tunnel T.
After completing this calculation, each TE tunnel is associated with 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 metric. computing OSPF instance and has a cost.
Note that for clarity of description the mapping algorithm is The algorithm described above is to be used only if the Node Local
specified as a single calculation. Actual implementations for the Address sub-TLV includes X-AF information.
efficiency may choose to support equivalent mapping functionality
without implementing the algorithm exactly as it is described.
As an example lets consider a router in dual-stack network running Note that, for clarity of description, the mapping algorithm is
OSPFv2 and OSPFv3 for IPv4 and IPv6 routing correspondingly. Suppose specified as a single calculation. Implementations may choose to
support equivalent mapping functionality without implementing the
algorithm as described.
As an example, consider a router in a dual-stack network using OSPFv2
and OSPFv3 for IPv4 and IPv6 routing, respectively. Suppose the
OSPFv2 instance is used to propagate MPLS TE information and the OSPFv2 instance is used to propagate MPLS TE information and the
router is configured to accept TE LSPs terminating at local addresses router is configured to accept TE LSPs terminating at local addresses
198.51.100.1 and 198.51.100.2. Then the router will advertise into 198.51.100.1 and 198.51.100.2. The router advertises in OSPFv2 the
OSPFv2 instance IPv4 address 198.51.100.1 in the Router Address TLV, IPv4 address 198.51.100.1 in the Router Address TLV, the additional
additional local IPv4 address 198.51.100.2 in the Node IPv4 Local local IPv4 address 198.51.100.2 in the Node IPv4 Local Address sub-
Address sub-TLV, plus other Traffic Engineering TLVs as required by TLV, and other TE TLVs as required by [RFC3630]. If the OSPFv3
[RFC3630]. If OSPFv3 instance in the network is enabled for X-AF TE instance in the network is enabled for X-AF TE routing (that is, to
routing (that is, to use for IPv6 routing MPLS TE LSPs computed by use MPLS TE LSPs computed by OSPFv2 for IPv6 routing), then the
OSPFv2), then the OSPFv3 instance of the router will advertise the OSPFv3 instance of the router will advertise the Node IPv4 Local
Node IPv4 Local Address sub-TLV listing local IPv4 addresses Address sub-TLV listing the local IPv4 addresses 198.51.100.1 and
198.51.100.1 and 198.51.100.2. Other routers in the OSPFv3 network 198.51.100.2. Other routers in the OSPFv3 network will use this
will use this information to reliably identify this router as egress information to reliably identify this router as the egress LSR for
LSR for MPLS TE LSPs terminating at either 198.51.100.1 or MPLS TE LSPs terminating at either 198.51.100.1 or 198.51.100.2.
198.51.100.2.
4. Backward Compatibility 4. Backward Compatibility
Node Attribute TLV and Node Local Address sub-TLVs and their usage Only routers that serve as endpoints for one or more TE tunnels MUST
are defined in [RFC5786] and updated by [RFC6827]. Way of using be upgraded to support the procedures described herein:
these TLVs as specified in this document is fully backward compatible
with previous standard documents.
An implementation processing Node Attribute TLV MUST interpret its * Tunnel tail-end routers advertise the Node IPv4 Local Address sub-
content as follows: TLV and/or the Node IPv6 Local Address sub-TLV.
o If the Node Attribute TLV contains Local TE Router ID sub-TLV then * Tunnel head-end routers perform the X-AF routing calculation.
this Node Attribute TLV MUST be treated as carrying routing
information for ASON (Automatically Switched Optical Network) and
processed as specified in [RFC6827].
o Otherwise Node Attribute TLV contains one or more instance(s) of Both the endpoints MUST be upgraded before the tail end starts
Node IPv4 Local Address and/or Node IPv6 Local Address sub-TLVs. advertising the X-AF information. Other routers in the network do
Meaning of each Local Address sub-TLV has to be identified not need to support X-AF procedures.
separately.
* If Node Local Address sub-TLV belongs to the same address 4.1. Automatically Switched Optical Networks
family as instance of OSPF protocol advertising it then address
carried in the sub-TLV MUST be treated as described in
[RFC5786].
* Otherwise the address is used for X-AF tunnel tail-end mapping [RFC6827] updates [RFC5786] by defining extensions to be used in an
as defined by this document. Automatically Switched Optical Network (ASON). The Local TE Router
ID sub-TLV is required for determining ASON reachability. The
implication is that if the Local TE Router ID sub-TLV is present in
the Node Attribute TLV, then the procedures in [RFC6827] apply,
regardless of whether any X-AF information is advertised.
5. Security Considerations 5. Security Considerations
This document introduces no new security concerns. Security This document describes the use of the Local Address sub-TLVs to
considerations of using Node Attribute TLV are discussed in provide X-AF information. The advertisement of these sub-TLVs, in
[RFC5786]. any OSPF instance, is not precluded by [RFC5786]. As such, no new
security threats are introduced beyond the considerations in OSPFv2
[RFC2328], OSPFv3 [RFC5340], and [RFC5786].
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 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
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 [RFC3630] and
[RFC5329].
6. IANA Considerations 6. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
7. Acknowledgements 7. References
The authors would like to thank Peter Psenak and Eric Osborne for
early discussions and Acee Lindem for discussing compatibility with
ASON extensions.
We would also like to thank the authors of RFC5786 for laying down
the foundation for this work.
8. References
8.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>.
[RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's
Local Addresses in OSPF Traffic Engineering (TE) Local Addresses in OSPF Traffic Engineering (TE)
Extensions", RFC 5786, DOI 10.17487/RFC5786, March 2010, Extensions", RFC 5786, DOI 10.17487/RFC5786, March 2010,
<https://www.rfc-editor.org/info/rfc5786>. <https://www.rfc-editor.org/info/rfc5786>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 7.2. Informative References
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>. <https://www.rfc-editor.org/info/rfc2328>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway
(TE) Extensions to OSPF Version 2", RFC 3630, Protocol (IGP) Routes Over Traffic Engineering Tunnels",
DOI 10.17487/RFC3630, September 2003, RFC 3906, DOI 10.17487/RFC3906, October 2004,
<https://www.rfc-editor.org/info/rfc3630>. <https://www.rfc-editor.org/info/rfc3906>.
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to- [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006, (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006,
<https://www.rfc-editor.org/info/rfc4461>. <https://www.rfc-editor.org/info/rfc4461>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>. <https://www.rfc-editor.org/info/rfc5340>.
[RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
R. Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, DOI 10.17487/RFC5838, April 2010,
<https://www.rfc-editor.org/info/rfc5838>.
[RFC6827] Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou, [RFC6827] Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou,
Ed., "Automatically Switched Optical Network (ASON) Ed., "Automatically Switched Optical Network (ASON)
Routing for OSPFv2 Protocols", RFC 6827, Routing for OSPFv2 Protocols", RFC 6827,
DOI 10.17487/RFC6827, January 2013, DOI 10.17487/RFC6827, January 2013,
<https://www.rfc-editor.org/info/rfc6827>. <https://www.rfc-editor.org/info/rfc6827>.
Acknowledgements
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.
We would also like to thank the authors of RFC 5786 for laying down
the foundation for this work.
Authors' Addresses Authors' Addresses
Anton Smirnov Anton Smirnov
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a De Kleetlaan 6a
Diegem 1831 1831 Diegem
Belgium Belgium
Email: as@cisco.com Email: as@cisco.com
Alvaro Retana Alvaro Retana
Huawei R&D USA Futurewei Technologies, Inc.
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA United States of America
Email: alvaro.retana@huawei.com Email: alvaro.retana@futurewei.com
Michael Barnes Michael Barnes
Cisco Systems, Inc.
510 McCarthy Blvd.
Milpitas, CA 95035
USA
Email: mjbarnes@cisco.com Email: michael_barnes@usa.net
 End of changes. 54 change blocks. 
204 lines changed or deleted 235 lines changed or added

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