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

Alvaro Retana <> Thu, 03 December 2020 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C8A03A0C59; Thu, 3 Dec 2020 06:38:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CA1ObI_m0jdB; Thu, 3 Dec 2020 06:38:03 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 920C83A0C3A; Thu, 3 Dec 2020 06:38:03 -0800 (PST)
Received: by with SMTP id 7so3842922ejm.0; Thu, 03 Dec 2020 06:38:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=8DVLuvLqSiEarN+SQ1MAq2aPucyJSwyyQu9OpBFhlnU=; b=fO0jQFWaDa5PtxcQnZpXOb4yODzbEF6XlUGrX+2LBCAXQv5JzOb2+o89BK4FGTpsR9 S0o4NW5A5EofSwFB7pY8z4wFu4oei9nsb6WKwZKmb0O4d9oofeDrR3I1wqEtta+aqdyG cO0v4wzvJS69JdbCXx7FNLgZAEVpmuXngucMs0k+ev5DdZX7MgWD7HzTcz/7LGTbTwWh k10pl6qR2h8CqY/wH9XxqugvBwJ6qd9618RwaTyG2QvQH6l0y/edAw3n5S9ma7YLbUVV LEVUk5TAiEQYhlJn2PoxgFN4CXWc3hV3pTLAmyZZ7owfSyl4sWPbdUjPZa6Xkce9bGg+ TVow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=8DVLuvLqSiEarN+SQ1MAq2aPucyJSwyyQu9OpBFhlnU=; b=QECfFKBHKmgz7LXfhXuet3d+8GU/cf70N1JwGhm/oJ33wCmVJ3t18+am+8qb6ZzXsb VtQzO1dVPQPhGOlUT7D9G6rjbtEpMhpOTUA0UREktwIWPCF8YMf0jTdb9Z6ExLae3FmQ YuUnF/9sKCmc7jTRpKQBAJqyuv7rcwGJMz4K7Q8cRXc0zOUH6uvIDJn/wEvHM09Jhnvz qRO4mvakrc8C7lYpRWGzrhle/cSvo7PZs4SebWZXSYc+L4smaDlFiHYxLCNDIXG2L8Oj I01wmF5YitaQMAdlachi4Vz43D/M8cH+RoNoaLcfeZdbqIkQy1vhP48jpheDKKsQ1yC0 +kTw==
X-Gm-Message-State: AOAM533FrPjm2DXgsMCldMVPoWnKkK3kA953V1RC6GlnXym55TzlmKno yffib/WgBma3X30XjJs+zvx2s5GWz6hD25QR600=
X-Google-Smtp-Source: ABdhPJzLWvZQxa9Msj4KMb3/BZ8M8+2XLvI8bG7QZeJmVJZCe40cXBDCs/2OOLGAVYJm4dyPe/WRqnk5L0fAxJZB5+c=
X-Received: by 2002:a17:907:444f:: with SMTP id on23mr2852245ejb.300.1607006282168; Thu, 03 Dec 2020 06:38:02 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 3 Dec 2020 06:38:01 -0800
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Date: Thu, 03 Dec 2020 06:38:01 -0800
Message-ID: <>
To: Benjamin Kaduk <>
Cc: Susan Hares <>, Benjamin Kaduk via Datatracker <>,,, The IESG <>,, John Scudder <>
Content-Type: multipart/alternative; boundary="00000000000099bc5f05b5904e97"
Archived-At: <>
Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Dec 2020 14:38:07 -0000

Yes, you’re right.



On December 3, 2020 at 9:04:39 AM, Benjamin Kaduk ( wrote:

Hi Alvaro,

Thanks for this; it causes a lot of the pieces to fit together better and
make sense.

Regarding just one thing:

> related to rfc8365 there's nothing that has to be done.

The Appendix does mention that "a review of Section 8.3.1 of RFC 8365 is
called for" regarding the split horizon procedures. Am I correct in
understanding that this review is only needed in the case that someone
decides to use RFC 8365 with the expanded functionality provided by the
Tunnel Encapsulation Attribute (rather than the preexisting extended
community)? In some sense, that would just be saying that "the combination
of the two is out of scope for this document", which is something that we
see fairly often and does not seem problematic.

Anyway, I think we can consider this discuss point resolved.

Thanks again!


On Thu, Dec 03, 2020 at 05:09:41AM -0800, Alvaro Retana wrote:
> On December 1, 2020 at 1:18:15 PM, Benjamin Kaduk wrote:
> Ben:
> Hi!
> I’m just addressing your second DISCUSS point.
> Thanks!
> Alvaro.
> > ----------------------------------------------------------------------
> > ———————————————————————————————————
> …
> > 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
> > 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
> 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.