Re: [Gen-art] [Idr] Genart last call review of draft-ietf-idr-flow-spec-v6-17

Christoph Loibl <> Mon, 09 November 2020 10:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E60D3A0DED; Mon, 9 Nov 2020 02:06:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RsylKhCven-o; Mon, 9 Nov 2020 02:05:59 -0800 (PST)
Received: from ( [IPv6:2001:858:58::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC4CE3A0D01; Mon, 9 Nov 2020 02:05:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=rev1; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=yBAmKFbUGQw/Oat4jBN0ZZYd7YvAg45M+x+0qhhZr5o=; b=m88FejklJi9/GUUtKYvI9KRsuH by7DQ+Zs/S8o9vZiS9+CZHUhbyngd20bbQm9mJOr+EeMLGCbTYhC329QA6SIkdvmoFtBJSM7kZoi/ mkl6mmeEWmoF4L0RZPZr8psMgUMbn4d5Jllt4soFw+sglQOHciRKxv5h3AFMOVdfeD4AOF8uAvwXB vDcJZbaw3enmasQQ90ny+WCRGaOwkMeY7xqfn8r/usYnDG2kg+SSvH5UHIUY+s9W7QC0oZEldMkdt +OCc8rvYM/i6t2CWF3uW/T+MGGiWY3Xs2YKCxEwPL4MogqmHk+1IN9rERgAoiBMiTg7JoS+XSQZVb Ga3Tr2Ag==;
Received: from ([] helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <>) id 1kc43f-000BLX-Az; Mon, 09 Nov 2020 11:05:56 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Christoph Loibl <>
In-Reply-To: <>
Date: Mon, 09 Nov 2020 11:05:51 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Dale Worley <>
X-Mailer: Apple Mail (2.3608.
X-Scanned-By: primary on (; Mon, 09 Nov 2020 11:05:55 +0100
Archived-At: <>
Subject: Re: [Gen-art] [Idr] Genart last call review of draft-ietf-idr-flow-spec-v6-17
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Nov 2020 10:06:02 -0000

Hi Dale,

Thank you for your review of the document. Please, see my comments inline.

The document has been edited, but since the datatracker is closed it will take some time until the changes are online.

Cheers Christoph

Christoph Loibl | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 |

> Nits/editorial comments:
> 3.1. Type 1 - Destination IPv6 Prefix
> 3.2. Type 2 - Source IPv6 Prefix
> Unlike IPv4, it is plausible that a set of flows could be determined
> by two contiguous sections of an address, e.g., an initial prefix and
> a subset of bits within an embedded IPv4 address. By
> draft-ietf-idr-rfc5575bis-26 section 4.2, an IPv6 flow specification
> may not contain two Destination IPv6 Prefix or two Source IPv6 Prefix
> components, so this type of selection cannot be specified.

A single Flow Specificaton NLRI "rule" can only contain a single destination (Type1) and a single source prefix (Type 2). However you can have multiple FS rules "like firewall rules" matching different src/dst pairs. 

> 1. Ordering of Flow Specifications
> If the offsets are not equal, the lowest offset has
> precedence, as this flow matches the most significant bit.
> "as this flow" should be "as this flow specification"

Edited as suggested.

> 1. Validation Procedure
>    a) A destination prefix component with offset=0 is embedded in the
>    Flow Specification
> I note that this requirement has no functional effect, as a
> destination prefix with length = 0 can always be added to a flow
> specification without effect. However, this observation also applies
> to IPv4 flow specifications, so I assume it has been given due
> consideration.

A length=0 destination-prefix (IPv4 or IPv6 FS) would match every destination prefix. This will only validate if the BGP neighbor announces a default route and you are only following this single route (very unlikely though).