Re: [Idr] Returning draft-ietf-idr-rfc5575bis to WG, new 2 week discussion period
Christoph Loibl <c@tix.at> Tue, 18 June 2019 09:13 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 DCD5A12000E; Tue, 18 Jun 2019 02:13:26 -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 fTsFopncN4gQ; Tue, 18 Jun 2019 02:13:24 -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 4EF321200BA; Tue, 18 Jun 2019 02:13:24 -0700 (PDT)
Received: from gaestewlan.nextlayer.at ([92.60.6.196] helo=[192.168.68.119]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <c@tix.at>) id 1hdA5T-0002Im-PK; Tue, 18 Jun 2019 11:07:32 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Christoph Loibl <c@tix.at>
In-Reply-To: <99A607F0-84C5-4D3D-99EF-36B733DE205A@tix.at>
Date: Tue, 18 Jun 2019 11:13:17 +0200
Cc: "draft-ietf-idr-rfc5575bis@ietf.org" <draft-ietf-idr-rfc5575bis@ietf.org>, John Scudder <jgs=40juniper.net@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5126B079-AD79-4645-9A90-F960A3BB20F3@tix.at>
References: <A68BF050-9846-4E14-918D-297548E078A2@juniper.net> <99A607F0-84C5-4D3D-99EF-36B733DE205A@tix.at>
To: "idr@ietf. org" <idr@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/2t3RANSenBQ-juL0lROkzUsUCGY>
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: Tue, 18 Jun 2019 09:13:27 -0000
Hi IDR, After some discussion on the list and also off-list I uploaded a new version of the draft (-17) that seems to have enough support from the WG (basically what John suggested initially). If there are very strong arguments against this change, please suggest a different fix to the problem John pointed out. John wanted to keep the discussion open until 28th June. Cheers Christoph OLD: A Flow Specification NLRI must be validated such that it is considered feasible if and only if: 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. b) 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 a). NEW: A Flow Specification NLRI must be validated such that it is considered feasible if and only if all of the below is true: 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 rule 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. -- Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at
- [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