Re: [Idr] Returning draft-ietf-idr-rfc5575bis to WG, new 2 week discussion period

Christoph Loibl <c@tix.at> Thu, 13 June 2019 21:54 UTC

Return-Path: <c@tix.at>
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 4487212013C; Thu, 13 Jun 2019 14:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 epTJM0061aYM; Thu, 13 Jun 2019 14:54:29 -0700 (PDT)
Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7D89120167; Thu, 13 Jun 2019 14:54:28 -0700 (PDT)
Received: from 80-110-113-122.cgn.dynamic.surfer.at ([80.110.113.122] helo=[192.168.66.207]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <c@tix.at>) id 1hbXaM-0002dz-FB; Thu, 13 Jun 2019 23:48:43 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Christoph Loibl <c@tix.at>
In-Reply-To: <20190613205310.GI23231@pfrc.org>
Date: Thu, 13 Jun 2019 23:54:22 +0200
Cc: John Scudder <jgs=40juniper.net@dmarc.ietf.org>, "draft-ietf-idr-rfc5575bis@ietf.org" <draft-ietf-idr-rfc5575bis@ietf.org>, "idr@ietf. org" <idr@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <374ACD0E-45BC-4416-AE8B-8D5C1AF6535D@tix.at>
References: <A68BF050-9846-4E14-918D-297548E078A2@juniper.net> <99A607F0-84C5-4D3D-99EF-36B733DE205A@tix.at> <20190613205310.GI23231@pfrc.org>
To: Jeffrey Haas <jhaas@pfrc.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/6bDAvT_BO8pwqIWmYAwqaI2DuYU>
Subject: Re: [Idr] Returning draft-ietf-idr-rfc5575bis to WG, new 2 week discussion period
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, 13 Jun 2019 21:54:31 -0000

Hi,


> On 13.06.2019, at 22:53, Jeffrey Haas <jhaas@pfrc.org> wrote:
> On Thu, Jun 13, 2019 at 09:22:15PM +0200, Christoph Loibl wrote:
>> NEW:
>> 
>>     a) The originator of the Flow Specification matches the originator
>>     of the best-match unicast route for the destination prefix
>>     embedded in the Flow Specification. 0/0 is assumed as destination prefix in 
>>     this context if it is not embedded in the Flow Specification.  
> 
> I think this has the likelihood to cause some undesirable implementation
> behaviors.

I have no lab at hand (now) - but I am really curios how ie. Juniper (also other vendors) actually validate FS without a destination-prefix component (to be honest, I never tried this - but it is supposed to be easily verified).

> If the dest-prefix filter is presumed to be 0/0, the only route that can
> contain it is 0/0.  We're thus implicitly suggesting that if you want
> flowspec validation to work, originate default.

Originate default + have no other more-specifics punching holes into that 0/0 - this is arguable very unlikely :-) - still I am not convinced if the behaviour is so much different to what John suggested. I have no objections to John’s solution either.

>> Extensions may need to revise this validation behaviour for their needs anyway.
> 
> See also https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-08

Yes. Saw that.

> Thus why John's text is probably the level of desired flexibility.  Copied
> from below:

Reading John’s suggestion twice this seems to give more flexibility to extensions while keeping the core behaviour close to what is out there (still there may be changes in behaviour given we do not know what is out there). 

Cheers Christoph

-- 
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at