Re: [Idr] WGLC for draft-ietf-idr-rfc5575bis-04

Christoph Loibl <c@tix.at> Mon, 16 October 2017 17:30 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 09D29133047; Mon, 16 Oct 2017 10:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 MBep93QBD_UH; Mon, 16 Oct 2017 10:30:56 -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 38E3C13304D; Mon, 16 Oct 2017 10:30:56 -0700 (PDT)
Received: from 80-110-97-151.cgn.dynamic.surfer.at ([80.110.97.151] helo=[192.168.66.220]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <c@tix.at>) id 1e48yB-0003bE-JP; Mon, 16 Oct 2017 19:14:28 +0200
From: Christoph Loibl <c@tix.at>
Message-Id: <2BC99F74-930C-4826-A1C0-9F1C520B9A8A@tix.at>
Content-Type: multipart/signed; boundary="Apple-Mail=_CC7237C4-C47A-4C55-B51B-35CE6D3BFF8A"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 16 Oct 2017 19:30:51 +0200
In-Reply-To: <20171016170701.zya6xoa5tsbwohw6@hanna.meerval.net>
Cc: draft-ietf-idr-rfc5575bis@ietf.org, idr@ietf.org
To: Job Snijders <job@ntt.net>
References: <00A83D9A-C00E-4A91-8007-421067DCE879@juniper.net> <20171014153402.GY19142@Vurt.local> <55EAFCD6-4783-4DDD-B1B9-30AF18FD2342@tix.at> <20171016120520.GM19142@Vurt.local> <5B6788C8-6E39-4CF0-880A-2D35DCCEEB82@tix.at> <20171016163046.mxgeamcgdx6xhzoh@hanna.meerval.net> <20171016170701.zya6xoa5tsbwohw6@hanna.meerval.net>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jXyVxwG9jsA_EaRHVJDLuxw2qQk>
Subject: Re: [Idr] WGLC for draft-ietf-idr-rfc5575bis-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 16 Oct 2017 17:30:59 -0000

Hi Job,


> On 16 Oct 2017, at 19:07, Job Snijders <job@ntt.net>; wrote:
> 
> On Mon, Oct 16, 2017 at 04:30:46PM +0000, Job Snijders wrote:
>> OLD: For IP prefix values (IP destination and source prefix) precedence
>>     is given to the lowest IP value of the common prefix length; if the
>>     common prefix is equal, then the most specific prefix has
>>     precedence
>> 
>> PERHAPS:
>>    For IP prefix values (destination or source) the common high-order
>>    bits are compared. The number of common bits to compare is the
>>    lowest prefix-length of the two prefixes. If the high-order bits are
>>    equal, the prefix with the longer prefix-length has higher
>>    precedence. If the common high-order bits are different, the prefix
>>    with the lowest numeric value takes higher precedence.
> 
> Still feels wonky, maybe this:
> 
> PERHAPS:
>    For IP prefix values (destination or source) the common high-order
>    bits are compared. The number of common bits to compare is the
>    lowest prefix-length value of the two prefixes. If the high-order
>    bits are equal, the prefix with the longer prefix-length has higher
>    precedence. If the common high-order bits are different, the prefix
>    with the set of bits that represent the lowest numeric value takes
>    higher precedence.
> 

Maybe you missed this in one of my previous emails, but this seems to be very easy to read and is the same behaviour:

PERHAPS:
For IP prefix values (IP destination or source prefix): If the prefixes are overlapping, the one with the longer prefix-length has higher precedence. If they are not overlapping the one with the lowest IP value has higher precedence.

Christoph