IETF Logo Mail Archive

Re: [lisp] Draft-kouvelas-lisp-map-server-reliable-transport WG Adoption

Robert Raszuk <robert@raszuk.net> Sat, 23 April 2022 20:56 UTC

Return-Path: <robert@raszuk.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 EF5983A0CEF for <lisp@ietfa.amsl.com>; Sat, 23 Apr 2022 13:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 vGJIRNKmZ1OV for <lisp@ietfa.amsl.com>; Sat, 23 Apr 2022 13:56:49 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 282CD3A0CE1 for <lisp@ietf.org>; Sat, 23 Apr 2022 13:56:49 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id w19so19931009lfu.11 for <lisp@ietf.org>; Sat, 23 Apr 2022 13:56:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VZHhy58mjFdlB3uZYcTCck39OGUFIQUyEL20QbRtFdA=; b=A+Ql3jbkSm3ixH2TkXttiaSialNVR2ppX8oMS75DEa49QcEli9deAZMwmXrHjqDxpr r5uPaDw5cGwWRgI9vKJ6dAiiRJnsi5kS370/Qy79GdGSswSHs2/yW+gMiPRR2HerzslO Gb6yWfQkSs8cdyJwipTV3PmMLA+G4BkTsgoYg/Z7vtv1OCJyC2jqip+BZjEdXjZ36MXZ dMUVJYwUIJh0mczMv6Bw8qfwLHwbkezJUfhNBhMNL2gq/Lm4gwGE5IM+p7nGkE4nm6R5 x4yEHDs1mzwWkHyrd80J3Kwqlo2xblr6NrbGsl5zYE+RG9TQT9YnuIvZ/TnfJRTc+0LG k/Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VZHhy58mjFdlB3uZYcTCck39OGUFIQUyEL20QbRtFdA=; b=4j8XWbKrWCh5JF6l/JoaZpvwU0ffEIdVTOC0Nx6v7zqModD0VsImu2hrVEpAOk/8Fy A/2qczF6o4obtT0rqxHaUWTYnugumBiMY9LGC/d8OUxGqK9ge1WsTemFbf8yZjE2g2UX aN6rBfjgKDJzAqjwA8MT3zn91epZ5+kMB/SKVr6vAln+7ZiF0OA9PuyYaFsFv52qjpOn uLst2kfWzRNV17yBeXEhxvYZze8g/FfL1n06wwET3ruTMsQX7cgZucYrWjgiaBwPO8vT JCLRrZHvYUmaWj2KVUN7l/wGrTH8o+PMoWzWL3LAB50dpdmeBADUGOoyhHKJt/uDUqBm H6eQ==
X-Gm-Message-State: AOAM533MYL7edHpCwlCDu6cK4yx/RuE+nr6boUIhL3Ciw6FlCHBQYI8n GxsziC0CXbRvPaYrB4rktgXJ8bB2AXi80wU6KwT5lw==
X-Google-Smtp-Source: ABdhPJx5VGPTWjs/d2rEh/4EIOBWV27aKYiBlLf8twibtcybaIkVLDBPmI9NeGh+G+1MxVOj+W1ezfqu3IK7hL6NHv0=
X-Received: by 2002:a05:6512:318a:b0:471:8f3b:e2bd with SMTP id i10-20020a056512318a00b004718f3be2bdmr7595388lfe.129.1650747406945; Sat, 23 Apr 2022 13:56:46 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <F765B841-202A-4184-B749-C5F2036D4DBF@gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 23 Apr 2022 22:56:36 +0200
Message-ID: <CAOj+MMGXFFK0iPw2pOTU-EsBPdEHXrueTtYxXqg_qHPXmqok+w@mail.gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
Cc: Luigi Iannone <ggx@gigix.net>, lisp-chairs@ietf.org, "lisp@ietf.org list" <lisp@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ce228305dd5894c9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/rz5Q8dVRybY8pTatRv9nUqVMlh0>
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 20:56:54 -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.

That is what I meant by "radio overlap".

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.

Would that not be a better overall option ?

R.

On Sat, Apr 23, 2022 at 10:51 PM Dino Farinacci <farinacci@gmail.com> wrote:

> > I would rather describe it as "You are here and there in the same time"
> :) so the switchover is seamless and does not require to put any stress on
> the control plane.
>
> Right.
>
> > In my view it should be the most often (if not the only one) mode of
> operation during RLOCs handovers.
>
> Well, there is a big tradeoff the user has to make. If they want near-0
> packet loss at the expense of sending more data packets, then they use
> predictive-RLOCs. If they don't need mind the handoff latency, then the
> control-plane mechanism is sufficient.
>
> Dino
>
>
>

v2.35.0 | Report a Bug | By Email | System Status