[lisp] Lisp 108 meeting comments

Sharon Barkai <sharon.barkai@getnexar.com> Thu, 30 July 2020 09:11 UTC

Return-Path: <sharon.barkai@getnexar.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 0D8723A1018 for <lisp@ietfa.amsl.com>; Thu, 30 Jul 2020 02:11:39 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=getnexar.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 V4LaW7AzRBGW for <lisp@ietfa.amsl.com>; Thu, 30 Jul 2020 02:11:37 -0700 (PDT)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 B44B73A1002 for <lisp@ietf.org>; Thu, 30 Jul 2020 02:11:36 -0700 (PDT)
Received: by mail-ej1-x62b.google.com with SMTP id w9so27190098ejc.8 for <lisp@ietf.org>; Thu, 30 Jul 2020 02:11:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getnexar.com; s=google; h=content-transfer-encoding:from:mime-version:date:subject:message-id :to; bh=ov8nyK4bYnq0TYum59MtIvlFzMkMsLXEDRInaGw/8Z0=; b=XQXlxqwEO6x/ogQu/oPL8xmNsV9eBo7UGqttyn61W6tH5BkUxn/LKAiEEUedMPDHGL jKy5uUzPk160wUovq3vNo+cy5sopPzMb8yjzjpTiAmcJ+6qSNkA1kvfdpAiJCL+Ou2th q3ODBSmIGc7Q7eMpjXJCp9657V7L8byT4sFYs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :subject:message-id:to; bh=ov8nyK4bYnq0TYum59MtIvlFzMkMsLXEDRInaGw/8Z0=; b=rVSj6c3nWafDyBYybX+gF8Dbvh3UIalxhzpQh7gQdU4R7znkDLqY1lBXqcrJodc971 95BcMntCHwWVQ5WPyT7Im+jSXi6+c+ITxMY1iTa0LSNIU1hz4dTVrmNG/Icg3nZGfkTQ O9U1yVrnp9bwtUQ7gC0mqOZmSXgwTIEj0htDF6IllgQVORrxzsjiL7c1xezxbeGepNoZ R3TtYFBNTpTpp55KWX+KlgvKPYOD2C1tbKrC1AGFQ6AonAHpy8A0MvZeExOrmOlrW6to fDHDLrdH7R6zHv/QQCE2a9kixIKF0oO/bBEEHcQBxkC3jhmNERFBJGINrIhEDyDSX2EP jcUg==
X-Gm-Message-State: AOAM532bruleLSvtTNkbnIB7/gU7yUlDsPR13U0ldyI7ttXJ14tSuU7n I1xegls/ZfzuENaqiFGwTMF29fqGD/+rg+lPcz6+cJ4IYwWScSxjjMr5UNkbSHhlRzdHStSwC74 Rb7ttF7NCI33i84D2yrV8kMNXfdqw+WFeRkCHNAPOo6Tk3Tk76W2Ws/Vp+XoK8eWUomg=
X-Google-Smtp-Source: ABdhPJxfz4hV0btPl3Mm6bIKiHljh5RQqeQ2jd2xr7euVlBGZEEY2TOkvCNG2w8dLFSNSOshBAiIkw==
X-Received: by 2002:a17:906:8517:: with SMTP id i23mr1582315ejx.287.1596100294908; Thu, 30 Jul 2020 02:11:34 -0700 (PDT)
Received: from [10.0.0.3] (89-139-213-112.bb.netvision.net.il. [89.139.213.112]) by smtp.gmail.com with ESMTPSA id qk30sm3438604ejb.125.2020.07.30.02.11.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jul 2020 02:11:34 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
From: Sharon Barkai <sharon.barkai@getnexar.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 30 Jul 2020 12:11:32 +0300
Message-Id: <666A774F-8BD8-498F-9353-3821B33E048D@getnexar.com>
To: "lisp@ietf.org list" <lisp@ietf.org>
X-Mailer: iPhone Mail (17F80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/fNJuVc9QyH4_gQhwXJqarrp_GJE>
Subject: [lisp] Lisp 108 meeting comments
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: Thu, 30 Jul 2020 09:11:41 -0000

Just wanted to say that the  meeting was very short, and perhaps make a couple suggestions

1. LISP NAT Traversal 

This is an important problem which is inherent from the fact that rlocs are a stored in the map server-resolver and not just in the data-path.

I think we need a full interim and a strategy to deal with it starting with brute force: all EIDs and XTR which are CPE or behind NAT can use RTRs in the provider edge - or same NAT zone as the map server-resolver - allocated dynamically by the map server-resolver.

From this starting point we can start to offer optional breakout optimizations, For example:

- If the map server-resolver and the ITR are in the same NAT domain
- when the map server gets a query which it knows is for an ETR which is behind NAT
- it asks the ETR to self-resolve for that specific query for that specific ITR
- so the ETR will talk to the ITR before talked-to by the ITR

Or things like that, but remove NAT doubts from all LISP Edge Networks and LISP VPNs.

2. LISP-Nexagon

Edge street processing and Edge AV-OSS are getting hot. If we do not issue at least one good IETF layer3 geo-pub-sub then the following will likely happen:

From the folks who brought us mobility application networks directly over layer2 which never got implemented will be getting mobility layer2 edge networks based on RSUs that will not be installed in our lifetime. Where as SIMSensors will be everywhere streets and vehicles very soon.

A bit blunt but many of us are not young anymore  apropos 0x3Dino :) so need to make progress also in the interim till 109.

Hope makes sense.


--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794