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

Benjamin Kaduk <kaduk@mit.edu> Fri, 24 April 2020 01:46 UTC

Return-Path: <kaduk@mit.edu>
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 B2EDC3A0D2D; Thu, 23 Apr 2020 18:46:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 Kybvg93kbG8j; Thu, 23 Apr 2020 18:46:08 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 4BD543A0891; Thu, 23 Apr 2020 18:45:50 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03O1jTJb026491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Apr 2020 21:45:32 -0400
Date: Thu, 23 Apr 2020 18:45:29 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Robert Raszuk <robert@raszuk.net>
Cc: The IESG <iesg@ietf.org>, draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, "idr@ietf. org" <idr@ietf.org>, Jie Dong <jie.dong@huawei.com>, Alvaro Retana <aretana.ietf@gmail.com>
Message-ID: <20200424014529.GQ27494@kduck.mit.edu>
References: <158760254746.26942.2049621502527864651@ietfa.amsl.com> <CAOj+MMHUrPLrmy-sARPDnx0PQg4Uzg49uq06O_81YD0VTfFA3Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOj+MMHUrPLrmy-sARPDnx0PQg4Uzg49uq06O_81YD0VTfFA3Q@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/NvtxRR6lLCw_Q6SKn_Y4iynkbdI>
Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22: (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: Fri, 24 Apr 2020 01:46:10 -0000

Hi Robert,

On Thu, Apr 23, 2020 at 04:49:43PM +0200, Robert Raszuk wrote:
> Hi Benjamin
> 
> Acceptance and validation are completely different things.
> 
> By acceptance we say that router control plane accepted the update
> message (as opposed to dropping it due to non intersecting RTs in VPNs).
> 
> Validation however is executed on accepted routes to check if such routes -
> or to be more precise paths - are eligible to be used for best path
> selection and therefor for local installation into data plane.
> 
> Hope that clarifies the discuss :)

That does help clarify quite a bit, and I'm glad that I added my disclaimer
about misunderstanding things :)
I will of course drop the Discuss point.

>From just the previous messages in the thread I wasn't sure whether the
"accept" operation was meant to happen before or after validation, so thank
you for spelling it out clearly.  (Also thanks to everyone for being
patient with my misunderstanding!)  The string "accept" appears 7 times,
and the Section-1 usage seems to be what tripped me up ("A Flow
Specification received from an external autonomous system will need to be
validated against unicast routing before being accepted") -- note the
"before".  Section 12 perhaps has something similar ("[...], this may also
cause this validation to fail and consequently prevent Flow Specifications
from being accepted by a peer.").  I'll leave it up to you as to whether
any rewording is appropriate in those two places.

Anyway, armed with this new knowledge I can see that I was wrongly
interpreting what the text about "contrary to the behavior specified for
the non-VPN NLRI" was referring to.  I'm still not 100% sure what it is
intending to refer to, though -- is it even something in this document
(like the "Standard BGP policy mechanisms, such as UPDATE filtering by NLRI
prefix as well as community matching and manipulation, must apply to the
Flow Specification defined NLRI-type, especially in an inter- domain
environment." in Section 3) vs. just general knowledge of how things work?