Network Working Group | D. Dukes |
Internet-Draft | Cisco Systems |
Intended status: Standards Track | J. Arango |
Expires: June 21, 2018 | Microsoft |
December 18, 2017 |
LISP Colored Engineered Underlays
draft-dukes-lisp-colored-engineered-underlays-01
This document defines a LISP control plane extension that associates a locator record with a color value that can be used to select an engineered underlay path to the corresponding RLOC.
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 June 21, 2018.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
LISP [RFC6830] provides reachability to overlay addresses called Endpoint Identifiers (EIDs) via one or more underlay addresses called Routing Locators (RLOCs). For each destination RLOC, it may be desirable for the control plane to select one of potentially multiple underlay paths.
For traffic traversing an Ingress Transit Router (ITR) to an Egress Transit Router (ETR), the ITR may be able to reach a particular ETR RLOC through multiple underlay paths available via one or more locally connected service providers. Furthermore, the ITR may be able to select which of these paths per provider to use, for example different paths may have unique bandwidth and latency metrics making them more or less suitable for traffic destined to some EIDs. When the ITR requests and obtains an EID mapping, it needs to know how to choose an underlay path for each remote RLOC. If the ETR can provide a hint in terms of an opaque color attribute for each RLOC the EID maps to, then the ITR would be able to select a policy matching that <RLOC,color> tuple to satisfy the needs of the application or endpoint associated with this particular EID.
One expected use of the <RLOC,color> tuple is to select a Segment Routing policy as defined in [I-D.filsfils-spring-segment-routing-policy].
This draft specifies an LCAF type [RFC8060] that encodes the color for each RLOC in an EID mapping record. The ITR MAY use the color to determine the underlay path to reach the EID via the corresponding RLOC.
A locator record now has an RLOC and color, and both fields are part of the comparison to determine if two locator records are the same.
The definition of how the color is chosen or configured at the ETR, or how policies are distributed and configured at the ITR is outside the scope of this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
When a color is stored in the LISP Mapping Database System for selection of an appropriate policy to reach an EID via a destination RLOC it MAY be encoded in a LISP Canonical Address.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = LCAF (16887) | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD |C|O| Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Color ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Color | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Color Canonical Address Type can be used to encode RLOC addresses.
Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages.
An assignment is requested from IANA "LISP LCAF Type" registry for the "Color LCAF", value is TBD.
The Color LCAF may indirectly indicate association of the type of service offered by some subsets of endpoints to ITRs that was not previously disclosed to the ITR.
[I-D.filsfils-spring-segment-routing-policy] | Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, F., Hegde, S., Lin, S., bogdanov@google.com, b., Horneffer, M., Steinberg, D., Decraene, B. and S. Litkowski, "Segment Routing Policy for Traffic Engineering", Internet-Draft draft-filsfils-spring-segment-routing-policy-03, October 2017. |
[I-D.ietf-lisp-ddt] | Fuller, V., Lewis, D., Ermagan, V., Jain, A. and A. Smirnov, "LISP Delegated Database Tree", Internet-Draft draft-ietf-lisp-ddt-09, January 2017. |
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
[RFC6830] | Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013. |
[RFC8060] | Farinacci, D., Meyer, D. and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017. |