Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)

Alvaro Retana <aretana.ietf@gmail.com> Thu, 03 December 2020 13:09 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1997A3A09A8; Thu, 3 Dec 2020 05:09:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, UNPARSEABLE_RELAY=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhCD6Dt9_iD4; Thu, 3 Dec 2020 05:09:44 -0800 (PST)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 7EE503A0989; Thu, 3 Dec 2020 05:09:44 -0800 (PST)
Received: by mail-ej1-x634.google.com with SMTP id 7so3412502ejm.0; Thu, 03 Dec 2020 05:09:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=0hWwaoc6fnZ5UJzpMHH2m5iIellAMxuq57/vajnz7Uk=; b=YlwjFjTNZ3IpzMioXdw+x4E3ZRPoGpnks+mMvAOKCbM/BEOpIdrr2SFcwFOtYyWu4m yEXlEF+mbH7wcFgG2kEpwDMdMCEsJ/06p1DpVdslOMRoS3YFC+TN7DRVZYwWcZRtCEUO qPPadHV0L+lUuWvUPycag437eUa9wZsSz1nKy40YdNlSzvEB42OUnScZrcEsiUhZBxa5 K2EAuYyMe/XpLcDD+AAbcNSI4H76rNVTUTkPhTbAIkjfyvyra+4LoNPopYhv8hxo6Cu+ Qh8mDswGzbvZ4kiHQwRy3RzG/HdylIVNkZcIdTiEvaDO1FUa6vpnO5PS0y/FENew+wLm VsTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=0hWwaoc6fnZ5UJzpMHH2m5iIellAMxuq57/vajnz7Uk=; b=uYeBqv7JkoiHOGsbd3WyvV3iHqSGtKgT6IWoRLsZQdscXV8gEJHjzPEUHRk7xQUOPZ yLVRcr2E/FW1tWbJZwkSIY/UU5UAhBxJiCpKYCiQEGe5Q2A8GIOiFf8NpyUU9RfCf82r 2SgIuLB5bkTz1xLj5N50CuLzoLtnIElBhc0WUVmn2rxcUCTRTuiZT18vC3XjgKgjbaG4 0RXPeTRSdJaxpzVDJGfFcRkjpQ28sq4BwC6iJswL/OaEdmhHf6wROGS6XPyXsiUHpDCd DvaU8gwopDx4SMp1vcd54EO9R44SdL1bGWGNBA84oxqeaLB9SuJ/mgJK9wsxh851ev8L MN7g==
X-Gm-Message-State: AOAM53196d8jZ9EUTdw2IwF5IyUJO8zbv1c9JG0baUgYG3bAXFY5+j4M 6ux993ZfFeJdQ/YcVs/wMER5eQmYkpE7jqxPHL8=
X-Google-Smtp-Source: ABdhPJxtCre7kpHN4e1YmfVJyL75mgCaLjzbc9H7tRQgTVvW9UPRMt4bA5GRTbmqqTMwodAnaNhkkTHqR1tPPBFBqQU=
X-Received: by 2002:a17:906:cf81:: with SMTP id um1mr1242662ejb.122.1607000982946; Thu, 03 Dec 2020 05:09:42 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 3 Dec 2020 05:09:41 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <160684669488.21585.5180075052177708759@ietfa.amsl.com>
References: <160684669488.21585.5180075052177708759@ietfa.amsl.com>
MIME-Version: 1.0
Date: Thu, 3 Dec 2020 05:09:41 -0800
Message-ID: <CAMMESswgRDhtLuHcsh6CoZFuA7j=O4HuZtika6QfmY0pv4D7MA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>, Benjamin Kaduk via Datatracker <noreply@ietf.org>
Cc: Susan Hares <shares@ndzh.com>, idr-chairs@ietf.org, John Scudder <jgs@juniper.net>, idr@ietf.org, draft-ietf-idr-tunnel-encaps@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Wh5OlRVny3Pry5Z4CM4S4pw6HxI>
Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2020 13:09:46 -0000

On December 1, 2020 at 1:18:15 PM, Benjamin Kaduk wrote:


Ben:

Hi!

I’m just addressing your second DISCUSS point.

Thanks!

Alvaro.



> ----------------------------------------------------------------------
> DISCUSS:
> ———————————————————————————————————
…
> I also would like to ensure that we have had adequate discussion of the
> relationship between this document and RFC 8365. The IESG has received
> comments recently (in the context of a different document) that it is
> irresponsible to effectively obsolete or deprecate existing work without
> identifying or explicitly updating such work, and without indicating
> whose responsibility it is to find discrepancies. That seems like it
> might apply to what's currently in Appendix A, which on first reading
> suggests "there might be a problem here, but we aren't saying exactly
> what or how to fix it, or even who is going to do that work”.

First of all, the part (in §1.5) about obsoleting rfc8365 is wrong.  I
had pointed that out and expected it to be fixed, then lost track of
the updates.  To be fair to the authors, I sent my note in the middle
of the IETF week.


On to Appendix A.

rfc8365 Normatively references rfc5512 (the main RFC we're
Obsoleting).  This document includes the functionality (Encapsulation
Extended Community) that rfc8365 uses from rfc5512, so no change
there.

The functionality specified in this document (specifically carrying
the Tunnel Encapsulation Attribute in other AFI/SAFIs) means that the
attribute, and not just the Encapsulation Extended Community, could
also be used to signal the same thing.  The appendix is then pointing
out that if this "new" signaling mechanism is used then there might be
some things to consider.  But we're not making any change to rfc8365.

IOW, there's no problem, rfc8365 implementations can continue to work
as specified.


To your point about indicating who/how/where any additional work
should be done.  In general, I tend to agree with the point.  In this
case, related to rfc8365 there's nothing that has to be done.  If at
some point in the future a potential rfc8365bis wants to make use of
the Tunnel Encapsulation Attribute then it may want to consider
Appendix A.


This document is Obsoleting 2 documents.  Yes, I know the header says
3, but -21 should have also pointed at an Update (not Obsolete) for
rfc5640.

This document replaces rfc5512, so there's no work left unaddressed there.

As far as rfc5566, the WG had checked on implementations and/or
interest in updating it along with this document, but the Chairs came
up empty: no current interest or implementations.  There is however
other work that is "replacing" the IPsec functionality described in
rfc5566 (but independent of it):
draft-dunbar-idr-sdwan-edge-discovery,
draft-sajassi-besss-secure-evpn, and draft-hujun-idr-bgp-ipsec.