draft-ietf-ospf-xaf-te-05.txt   draft-ietf-ospf-xaf-te-06.txt 
LSR A. Smirnov LSR A. Smirnov
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Updates: 5786 (if approved) A. Retana Updates: 5786 (if approved) A. Retana
Intended status: Standards Track Huawei R&D USA Intended status: Standards Track Futurewei Technologies, Inc.
Expires: June 13, 2019 M. Barnes Expires: December 28, 2019 M. Barnes
Cisco Systems, Inc. Cisco Systems, Inc.
December 10, 2018 June 26, 2019
OSPF Routing with Cross-Address Family Traffic Engineering Tunnels OSPF Routing with Cross-Address Family Traffic Engineering Tunnels
draft-ietf-ospf-xaf-te-05 draft-ietf-ospf-xaf-te-06
Abstract Abstract
When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 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 Paths (LSP) infrastructure may be duplicated, even if the destination
IPv4 and IPv6 addresses belong to the same remote router. In order IPv4 and IPv6 addresses belong to the same remote router. In order
to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must
be computed over MPLS TE tunnels created using information propagated be computed over MPLS TE tunnels created using information propagated
in another OSPF instance. This issue is solved by advertising cross- in another OSPF instance. This issue is solved by advertising cross-
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 13, 2019. This Internet-Draft will expire on December 28, 2019.
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
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 6 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 6
4.1. Automatically Switched Optical Networks . . . . . . . . . 6 4.1. Automatically Switched Optical Networks . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
TE Extensions to OSPFv2 [RFC3630] and 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 advertised TE signaling coupling between the routed protocol and advertised TE signaling
information. In other words, any use of the TE link state database information. In other words, any use of the TE database is limited
is limited to IPv4 for OSPFv2 [RFC2328] and IPv6 for OSPFv3 to IPv4 for OSPFv2 [RFC2328] and IPv6 for OSPFv3 [RFC5340].
[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 and/or applications or class of service, not
constrained by the network protocol used. 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 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 separate LSP for each address family. Even if in some cases the
address family-specific traffic is to be separated, calculation from address family-specific traffic is to be separated, calculation from
a common database may prove to be operationally beneficial. a common TE database may prove to be operationally beneficial.
During the SPF calculation on the TE tunnel head-end router, OSPF During the SPF calculation on the TE tunnel head-end router, OSPF
computes shortcut routes using TE tunnels. A commonly used algorithm computes shortcut routes using TE tunnels. A commonly used algorithm
for computing shortcuts is defined in [RFC3906]. For that, or any for computing shortcuts is defined in [RFC3906]. For that, or any
similar, algorithm to work with a common MPLS TE infrastructure in a similar, algorithm to work with a common MPLS TE infrastructure in a
dual-stack network, a requirement is to reliably map the X-AF dual-stack network, a requirement is to reliably map the X-AF
addresses to the corresponding tail-end router. This mapping is a addresses to the corresponding tail-end router. This mapping is a
challenge because the LSAs containing the routing information are challenge because the LSAs containing the routing information are
carried in one OSPF instance while the TE calculations may be done carried in one OSPF instance while the TE calculations may be done
using a TE database from a different OSPF instance. 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 configuration puts additional burden and cost on the relying on the correctness of configuration puts additional burden
operation of the network. The network becomes even more difficult to and cost on the operation of the network. The network becomes even
manage if OSPFv2 and OSPFv3 topologies do not match exactly, for more difficult to manage if OSPFv2 and OSPFv3 topologies do not match
example if area borders are chosen differently in the two protocols. exactly, for example if area borders are chosen differently in the
Also, if the routing processes do fall out of sync (e.g., having two protocols. Also, if the routing processes do fall out of sync
different Router IDs for local administrative reasons), there is no (e.g., having different Router IDs for local administrative reasons),
defined way for other routers to discover such misalignment and to there is no defined way for other routers to discover such
take corrective measures (such as to avoid routing traffic through misalignment and to take corrective measures (such as to avoid
affected TE tunnels or alerting the network administrators). The use routing traffic through affected TE tunnels or alerting the network
of misaligned Router IDs may result in delivering the traffic to the administrators). The use of misaligned Router IDs may result in
wrong tail-end router, which could lead to suboptimal routing or even delivering the traffic to the wrong tail-end router, which could lead
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
described 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.
This document updates [RFC5786] so that a router can also announce
one or more local X-AF addresses using the corresponding Local
Address sub-TLV. Routers using the Node Attribute TLV [RFC5786] 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.
The method specified in this document can also be used to compute the 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 X-AF mapping of the egress Label Switching Router (LSR) for sub-LSPs
of a Point-to-Multipoint LSP [RFC4461]. Considerations of using of a Point-to-Multipoint LSP [RFC4461]. Considerations of using
Point-to-Multipoint MPLS TE for X-AF traffic forwarding is outside Point-to-Multipoint MPLS TE for X-AF traffic forwarding is outside
the scope of this document. 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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 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. However, [RFC5786] did not will advertise the Node IPv4 Local Address sub-TLV, possibly in
describe the advertisement and usage of these sub-TLVs when the addition to advertising other IP addresses as documented by
address family of the advertised local address differed from the [RFC5786].
address family of the OSPF traffic engineering protocol.
This document updates [RFC5786] so that a router can also announce On a node that implements X-AF routing, each OSPF instance
one or more local X-AF addresses using the corresponding Local advertises, using the Node Local Address sub-TLV, all X-AF IPv6 (for
Address sub-TLV. In other words, to implement the X-AF routing OSPFv2 instance) or IPv4 (for OSPFv3) addresses local to the router
technique described in this document, OSPFv2 will advertise the Node that can be used by Constrained SPF (CSPF) to calculate MPLS TE LSPs:
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 [RFC5786].
A node that implements X-AF routing SHOULD advertise, in the OSPF instance MUST advertise the IP address listed in the Router
corresponding Node Local Address sub-TLV, all X-AF IPv4 and IPv6 Address TLV [RFC3630], [RFC5329] of the X-AF instance maintaining
addresses local to the router that can be used by Constrained SPF the TE database.
(CSPF) to calculate MPLS TE LSPs. OSPF MUST advertise the IP address
listed in the Router Address TLV [RFC3630] [RFC5329] of the X-AF
instance maintaining the MPLS TE database, and SHOULD include
additional local addresses advertised by the X-AF OSPF instance in
its Node Local Address sub-TLVs. An implementation MAY advertise
other local X-AF addresses.
If the Node Attribute TLV carries both the Node IPv4 Local Address OSPF instance SHOULD include additional local addresses advertised
sub-TLV and the Node IPv6 Local Address sub-TLV, then the X-AF by the X-AF OSPF instance in its Node Local Address sub-TLVs.
component MUST be considered for the consolidated calculation of MPLS
TE LSPs. Both instances MAY advertise the required information and An implementation MAY advertise other local X-AF addresses.
it is left to local configuration to determine which database is
used. When TE information is advertised in an OSPF instance both natively
(i.e. as per RFC [RFC3630] or [RFC5329]) and as XAF 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 (ABR), each advertised X-AF IP address MUST be On Area Border Routers (ABR), each advertised X-AF IP address MUST be
advertised into at most one area. If OSPFv2 and OSPFv3 area border advertised into at most one area. If OSPFv2 and OSPFv3 area border
routers coincide (i.e., the areas for all OSPFv2 and OSPFv3 routers coincide (i.e., the areas for all OSPFv2 and OSPFv3
interfaces are the same), then the X-AF addresses MUST be advertised interfaces are the same), then the X-AF addresses MUST be advertised
into the same area in both instances. This allows other ABRs into the same area in both instances. This allows other ABRs
connected to the same set of areas to know with which area to connected to the same set of areas to know with which area to
associate computed MPLS TE tunnels. 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
skipping to change at page 6, line 35 skipping to change at page 6, line 35
5. Security Considerations 5. Security Considerations
This document describes the use of the Local Address sub-TLVs to This document describes the use of the Local Address sub-TLVs to
provide X-AF information. The advertisement of these sub-TLVs, in provide X-AF information. The advertisement of these sub-TLVs, in
any OSPF instance, is not precluded by [RFC5786]. As such, no new any OSPF instance, is not precluded by [RFC5786]. As such, no new
security threats are introduced beyond the considerations in OSPFv2 security threats are introduced beyond the considerations in OSPFv2
[RFC2328], OSPFv3 [RFC5340], and [RFC5786]. [RFC2328], OSPFv3 [RFC5340], and [RFC5786].
The X-AF information is not used for SPF computation or normal The X-AF information is not used for SPF computation or normal
routing, so the mechanism specified here has no affect on IP routing. routing, so the mechanism specified here has no effect on IP routing.
However, generating incorrect information, or tampering with the sub- However, generating incorrect information, or tampering with the sub-
TLVs may have an effect on traffic engineering computations. TLVs may have an effect on traffic engineering computations.
Specifically, TE traffic may be delivered to the wrong tail-end Specifically, TE traffic may be delivered to the wrong tail-end
router, which could lead to suboptimal routing or even traffic loops. router, which could lead to suboptimal routing or even traffic loops.
These threats are already present in other TE-related specifications, These threats are already present in other TE-related specifications,
and their considerations apply here as well, including [RFC3630] and and their considerations apply here as well, including [RFC3630] and
[RFC5329]. [RFC5329].
6. IANA Considerations 6. IANA Considerations
skipping to change at page 7, line 17 skipping to change at page 7, line 17
8. References 8. References
8.1. Normative References 8.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 8.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
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway
Protocol (IGP) Routes Over Traffic Engineering Tunnels", Protocol (IGP) Routes Over Traffic Engineering Tunnels",
RFC 3906, DOI 10.17487/RFC3906, October 2004, RFC 3906, DOI 10.17487/RFC3906, October 2004,
<https://www.rfc-editor.org/info/rfc3906>. <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>.
[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>.
Authors' Addresses Authors' Addresses
Anton Smirnov Anton Smirnov
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
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 USA
Email: alvaro.retana@huawei.com Email: alvaro.retana@futurewei.com
Michael Barnes Michael Barnes
Cisco Systems, Inc. Cisco Systems, Inc.
510 McCarthy Blvd. 510 McCarthy Blvd.
Milpitas, CA 95035 Milpitas, CA 95035
USA USA
Email: mjbarnes@cisco.com Email: mjbarnes@cisco.com
 End of changes. 21 change blocks. 
73 lines changed or deleted 74 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/