Re: [lisp] Unknown LCAF Types (?) (draft-ietf-lisp-vendor-lcaf)

Alvaro Retana <aretana.ietf@gmail.com> Thu, 14 April 2022 11:39 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 0D2BC3A0D71; Thu, 14 Apr 2022 04:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.106
X-Spam-Level:
X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 54TYL90BwC-u; Thu, 14 Apr 2022 04:39:44 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 565093A0D6F; Thu, 14 Apr 2022 04:39:43 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id l3-20020a05600c1d0300b0038ff89c938bso403266wms.0; Thu, 14 Apr 2022 04:39:43 -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=t5O9KG7i28nhdE8XCn62Y+USmdVS56h7PbhDk3a9SpY=; b=n810yWLBLcsTrz88flb3uhLeGwRB4lkTWlGkQNFPRzYV6+RTgeplVAT9TPXeAEAFbC wRWPUW0g21WFoETdurGZYLXHauhLF2dsJZF6vz4SVCwr/feuQ605Cq7wBSpLzwitvZBn qz5bH2UGYwD6j1D+VRfSiz1tSH/nmZkEWdv3qhWRQnB+G35r2Jypt+2F2SGZWYDsa5ho QY67V4Yuqdy7BJuqtuJatiRrD0MPZFVIGjVQRhcis086mU2vcTSWLlb3IeHuCzUqHymz kdV05nH6iIgNnMANp2nLTbtjPcNmLnS3Bne4QYn7uZnbTA1vjWyg6duHp6slXWj+L512 ovSw==
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=t5O9KG7i28nhdE8XCn62Y+USmdVS56h7PbhDk3a9SpY=; b=PlVquOPdS42sz20doRTzoezjyzNOj01KLoqYdG0E73ta+IPmx2as99EkzvAM1SvPm5 xBGzCoLcXo1yKlep42ARPpiKx3vjL6nbzE5C3ERpmvUjG3aYmmQ5ClrlD6ce7JP36pPB dEnYcX6fn03yvGuDDL9E/UC+7ELnQer5JB1W/R94BM8STmiLW/JOYz9N1jn506ZW8pCl bd2AsqV6zFYTkw2uQO3rCROEiq4pAOsFG+fSzC0XMz/zKuzp0Q3GGuHyrNHl4U2D5T5t I13BBslLV7GWpTLOl3RSrmN769MBxo1mc82PxtV309mPaIyyCBg3s4Op03xTyeESkisF SDjQ==
X-Gm-Message-State: AOAM530oV5WkQLsejd5skWg6mBikBYHy53DJvRiU1zJSRNh/mWnfwV/8 IAFelpUeHHX/ar4yZRabDa5gj2W96TFc12y49rSMPflWXV4=
X-Google-Smtp-Source: ABdhPJyjNj24S/x0ApT7I6DxblNNeAYvbEnLMpjBN04hsHfui+b+yvkHHo8lHRTKnRZfBBSpSSSx+Iodd/Ck6b2y15k=
X-Received: by 2002:a05:600c:3d18:b0:38e:c876:190c with SMTP id bh24-20020a05600c3d1800b0038ec876190cmr3238292wmb.19.1649936380935; Thu, 14 Apr 2022 04:39:40 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 14 Apr 2022 04:39:40 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <AC1EB0F8-6796-4ACC-A90C-0955B807F851@gmail.com>
References: <CAMMESswV6p7WiyZnaKwn=wH-ZwF9wZOUEgzOygjBZ9NQckhj7g@mail.gmail.com> <D87F979E-D790-4FE4-9E8D-3EC3BB9D83B3@gmail.com> <CAMMESsx5eTQvYnrMUNeJ=0JxBtDydB12H4Av6ykPW+VeWP8Hrw@mail.gmail.com> <AC1EB0F8-6796-4ACC-A90C-0955B807F851@gmail.com>
MIME-Version: 1.0
Date: Thu, 14 Apr 2022 04:39:40 -0700
Message-ID: <CAMMESsxY56BOxKyXMrRwoVFwWu6tx-F4WSG1FQSJs3tHA6L29w@mail.gmail.com>
To: "lisp@ietf.org list" <lisp@ietf.org>
Cc: Luigi Iannone <ggx@gigix.net>, Dino Farinacci <farinacci@gmail.com>, "draft-ietf-lisp-vendor-lcaf@ietf.org" <draft-ietf-lisp-vendor-lcaf@ietf.org>, lisp-chairs@ietf.org
Content-Type: multipart/related; boundary="000000000000e37ca105dc9bbfb2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/HnrDvHbnDc0dYHU3eYJd8v5zxe4>
Subject: Re: [lisp] Unknown LCAF Types (?) (draft-ietf-lisp-vendor-lcaf)
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, 14 Apr 2022 11:39:47 -0000

Hi!

Hmm — let’s start with the positive.  The new text looks good to me.

OTOH, even if rfc6833bis is the base specification, rfc8060 is an optional
extension…. The problem is one of references and document status:

rfc8060 is an Experimental document — the current reference in rfc6833bis
is Informative, which is ok because there’s just a general reference to the
AFI — “LCAF-Type MUST” makes the relationship to rfc8060 Normative and
changes the behavior of rfc8060 implementations, so we should change the
reference type and formally update rfc8060, which results in a downref,
which requires community approval (new IETF LC), which requires the IESG to
consider the downref registry, . . .

I don’t think any of us wants to reopen rfc6833bis at this point. <sigh>


Ideally, rfc8060 would have included that one extra sentence: “an
unrecognized LCAF-Type MUST be dropped”.

We have two other options:

(1) Let it be.  rfc8060 is Experimental, people “experimenting” with it can
figure it out, and when/if the document goes on the Standards Track we can
add the text.  I know there are production deployments, but these are
mostly controlled (people shouldn’t see unknown types).

(2) Use lisp-vendor-lcaf, which adds a new Type, to formally update rfc8060
on what needs to be done if an unknown Type is received.  Both documents
are Experimental and lisp-vendor-lcaf is in line to be approved next week
by the IESG, so there are no cumbersome process issues.


So…what does the WG want to do?  reopen rfc6833bis, nothing, or use
lisp-vendor-lcaf

[FWIW, my personal preference (as WG participant) is to use
lisp-vendor-lcaf.]

Thanks!

Alvaro.

On April 13, 2022 at 3:02:28 PM, Dino Farinacci (farinacci@gmail.com) wrote:

Just confirm, the behavior is not specified in rfc8060, right?  It seems to
me that it would be good to specify it somewhere and
draft-ietf-lisp-vendor-lcaf looks as good a place as any - do you agree?


I search as well and it wasn't obviously stated. But 6833bis has this text:


Which doesn't make clear if the LCAF AFI is supported but the LCAF type is
NOT supported, the LCAF type should be dropped.

Should we add this to rfc6833bis?

The suggested text would be:

. . . LISP control-plane messages that include an unrecognized AFI or
LCAF-Type MUST be dropped . . .

Dino