Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Mon, 17 December 2018 06:09 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279B5128CE4; Sun, 16 Dec 2018 22:09:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 GiFD4b9HkRDm; Sun, 16 Dec 2018 22:08:59 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 A331B1286E7; Sun, 16 Dec 2018 22:08:58 -0800 (PST)
X-AuditID: 12074425-029ff70000003bdd-1f-5c173d77790b
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 69.B6.15325.87D371C5; Mon, 17 Dec 2018 01:08:56 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wBH68spv020151; Mon, 17 Dec 2018 01:08:55 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wBH68qC4011043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Dec 2018 01:08:54 -0500
Date: Mon, 17 Dec 2018 00:08:51 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Peter Psenak <ppsenak@cisco.com>
Cc: draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.org, aretana.ietf@gmail.com, lsr-chairs@ietf.org, The IESG <iesg@ietf.org>, lsr@ietf.org, Acee Lindem <acee@cisco.com>
Message-ID: <20181217060851.GD94620@kduck.kaduk.org>
References: <154398144445.4943.7198735398003216566.idtracker@ietfa.amsl.com> <5C079200.1030701@cisco.com> <20181217055358.GC94620@kduck.kaduk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181217055358.GC94620@kduck.kaduk.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IR4hRV1q2wFY8xWH3UwGLy23nMFjcObWCy WDuti9lixp+JzBbrr55ksTjxZAWrxY7d7WwO7B5Tfm9k9dg56y67x5IlP5kCmKO4bFJSczLL Uov07RK4Mp61LGcs+CxY8b33HUsD4w3eLkZODgkBE4krh6+xdjFycQgJrGGSuLS0iRHC2cgo 8fTtYjYI5w6TxK0Fl5hBWlgEVCUWP+xgBbHZBFQkGrovg8VFgOx513tYQBqYBQ4zSjz/epUR JCEsUCsxbeIcsCJeoH03dz+H2jeNUeLu+olsEAlBiZMzn7CA2MwCWhI3/r1k6mLkALKlJZb/ 4wAJcwqYStzZ/QYsLAq07PMCgQmMArOQNM9C0jwLoXkBI/MqRtmU3Crd3MTMnOLUZN3i5MS8 vNQiXQu93MwSvdSU0k2MoCBnd1HdwTjnr9chRgEORiUe3gt7xGKEWBPLiitzDzFKcjApifJ+ NRCPEeJLyk+pzEgszogvKs1JLT7EKMHBrCTC22sJVM6bklhZlVqUD5OS5mBREuf9I/I4Wkgg PbEkNTs1tSC1CCYrw8GhJME7ywZoqGBRanpqRVpmTglCmomDE2Q4D9DwJJAa3uKCxNzizHSI /ClGRSlxXtbzgjFCAiCJjNI8uF5QEpLI3l/zilEc6BVhXgWQdh5gAoPrfgU0mAlocM4WJpDB JYkIKakGxsV3FG/xfF35PHOZf1NMV9fHC/M+Vpi/ZZwbV1Xh++h3p4fE26z8BQlpsw70Xf69 eWdrWUaB5zRVp8In75kf7NpgtGKSyt7H7A5yG0JPnGvb2L20OyyGd6PZvQzeLaemTT3f1h16 1JZpyvPfi742MJrKfXnL/i20ZUaBzpUM0wKlCxZPF1y78EyJpTgj0VCLuag4EQCweP+vHQMA AA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/6OgDo2uhcvI-obhzuRgtLqx2K38>
Subject: Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (with DISCUSS and COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Dec 2018 06:09:01 -0000

On Sun, Dec 16, 2018 at 11:53:59PM -0600, Benjamin Kaduk wrote:
> Sorry for the slow reply -- you caught me right as I was leaving for
> vacation.
> 
> On Wed, Dec 05, 2018 at 09:53:20AM +0100, Peter Psenak wrote:
> > 
> > On 05/12/18 04:44 , Benjamin Kaduk wrote:
> 
> > >
> > > I'm also not entirely sure how to construct the prefix range just given
> > > this format description.  Suppose I have an IPv4 prefix of 18.18/16 and a
> > > range size of 4; my prefix length is 16 and the address prefix is encoded
> > > as 0x120120000.  Am I then representing the four prefixes 18.18/16,
> > > 18.19/16, 18.20/16, and 18.21/16?
> > 
> > yes.
> > 
> > > Or am I constrained to be a subset of
> > > 18.18/18 (in which case I don't know what the actual distinct prefixes
> > > would be)?  The examples in Section 6 suggests the former, but I would suggest
> > > stating this explictly, here.
> > >
> > 
> > I would thing that the example in section 16 is clear enough.
> 
> I generally prefer to describe the normative behavior in actual text
> description instead of relying on examples to clarify the expected
> behavior.  That said, this is a non-blocking comment, so feel free to
> retain the current text.  If you did want to add something, I would
> propose the strawman:
> 
> OLD:
>    The range represents the contiguous set of prefixes with the same
>    prefix length as specified by the Prefix Length field.  The set
>    starts with the prefix that is specified by the Address Prefix field.
>    The number of prefixes in the range is equal to the Range size.
> 
> NEW:
>    The range represents the contiguous set of prefixes with the same
>    prefix length as specified by the Prefix Length field.  The set
>    starts with the prefix that is specified by the Address Prefix field and
>    continues with the subsequent prefixes of the same length, forming a
>    contiguous block of addresses.  Since the Range Size is not restricted to a
>    power of two, this new block of addresses may not be describable using a
>    single address prefix/length.  The number of prefixes in the range is
>    equal to the Range size.

Ah, now I see the text proposed in response to Suresh's comments; that text
works for me, too.

-Benjamin