Re: [lisp] Draft-kouvelas-lisp-map-server-reliable-transport WG Adoption
Dino Farinacci <farinacci@gmail.com> Sat, 23 April 2022 21:03 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 2A9E53A111A; Sat, 23 Apr 2022 14:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZgafd0HnJJi; Sat, 23 Apr 2022 14:03:48 -0700 (PDT)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680D83A1118; Sat, 23 Apr 2022 14:03:48 -0700 (PDT)
Received: by mail-pl1-x634.google.com with SMTP id h12so14798243plf.12; Sat, 23 Apr 2022 14:03:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pWSoGIaRGE+T95jqhiXTZ/MlsG8laAhO1fiT5cJ7nW0=; b=cJBEjUSY7vnELbjlueW2qmJYtXb81ELYDmAUpQRc16H8RKeQdsEYdsUU51VkyjyGUp IKdreYnVFmZOG8gghQVhiwrTkgeBWkk1jgRYdp7r/6TL1KPN8jQNEOxDH8RaG0+FaCyL yGZf1YA8L+5iKrK9sjTRpNLPHEg4OTdDFTGs/icP5b4tgyEJFkqc0Y2JSW6t+gmYp1cr wNZZUczHzMwIhsAcVkVNM8rvPPKPxxE2jNKHdcZbcv30KX/sMjTTJStwuaQf/5Vd89MS WDkUvxBC+2EdaUS1/a20VQUE7hwr8nOFrBkvbm5IFBpn3hexFkE0TeG60uhQfpuInNt/ u4BQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pWSoGIaRGE+T95jqhiXTZ/MlsG8laAhO1fiT5cJ7nW0=; b=bWDLfK+5s05Rlzu3bW4okV0q637qvy1dVwSFkND4QgWJyuYf3BAhKcEw7cv52HPdh4 t04cLAYZwtH2fh3lw105TldkEPzHrbdLo2TzSbyKa6DP+Hnc/BEwYa2pCDSEm2ILNfPL 9Mjl5lmMJkTaxCNqpn/H6h4Tev47hxazWi4Ax3r1jPeI/TvTKpvxroKWnN8Kk+zVHKKw 5ru4yI+1F5wfvSHYb0jRAz+0nAfEU0f1yV+6YOiVIqGa+B6iuLJgUMhwM9fJacLFDpgc a+MFRYApFUvC6wHDYmC1To5DyJcIyf2dlyIfj3q5Wgd+YmyuDotTyStA8yOrTNBus8W7 AyWg==
X-Gm-Message-State: AOAM53058UcdPE0nJqfboqMlBD6fgvuSoTijXYYuqnUPracGvWXhsT7/ kw2mmxhtAyYPgAHtIpHjl58=
X-Google-Smtp-Source: ABdhPJwG7Q1Tuq8bF50YsINYYPPHofZLhRiLEVqgQaqaiSvqur7xlWURTWB0AWf0wvix6Yrfg2dqTg==
X-Received: by 2002:a17:902:ea0d:b0:15c:eceb:de38 with SMTP id s13-20020a170902ea0d00b0015cecebde38mr3273097plg.37.1650747827041; Sat, 23 Apr 2022 14:03:47 -0700 (PDT)
Received: from smtpclient.apple (c-98-234-33-188.hsd1.ca.comcast.net. [98.234.33.188]) by smtp.gmail.com with ESMTPSA id gw16-20020a17090b0a5000b001cd4989fed1sm9868951pjb.29.2022.04.23.14.03.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Apr 2022 14:03:46 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <CAOj+MMGXFFK0iPw2pOTU-EsBPdEHXrueTtYxXqg_qHPXmqok+w@mail.gmail.com>
Date: Sat, 23 Apr 2022 14:03:45 -0700
Cc: Luigi Iannone <ggx@gigix.net>, lisp-chairs@ietf.org, "lisp@ietf.org list" <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F6660087-67C2-4A5F-9A3E-07537C5F64F9@gmail.com>
References: <1F470969-4ECE-437A-8E1A-C005679F9422@gigix.net> <CAOj+MMG2qnYhRXEeyOOjPuaAD4ZYcvP9wyUBiqGECrzUupLyew@mail.gmail.com> <73F7376E-B22B-488A-8503-B91F11D965AB@gmail.com> <CAOj+MMEVLzvuy2ZUS=5uzgVnj3xmF_C2LQSYOMUZ4E7xvy_GQw@mail.gmail.com> <CF1852EE-3684-4093-AA53-0F450C56CA18@gmail.com> <CAOj+MMG5XSSDB-z23fZwOPHFebntXYDcRtaDzgq6tespEHBMPA@mail.gmail.com> <E54406EF-5CAF-4492-90C0-8E9A99BCC07B@gmail.com> <6D2655D8-DC32-4EC6-A946-AEC4CDCF00B7@gmail.com> <CAOj+MMF0T0i_JN=KVHnFs7UyDs6eX3eqekzoFLveQ0TMhkcFnA@mail.gmail.com> <4440288E-32A0-4DB2-9EEA-6DEC9277CD24@gmail.com> <CAOj+MMHaEV0G1rOKxKT6JbvTGt00ybYf=xGqWwFq0b574GHcXw@mail.gmail.com> <E285D8C7-82DC-4F9F-8566-FD7AEDDF15B6@gmail.com> <CAOj+MMFhTjYWdQ9xVJp-zoRZ56EwHfq5euy37CM_jwa1XEopMQ@mail.gmail.com> <F765B841-202A-4184-B749-C5F2036D4DBF@gmail.com> <CAOj+MMGXFFK0iPw2pOTU-EsBPdEHXrueTtYxXqg_qHPXmqok+w@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/eKJEEMGdsFyJmO9dd5R-66iDjS4>
Subject: Re: [lisp] Draft-kouvelas-lisp-map-server-reliable-transport WG Adoption
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 23 Apr 2022 21:03:50 -0000
> I am actually referring to the case where the control plane during the handoff registers new RLOC while the active/old one still works. Nothing to do with the data plane. You can register the new RLOC and new cachers will use it. Old cachers will use the old one. Now the question is, where is the EID, it can be the old, the new, and in transit (meaning offline). If you are an EID that is at both RLOCs at the same time, and want to migrate from one (removing one of them), then this works per specs. > That is what I meant by "radio overlap". There is no such thing as overlap unless the EID has two interfaces each with an RLOC. But that is not the interesting handoff case. I know cells overlap but most phones have ONE cellular interface and therefore one RLOC at a time. I wish this could change, but the mobile OSes aren't there. > Then there will be time where more then one RLOC is active and the old one can get pruned after the new one is tested as working fine. You have to define the details of "active". That is what brings interest to this discussion. > Would that not be a better overall option ? Its not that simple. Dino
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Robert Raszuk
- [lisp] Draft-kouvelas-lisp-map-server-reliable-tr… Luigi Iannone
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Robert Raszuk
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Dino Farinacci
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Dino Farinacci
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Robert Raszuk
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Dino Farinacci
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Dino Farinacci
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Robert Raszuk
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Dino Farinacci
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Robert Raszuk
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Dino Farinacci
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Robert Raszuk
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Dino Farinacci
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Robert Raszuk
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Dino Farinacci
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Robert Raszuk
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Dino Farinacci
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Robert Raszuk
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Dino Farinacci
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Joel Halpern
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Dino Farinacci
- Re: [lisp] Draft-kouvelas-lisp-map-server-reliabl… Luigi Iannone