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

Alvaro Retana <aretana.ietf@gmail.com> Thu, 28 April 2022 16:07 UTC

Return-Path: <aretana.ietf@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 A77C9C15EB3F; Thu, 28 Apr 2022 09:07:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 GdKuPQdXKXJl; Thu, 28 Apr 2022 09:07:15 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 CBED6C15EB2B; Thu, 28 Apr 2022 09:07:15 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id b19so7380878wrh.11; Thu, 28 Apr 2022 09:07:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=KwiQeUAqiPJMCx+Rmwi8q3S9eRuvD0ewS1hjV2wbHPU=; b=nmBsodVfK5rCgF1Xcai7t29DewEHoaLhwZq+F4APKXyAiHyRoUHV0GPk98a4VwvB3r MuJxwaQjwiw50Yzp6p+ade1XxExO2DGrWFitFFqIShICtAX8fU110ly/JyB3eTgj6eYB RO/pGpxfSeUllV5rY4jOOrrxb8qc6tEmnqbf6cOHgIaVIuu6Uqk5dD0ExNMG4wl1CzkN O5G4hkMN/J8Rc/L7r7gb8uolMnq/yfzOq7kJX07Zv6kVzADHFNJDOeONcdswFCkT5cO8 wwFELd+xmq84MWov4ysrdQfTHE/RSjIdSjMAawCWlXvlMf9sf11sgKLVoFZu0AbdsNlH eD1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=KwiQeUAqiPJMCx+Rmwi8q3S9eRuvD0ewS1hjV2wbHPU=; b=pUlMXIh0XHBjT1vE5DAS4m2UWiSw/TFeePdsRkWXsaO2KVciyTdrdNxe5DwMqy5PoR oit707WiO/7CNzdNT6mEBrCY5dcdtWPiM51m/4V6zaCKnEBUyahCVsGQzbYlm/qpwTv8 IoNJ0piyPS2Sw5BdgNdhA+Zmdf5f1KFyoUG03t5ECmIslH3qp/Iw5f0DtE9K+hkwJdDR QdPaMcTeoZ2Sj7Wvt8PnEfXLhYOP3InUpD3UbXL8AzVxsT1rNYzCExlIpHBhYDqAmq9U pm4O5DRwOACZxLSg+4lZk9I12cKVeeoXM6SpvUwo1r4iRypa1/Tetxb8ESSrBOtNEBSn DoVw==
X-Gm-Message-State: AOAM533xizP6AcGummthhSKjyAYD1WCTC0fzOaYxg6fF3ppWMxrlAmQf HLvOZgMuj6/+q3rm/bSDYJfRb/rj5xr+9VLbESQ=
X-Google-Smtp-Source: ABdhPJz5J0/KKudBA1dk55DTvfCQ3U1xiLU8p08SwgjRTsPz471Khlzj23U1mKhAKEwotSHjjKucMlTGkAkBxd4Gwxk=
X-Received: by 2002:a5d:52d2:0:b0:207:97df:d166 with SMTP id r18-20020a5d52d2000000b0020797dfd166mr26554950wrv.356.1651162033843; Thu, 28 Apr 2022 09:07:13 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 28 Apr 2022 09:07:12 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <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> <19D54551-1411-4123-96AA-FD149032541C@gmail.com>
MIME-Version: 1.0
Date: Thu, 28 Apr 2022 09:07:12 -0700
Message-ID: <CAMMESsxGUXFwfcMc2GPTHO7A9d_o7DLGoV8TsZJc8O7BRorGMQ@mail.gmail.com>
To: "Alberto Rodriguez-Natal (natal)" <natal=40cisco.com@dmarc.ietf.org>, Dino Farinacci <farinacci@gmail.com>
Cc: "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-Type: multipart/alternative; boundary="0000000000007e73dc05ddb91ecc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/tgzAcqwmF810sHxiae_2_dQLufQ>
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: Thu, 28 Apr 2022 16:07:16 -0000

[WG participant hat on.]

Dino:

Hi!

I agree that the behavior could be implementation-specific: just configure
both
sides.

It would be valuable to document it.  If it is an optional implementation
configuration and there are no bits involved, the specification could even
go
in the current draft:

  An implementation MAY consider more specifics...more details...
  The xTRs and Map-Servers in the network MUST be explicitly configured
  if this optional functionality is used.

  This is an example of a possible deployment: [describe a case
  where a single message would be used -- doesn't have to be specific
  to ICAO's application].


A couple of paragraphs should do it. ;-)


My 2c,

Alvaro.

On April 26, 2022 at 5:32:52 PM, Dino Farinacci (farinacci@gmail.com) wrote:

> 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
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp