Re: [lisp] Review draft-ietf-lisp-te

Luigi Iannone <ggx@gigix.net> Mon, 29 April 2024 09:24 UTC

Return-Path: <ggx@gigix.net>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146EEC169415 for <lisp@ietfa.amsl.com>; Mon, 29 Apr 2024 02:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkPnKRP6X3kG for <lisp@ietfa.amsl.com>; Mon, 29 Apr 2024 02:24:45 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327D0C169402 for <lisp@ietf.org>; Mon, 29 Apr 2024 02:24:44 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-41ba1ba5592so16811685e9.1 for <lisp@ietf.org>; Mon, 29 Apr 2024 02:24:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20230601.gappssmtp.com; s=20230601; t=1714382683; x=1714987483; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=EUPONOuWM1dEc345I6hAitwTRiI8fbZz8e2iIbYPglo=; b=XJuUClBnSq5UniZO0MLjuZuKH93V6XFtmq4KvBAD53K/3QUQpDpO4r0UKg1isLxxOw ZayRnjH8JyMut1uZTgl9UBJkiVW4dGt96NX+80uqCliguFTJL6Vp1EREEP0IfHBeN5T4 QbgRVdt3OPh8OxyFl9Ok2g+aGZMJauFtTpFxlsWqc9bqY/hWcPGsb8K0Ez3hOhGC6p0k iNHXPiPTcvkI6ndzFQST7MFbaBppNzP5gfd8isgBr/+LYYJBmN0QlCrz306u/0T528Hv wCNHZizVSAqYRO7t0KiahkHK6ZQZ2UBwJ88nW61xUzFA61PNsSdJyvu2hs9Hf7EmvYNp Ce1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714382683; x=1714987483; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EUPONOuWM1dEc345I6hAitwTRiI8fbZz8e2iIbYPglo=; b=r8ec+yicwvUB3zM/goQBS+TFdxKG7SFyZHGnCke8FncH2RToNHx4EmAAt9TrBnVdhW xTL3gAIwSAxZzAiFJ46CNZONjVCTun6wJ39yLTZIWGQw9C/nSwe7/YZfcYn3c7rIEGoW 0PqwD/xh/2jnxY9DvfjzhL9d9RAuliD3mwhePvIXw/V+jQgGr6wuWFz+JDIWzgl14bvL 3k3+DxY1Arkitsiz3WF9SizqzK9XO40GNJ6d1A+XFKfLMNtR9BGQhiLulagMT1UDqlu5 MxvzYbJH+2wFYC4GjQ9s0ZCxY3uUVOqx/v/DEnuIgLxXhyqEPuI9GyY2KisIEqYBkrPI ib9A==
X-Forwarded-Encrypted: i=1; AJvYcCUc0YHm7tX3CBpywaMqeiUe92WoiOXnSAEmAw+I+9lsqoSrmqiBHZVAdQrryqnB3uIh4t+tqF6cwqK5ML6i
X-Gm-Message-State: AOJu0Yxokjmt+KugU/GGoEda49fmrYwiGRHjbyP1E6aZEeQUW9VgZgpG RsTVWh9FjiG/LHZ9SzoNfLDfjqbek4UXszZwJZMe7z+lgZr34cBvnx48BEjMnAI=
X-Google-Smtp-Source: AGHT+IFbZchHO0rKaFtBd8V3i5yr8/Haa3p91V/+p6LS6lHeLSxwAbXvyhl/nMyjfx3S+2MCpGZZxA==
X-Received: by 2002:a05:600c:4f05:b0:416:7b2c:df0f with SMTP id l5-20020a05600c4f0500b004167b2cdf0fmr9229486wmq.7.1714382682718; Mon, 29 Apr 2024 02:24:42 -0700 (PDT)
Received: from smtpclient.apple (91-167-176-17.subs.proxad.net. [91.167.176.17]) by smtp.gmail.com with ESMTPSA id t13-20020a05600c198d00b0041c542636bcsm2145302wmq.44.2024.04.29.02.24.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Apr 2024 02:24:42 -0700 (PDT)
From: Luigi Iannone <ggx@gigix.net>
Message-Id: <681DC702-3BCA-404B-B12D-03F2109E2FFD@gigix.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_88F9DF6A-006F-4CB3-92C3-A0920BAFCCDF"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Date: Mon, 29 Apr 2024 11:24:10 +0200
In-Reply-To: <483F064A-2769-4271-A0BA-E69E72257D3E@gmail.com>
Cc: lisp-chairs@ietf.org, draft-ietf-lisp-te@ietf.org, LISP mailing list list <lisp@ietf.org>
To: Dino Farinacci <farinacci@gmail.com>
References: <43AE7DEC-BA11-4BA7-96BE-1CECCFAB5EA3@gigix.net> <483F064A-2769-4271-A0BA-E69E72257D3E@gmail.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/H-Fg0Z2qwnScMBj2QgyNGr4BEUU>
Subject: Re: [lisp] Review draft-ietf-lisp-te
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Apr 2024 09:24:50 -0000

Hi Dino,

It was marked to append the text to section 5. 

I’ve added  <PUT HERE MOVED TEXT> to mark the exact spot, should be easier now ;-)

Ciao

L.

