Re: [Idr] Routing directorate review of draft-ietf-idr-flow-spec-v6-17

Christoph Loibl <c@tix.at> Thu, 22 October 2020 10:52 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 81FD63A0997; Thu, 22 Oct 2020 03:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at
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 4uzP-jwFakR2; Thu, 22 Oct 2020 03:52:39 -0700 (PDT)
Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9256C3A0994; Thu, 22 Oct 2020 03:52:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject: Mime-Version:Content-Type:Sender:Reply-To:Content-Transfer-Encoding: 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=5bXfkq6Q3WRGpHFguH6fHwCj4eE/Hq140lt3S/xtGRo=; b=cr1X1O3lWGAajw85mavq07WhTU w54P4KUlE5IjLe0z/1VDZw+vCcT1T2XVobYqKR4o6fIPZ6E1UQe+VmwDvBUHypEelpDBY1q2td5d6 lj7Vr21ULBibCYROYmzRT3cPtjDuoj5SooHm7aiozRCX++rjMI1T4TforWuFkxaHWANOIzN3pHoO8 1WhnKl6C5PDuOBVP6jNskgDXdtn3gwR+4HCPJu8ONejRF3DbEswQ96QSz92NFonpKF8cfvH4TUtyp XTx6RVW4kLEy2OktdCwjKsoeDre8upjFqp3qJgKVTUTnGTf38DsB7MUXijEnX7DbBhtvxWRYkapt9 4GWrCmWg==;
Received: from 213-225-13-132.nat.highway.a1.net ([213.225.13.132] helo=[192.168.43.10]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <c@tix.at>) id 1kVYCv-000Ifj-Ix; Thu, 22 Oct 2020 12:52:34 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_31617476-2A11-4D38-9BD8-E068C17868B3"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Christoph Loibl <c@tix.at>
In-Reply-To: <SN6PR02MB5101DA401EA6480D5BD24207841C0@SN6PR02MB5101.namprd02.prod.outlook.com>
Date: Thu, 22 Oct 2020 12:52:31 +0200
Cc: "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-idr-flow-spec-v6.all@ietf.org" <draft-ietf-idr-flow-spec-v6.all@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Message-Id: <140D33E4-970B-41C5-9CBD-E4357E96DC51@tix.at>
References: <SN6PR02MB5101DA401EA6480D5BD24207841C0@SN6PR02MB5101.namprd02.prod.outlook.com>
To: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Thu, 22 Oct 2020 12:52:33 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/PAqadvDpR4_IaxAghnyXPS8RIKA>
Subject: Re: [Idr] Routing directorate review of draft-ietf-idr-flow-spec-v6-17
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, 22 Oct 2020 10:52:43 -0000

Hi Jonathan,

Thanks for reviewing the document. Please see my comments on the minor issues you raised inline.


> On 21.10.2020, at 21:11, Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com> wrote:
> 
> Minor issues:
>  
> Section 3.6
> I note that this is consistent with rfc5575bis, but it left me with several questions.
> What is an implementation to do if contradictory bits are set in the same bitmask? (IsF & FF)? (FF & LF)?

That depends on the setting of the match-bit in the bitmask operator. If, for example FF and LF are set in the bitmask and the m-bit=0 packets will match where either the FF OR the LF test results in True. If the m-bit=1 both the FF AND the LF test must result in True (which is not possible) and it will never match any packets. Side-note: in the m-bit=1 case also the IsF is taken into account and the result must match the bitmask (0 or 1). 


> Same question if contradictory bits are set in successive bitmasks and the “AND” bit is set in bitmask_op?
> What is the effect of setting / clearing the “match” bit in bitmask_op?

See the match-bit above. The numeric operator as well as the bitmask operator allows multiple operations to be chained:

<type (1 octet), [bitmask_op, bitmask]+>

So the encoding can express the following:

0x0c (Type=Fragment), bitmask_op1, bitmask1, bitmask_op2, bitmask2, …

When the AND bit is *not* set match is based on result1 OR result2 (either result1 gives a match OR result2). If the AND bit is set the result of the match is result1 AND result2. Especially in the case of the numeric operator you can use this for matching ranges like this:

(port < 1000) & (port > 2000) 


>  
> Section 3.3
> “Type 3 component values SHOULD be encoded as single octet” – why not a MUST?

Simply to have it aligned with rfc5575(bis) where we had no consensus to change this to a MUST. Keeping this in sync may allow reusable code.  

>  
> Nits:
>  
> Section 3.1
> Suggest rewording “of N first bits of the address” -> “the first N bits of the address”
> I find the “length” field oddly named. I misunderstood it at first as the length of the pattern. I think “end_offset” might have been a better choice. Not a big deal though.

This is true - I will add this to the list of potential issues. In case of offset=0 this length-field is very much like the prefix-length in the ipv6 nlri.

Thanks.

Cheers 
Christoph

-- 
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at