Re: [lisp] Review draft-ietf-lisp-te
Dino Farinacci <farinacci@gmail.com> Mon, 29 April 2024 15:12 UTC
Return-Path: <farinacci@gmail.com>
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 99C52C180B62; Mon, 29 Apr 2024 08:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.096
X-Spam-Level:
X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, GB_SUMOF=5, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 rh2-ixg33CWM; Mon, 29 Apr 2024 08:12:26 -0700 (PDT)
Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 53348C19ECBB; Mon, 29 Apr 2024 08:06:15 -0700 (PDT)
Received: by mail-qv1-xf2c.google.com with SMTP id 6a1803df08f44-69b5ece41dfso18952156d6.2; Mon, 29 Apr 2024 08:06:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714403174; x=1715007974; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ZGX1iXusgkv7bx+OFme5LS8UhXjp6uU7xWpNZkXOUzY=; b=eE6DcAcSaKaPx8FzLxemBF0+96H0Kzt+1Ji+0sJBXuzuDe9TV2jdmfitCJ4RIGQOrw Lhi1XNEfNnDJHdwiYFYsiJOZW1gJnkpF3chPK4aIxJDfZwKvUUGixrAs3xsGq9MuS8Ha STlx4Mxve+QKzLdienIKQPRWi4ZkrN6CldEBJxKLEKdophnizS71Pcv1WTyPc91VXP9V SYu6wAc+jJz+kXoTjntYaA5pWwaBSWvqkr9bd+gHp8gBVmhP8EFAztCbuAep0FzfIokE yPhsNji4n9vNaqZI0qXmeGFpO6tnhSAxi/JFjNAnEM2IoRmL9McNtSa09lMbWSUzqQQk O8EA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714403174; x=1715007974; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZGX1iXusgkv7bx+OFme5LS8UhXjp6uU7xWpNZkXOUzY=; b=BTKNo9OB7jA7M5a69zriCE9AaxyPafz8uhOtRlfi4N9yHf5QoP9Vf0fuSUyhMyubAp lh1PRnM0dMsv9QhplnM5KZx6izEPTqqS9dU5VhhhSLZlvDqjv/8M/tfMG+J2GyLPYkv/ EF0LjdJxZ7jA+472vpEYshSyN+tKKZ3CT9kaxJ/N8EKn5DVQBuRxpA0FOEd7D0V7cbT1 YhG7RamctDT0fXZEWt7zgrUiIl+9LHjvwTk/XEoq0OkVwBklt/mU1S47OelMWvsaZGhd 0gbh7wkbqcBZo3/Chd6MhEL7Nuq0g33t3yi4JLvXhHxIaWEiRjdZZeGZXR0ocxvLJTdk /AXg==
X-Forwarded-Encrypted: i=1; AJvYcCVbYuZYHA5PEFBT4BmErJw3yalEbguOOw9zJvhx6D/f9OKvik8s6U60zMFceyo2/97q+dn2q9uYgPfc6Wf23j1d8UE3nTy7qxva0ZTtTgLy1zibhTMIuavXcSg=
X-Gm-Message-State: AOJu0YwLgB37m64BN0mE0ZzYMX2CmpLVY52Vl0ZM4H3VD5b56lJ+aS3I 8sMQSYuFIcA7MVKsSvgWLX/gzaUzFnhm5LmzYphKedv+AzFYGFG0jTZHgQ==
X-Google-Smtp-Source: AGHT+IFxd3utdi0TkLK55Py1VzgX5AULM0+cluhfwxzMzFDTnWWsFdmj8bREAqBV+QjSqyt9Nh6inA==
X-Received: by 2002:ad4:5ccd:0:b0:6a0:d291:a35e with SMTP id iu13-20020ad45ccd000000b006a0d291a35emr3030506qvb.52.1714403173450; Mon, 29 Apr 2024 08:06:13 -0700 (PDT)
Received: from smtpclient.apple ([148.76.183.114]) by smtp.gmail.com with ESMTPSA id mi13-20020a056214558d00b006a0d771409csm300668qvb.89.2024.04.29.08.06.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Apr 2024 08:06:13 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <681DC702-3BCA-404B-B12D-03F2109E2FFD@gigix.net>
Date: Mon, 29 Apr 2024 11:06:02 -0400
Cc: lisp-chairs@ietf.org, draft-ietf-lisp-te@ietf.org, LISP mailing list list <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7C282246-DA8E-4CAE-B64D-8587BA78B035@gmail.com>
References: <43AE7DEC-BA11-4BA7-96BE-1CECCFAB5EA3@gigix.net> <483F064A-2769-4271-A0BA-E69E72257D3E@gmail.com> <681DC702-3BCA-404B-B12D-03F2109E2FFD@gigix.net>
To: Luigi Iannone <ggx@gigix.net>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/CNP4jwbPiKYfSUQiVuJkCqMJ94w>
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 15:12:30 -0000
Okay, thanks. So this email has an updated version of your comments. Right? Dino > On Apr 29, 2024, at 5:24 AM, Luigi Iannone <ggx@gigix.net> wrote: > > 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