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