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]
- [lisp] Re: Review draft-ietf-lisp-te Padma Pillay-Esnault
- Re: [lisp] Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Review draft-ietf-lisp-te Luigi Iannone
- Re: [lisp] Review draft-ietf-lisp-te Dino Farinacci
- Re: [lisp] Review draft-ietf-lisp-te Luigi Iannone
- Re: [lisp] Review draft-ietf-lisp-te Luigi Iannone
- Re: [lisp] Review draft-ietf-lisp-te Luigi Iannone
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Re: Review draft-ietf-lisp-te Luigi Iannone
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Re: Review draft-ietf-lisp-te Luigi Iannone
- [lisp] Re: Review draft-ietf-lisp-te Padma Pillay-Esnault
- [lisp] Re: Review draft-ietf-lisp-te Luigi Iannone
- [lisp] Re: Review draft-ietf-lisp-te Luigi Iannone
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Re: Review draft-ietf-lisp-te Joel Halpern
- [lisp] Re: Review draft-ietf-lisp-te Padma Pillay-Esnault
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Re: Review draft-ietf-lisp-te Padma Pillay-Esnault
- [lisp] Re: Review draft-ietf-lisp-te Padma Pillay-Esnault
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Re: Review draft-ietf-lisp-te Padma Pillay-Esnault
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci