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

Dino Farinacci <farinacci@gmail.com> Fri, 29 April 2022 23:57 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 D26EEC15E418 for <lisp@ietfa.amsl.com>; Fri, 29 Apr 2022 16:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8wLJ_VeRWtk for <lisp@ietfa.amsl.com>; Fri, 29 Apr 2022 16:57:41 -0700 (PDT)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 8EEEEC14F74D for <lisp@ietf.org>; Fri, 29 Apr 2022 16:57:41 -0700 (PDT)
Received: by mail-pl1-x631.google.com with SMTP id c23so8470779plo.0 for <lisp@ietf.org>; Fri, 29 Apr 2022 16:57:41 -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=g+RNdHUtXutl9e8wfgskYnA1OEePsdTkNF8sOiiCHwk=; b=YGZwERA3/UVRWLC5xujJ7M1KXYnCmSH5iWWWA8tKwnp3H1CDtW7vTENMF9BOSH7EpA 6jIEYvV329xJdjP6AUGEGkOzNEYt3toSJyuQWONOFxjjWevEyyOguTgp2P2VLLWp+LQG 2i+mWiAWNOh1hFjyGYjyaBkLcCNvpmB8KFXKFUcTYNVm9JmsbI2gMDjWGR6Q+aZn3D0F 6tGhrjlf8UGCYk6EYq9/1JNuoQV1uE6KkRvkDwoPtSmoapPRCFwhCiO77r3+QyQ6MhMc O3hntvQH1+CZBQ1U7cSQalt5ertjTLIbbazVU+C3kZGiCQZu0MMzmDXB4d1hudSa8SNc gAwA==
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=g+RNdHUtXutl9e8wfgskYnA1OEePsdTkNF8sOiiCHwk=; b=q5BCjIIbqEWz2S4UNQt7NlgWAW7HYPtR7dOitSGhqbXO4xQNzUllzb2smXZiLx7fAW soRtxXlLl4oUyDJWK0Gr2hQfL4PF+Mm+06EtpT33c+BaKCN9dAY+UOya7qZqKIw7q9tZ vRd8yThtVKqUuWUpHjkVvtb1mvC6YQKwuJhwtlD/9Palj2PO/ClMFTT0BLjyWDtHgRin rX111MF8k3RjPa/eEapjOriVjkQymPTTc9EePBWoNwny5ukR6Exvlf3iwUHavnpd3K8R ePjDU/rWx42D5IHq0LX1CwFKHCmhwoMNiEyzxg/AeBZZdmKnnboc7cQ9ErTTOwwIqBel Px3g==
X-Gm-Message-State: AOAM5300A/rOMVH6v9Dnlbtnb6oJPLHijo5rmfedMK4U72yk709jteUl u6QsyCFs2jbRX9FYgWp2CMsujpQyF9o=
X-Google-Smtp-Source: ABdhPJxp6fYoSGYVkcWlzLzbexec43AIeH+JIf7B72cSduIOcNDsTjIVjSpRfZ3d+uNhgoGXU9PI0Q==
X-Received: by 2002:a17:90a:5ae1:b0:1db:d0a4:30a4 with SMTP id n88-20020a17090a5ae100b001dbd0a430a4mr1643672pji.128.1651276660541; Fri, 29 Apr 2022 16:57:40 -0700 (PDT)
Received: from smtpclient.apple ([2601:646:9600:fef0:b85f:64c9:d8d6:7819]) by smtp.gmail.com with ESMTPSA id b26-20020aa7871a000000b0050dc7628130sm246452pfo.10.2022.04.29.16.57.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Apr 2022 16:57:40 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <aacf3f04-a318-8749-bf16-62fbd69eb127@joelhalpern.com>
Date: Fri, 29 Apr 2022 16:57:38 -0700
Cc: Robert Raszuk <robert@raszuk.net>, "lisp@ietf.org list" <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F6FC2E3-640E-4FE6-8B0C-B1BED880635D@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> <aacf3f04-a318-8749-bf16-62fbd69eb127@joelhalpern.com>
To: Joel Halpern <jmh@joelhalpern.com>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/hWIaGVmyQXcYR6U5t1D5x1eO4v8>
Subject: Re: [lisp] Draft-kouvelas-lisp-map-server-reliable-transport WG Adoption
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.34
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: Fri, 29 Apr 2022 23:57:45 -0000

> Q1: Should the draft describe how to use QUIC as one of the reliable transports after initial communication?  That is up to the authors and working group.  If someone wants to do the work to specify it, and coordinate with the QUIC folks to make sure we get it right, then I see no reason we can't do so.  It would however delay the work.

Well, we don't say how you use a TCP connection once the connection is established. I mean, you simply send and receive data. What do you think would need to be said for QUIC, in this context?

> Q2: Should the base LISP mechanism be changed to use QUIC instead of UDP?  While a fair quesiton in general, that is out of scope for this draft.  And given that we have a pile of LISP documents about the UDP based mechanism in the hands of the RFC Editor, I would really like to see us finish our work before we decide to change its underpinnings.    I am sure it could be done.  Once we have completed getting the PS documents out, if someone wanted to write a draft on how to replace the base UDP with QUIC, go through all of the protocol implications, include a comparison of state and time issues so as to make an evaluation practical, and then ask the WG to consider it, well, it would be up to the WG.  But it would need a lot more than "how about we replace UDP with QUIC?"

I agree we should not generally specify this. Not just because we have documents in the queue, but because we need more experience with QUIC to decide its a better way to go. There are a lot of assumptions and reliability put into LISP for sending and receiving datagrams and the state require to have many connections maintained between ITRs and ETRs would be much larger (order of magnitude) than the mesh of TCP connections we see amoung BGP peers, for example. 

Dino