> On 27 Apr 2024, at 15:54, Dino Farinacci <farinacci@gmail.com> wrote:
> 
> I browsed your comments. They are easier to interpret now. Thanks for that. However, your <move> references are not helpful because they indicate you want text to be moved but you don’t say where. So please clarify that before I make any changes. 
> 
> Dino
> 
>> On Apr 26, 2024, at 9:16 AM, Luigi Iannone <ggx@gigix.net> wrote:
>> 
>> 
>> Comments inline.
>> 
>> Ciao
>> 
>> L.
>> 
>> 
>>> 
>>> 
>>> 
>>> Internet Engineering Task Force                             D. Farinacci
>>> Internet-Draft                                               lispers.net
>>> Intended status: Experimental                                   M. Kowal
>>> Expires: 24 October 2024                                   cisco Systems
>>>                                                                P. Lahiri
>>>                                                            22 April 2024
>>> 
>>> 
>>>                         LISP Traffic Engineering
>>>                          draft-ietf-lisp-te-15
>>> 
>>> Abstract
>>> 
>>>    This document describes how LISP re-encapsulating tunnels can be used
>>>    for Traffic Engineering purposes.  The mechanisms described in this
>>>    document require no LISP protocol changes but do introduce a new
>>>    locator (RLOC) encoding.  The Traffic Engineering features provided
>>>    by these LISP mechanisms can span intra-domain, inter-domain, or
>>>    combination of both.
>>> 
>>> 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 24 October 2024.
>>> 
>>> Copyright Notice
>>> 
>>>    Copyright (c) 2024 IETF Trust and the persons identified as the
>>>    document authors.  All rights reserved.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024                [Page 1]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>>    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 Revised BSD License text as
>>>    described in Section 4.e of the Trust Legal Provisions and are
>>>    provided without warranty as described in the Revised BSD License.
>>> 
>>> Table of Contents
>>> 
>>>    1.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
>>>    2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
>>>    3.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   3
>>>    4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
>>>    5.  Explicit Locator Paths  . . . . . . . . . . . . . . . . . . .   5
>>>      5.1.  ELP Re-optimization . . . . . . . . . . . . . . . . . . .   7
>>>      5.2.  Using Recursion . . . . . . . . . . . . . . . . . . . . .   8
>>>      5.3.  ELP Selection based on Class of Service . . . . . . . . .   8
>>>      5.4.  Packet Loop Avoidance . . . . . . . . . . . . . . . . . .   9
>>>    6.  Service Chaining  . . . . . . . . . . . . . . . . . . . . . .  10
>>>    7.  RLOC Probing by RTRs  . . . . . . . . . . . . . . . . . . . .  10
>>>    8.  ELP Probing . . . . . . . . . . . . . . . . . . . . . . . . .  10
>>>    9.  Interworking Considerations . . . . . . . . . . . . . . . . .  11
>>>    10. Multicast Considerations  . . . . . . . . . . . . . . . . . .  12
>>>    11. Security Considerations . . . . . . . . . . . . . . . . . . .  14
>>>    12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
>>>    13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
>>>      13.1.  Normative References . . . . . . . . . . . . . . . . . .  14
>>>      13.2.  Informative References . . . . . . . . . . . . . . . . .  15
>>>    Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  16
>>>    Appendix B.  Document Change Log  . . . . . . . . . . . . . . . .  16
>>>      B.1.  Changes to draft-ietf-lisp-te-15  . . . . . . . . . . . .  16
>>>      B.2.  Changes to draft-ietf-lisp-te-14  . . . . . . . . . . . .  16
>>>      B.3.  Changes to draft-ietf-lisp-te-13  . . . . . . . . . . . .  16
>>>      B.4.  Changes to draft-ietf-lisp-te-12  . . . . . . . . . . . .  16
>>>      B.5.  Changes to draft-ietf-lisp-te-11  . . . . . . . . . . . .  16
>>>      B.6.  Changes to draft-ietf-lisp-te-10  . . . . . . . . . . . .  17
>>>      B.7.  Changes to draft-ietf-lisp-te-09  . . . . . . . . . . . .  17
>>>      B.8.  Changes to draft-ietf-lisp-te-08  . . . . . . . . . . . .  17
>>>      B.9.  Changes to draft-ietf-lisp-te-07  . . . . . . . . . . . .  17
>>>      B.10. Changes to draft-ietf-lisp-te-06  . . . . . . . . . . . .  17
>>>      B.11. Changes to draft-ietf-lisp-te-05  . . . . . . . . . . . .  17
>>>      B.12. Changes to draft-ietf-lisp-te-04  . . . . . . . . . . . .  17
>>>      B.13. Changes to draft-ietf-lisp-te-03  . . . . . . . . . . . .  17
>>>      B.14. Changes to draft-ietf-lisp-te-02  . . . . . . . . . . . .  18
>>>      B.15. Changes to draft-ietf-lisp-te-01  . . . . . . . . . . . .  18
>>>      B.16. Changes to draft-ietf-lisp-te-00  . . . . . . . . . . . .  18
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024                [Page 2]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>>      B.17. Changes to draft-farinacci-lisp-te-02 through -12 . . . .  18
>>>      B.18. Changes to draft-farinacci-lisp-te-01.txt . . . . . . . .  18
>>>      B.19. Changes to draft-farinacci-lisp-te-00.txt . . . . . . . .  18
>>>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18
>>> 
>>> 1.  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.
>>> 
>>> 2.  Introduction
>>> 
>>>    This document describes extensions to the Locator/Identifier
>>>    Separation Protocol (LISP) for traffic engineering features.
>>> 
>>>    When LISP routers encapsulate packets to other LISP routers, the path
>>>    stretch is typically 1, meaning the packet travels on a direct path
>>>    from the encapsulating ITR to the decapsulating ETR at the
>>>    destination site.  The direct path is determined by the underlying
>>>    routing protocol and metrics it uses to find the shortest path.
>>> 
>>>    This specification will examine how re-encapsulating tunnels
>>>    [RFC9300] can be used so a packet can take an administratively
>>>    specified path, a congestion avoidance path, a failure recovery path,
>>>    or multiple load-shared paths, as it travels from ITR to ETR.  By
>>>    introducing an Explicit Locator Path (ELP) locator encoding
>>>    [RFC8060], an ITR can encapsulate a packet to a Re-Encapsulating
>>>    Tunnel Router (RTR) which decapsulates the packet, then encapsulates
>>>    it to the next locator in the ELP.
>>> 
>>> 3.  Definition of Terms
>>> 
>>>    Refer to [RFC9300] for authoritative definitions for terms EID, RLOC,
>>>    RTR, and Recursive Tunneling.  The other terms defined in this
>>>    section add to the canonical definition to reflect the design
>>>    considerations in this specification.
>>> 
>>>    Explicit Locator Path (ELP):  The ELP is an explicit list of RLOCs
>>>       for each RTR a packet must travel to along its path toward a final
>>>       destination ETR (or PETR).  The list is a strict ordering where
>>>       each RLOC in the list is visited.  However, the path from one RTR
>>>       to another is determined by the underlying routing protocol and
>>>       how the infrastructure assigns metrics and policies for the path.
>>> 
>>>    Re-Encapsulating Tunnel Router (RTR):  An RTR is a router that acts
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024                [Page 3]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>>       as an ETR (or PETR) by decapsulating packets where the destination
>>>       address in the "outer" IP header is one of its own RLOCs.  Then
>>>       acts as an ITR (or PITR) by making a decision where to encapsulate
>>>       the packet based on the next locator in the ELP towards the final
>>>       destination ETR.
>> For that you do not need to re-define the RTR term. You just need to state that RTR uses ELPs in the body of this document, which you do.
>> The must be only one document authoritative on the terms, and 9300 is already there.
>>> 4.  Overview
>>> 
>>>    Typically, a packet's path from source EID to destination EID travels
>>>    through the locator core via the encapsulating ITR directly to the
>>>    decapsulating ETR as the following diagram illustrates:
>>> 
>>>    Legend:
>>> 
>>>    seid:  Packet is originated by source EID 'seid'.
>>> 
>>>    deid:  Packet is consumed by destination EID 'deid'.
>>> 
>>>    A,B,C,D :  Core routers in different ASes.
>>> 
>>>    ---> :  The physical topological path between two routers.
>>> 
>>>    ===> :  A multi-hop LISP dynamic tunnel between LISP routers.
>>> 
>>> 
>>>                               Core Network
>>>    Source site       (----------------------------)    Destination Site
>>>    +--------+        (                            )         +---------+
>>>    |         \       (                            )        /          |
>>>    | seid     ITR ---(---> A --> B --> C --> D ---)---> ETR      deid |
>>>    |         / ||    (                            )     ^^ \          |
>>>    +--------+  ||    (                            )     ||  +---------+
>>>                ||    (----------------------------)     ||
>>>                ||                                       ||
>>>                ===========================================
>>>                                 LISP Tunnel
>>> 
>>> 
>>>                 Figure 1: Typical Data Path from ITR to ETR
>>> 
>>> 
>>>    Let's introduce RTRs 'X' and 'Y' so that, for example, if it is
>>>    desirable to route around the path from B to C, one could provide an
>>>    ELP of (X,Y,etr):
>>> 
>>> 
>>> 
>> In the current figure 2 there is no physical path, between X and Y, that "routes around” the path from B to C. 
>> Packets will still go through the path B to C, in contradiction with your objective “route around the path from B to C”.
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024                [Page 4]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>>                               Core Network
>>>    Source site       (----------------------------)    Destination Site
>>>    +--------+        (                            )         +---------+
>>>    |         \       (                            )        /          |
>>>    | seid     ITR ---(---> A --> B --> C --> D ---)---> ETR      deid |
>>>    |         / ||    (          /      ^          )     ^^ \          |
>>>    |        /  ||    (         |        \         )     ||  \         |
>>>    +-------+   ||    (         v         |        )     ||   +--------+
>>>                ||    (         X ======> Y        )     ||
>>>                ||    (        ^^         ||       )     ||
>>>                ||    (--------||---------||-------)     ||
>>>                ||             ||         ||             ||
>>>                =================         =================
>>>                  LISP Tunnel                 LISP Tunnel
>>> 
>>> 
>>>    Figure 2: ELP tunnel path ITR ==> X, then X ==> Y, and then Y ==> ETR
>>> 
>>> 
>>>    There are various reasons why the path from 'seid' to 'deid' may want
>>>    to avoid the path from B to C.  To list a few:
>>> 
>>>    *  There may not be sufficient capacity provided by the networks that
>>>       connect B and C together.
>>> 
>>>    *  There may be a policy reason to avoid the ASes that make up the
>>>       path between B and C.
>>> 
>>>    *  There may be a failure on the path between B and C which makes the
>>>       path unreliable.
>>> 
>>>    *  There may be monitoring or traffic inspection resources close to
>>>       RTRs X and Y that do network accounting or measurement.
>>> 
>>>    *  There may be a chain of services performed at RTRs X and Y
>>>       regardless if the path from ITR to ETR is through B and C.
>>> 
>>> 5.  Explicit Locator Paths
>> 
>> This is the main technical contribution of this document and should be separated from the use cases. However, some of the technical details is spread in the use cases. 
>> Paragraphs that should be appended to this sections are enclosed by the tags <move> </move>.
>>>    The notation for a general formatted ELP is (x, y, etr) which
>>>    represents the list of RTRs a packet SHOULD travel through to reach
>>>    the final tunnel hop to the ETR.
>>> 
>>>    The procedure for using an ELP at each tunnel hop is as follows:
>>> 
>>>    1.  The ITR will retrieve the ELP from the mapping database.
>>> 
>>>    2.  The ITR will encapsulate the packet to RLOC 'x'.
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024                [Page 5]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>>    3.  The RTR with RLOC 'x' will decapsulate the packet.  It will use
>>>        the decapsulated packet's destination address as a lookup into
>>>        the mapping database to retrieve the ELP.
>>> 
>>>    4.  RTR 'x' will encapsulate the packet to RTR with RLOC 'y'.
>>> 
>>>    5.  The RTR with RLOC 'y' will decapsulate the packet.  It will use
>>>        the decapsulated packet's destination address as a lookup into
>>>        the mapping database to retrieve the ELP.
>>> 
>>>    6.  RTR 'y' will encapsulate the packet on the final tunnel hop to
>>>        ETR with RLOC 'etr'.
>>> 
>>>    7.  The ETR will decapsulate the packet and deliver the packet to the
>>>        EID inside of its site.
>>> 
>>>    The specific encoding format for the ELP can be found in [RFC8060].
>>>    It is defined that an ELP will appear as a single encoded locator in
>>>    a locator-set.  Say for instance, we have a mapping entry for EID-
>>>    prefix 10.0.0.0/8 that is reachable via 4 locators.  Two locators are
>>>    being used as active/active and the other two are used as active/
>>>    active if the first two go unreachable (as noted by the priority
>>>    assignments below).  This is what the mapping entry would look like:
>>> 
>>> 
>>>    EID-prefix:   10.0.0.0/8
>>>    Locator-set:  ETR-A: priority 1, weight 50
>>>                  ETR-B: priority 1, weight 50
>>>                  ETR-C: priority 2, weight 50
>>>                  ETR-D: priority 2, weight 50
>>> 
>>> 
>>>    If an ELP is going to be used to have a policy path to ETR-A and
>>>    possibly another policy path to ETR-B, the locator-set would be
>>>    encoded as follows:
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024                [Page 6]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>>    EID-prefix:   10.0.0.0/8
>>>    Locator-set:  (x, y, ETR-A): priority 1, weight 50
>>>                  (q, r, ETR-B): priority 1, weight 50
>>>                  ETR-C:         priority 2, weight 50
>>>                  ETR-D:         priority 2, weight 50
>>> 
>>> 
>>>    The mapping entry with ELP locators is registered to the mapping
>>>    database system just like any other mapping entry would.  The
>>>    registration is typically performed by the ETR(s) that are assigned
>>>    and own the EID-prefix. 
>> Add reference to RFC9301.
>> You state that ELP are registered as any other mapping but you do not state how they are retrieved by the RTRs.
>> Put a sentence and a reference to RFC9300.
>> 
>>>  That is, the destination site makes the
>>>    choice of the RTRs in the ELP.  Alternatively, it may be common
>>>    practice for a provisioning system to program the mapping database
>>>    with ELPs.
>> Do not understand the role of this provisioning system. Clarify or delete.
>> 
>>>    Another case where a locator-set can be used for flow-based load-
>>>    sharing across multiple paths to the same destination site:
>>> 
>>> 
>>>    EID-prefix:   10.0.0.0/8
>>>    Locator-set:  (x, y, ETR-A): priority 1, weight 75
>>>                  (q, r, ETR-A): priority 1, weight 25
>>> 
>>> 
>>>    Using this mapping entry, an ITR would load split 75% of the EID
>>>    flows on the (x, y, ETR-A) ELP path and 25% of the EID flows on the
>>>    (q, r, ETR-A) ELP path.  If any of the ELPs go down, then the other
>>>    can take 100% of the load.
>>>  

