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