Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-mvpn-expl-track-13: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Mon, 03 December 2018 00:21 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AD9130DE0; Sun, 2 Dec 2018 16:21:08 -0800 (PST)
X-Quarantine-ID: <cVJl6JOp4Nrw>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 cVJl6JOp4Nrw; Sun, 2 Dec 2018 16:21:06 -0800 (PST)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D89D130DE5; Sun, 2 Dec 2018 16:21:05 -0800 (PST)
X-AuditID: 1209190d-925ff70000005108-da-5c0476f09b0c
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id C7.4C.20744.0F6740C5; Sun, 2 Dec 2018 19:21:04 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wB30L2c7020101; Sun, 2 Dec 2018 19:21:03 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wB30KvhY006982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 2 Dec 2018 19:21:00 -0500
Date: Sun, 2 Dec 2018 18:20:57 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Eric Rosen <erosen@juniper.net>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-bess-mvpn-expl-track@ietf.org" <draft-ietf-bess-mvpn-expl-track@ietf.org>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "bess@ietf.org" <bess@ietf.org>
Message-ID: <20181203002057.GC54918@kduck.kaduk.org>
References: <154352912422.26019.11045526919398221329.idtracker@ietfa.amsl.com> <c6c2b01d-ee17-b556-cf18-b0ef3ecd9186@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <c6c2b01d-ee17-b556-cf18-b0ef3ecd9186@juniper.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixCmqrPuhjCXGYP4na4udF/8wW6w4PpPZ 4sCZ7YwW6zZ8YLaY8Wcis8XXvQ9ZHdg8liz5yeRxvekqu0fLs5NsAcxRXDYpqTmZZalF+nYJ XBmPT19nLtjLX7F2xRW2BsbZPF2MnBwSAiYSJy+sZO5i5OIQEljDJDG34ReUs4FRYu3VmywQ zh0mialXn7KAtLAIqEhcabjABmKzAdkN3ZeZQWwRAWWJ5kUQo5gFVjBJTJ/ygh0kISyQKXH2 1nGwIl6gfQ/PHGaDmNrMKNE5eTErREJQ4uTMJ2AbmAV0JHZuvQNUxAFkS0ss/8cBEZaXaN46 G2wOp4C9xMHJ11lASkSBjvi8QGACo+AsJINmIRk0C2HQLCSDFjCyrGKUTcmt0s1NzMwpTk3W LU5OzMtLLdI10svNLNFLTSndxAiOBUneHYz/7nodYhTgYFTi4Z2RyBIjxJpYVlyZe4hRkoNJ SZTXqQgoxJeUn1KZkVicEV9UmpNafIhRgoNZSYS3oBAox5uSWFmVWpQPk5LmYFES5/0t8jha SCA9sSQ1OzW1ILUIJivDwaEkwbu5GKhRsCg1PbUiLTOnBCHNxMEJMpwHaHge2PDigsTc4sx0 iPwpRkUpcV7WZKCEAEgiozQPrheUqiSy99e8YhQHekWY1w2YuIR4gGkOrvsV0GAmoME5W5hA BpckIqSkGhgny1xZzDPjlJeuVZPIpCvv34af2JlxTXsz82aHdtWQHFGJFZyvLFnLNvpeku3K +Be8bi6nXoN+rmbov85KU1YJyyerdR7seOg7j/OkKN8v86UJt92Utd5oTssze/+2rGHFFbl9 QoY/H/A2CP3STUsy+rRp8aPzzYYi+8U35Bkt+8o1M/BInq8SS3FGoqEWc1FxIgAhbLjpMAMA AA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/UIrbmU7qhlwESshvr7cMRKqhcrQ>
Subject: Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-mvpn-expl-track-13: (with DISCUSS and COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Dec 2018 00:21:09 -0000

On Fri, Nov 30, 2018 at 04:23:36PM +0000, Eric Rosen wrote:
> On 11/29/2018 5:05 PM, Benjamin Kaduk wrote:
> > The updates in the -13 include new Updates headers for RFCs 7582 and 7900,
> > which may or may not call for additional IESG eyes on the changes.  Just from
> > looking at the diff, it's not entirely clear to me what about those documents is
> > being updated.
> 
> In Alvaro's comments, he explicitly asked me to put 7582 and 7900 in the 
> "Updates" header.
> 
> His reasoning was based on the the following text (which is unchanged 
> from the previous version) from Section 3:
> 
>     The rules for finding a "match for reception" in [RFC6625] are hereby
>     modified as follows:
> 
>        When applying the rules of Section 3.2.1 or 3.2.2 of [RFC6625], it
>        is REQUIRED to ignore any S-PMSI A-D route that has no PTA, or
>        whose PTA specifies "no tunnel information present".
> 
>     There are other RFCs that update [RFC6625] and that modify the rules
>     for finding a "match for reception".  See, e.g., [RFC7582] and
>     [RFC7900].  When applying those modified rules, it is REQUIRED to
>     ignore any S-PMSI A-D route that has no PTA, or whose PTA specifies
>     "no tunnel information present".

Ah, I see it now...

> Alvaro's comment was:
> 
> "This text is also Updating rfc7582 and rfc7900 (and others?) that Updated
> rfc6625.  This document should then be marked to Update those other RFCs
> explicitly."
> 
> This comment seems reasonable to me, but if you two would like to fight 
> it out, just let me know the resolution ;-)

...and apparently had completely forgotten about Alvaro's remark.

I'll go clear now, but will leave a mention of
https://mailarchive.ietf.org/arch/msg/ietf/-1u_1-peHKAmUDuLyGAJYu0fPCE for
reasons why one might want (or not want) to explicitly say things like
"this document Updates RFC XXXX by YYY".  As a non-blocking comment, of
course.

-Benjamin