Re: [lisp] draft-ietf-lisp-pubsub-09

Dino Farinacci <farinacci@gmail.com> Tue, 26 April 2022 21:32 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 75025C1D132B; Tue, 26 Apr 2022 14:32:40 -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 V685JPn7lPqE; Tue, 26 Apr 2022 14:32:40 -0700 (PDT)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 D1CA1C15E3E8; Tue, 26 Apr 2022 14:31:49 -0700 (PDT)
Received: by mail-pj1-x102c.google.com with SMTP id u6-20020a17090a1f0600b001d86bd69427so119266pja.5; Tue, 26 Apr 2022 14:31:49 -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=eu79iFxxAvpSaZHXJH2+KwoJFoGRHqUSR8iAXSAA2eQ=; b=PkxWtnO/kerrk2PPSfcDrM3My/kRkuZkZ0bSFy+yuGYb4MW9qovHYqnnDsoNA+N1q5 kG1Txc824sGhrzF6xMdJ3qrMy3k/U3BsL1je13mnP/fN688Dxon+ifRrt8C/6L8cxjLG TKhYokcBLqj6VNmF/eRZHEELGaG+O2dJ24D7v8+3m7VPa8sKMdpyVmjmPuWKYUD+lnsL Gq6XdXVAc9I/eV0xuhrssf6Z5bx2c8K3338LJJtmqcSmebaKOkVBUwgCNAB01nOevlnL TWfi1u/iCL/GiK893uMQp45ylPX+RHrwSSyV8k1gjOzQHFqnbf5i1d00niwVKQqw1SNt 4qwA==
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=eu79iFxxAvpSaZHXJH2+KwoJFoGRHqUSR8iAXSAA2eQ=; b=5CQTlj37bsC0jvPH9rrh+LW/ZHOk+2M2B+ktSumYv5ynY1XgjKvJr9MV7JWZSWFLWt oUbE9f91Iml/KKcA9D3LldmnM8tn44IhGssb01gI8QCAmxSO/5Ndd50wJoG3NoHB31HN hWhuDuPfvhf6FPTMqRrZ+FmGicaAODw2br4rIdiwQLfFCJGCikwGzTQdcjvz2RExI7HT euOYx8HHK7pIOT2Q3oMzC99PvdkiJ3WqZryem0dVPANTsDCZZmr9EA1OESyPMz+uTWHi g02RxAF3TR25Jj7xNfOlPw9kljTsVdHOqsFqL8CLcr2HbR/5AqJUlRuaZlqzKU0iIN9J 2x2Q==
X-Gm-Message-State: AOAM533fVs2HDp2Agp21falZFNVLTyMIxx7zS0cDdl7qSJzUjM5zDlo1 YXTH6SG7Iuwde+F8fFIG28c=
X-Google-Smtp-Source: ABdhPJzfWgCw07nUuueH+Ps+0n2hZgZ2Xs+mt7u4ycJujm7inmBdgkWyt7lxRekqvNdQkplExUVM/Q==
X-Received: by 2002:a17:902:708c:b0:15c:e0fa:faa with SMTP id z12-20020a170902708c00b0015ce0fa0faamr20335518plk.30.1651008709075; Tue, 26 Apr 2022 14:31:49 -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 x36-20020a634a24000000b0039cc6fff510sm13837774pga.58.2022.04.26.14.31.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Apr 2022 14:31:48 -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: <BYAPR11MB35917B125143BFD5782A9FF6B6FB9@BYAPR11MB3591.namprd11.prod.outlook.com>
Date: Tue, 26 Apr 2022 14:31:47 -0700
Cc: Robert Raszuk <robert@raszuk.net>, "lisp@ietf.org list" <lisp@ietf.org>, "draft-ietf-lisp-pubsub@ietf.org" <draft-ietf-lisp-pubsub@ietf.org>, "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <19D54551-1411-4123-96AA-FD149032541C@gmail.com>
References: <CAMMESsyB6WXxZP-CxQ6xzYQ6rRC86TQPT+PDqc3+qvR364qdCw@mail.gmail.com> <CAOj+MMHj-kUJry65zprwv+QxDRJ8LCM73MRfG8MEBNFtniLoxg@mail.gmail.com> <BYAPR11MB35911DE963E0A8A3D9ED48FEB6FB9@BYAPR11MB3591.namprd11.prod.outlook.com> <CAOj+MMHsB0eRyYtAR4eE5b-i9TZbSA4fXvZsCKY8E+2dmaf1YA@mail.gmail.com> <BYAPR11MB35917B125143BFD5782A9FF6B6FB9@BYAPR11MB3591.namprd11.prod.outlook.com>
To: "Alberto Rodriguez-Natal (natal)" <natal=40cisco.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/qsOs016sJ2M7xH3WxDyDhgfVL9Q>
Subject: Re: [lisp] draft-ietf-lisp-pubsub-09
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: Tue, 26 Apr 2022 21:32:40 -0000

> Interesting, there might be use-cases for that. Maybe that is something we can work as an extension of the base PubSub, once the base spec is done?

So from the discussion with the ICAO guys (Bela and Bernhard), they want a "more-specific" type processing of both Subscribe-Requests and Map-Registers. For example:

(1) subcribe 10.1.1.1/32, 10.1.1.2/32, then unsubscribe for 10.1.1.0/24 which unscribes all the more-specifics to 10.1.1.0.

(2) Map-Register 10.1.1.1/32, 10.1.1.2/32, then deregister for 10.1.1.0/24 which unscribes all the more-specifics to 10.1.1.0.

We don't spec this out in either the pubsub or 6833bis and an implementation could do this with no new flag bits required, but if we wanted to standarize this a Map-Register and Map-Request would need a "process-all-more-specifics" flag bit.

And, the aggregate that "undoes" all the more-specifics would have to use the same authentication key and signature used for all the specific registered.

We are still discussing this privately. We took the discussion off the list, but I wanted to update everyone on the status of the discussion.

Any comments?

It is of my opinion, that this is a moderate protocol change but they need it so they can send one message rather than possibly more than one message with a list of specifics. And I am not sure we should update specs for this since an implementation can be configured on both the xTR side and the map-server side to do this functionality.

Comments about documenting this?

Dino