<PUT HERE MOVED TEXT>


>> Dino, you correct text mixes specifications and use cases. By concentrating the specifications in one section (namely section 5) you will improve readability and clarity of the document. 
>> 
>> Put here:
>> 
>> 6. Use cases
>> 
>> And renumber the subsections.
>> 
>>> 5.1.  ELP Re-optimization
>> 
>> <move>
>>>    ELP re-optimization is a process of changing the RLOCs of an ELP due
>>>    to underlying network change conditions.  Just like when there is any
>>>    locator change for a locator-set, the procedures from the main LISP
>>>    specification [RFC9300] are followed.
>>> 
>>>    When a RLOC from an ELP is changed, Map-Notify messages [RFC9301] can
>>>    be used to inform the existing RTRs in the ELP so they can do a
>>>    lookup to obtain the latest version of the ELP.  Map-Notify messages
>>>    can also be sent to new RTRs in an ELP so they can get the ELP in
>>>    advance to receiving packets that will use the ELP.  This can
>>>    minimize packet loss during mapping database lookups in RTRs.
>>> 
>>> 
>> </move>
>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024                [Page 7]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>> 5.2.  Using Recursion
>>> 
>>>    In the previous examples, we showed how an ITR encapsulates using an
>>>    ELP of (x, y, etr).  When a packet is encapsulated by the ITR to RTR
>>>    'x', the RTR may want a policy path to RTR 'y' and run another level
>>>    of re-encapsulating tunnels for packets destined to RTR 'y'.  In this
>>>    case, RTR 'x' does not encapsulate packets to 'y' but rather performs
>>>    a mapping database lookup on the address 'y', requests the ELP for
>>>    RTR 'y', 
>> What really request is a mapping, which may or may not be an ELP.
>> What happens if it receives a negative map-reply?
>> 
>>> and encapsulates packets to the first-hop of the returned
>>>    ELP.  This can be done when using a public or private mapping
>>>    database.  
>> You mean that this second lookup can be done on a mapping system that is different from the one who delivered the initial ELP, right?
>> If yes, can you state so?
>> 
>>> The decision to use address 'y' as an encapsulation
>>>    address versus a lookup address is based on the L-bit 
>> How the S-bit, L-bit, and the P-bit are used is not covered at all and should be described in section 5.
>> 
>> 
>>> setting for 'y'
>>>    in the ELP entry.  The decision and policy of ELP encodings are local
>>>    to the entity which registers the EID-prefix associated with the ELP.
>>> 
>>>    Another example of recursion is when the ITR uses the ELP (x, y, etr)
>>>    to first prepend a header with a destination RLOC of the ETR and then
>>>    prepend another header and encapsulate the packet to RTR 'x'.  When
>>>    RTR 'x' decapsulates the packet, rather than doing a mapping database
>>>    lookup on RTR 'y' the last example showed, instead RTR 'x' does a
>>>    mapping database lookup on ETR 'etr'.  In this scenario, RTR 'x' can
>>>    choose an ELP from the locator-set by considering the source RLOC
>>>    address of the ITR versus considering the source EID.
>>> 
>>>    This additional level of recursion also brings advantages for the
>>>    provider of RTR 'x' to store less state.  Since RTR 'x' does not need
>>>    to look at the inner most header, it does not need to store EID
>>>    state.  It only stores an entry for RTR 'y' which many EID flows
>>>    could share for scaling benefits.  The locator-set for entry 'y'
>>>    could either be a list of typical locators, a list of ELPs, or
>>>    combination of both.  Another advantage is that packet load-splitting
>>>    can be accomplished by examining the source of a packet.  If the
>>>    source is an ITR versus the source being the last-hop of an ELP the
>>>    last-hop selected, different forwarding paths can be used.
>>> 
>>> 5.3.  ELP Selection based on Class of Service
>>> 
>>>    Paths to an ETR may want to be selected based on different classes of
>>>    service.  Packets from a set of sources that have premium service can
>>>    use ELP paths that are less congested where normal sources use ELP
>>>    paths that compete for less resources or use longer paths for best
>>>    effort service.
>>> 
>>>    Using source/destination lookups into the mapping database can yield
>>>    different ELPs.  For example, a premium service flow with
>>>    (source=1.1.1.1, dest=10.1.1.1) can be described by using the
>>>    following mapping entry:
>>> 
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024                [Page 8]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>>    EID-prefix:   (1.0.0.0/8, 10.0.0.0/8)
>>>    Locator-set:  (x, y, ETR-A): priority 1, weight 50
>>>                  (q, r, ETR-A): priority 1, weight 50
>>> 
>>> 
>>>    And all other best-effort sources would use different mapping entry
>>>    described by:
>>> 
>>> 
>>>    EID-prefix:   (0.0.0.0/0, 10.0.0.0/8)
>>>    Locator-set:  (x, x', y, y', ETR-A): priority 1, weight 50
>>>                  (q, q', r, r', ETR-A): priority 1, weight 50
>>> 
>>> 
>>>    If the source/destination lookup is coupled with recursive lookups,
>>>    then an ITR can encapsulate to the ETR, prepending a header that
>>>    selects source address ITR-1 based on the premium class of service
>>>    source, or selects source address ITR-2 for best-effort sources with
>>>    normal class of service.  The ITR then does another lookup in the
>>>    mapping database on the prepended header using lookup key
>>>    (source=ITR-1, dest=10.1.1.1) that returns the following mapping
>>>    entry:
>>> 
>>> 
>>>    EID-prefix:   (ITR-1, 10.0.0.0/8)
>>>    Locator-set:  (x, y, ETR-A): priority 1, weight 50
>>>                  (q, r, ETR-A): priority 1, weight 50
>>> 
>>> 
>>>    And all other sources would use different mapping entry with a lookup
>>>    key of (source=ITR-2, dest=10.1.1.1):
>>> 
>>> 
>>>    EID-prefix:   (ITR-2, 10.0.0.0/8)
>>>    Locator-set:  (x, x', y, y', ETR-A): priority 1, weight 50
>>>                  (q, q', r, r', ETR-A): priority 1, weight 50
>>> 
>>> 
>>>    This will scale the mapping system better by having fewer source/
>>>    destination combinations.  Refer to the Source/Dest LCAF type
>>>    described in [RFC8060] for encoding EIDs in Map-Request and Map-
>>>    Register messages.
>>> 
>>> 5.4.  Packet Loop Avoidance
>>> 
>> <move>
>>>    An ELP that is first used by an ITR must be inspected for encoding
>>>    loops.  If any RLOC appears twice in the ELP, it MUST not be used.
>>> 
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024                [Page 9]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>>    Since it is expected that multiple mapping systems will be used,
>>>    there can be a loop across ELPs when registered in different mapping
>>>    systems.  The TTL copying procedures for re-encapsulating tunnels and
>>>    recursive tunnels in [RFC9300] MUST be followed.
>>> 
>> </move>
>> 
>>> 6.  Service Chaining
>>> 
>>>    An ELP can be used to deploy services at each reencapsulation point
>>>    in the network.  One example is to implement a honey-pot service when
>>>    a destination EID is being DoS attacked.  That is, when a DoS attack
>>>    is recognized when the encapsulation path is between ITR and ETR, an
>>>    ELP can be registered for a destination EID to the mapping database
>>>    system.  The ELP can include an RTR so the ITR can encapsulate
>>>    packets to the RTR which will decapsulate and deliver packets to a
>>>    scrubber service device.  The scrubber could decide if the offending
>>>    packets are dropped or allowed to be sent to the destination EID.  In
>>>    which case, the scurbber delivers packets back to the RTR which
>>>    encapsulates to the ETR.
>>> 
>>> 7.  RLOC Probing by RTRs
>>> 
>> <move>
>>>    Since an RTR knows the next tunnel hop to encapsulate to, it can
>>>    monitor the reachability of the next-hop RTR RLOC by doing RLOC-
>>>    probing according to the procedures in [RFC9300].  When the RLOC is
>>>    determined unreachable by the RLOC-probing mechanisms, the RTR can
>>>    use another locator in the locator-set.  That could be the final ETR,
>>>    a RLOC of another RTR, or an ELP where it must search for itself and
>>>    use the next RLOC in the ELP list to encapsulate to.
>>> 
>>>    RLOC-probing can also be used to measure delay on the path between
>>>    RTRs and when it is desirable switch to another lower delay ELP.
>>> 
>> </move>
>>> 8.  ELP Probing
>>> 
>>>    Since an ELP-node knows the reachabiliy of the next ELP-node in a ELP
>>>    by using RLOC probing, the sum of reachability can determine the
>>>    reachability of the entire path.  A head-end ITR/RTR/PITR can
>>>    determine the quality of a path and decide to select one path from
>>>    another based on the telemetry data gathered by RLOC-probing for each
>>>    encapsulation hop.
>>> 
>>>    ELP-probing mechanism details can be found in
>>>    [I-D.filyurin-lisp-elp-probing].
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024               [Page 10]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>> 9.  Interworking Considerations
>>> 
>>>    [RFC6832] defines procedures for how non-LISP sites talk to LISP
>>>    sites.  The network elements defined in the Interworking
>>>    specification, the proxy ITR (PITR) and proxy ETR (PETR) (as well as
>>>    their multicast counterparts defined in [RFC6831]) can participate in
>>>    LISP-TE.  That is, a PITR and a PETR can appear in an ELP list and
>>>    act as an RTR.
>>> 
>> <move>
>>>    Note when an RLOC appears in an ELP, it can be of any address-family.
>>>    There can be a mix of IPv4 and IPv6 locators present in the same ELP.
>>>    This can provide benefits where islands of one address-family or the
>>>    other are supported and connectivity across them is necessary.  For
>>>    instance, an ELP can look like:
>>> 
>>>    (x4, a46, b64, y4, etr)
>>> 
>>>    Where an IPv4 ITR will encapsulate using an IPv4 RLOC 'x4' and 'x4'
>>>    could reach an IPv4 RLOC 'a46', but RTR 'a46' encapsulates to an IPv6
>>>    RLOC 'b64' when the network between them is IPv6-only.  Then RTR
>>>    'b64' encapsulates to IPv4 RLOC 'y4' if the network between them is
>>>    dual-stack.
>>> 
>> </move>
>>>    Note that RTRs can be used for NAT-traversal scenarios
>>>    [I-D.ermagan-lisp-nat-traversal] as well to reduce the state in both
>>>    an xTR that resides behind a NAT and the state the NAT needs to
>>>    maintain.  In this case, the xTR only needs a default map-cache entry
>>>    pointing to the RTR for outbound traffic and all remote ITRs can
>>>    reach EIDs through the xTR behind a NAT via a single RTR (or a small
>>>    set RTRs for redundancy).
>>> 
>>>    RTRs have some scaling features to reduce the number of locator-set
>>>    changes, the amount of state, and control packet overhead:
>>> 
>>>    *  When ITRs and PITRs are using a small set of RTRs for
>>>       encapsulating to "orders of magnitude" more EID-prefixes, the
>>>       probability of locator-set changes are limited to the RTR RLOC
>>>       changes versus the RLOC changes for the ETRs associated with the
>>>       EID-prefixes if the ITRs and PITRs were directly encapsulating to
>>>       the ETRs.  This comes at an expense in packet stretch, but
>>>       depending on RTR placement, this expense can be mitigated.
>>> 
>>>    *  When RTRs are on-path between many pairwise EID flows, ITRs and
>>>       PITRs can store a small number of coarse EID-prefixes.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024               [Page 11]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>>    *  RTRs can be used to help scale RLOC-probing.  Instead of ITRs
>>>       RLOC-probing all ETRs for each destination site it has cached, the
>>>       ITRs can probe a smaller set of RTRs which in turn, probe the
>>>       destination sites.
>>> 
>>> 10.  Multicast Considerations
>>> 
>>>    ELPs have application in multicast environments.  Just like RTRs can
>>>    be used to provide connectivity across different address family
>>>    islands, RTRs can help concatenate a multicast region of the network
>>>    to one that does not support native multicast.
>>> 
>>>    Note there are various combinations of connectivity that can be
>>>    accomplished with the deployment of RTRs and ELPs:
>>> 
>>>    *  Providing multicast forwarding between IPv4-only-unicast regions
>>>       and IPv4-multicast regions.
>>> 
>>>    *  Providing multicast forwarding between IPv6-only-unicast regions
>>>       and IPv6-multicast regions.
>>> 
>>>    *  Providing multicast forwarding between IPv4-only-unicast regions
>>>       and IPv6-multicast regions.
>>> 
>>>    *  Providing multicast forwarding between IPv6-only-unicast regions
>>>       and IPv4-multicast regions.
>>> 
>>>    *  Providing multicast forwarding between IPv4-multicast regions and
>>>       IPv6-multicast regions.
>>> 
>>>    An ITR or PITR can do a (S-EID,G) lookup into the mapping database.
>>>    What can be returned is a typical locator-set that could be made up
>>>    of the various RLOC addresses:
>>> 
>>> 
>>>    Multicast EID key:  (S-EID, G)
>> The document uses a mix of “seid” and “S-EID”, choose one.
>> 
>>>    Locator-set:        ETR-A: priority 1, weight 25
>>>                        ETR-B: priority 1, weight 25
>>>                        g1:    priority 1, weight 25
>>>                        g2:    priority 1, weight 25
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024               [Page 12]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>>     Figure 3: An entry for host 'S-EID' sending to application group 'G'
>>> 
>>> 
>>>    The locator-set above can be used as a replication list.  That is
>>>    some RLOCs listed can be unicast RLOCs and some can be delivery group
>>>    RLOCs.  A unicast RLOC in this case is used to encapsulate a
>>>    multicast packet originated by a multicast source EID into a unicast
>>>    packet for unicast delivery on the underlying network.  ETR-A could
>>>    be an IPv4 unicast RLOC address and ETR-B could be a IPv6 unicast
>>>    RLOC address.
>>> 
>>>    A delivery group address is used when a multicast packet originated
>>>    by a multicast source EID is encapsulated in a multicast packet for
>>>    multicast delivery on the underlying network.  Group address 'g1'
>>>    could be an IPv4 delivery group RLOC and group address 'g2' could be
>>>    an IPv6 delivery group RLOC.
>>> 
>>>    Flexibility for these various types of connectivity combinations can
>>>    be achieved and provided by the mapping database system.  And the RTR
>>>    placement allows the connectivity to occur where the differences in
>>>    network functionality is located.
>>> 
>>>    Extending this concept by allowing ELPs in locator-sets, one could
>>>    have this locator-set registered in the mapping database for (S-EID,
>>>    G).  For example:
>>> 
>>> 
>>>    Multicast EID key:  (S-EID, G)
>>>    Locator-set:        (x, y, ETR-A):    priority 1, weight 50
>>>                        (a, g, b, ETR-B): priority 1, weight 50
>>> 
>>>                   Figure 4: Using ELPs for multicast flows
>>> 
>>> 
>>>    In the above situation, an ITR would encapsulate a multicast packet
>>>    originated by a multicast source EID to the RTR with unicast RLOC
>>>    'x'.  Then RTR 'x' would decapsulate and unicast encapsulate to RTR
>>>    'y' ('x' or 'y' could be either IPv4 or IPv6 unicast RLOCs), which
>>>    would decapsulate and unicast encapsulate to the final RLOC 'ETR-A'.
>>>    The ETR 'ETR-A' would decapsulate and deliver the multicast packet
>>>    natively to all the receivers joined to application group 'G' inside
>>>    the LISP site.
>>> 
>>>    Let's look at the ITR using the ELP (a, g, b, ETR-B).  Here the
>>>    encapsulation path would be the ITR unicast encapsulates to unicast
>>>    RLOC 'a'.  RTR 'a' multicast encapsulates to delivery group 'g'.  The
>>>    packet gets to all ETRs that have joined delivery group 'g' so they
>>>    can deliver the multicast packet to joined receivers of application
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024               [Page 13]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>>    group 'G' in their sites.  RTR 'b' is also joined to delivery group
>>>    'g'. 
>> What if it isn’t? Or what if there are several RTR that should re-encap in unicast? It look underspecified to me.
>> 
>>>  Since it is in the ELP, it will be the only RTR that unicast
>>>    encapsulates the multicast packet to ETR 'ETR-B'.  Lastly, 'ETR-B'
>>>    decapsulates and delivers the multicast packet to joined receivers to
>>>    application group 'G' in its LISP site.
>>> 
>>>    As one can see there are all sorts of opportunities to provide
>>>    multicast connectivity across a network with non-congruent support
>>>    for multicast and different address-families.  One can also see how
>>>    using the mapping database can allow flexible forms of delivery
>>>    policy, rerouting, and congestion control management in multicast
>>>    environments.
>>> 
>>> 11.  Security Considerations
>>> 
>>>    When an RTR receives a LISP encapsulated packet, it can look at the
>>>    outer source address to verify that RLOC is the one listed as the
>>>    previous hop in the ELP list.  If the outer source RLOC address
>>>    appears before the RLOC which matches the outer destination RLOC
>>>    address, the decapsulating RTR (or ETR if last hop), MAY choose to
>>>    drop the packet.
>> Why not a SHOULD?
>> Flexibility is not a sufficient answer. The MAY opens the door to security issues. 
>> How does this work with LISP-SEC? IMO there is no changes needed, it just works out of the box. Would be good to state it explicitly.
>> 
>> I would add a sentence about new attacks. Refer to RFC7835 and state if there are additional attack. If not, just state explicitly that no new attack vectors are introduced by this mechanism.
>>> 12.  IANA Considerations
>>> 
>>>    This document does not make any request to IANA.
>>> 
>>> 13.  References
>>> 
>>> 13.1.  Normative References
>>> 
>>>    [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
>>>               DOI 10.17487/RFC0791, September 1981,
>>>               <https://www.rfc-editor.org/info/rfc791>.
>>> 
>>>    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
>>>               STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
>>>               <https://www.rfc-editor.org/info/rfc1034>.
>>> 
>>>    [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>.
>>> 
>>>    [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
>>>               (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
>>>               December 1998, <https://www.rfc-editor.org/info/rfc2460>.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024               [Page 14]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>>    [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
>>>               A., Peterson, J., Sparks, R., Handley, M., and E.
>>>               Schooler, "SIP: Session Initiation Protocol", RFC 3261,
>>>               DOI 10.17487/RFC3261, June 2002,
>>>               <https://www.rfc-editor.org/info/rfc3261>.
>>> 
>>>    [RFC6831]  Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
>>>               Locator/ID Separation Protocol (LISP) for Multicast
>>>               Environments", RFC 6831, DOI 10.17487/RFC6831, January
>>>               2013, <https://www.rfc-editor.org/info/rfc6831>.
>>> 
>>>    [RFC6832]  Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
>>>               "Interworking between Locator/ID Separation Protocol
>>>               (LISP) and Non-LISP Sites", RFC 6832,
>>>               DOI 10.17487/RFC6832, January 2013,
>>>               <https://www.rfc-editor.org/info/rfc6832>.
>>> 
>>>    [RFC8060]  Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
>>>               Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
>>>               February 2017, <https://www.rfc-editor.org/info/rfc8060>.
>>> 
>>>    [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>.
>>> 
>>>    [RFC9300]  Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
>>>               Cabellos, Ed., "The Locator/ID Separation Protocol
>>>               (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
>>>               <https://www.rfc-editor.org/info/rfc9300>.
>>> 
>>>    [RFC9301]  Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
>>>               Ed., "Locator/ID Separation Protocol (LISP) Control
>>>               Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
>>>               <https://www.rfc-editor.org/info/rfc9301>.
>>> 
>>> 13.2.  Informative References
>>> 
>>>    [I-D.ermagan-lisp-nat-traversal]
>>>               Ermagan, V., Farinacci, D., Lewis, D., Maino, F.,
>>>               Portoles-Comeras, M., Skriver, J., White, C., Brescó, A.
>>>               L., and A. Cabellos-Aparicio, "NAT traversal for LISP",
>>>               Work in Progress, Internet-Draft, draft-ermagan-lisp-nat-
>>>               traversal-19, 7 May 2021,
>>>               <https://datatracker.ietf.org/doc/html/draft-ermagan-lisp-
>>>               nat-traversal-19>.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024               [Page 15]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>>    [I-D.filyurin-lisp-elp-probing]
>>>               Filyurin, Y., Raszuk, R., Boyes, T., and D. Farinacci,
>>>               "LISP Explicit Locator Path (ELP) Probing", Work in
>>>               Progress, Internet-Draft, draft-filyurin-lisp-elp-probing-
>>>               01, 14 May 2018, <https://datatracker.ietf.org/doc/html/
>>>               draft-filyurin-lisp-elp-probing-01>.
>>> 
>>> Appendix A.  Acknowledgments
>>> 
>>>    The authors would like to thank the following people for their ideas
>>>    and comments.  They are Albert Cabellos, Khalid Raza, and Vina
>>>    Ermagan, Gregg Schudel, Yan Filyurin, Robert Raszuk, and Truman
>>>    Boyes.
>>> 
>>> Appendix B.  Document Change Log
>>> 
>>> B.1.  Changes to draft-ietf-lisp-te-15
>>> 
>>>    *  Posted April 2024.
>>> 
>>>    *  Made changes to reflect comments from Luigi as we ready document
>>>       for standards track.
>>> 
>>> B.2.  Changes to draft-ietf-lisp-te-14
>>> 
>>>    *  Posted February 2024.
>>> 
>>>    *  Update references and document timer.
>>> 
>>> B.3.  Changes to draft-ietf-lisp-te-13
>>> 
>>>    *  Posted August 2023.
>>> 
>>>    *  Update references (to proposed standard documents) and document
>>>       timer.
>>> 
>>> B.4.  Changes to draft-ietf-lisp-te-12
>>> 
>>>    *  Posted March 2023.
>>> 
>>>    *  Update references (to propsed standard documents) and document
>>>       timer.
>>> 
>>> B.5.  Changes to draft-ietf-lisp-te-11
>>> 
>>>    *  Posted September 2022.
>>> 
>>>    *  Update document timer and references.
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024               [Page 16]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>> B.6.  Changes to draft-ietf-lisp-te-10
>>> 
>>>    *  Posted March 2022.
>>> 
>>>    *  Update document timer and references.
>>> 
>>> B.7.  Changes to draft-ietf-lisp-te-09
>>> 
>>>    *  Posted September 2021.
>>> 
>>>    *  Update document timer and references.
>>> 
>>> B.8.  Changes to draft-ietf-lisp-te-08
>>> 
>>>    *  Posted March 2021.
>>> 
>>>    *  Update document timer and references.
>>> 
>>> B.9.  Changes to draft-ietf-lisp-te-07
>>> 
>>>    *  Posted October 2020.
>>> 
>>>    *  Update document timer and references.
>>> 
>>> B.10.  Changes to draft-ietf-lisp-te-06
>>> 
>>>    *  Posted April 2020.
>>> 
>>>    *  Update document timer and references.
>>> 
>>> B.11.  Changes to draft-ietf-lisp-te-05
>>> 
>>>    *  Posted October 2019.
>>> 
>>>    *  Update document timer and references.
>>> 
>>> B.12.  Changes to draft-ietf-lisp-te-04
>>> 
>>>    *  Posted April 2019.
>>> 
>>>    *  Update document timer and references.
>>> 
>>> B.13.  Changes to draft-ietf-lisp-te-03
>>> 
>>>    *  Posted October 2018.
>>> 
>>>    *  Update document timer and references.
>>> 
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024               [Page 17]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>> B.14.  Changes to draft-ietf-lisp-te-02
>>> 
>>>    *  Posted April 2018.
>>> 
>>>    *  Update document timer and references.
>>> 
>>> B.15.  Changes to draft-ietf-lisp-te-01
>>> 
>>>    *  Posted October 2017.
>>> 
>>>    *  Added section on ELP-probing that tells an ITR/RTR/PITR the
>>>       feasibility and reachability of an Explicit Lcoator Path.
>>> 
>>> B.16.  Changes to draft-ietf-lisp-te-00
>>> 
>>>    *  Posted April 2017.
>>> 
>>>    *  Changed draft-farinacci-lisp-te-12 to working group document.
>>> 
>>> B.17.  Changes to draft-farinacci-lisp-te-02 through -12
>>> 
>>>    *  Many postings from January 2013 through February 2017.
>>> 
>>>    *  Update references and document timer.
>>> 
>>> B.18.  Changes to draft-farinacci-lisp-te-01.txt
>>> 
>>>    *  Posted July 2012.
>>> 
>>>    *  Add the Lookup bit to allow an ELP to be a list of encapsulation
>>>       and/or mapping database lookup addresses.
>>> 
>>>    *  Indicate that ELPs can be used for service chaining.
>>> 
>>>    *  Add text to indicate that Map-Notify messages can be sent to new
>>>       RTRs in a ELP so their map-caches can be pre-populated to avoid
>>>       mapping database lookup packet loss.
>>> 
>>>    *  Fixes to editorial comments from Gregg.
>>> 
>>> B.19.  Changes to draft-farinacci-lisp-te-00.txt
>>> 
>>>    *  Initial draft posted March 2012.
>>> 
>>> Authors' Addresses
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024               [Page 18]
>>> 
>>> Internet-Draft          LISP Traffic Engineering              April 2024
>>> 
>>> 
>>>    Dino Farinacci
>>>    lispers.net
>>>    San Jose, California
>>>    United States of America
>>>    Phone: 408-718-2001
>>>    Email: farinacci@gmail.com
>>> 
>>> 
>>>    Michael Kowal
>>>    cisco Systems
>>>    111 Wood Avenue South
>>>    ISELIN, NJ
>>>    United States of America
>>>    Email: mikowal@cisco.com
>>> 
>>> 
>>>    Parantap Lahiri
>>>    United States of America
>>>    Email: parantap.lahiri@gmail.com
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Farinacci, et al.        Expires 24 October 2024               [Page 19]