OSPF Routing with Cross-Address Family Traffic Engineering Tunnels
draft-ietf-ospf-xaf-te-04

LSR                                                           A. Smirnov
Internet-Draft                                       Cisco Systems, Inc.
Updates: 5786 (if approved)                                    A. Retana
Intended status: Standards Track                          Huawei R&D USA
Expires: April 25, 2019                                        M. Barnes
                                                     Cisco Systems, Inc.
                                                        October 22, 2018

   OSPF Routing with Cross-Address Family Traffic Engineering Tunnels
                       draft-ietf-ospf-xaf-te-04

Abstract

   When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6
   network, the Multiprotocol Label Switching (MPLS) TE Label Switched
   Paths (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.

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

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 25, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Smirnov, et al.          Expires April 25, 2019                 [Page 1]
Internet-Draft    OSPF Routing with Cross-AF TE tunnels     October 2018

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Backward Compatibility  . . . . . . . . . . . . . . . . . . .   5
     4.1.  Automatically Switched Optical Networks . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   TE Extensions to OSPFv2 [RFC3630] and OSPFv3 [RFC5329] 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 link state database
   is limited 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
   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 class of service, not
   constrained by the network protocol used.

   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 in some cases the

Smirnov, et al.          Expires April 25, 2019                 [Page 2]
Internet-Draft    OSPF Routing with Cross-AF TE tunnels     October 2018

   address family-specific traffic is to be separated, calculation from
   a common database may prove to be operationally beneficial.

   A requirement when creating a common MPLS TE infrastructure is the
   ability to reliably map the X-AF family addresses to the
   corresponding advertising tail-end router.  This mapping is a
   challenge because the LSAs containing the routing information are
   carried in one OSPF instance while the TE calculation may be done
   using a TE database from a different instance.

   A simple solution to this problem is to rely on the Router ID to
   identify a node in the corresponding OSPFv2 and OSPFv3 databases.
   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 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.

   This document describes an update to [RFC5786] that allows for the
   easy identification of a router's local X-AF IP addresses.  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
   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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Smirnov, et al.          Expires April 25, 2019                 [Page 3]
Internet-Draft    OSPF Routing with Cross-AF TE tunnels     October 2018

3.  Operation

   [RFC5786] 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, [RFC5786] 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.

   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.  In other words, 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 [RFC5786].

   A node that implements X-AF routing SHOULD advertise, in the
   corresponding Node Local Address sub-TLV, all X-AF IPv4 and IPv6
   addresses local to the router that can be used by Constrained SPF
   (CSPF) to calculate MPLS TE LSPs.  In general, OSPF SHOULD advertise
   the IP address listed in the Router Address TLV [RFC3630] [RFC5329]
   of the X-AF instance maintaining the MPLS TE database, plus any
   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
   sub-TLV and the Node IPv6 Local Address sub-TLV, then the X-AF
   component MUST be considered for the consolidated calculation of MPLS
   TE LSPs.  Both instances MAY advertise the required information and
   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
   advertised into at most one area.  If OSPFv2 and OSPFv3 area border
   routers 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
   map locally created LSPs to tail-end routers in the Link State
   Database (LSDB).  The mapping algorithm can be described as:

      Walk the list of all MPLS TE tunnels for which the computing
      router is a head-end.  For each MPLS TE tunnel T:

Smirnov, et al.          Expires April 25, 2019                 [Page 4]
Internet-Draft    OSPF Routing with Cross-AF TE tunnels     October 2018

   1.  If T's destination IP address is from the same address family as
       the computing OSPF instance, then the tunnel must have been
       signaled based on MPLS TE information propagated in the same OSPF
       instance.  Process the tunnel as per [RFC3630] or [RFC5329].

   2.  Otherwise it is a X-AF MPLS TE tunnel.  Note tunnel's destination
       IP address.

   3.  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.

   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.

   The algorithm described above is to be used only if Node Local
   Address sub-TLV include X-AF information.

   Note that for clarity of description the mapping algorithm is
   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.

   As an example, consider a router in a dual-stack network respectively
   using OSPFv2 and OSPFv3 for IPv4 and IPv6 routing.  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 TLVs as required by [RFC3630].  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.

4.  Backward Compatibility

   Only routers that serve as endpoints for one or more TE tunnels MUST
   be upgraded to support the procedures described herein:

Smirnov, et al.          Expires April 25, 2019                 [Page 5]
Internet-Draft    OSPF Routing with Cross-AF TE tunnels     October 2018

   o  Tunnel tailend routers advertise the Node IPv4 Local Address sub-
      TLV and/or the Node IPv6 Local Address sub-TLV.

   o  Tunnel headend routers perform the X-AF routing calculation.

   Other routers in the network do not need to support X-AF procedures.

4.1.  Automatically Switched Optical Networks

   [RFC6827] updates [RFC5786] by defining extensions to be used in an
   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

   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 [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 affect 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 or even traffic loops.
   These threats are already present in other TE-related specifications,
   and their considerations apply here as well, including [RFC3630] and
   [RFC5329].

6.  IANA Considerations

   This document has no IANA actions.

7.  Acknowledgements

   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.

Smirnov, et al.          Expires April 25, 2019                 [Page 6]
Internet-Draft    OSPF Routing with Cross-AF TE tunnels     October 2018

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5786]  Aggarwal, R. and K. Kompella, "Advertising a Router's
              Local Addresses in OSPF Traffic Engineering (TE)
              Extensions", RFC 5786, DOI 10.17487/RFC5786, March 2010,
              <https://www.rfc-editor.org/info/rfc5786>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,
              <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>.

   [RFC4461]  Yasukawa, S., Ed., "Signaling Requirements for Point-to-
              Multipoint Traffic-Engineered MPLS Label Switched Paths
              (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006,
              <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
              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
              <https://www.rfc-editor.org/info/rfc5340>.

   [RFC6827]  Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou,
              Ed., "Automatically Switched Optical Network (ASON)
              Routing for OSPFv2 Protocols", RFC 6827,
              DOI 10.17487/RFC6827, January 2013,
              <https://www.rfc-editor.org/info/rfc6827>.

Smirnov, et al.          Expires April 25, 2019                 [Page 7]
Internet-Draft    OSPF Routing with Cross-AF TE tunnels     October 2018

Authors' Addresses

   Anton Smirnov
   Cisco Systems, Inc.
   De kleetlaan 6a
   Diegem  1831
   Belgium

   Email: as@cisco.com

   Alvaro Retana
   Huawei R&D USA
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Email: alvaro.retana@huawei.com

   Michael Barnes
   Cisco Systems, Inc.
   510 McCarthy Blvd.
   Milpitas, CA  95035
   USA

   Email: mjbarnes@cisco.com

Smirnov, et al.          Expires April 25, 2019                 [Page 8]