Re: [netmod] 6991bis: address-with-prefix-length

tom petch <ietfc@btconnect.com> Wed, 24 April 2019 10:10 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C21C1200DB for <netmod@ietfa.amsl.com>; Wed, 24 Apr 2019 03:10:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.248
X-Spam-Level:
X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
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 GJZamz5OHCxk for <netmod@ietfa.amsl.com>; Wed, 24 Apr 2019 03:10:29 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60132.outbound.protection.outlook.com [40.107.6.132]) (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 75A08120021 for <netmod@ietf.org>; Wed, 24 Apr 2019 03:10:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lVlsAJTYTZmSR8umJsnEAMpGwkgeb5QOusTKkI7vPQQ=; b=EOEo669uYeWXpOsX95pPOLbrlUllSHKWVJi61WGJiT/gqVfYLXgQwH7PQD/RBmb9q+0bEXdpxfrbM+wCCdmVPhjbjM6O6ZJwjd6Fd6NSOd9zVv+J9Yt5erUTZJQexOm0Sst/4rCCS5NDxyldUqGMkRe7zP+W/yhWryhnBPwItBQ=
Received: from DB7PR07MB5562.eurprd07.prod.outlook.com (20.178.46.212) by DB7PR07MB4540.eurprd07.prod.outlook.com (52.135.141.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.11; Wed, 24 Apr 2019 10:10:26 +0000
Received: from DB7PR07MB5562.eurprd07.prod.outlook.com ([fe80::89bf:8194:3f8c:ff65]) by DB7PR07MB5562.eurprd07.prod.outlook.com ([fe80::89bf:8194:3f8c:ff65%6]) with mapi id 15.20.1835.010; Wed, 24 Apr 2019 10:10:26 +0000
From: tom petch <ietfc@btconnect.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, Martin Bjorklund <mbj@tail-f.com>, "kristian@spritelink.net" <kristian@spritelink.net>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] 6991bis: address-with-prefix-length
Thread-Index: AQHU+oXvs2vL6ro8M0iyTaNYwhsJtA==
Date: Wed, 24 Apr 2019 10:10:26 +0000
Message-ID: <04d601d4fa85$7ab58da0$4001a8c0@gateway.2wire.net>
References: <20190418120353.gslhfbdic3tuyqu6@anna.jacobs.jacobs-university.de> <20190418.141843.1973570958718557899.mbj@tail-f.com> <ee598735-7853-fa64-1c26-80200e07d871@spritelink.net> <20190423.125503.1821955933546060158.mbj@tail-f.com> <e9409ee82f004c5cad7a149e33196ccc@XCH-RCD-007.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0079.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8::19) To DB7PR07MB5562.eurprd07.prod.outlook.com (2603:10a6:10:7b::20)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d190c6c9-d782-4fd4-e4a6-08d6c89d121d
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DB7PR07MB4540;
x-ms-traffictypediagnostic: DB7PR07MB4540:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <DB7PR07MB454090BF5455D945AF39B533A03C0@DB7PR07MB4540.eurprd07.prod.outlook.com>
x-forefront-prvs: 00179089FD
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(396003)(136003)(39860400002)(346002)(189003)(199004)(13464003)(51444003)(4720700003)(86152003)(97736004)(5660300002)(50226002)(71200400001)(25786009)(6306002)(6512007)(81166006)(229853002)(71190400001)(8676002)(6246003)(2501003)(53936002)(84392002)(2906002)(305945005)(14444005)(93886005)(256004)(68736007)(9686003)(6436002)(81156014)(44736005)(3846002)(6486002)(86362001)(478600001)(4326008)(6116002)(8936002)(110136005)(81686011)(14454004)(66476007)(6506007)(66446008)(52116002)(966005)(99286004)(102836004)(14496001)(66556008)(7736002)(81816011)(1556002)(26005)(486006)(62236002)(76176011)(66066001)(61296003)(316002)(476003)(186003)(446003)(66946007)(53546011)(73956011)(44716002)(64756008)(386003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB4540; H:DB7PR07MB5562.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: nrUVBUYBjNT7RboOKWXzFNyqrspCSdt5r8TAVq+I1aKQWojSoPrORW6bCH6xJJGVcnhoX2cAkhJAY9KSrwCobHioiKbtkUiwk1TCoRgXA/A9bRUJwx61da0+qZt9K9jBFhsolfHZsc4MmEaHll6WYoasrplnrk8V34taZh4wnL97kyrSWolCt5fYeABmF3ocGC+jwqSw3+HoBaFawB+k77nzMJmM7+4pR44dspLJEE7Krc63fouah9E6HBm+fy5C0Hsc47eHLKmgWS3cutwXCIyizhabd/3iBe6AxUOViO6p/LHYEC5t9L9tP/RKiJBeFtaDPzhCE8UqqZniiWS7gymhy3vVt7moP15dvEcS47f0dgQm0za+A8z8dGEJGDwfgOyp2tSmB9ZtZdPYVUgedHtwAjUzhU3Q3DJM41cgn1c=
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <ADAF29B3D9D7C544B902C6C460A5D525@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d190c6c9-d782-4fd4-e4a6-08d6c89d121d
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2019 10:10:26.4497 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4540
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/iami9A2nNEeRc-gKZUm9hMbPxUQ>
Subject: Re: [netmod] 6991bis: address-with-prefix-length
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Apr 2019 10:10:32 -0000

----- Original Message -----
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>;
ent: Tuesday, April 23, 2019 5:45 PM

> I'm with Kristian on this. :-)
>
> I also think that "1.2.3.4/24" contains an IP addresses, and the
length of the IP prefix.
>
> For me, the natural encoding of:
>   ip-address-and-prefix would be "1.2.3.4/1.2.3.0"
>   ip-address-and-prefix-mask would be "1.2.3.4/255.255.255.0"
>   ip-address-and-prefix-len would be "1.2.3.4/24"
>
> I think that only the first one actually contains both the IP address
and the prefix.  For the other two the prefix is derived from the
provided values.
>
> ----
>
> I also think that it is useful to define this type, because types like
this are being used in various vendor models.
>
> However, I do have a concern that we may be opening IETF up for
inconsistency with the IETF YANG models if different protocols define
this in different ways.  Perhaps the answer is to define both the
combined type and the equivalent grouping, and also perhaps highlight in
the description of the grouping of the two alternative representations
that are available.

I think that the other trap we are falling into is that of trying to
make an identifier do all the work, convey the semantics, and in doing
so make the identifier clumsy and hard to use - the IETF is good at
this:-(

As was said three weeks ago, this type has three elements, an address -
10.0.0.1 - a prefix - 10.0.0.0 - and a prefix length - /24.  If you do
not have the length, then you cannot tell 10.0.0.0 (with a length of 24)
from 10.0.0.0 (with a length of 16).  But to then call it 'ip address
with prefix and with prefix length' is - well, silly comes to mind.

We need to bear in mind the namespace we are slotting this into, namely

 ip-address
 ipv4-address
 ipv6-address
 ip-address-no-zone
 ipv4-address-no-zone
 ipv6-address-no-zone
 ip-prefix
 ipv4-prefix
 ipv6-prefix

which steers me towards
ip-address-prefix
with perhaps an alternative of
ip-address-mask
except that I fear that the latter would fall foul of the IESG with
their insistence that all must be IPv6 and having to cater for those who
are not old enough to know what a mask is.

If the namespace were large, e.g. Webster's Dictionary, then our
identifier would need to be longer - but it isn't

Tom Petch

> Thanks,
> Rob
>
>
> -----Original Message-----
> From: netmod <netmod-bounces@ietf.org>; On Behalf Of Martin Bjorklund
> Sent: 23 April 2019 11:55
> To: kristian@spritelink.net
> Cc: netmod@ietf.org
> Subject: Re: [netmod] 6991bis: address-with-prefix-length
>
> Kristian Larsson <kristian@spritelink.net>; wrote:
> >
> >
> > On 2019-04-18 14:18, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>;
wrote:
> > >> On Thu, Apr 18, 2019 at 10:41:11AM +0200, Ladislav Lhotka wrote:
> > >>>>>
> > >>>>> I am not in favour of adding this type. Having ip-prefix next
to
> > >>>>> ip-address-and-prefix is confusing.
> > >>>>
> > >>>> Confusing or not, they are NOT interchangeable and actually do
> > >>>> different things, which is why both are needed. There's plenty
of
> > >>>> precedence to
> > >>>
> > >>> I actually agree with you. It is a historical accident that
these
> > >>> two different things got mixed up (and some vendors contributed
to
> > >>> this). I would argue that
> > >>>
> > >>> - IP prefix is a set of IP addresses, and as such can be thought
of
> > >>>    as a single entity.
> > >>>
> > >>> - IP address and subnet mask/prefix are two separate things, the
> > >>>    latter being an instruction for routing to *other*
destination
> > >>>    addresses.
> > >>
> > >> I think we should be pragmatic. There are other common types that
> > >> are in fact constructed out of simpler types, date-and-time is a
> > >> prime example of a type constructed out of a date value and a
time value.
> > > I think that date-and-time represents one thing - a single point
in
> > > time.
> >
> > Convenient for users to enter a single point in time in terms of
year,
> > month, day, hours, minutes and seconds, perhaps. But not as
convenient
> > for a program that needs to compare two date-and-times.
>
> Actually, *comparing* works quite ok, but calculating diff is not as
easy.
>
> > Clearly for a
> > program comparing times against each other we must represent a point
> > in time as the number of vibrations of cesium since an arbitrarily
> > chosen epoch.
>
> We do have yang:timeticks as well.  In some cases that's a better type
than yang:date-and-time.
>
> > >> is sometimes convenient to treat something that is in fact
> > >> constructed as an atomic value.
> > > Convenient for users that enter these values, perhaps.  But not as
> > > convenient for a program (or a filter) that needs one of the
> > > combined values.
> >
> > Really? Are you using a text representation of IP addresses when you
> > handle them in your program?
> >
> > If you are to deal with IP addresses, prefixes etc in a robust way
in
> > your program, you need an internal datatype that understands what an
> > address is - it needs to handle it as bits and massage it to any
other
> > presentation you want. It needs to understand relevant comparisons
and
> > operations, like is prefix A contained in prefix B?
>
> I agree.  Note that I wrote *filter* above.  It also extends to
must/when expressions.  The problem is that these mechanisms use XPath,
and XPath is quite limited when it comes to "understanding"
> types.  I even wrote a (now expired) draft with a proposed solution:
>
https://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions
-00
>
>
> > Or if we are dealing with time, then a class that understands leap
> > years, leap seconds, time zones etc can be fairly useful so you
don't
> > have to fall in any of those pitfalls.
> >
> > I don't think we choose a format or representation in our YANG
models
> > primarily to suit the algorithmic needs of a computer program, in
that
> > case an IPv4 address would just be a uint32 and not the dotted quad
> > format we have today.
> >
> >
> > >  For example, suppose I want to find all entries with a given
> > > prefix; that is non-trivial with a combined ip-address-and-prefix
> > > type.
> >
> > This seems like a very weird example since it doesn't support your
> > case; it is not easier with two separate leaves!?
> >
> > The alternative to using ip-address-and-prefix-length would be to
use
> > two leaves; one for the address and the other for the subnet mask /
> > prefix-length.
> >
> > combined:
> > ip-address-and-prefix-length:
> [RW]
> >
> > split:
> > address: 1.2.3.4
> > prefix-length: 24
> >
> > Say we have another interface with address '1.2.3.5' (prefix-length
24
> > still). In what way is it easier to determine these are part of the
> > same IP prefix / subnetwork by having the values split in two
leaves?
>
> As have been said before in this thread, it is not an address and a
prefix length, it is an address and a prefix.  So the split model would
have a leaf "ip-prefix: 1.2.3.0/24", which can be compared.
>
> > There is no text operation that can easily do this for us - we need
to
> > parse the values with some class / type in our programming language
> > that helps us make this comparison so in what way is
> > ip-address-and-prefix-length worse?
> >
> > Let us look at some examples how this is typically done. Again,
> > postgresql has the 'inet' type. From the docs:
> >
> > "The input format for this type is address/y where address is an
IPv4
> > or IPv6 address and y is the number of bits in the netmask. If the
/y
> > portion is missing, the netmask is 32 for IPv4 and 128 for IPv6, so
> > the value represents just a single host. On display, the /y portion
is
> > suppressed if the netmask specifies a single host."
> >
> > It wants it combined, which means the two leaves need to be
formatted
> > into something that looks like 1.2.3.4/24.
> >
> > Python ipaddress.IPv4, from example:
> >
> >   interface = IPv4Interface('192.0.2.5/24')
> >
> > Same thing. Rust ipaddress? Same thing. Go net? Same. Our internal
> > classes that compute IP addressing? Same thing. It seems most of the
> > datatypes that natively handle this kind of information takes a text
> > format like 1.2.3.4/24 as input (and not as separate fields), which
is
> > what is being suggested we have a datatype for.
>
> Is your point that there exist libraries that _can_ handle
"<addr>/<plen>", or are you suggesting that it is problematic to have
separate objects b/c libraries _only_ handle "<addr>/<plen>"?
>
> If it is the former, I agree.  There exist functions that can handle
this format.
>
>
>
> /martin
>