LISP Colored Engineered UnderlaysCisco SystemsCanadaddukes@cisco.comCisco SystemsUSAjearango@cisco.comThis document defines a LISP control plane extension that associates
a locator record with a color that can be used to select an engineered
underlay path to the corresponding RLOC.LISP provides reachability to overlay
addresses called Endpoint Indentifiers (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 that the EID maps to, then the ITR
would be able to select a policy matching that (color, RLOC) tuple to
satisfy the needs of the application or endpoint associated with this
particular EID. The expected use of the (color,RLOC) tuple is to select
a Segment Routing policy as defined in .This draft specifies an LCAF type 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 .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.The CO Flags are as defined in and have the
following impact on how the subsequent Color is interpreted. 00 is
their default value.When 00, the traffic destined to EID is preferably steered onto a
valid policy (N, C) where N is the IPv4/6 destination RLOC address
and C is a color value, else it is steered on the shortest path to
the next-hop N.When 01, the traffic destined to EID is preferably steered onto a
valid policy (N, C) else onto a valid policy (null endpoint, C) else
on the shortest path to the next-hop N.When 10, the traffic destined to EID is preferably steered onto a
valid policy (N, C) else onto a valid policy (null endpoint, C) else
on any valid SR-TE policy (any endpoint, C) else on the IGP path to
the next-hop NThe null endpoint is 0.0.0.0 for IPv4 and ::0 for IPv6 (all bits
set to 0).A 64-bit color value.The address family of the locator. Valid values
are 1 for IPv4 and 2 for IPv6.The address of the locator.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 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.