Re: [Idr] Returning draft-ietf-idr-rfc5575bis to WG, new 2 week discussion period
Jeffrey Haas <jhaas@pfrc.org> Thu, 13 June 2019 20:52 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 8FCD212081D; Thu, 13 Jun 2019 13:52:08 -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_PASS=-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 qSstX9qAsRQB; Thu, 13 Jun 2019 13:52:06 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B45BC1207FD; Thu, 13 Jun 2019 13:52:06 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 6B1B61E2F1; Thu, 13 Jun 2019 16:53:10 -0400 (EDT)
Date: Thu, 13 Jun 2019 16:53:10 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Christoph Loibl <c@tix.at>
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>
Message-ID: <20190613205310.GI23231@pfrc.org>
References: <A68BF050-9846-4E14-918D-297548E078A2@juniper.net> <99A607F0-84C5-4D3D-99EF-36B733DE205A@tix.at>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <99A607F0-84C5-4D3D-99EF-36B733DE205A@tix.at>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/xYO8r_TOO3QaiJEtUSflqk7HM48>
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 20:52:14 -0000
Christoph, On Thu, Jun 13, 2019 at 09:22:15PM +0200, Christoph Loibl wrote: > I think that in this context we can treat a non-existing destination-ip flow-component as 0/0 and I suggest something like this: > > OLD: > > 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. > > 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. 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. > 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 > The draft itself does not deal with / mention any possible vendor-specific > exception mechanisms that allow to circumvent the validation (complete or > partly), thus I think there is no additional paragraph needed that tries > to explain how such validation can be relaxed. (maybe only very minimal > “This validation procedure MAY be relaxed by configuration.”) Thus why John's text is probably the level of desired flexibility. Copied from below: : NEW: : A Flow Specification NLRI must be validated such that it is : considered feasible if and only if: : : a) A destination prefix component is embedded in the Flow : Specification. : : b) The originator of the Flow Specification matches the originator : of the best-match unicast route for the destination prefix : embedded in the Flow Specification. : : c) There are no more specific unicast routes, when compared with : the flow destination prefix, that has been received from a : different neighboring AS than the best-match unicast route, which : has been determined in step b). : : Rule a) MAY be relaxed by configuration, permitting Flow : Specifications that include no destination prefix component. If such : is the case, rules b) and c) are moot and MUST be disregarded. -- Jeff
- [Idr] Returning draft-ietf-idr-rfc5575bis to WG, … John Scudder
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Robert Raszuk
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Christoph Loibl
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Jeffrey Haas
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Jeffrey Haas
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Robert Raszuk
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Christoph Loibl
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Jeffrey Haas
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Robert Raszuk
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Jeffrey Haas
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Robert Raszuk
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Christoph Loibl
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … John Scudder
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Susan Hares
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … John Scudder
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … John Scudder
- Re: [Idr] Returning draft-ietf-idr-rfc5575bis to … Susan Hares