<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="std"
     docName="draft-dukes-lisp-colored-engineered-underlays-00.txt"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes" ?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title>LISP Colored Engineered Underlays</title>

    <author fullname="Darren Dukes" initials="D." surname="Dukes">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street/>

          <country>Canada</country>
        </postal>

        <email>ddukes@cisco.com</email>
      </address>
    </author>

    <author fullname="Jesus Arango" initials="J." surname="Arango">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street/>

          <country>USA</country>
        </postal>

        <email>jearango@cisco.com</email>
      </address>
    </author>

    <date/>

    <abstract>
      <t>This 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.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>LISP <xref target="RFC6830"/> 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.</t>

      <t>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 <xref
      target="I-D.filsfils-spring-segment-routing-policy"/>.</t>

      <t>This draft specifies an LCAF type <xref target="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.</t>

      <t>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.</t>

      <t>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.</t>
    </section>

    <section title="Requirements Notation">
      <t>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 <xref
      target="RFC2119"/>.</t>
    </section>

    <section title="Color LCAF">
      <t>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.</t>

      <figure>
        <preamble/>

        <artwork>
	            
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      AFI = LCAF (16887)       |     Rsvd1     |     Flags     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type = TBD   |C|O|  Rsvd2    |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Color ...                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           ... Color                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             AFI               |            Address            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
	            </artwork>

        <postamble/>
      </figure>

      <t><list style="hanging">
          <t hangText="CO Flags: ">The CO Flags are as defined in <xref
          target="I-D.filsfils-spring-segment-routing-policy"/> and have the
          following impact on how the subsequent Color is interpreted. 00 is
          their default value.</t>

          <t>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.</t>

          <t>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.</t>

          <t>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 N</t>

          <t>The null endpoint is 0.0.0.0 for IPv4 and ::0 for IPv6 (all bits
          set to 0).</t>

          <t hangText="Color: ">A 64-bit color value.</t>

          <t hangText="AFI: ">The address family of the locator. Valid values
          are 1 for IPv4 and 2 for IPv6.</t>

          <t hangText="Address: ">The address of the locator.</t>
        </list></t>

      <t>The Color Canonical Address Type can be used to encode RLOC
      addresses.</t>

      <t>Usage: This encoding can be used in RLOC records in Map-Requests,
      Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT <xref
      target="I-D.ietf-lisp-ddt"/> is used as the mapping system mechanism,
      extended EIDs are used in Map-Referral messages.</t>
    </section>

    <section title="IANA Considerations">
      <t>An assignment is requested from IANA "LISP LCAF Type" registry for
      the "Color LCAF", value is TBD.</t>
    </section>

    <section title="Security Considerations">
      <t>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.</t>
    </section>
  </middle>

  <back>
    <references title="Informative References">
      <?rfc include='reference.I-D.filsfils-spring-segment-routing-policy.xml'?>
    </references>

    <references title="Normative References">
      <?rfc include='reference.RFC.6830' ?>

      <?rfc include='reference.I-D.ietf-lisp-ddt.xml' ?>

      <?rfc include='reference.RFC.2119' ?>

      <?rfc include='reference.RFC.8060' ?>
    </references>
  </back>
</rfc>
