Re: [Idr] WG adoption for draft-kumari-deprecate-as-set-confed-set - 8/16 to 8/30/2019

Jeffrey Haas <jhaas@pfrc.org> Fri, 23 August 2019 14:44 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 9E44D120073 for <idr@ietfa.amsl.com>; Fri, 23 Aug 2019 07:44:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iRXGnyIv--Xb for <idr@ietfa.amsl.com>; Fri, 23 Aug 2019 07:44:56 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4798812006E for <idr@ietf.org>; Fri, 23 Aug 2019 07:44:56 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 05CE61E2F6; Fri, 23 Aug 2019 10:47:16 -0400 (EDT)
Date: Fri, 23 Aug 2019 10:47:16 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Job Snijders <job@ntt.net>
Cc: john heasley <heas@shrubbery.net>, Interminable Discussion Room <idr@ietf.org>
Message-ID: <20190823144716.GO367@pfrc.org>
References: <012001d5543f$ab7015a0$025040e0$@ndzh.com> <20190816154827.GA26534@shrubbery.net> <m2k1bdyqwv.wl-randy@psg.com> <20190816172208.GC26534@shrubbery.net> <20190816172430.GB64486@hanna.meerval.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190816172430.GB64486@hanna.meerval.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/rDKhZAHfHFSUbm8AZR-SYI1aq1k>
Subject: Re: [Idr] WG adoption for draft-kumari-deprecate-as-set-confed-set - 8/16 to 8/30/2019
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, 23 Aug 2019 14:44:58 -0000

On Fri, Aug 16, 2019 at 07:24:30PM +0200, Job Snijders wrote:
> On Fri, Aug 16, 2019 at 05:22:08PM +0000, john heasley wrote:
> > Fri, Aug 16, 2019 at 10:13:36AM -0700, Randy Bush:
> > > > imo, wg discussion of this should address how the complete removal
> > > > will proceed, such that implementations can drop support entirely,
> > > > which this draft does not address.
> > > 
> > > could you explain a bit more?  e.g. do you mean how a conforming
> > > speaker, i.e. one which does not support sets, should act when
> > > receiving a set?
> > 
> > yes; wouldnt one respond with an unknown/malformed attribute
> > notification, unless some alternative were prescribed.
> 
> 'treat as withdraw' would seem more appropriate

That's one way to do this.  But as stands, simply saying "deprecated/don't
do this" and urging "don't support" in future implementations will get you
errors at some point if we're not careful.

Right now, we still have BGP speakers on the Internet that are speaking
largely raw RFC 1771.  It largely still works since a lot of the nits that
got addressed between 1771 and 4271 (and related modification RFCs like
confederations) have internal impact to a given AS and don't bleed into the
wider Internet.

It's necessary to presume we SHALL see SET elements in AS_PATHs for the
foreseeable future.  Deprecating needs to be explicit what to do when you
see them.  Treat as withdraw is a fine way to do it.  Encouraging existing
implementations to make sure their policy algebras are sophisticated enough
to match on set elements so you can do discard is another.  (Multiple
implementations are policy ignorant with regard to set matching.)

Saying "I don't recognize these" is not a viable incremental implementation
strategy.

-- Jeff