Re: [netmod] Address Family versus Address Family

tom petch <ietfc@btconnect.com> Fri, 23 November 2018 12:03 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 8BFA2128B14 for <netmod@ietfa.amsl.com>; Fri, 23 Nov 2018 04:03:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.738
X-Spam-Level: *
X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 pzNj3cgp3Hjr for <netmod@ietfa.amsl.com>; Fri, 23 Nov 2018 04:03:42 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30111.outbound.protection.outlook.com [40.107.3.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DA4130E2D for <netmod@ietf.org>; Fri, 23 Nov 2018 04:03:34 -0800 (PST)
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=Sric8AsjyGcvH1/lMOhtKYagLSKVKpxeI3B1I9WOCWk=; b=Q4wA4RRRy/WPfAwJDlXyxUrsUmpzHk9o7mFit1RjEIg6fULlwroPpg5/QmMFcTqHkn9/FCZ+F6iCxCMy9PBtNFsXwoiiQD2UpqVs9dxlcVuPdlt7D2AFcQP9yDjYuwpqpnglQFviUFrl+EvJyipj65D1ip2mUcMafy8Io1dkQ0s=
Received: from VI1PR07MB5022.eurprd07.prod.outlook.com (20.177.202.206) by VI1PR07MB4141.eurprd07.prod.outlook.com (52.134.25.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.12; Fri, 23 Nov 2018 12:03:28 +0000
Received: from VI1PR07MB5022.eurprd07.prod.outlook.com ([fe80::929:bd11:beb6:b887]) by VI1PR07MB5022.eurprd07.prod.outlook.com ([fe80::929:bd11:beb6:b887%4]) with mapi id 15.20.1382.010; Fri, 23 Nov 2018 12:03:28 +0000
From: tom petch <ietfc@btconnect.com>
To: Ladislav Lhotka <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Address Family versus Address Family
Thread-Index: AQHUgY5NMaELHgY0r0Cg02b5JWd9UQ==
Date: Fri, 23 Nov 2018 12:03:28 +0000
Message-ID: <019f01d48324$44356bc0$4001a8c0@gateway.2wire.net>
References: <033101d4818e$08689dc0$4001a8c0@gateway.2wire.net> <87wop6sk6k.fsf@nic.cz>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: CWXP265CA0023.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:2e::35) To VI1PR07MB5022.eurprd07.prod.outlook.com (2603:10a6:803:9b::14)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [86.139.215.184]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB4141; 6:4oGhWIhm5q6Q2JfcdiOLBKECSMs7FvVIGm3rV4W448DXJgc71o/dZSa0+f8tP3mRyf4jI53eWCArXl11d3uPinwh73RZssmU2pmNW+zZkq2MJYtCaQcmHDhytBjjSord0TPAFXHUoxYm6Xgu4xpLY/RqprMa3SfkLFEYhCafi092C40K3pA2cxDqaaovkRoh17ZDOAkr8RP/pCPS2uuJHEQtTNctLbQ5J7wZnzZ7aH2XJauJg+XQgYHqrepsfvraFq1PJw9y05shKJkR6HqpJKOaosoqhw861T4XvwcUGa6whmICoCIXHkhxsxiyCWe2z9Dgke+MnnKsTdrRLRHTLtdu2h61m1NPfY4kcfLUwgdBqhBCWRuzXHxEaSAOqf0rAIFq2d0QpV1J3yB0L/UN482vbrhhf4WuEZlx/7UXuK7RsjNyTjVT0MZgPSRyGcM6lMWDwCawy/zikCNga1b3fA==; 5:TvLFalIrzer1NZ5QQppEu84Txi060XuQj1GOIDzp+YvWfTljIDZ+5bvPDPnktbutn9lYQAuGwg0UTtrDvpnKpH3VTACpSlgajOwUOFrcXRoA1wLAtnj2xS626MvyiiHxgJ4QEf4AH7pL4UUHFZNSEkIAFdJkpZP6HvOwQUTJOns=; 7:wIGDGa6Ev1bUzwZVlnPtnMLGUXG1y6cpJw1sJrrf/DzRNQ907wJphR/Dito4lghVpTuVkmETD7Upp7l1kXjV8lXYV6tNOHMaoPa5gWiWCujlvgLbb3gpRF/VWoS1QMwnjPVTpGz7MJH4+ub0rAG7hg==
x-ms-office365-filtering-correlation-id: f2946aa9-736d-4204-09bc-08d6513badeb
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7193020); SRVR:VI1PR07MB4141;
x-ms-traffictypediagnostic: VI1PR07MB4141:
x-microsoft-antispam-prvs: <VI1PR07MB414139A7B85F56D56798D45FA0D40@VI1PR07MB4141.eurprd07.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231442)(944501410)(52105112)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB4141; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4141;
x-forefront-prvs: 086597191B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(396003)(376002)(346002)(136003)(13464003)(199004)(189003)(486006)(305945005)(66066001)(256004)(14444005)(99286004)(14454004)(86152003)(7736002)(2900100001)(446003)(52116002)(25786009)(71190400001)(5660300001)(86362001)(97736004)(6306002)(476003)(6246003)(478600001)(68736007)(966005)(76176011)(102836004)(6506007)(386003)(316002)(105586002)(1556002)(2501003)(229853002)(3846002)(84392002)(33896004)(8676002)(53936002)(44736005)(71200400001)(114624004)(106356001)(2906002)(81166006)(6486002)(14496001)(81156014)(8936002)(26005)(6436002)(110136005)(6512007)(9686003)(186003)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4141; H:VI1PR07MB5022.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: QgJwysTyZxego/EFr6RIcQm//3jP8NL4GPJKVXhnmPONYTC2q9vOTcACdyBcXTCx8ktxwhfLRxFoY+UsieG80dVxz+ZQTp+AaB5NUj3NJaROJ5P/m9w0qPKhgxR/8Ei5ATWJws7Amzj0WCnojzvY3ytncYwrOBuX311LAZK0wJosBDtGeVxMl2Z52//k7Jy0Ux+DuLaqAGVR2bTi02MNJhVBFIsdX3HZ5Wo83vDhgyYiWx5sNOgoet2BuofdymlD9RNDcd0KlfDM+qY4uBtbXl29dQy9LxHTgo3Ez8JLAhdjepEkoqGi7NYsRH9RWlYMiNi2IovQoKaEHNIS33SaWlGMcicDiXmXOzhF69uy6bE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <259A0CF7F6221148AB4E59830CE79953@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f2946aa9-736d-4204-09bc-08d6513badeb
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2018 12:03:28.4187 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4141
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/70yTnt3ukYAu7HZnfHEq2ZsWqjo>
Subject: Re: [netmod] Address Family versus Address Family
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: Fri, 23 Nov 2018 12:03:46 -0000

----- Original Message -----
From: "Ladislav Lhotka" <lhotka@nic.cz>
Sent: Wednesday, November 21, 2018 12:13 PM

> tom petch <ietfc@btconnect.com> writes:
>
> > I have always thought of Address Family as something that BGP
created
> > and that others have used.  In fact, I find that there is an IANA
> > registry of Address Families which RFC8294 has turned into a YANG
> > module, but one using enumeration and not identity, which would seem
to
> > limit its utility.
>
> In draft-lhotka-dnsop-iana-class-type-yang-00 we also use enumerations
> representing DNS classes and resource records types. However, in
> addition to the enumeration type that reflects the corresponding IANA
> registries, we also added a union type that allows for using either
the
> mnemonic name or assigned number:
>
> typedef rr-type {
>   type union {
>     type uint16;
>     type rr-type-name;
>   }
> }
>
> (and similarly for DNS classes). The numeric value corresponding to
each
> mnemonic name is given by the "value" statement inside each enum.
>
> Actually, this approach was suggested by RFC 3597 that introduced the
> general possibility of representing DNS classes and RR types
> numerically. For example, RR type "AAAA" can be equivalently
represented
> as "TYPE28".
>
> Perhaps this approach could be used for address families as well. In
> fact, the use of identities also has its share of problems.

Lada

As you say, both enumeration and identity have their issues and there is
just such a definition taking place now.

The softwires WG are creating an IANA-maintained YANG module for the
existing tunnel type IANA registry, such that when a new tunnel type is
registered, then entries will be added to the existing tunnel type MIB
and to the (new) YANG module.

The YANG module is purely identity, based on ift:tunnel.

Should they be being advised to take a more sophisticated approach?

Tom Petch


> Lada
>
> >
> > Indeed, while the lsr WG uses that module, I2RS does not with
> >  draft-ietf-i2rs-rib-data-model
> > defining
> >    identity address-family {description  "Base identity from which
all
> > RIB      address families are derived.";  }
> >
> > identity - good; RYO definition - um.
> >
> > BGP also goes its own way with
> >   identity AFI_SAFI_TYPE { description
> >          "Base identity type for AFI,SAFI tuples for BGP-4";
> >        reference "RFC4760 - multi-protocol extensions for BGP-4";  }
> >
> > And then there is RFC8349 with
> >   identity address-family {
> >     description  "Base identity from which identities describing
address
> >           families are derived.";      }
> > and which defines ipv4 and ipv6, and which ties the concept firmly
to a
> > RIB in a 1:1 correspondence.
> >
> > When I raised this on the rtgwg list, the response was that the
concept
> > of an address family is particular to a protocol, so there is no
reason
> > for ospf and BGP to share anything, which is how it seems.
> >
> > So, is there any reason for anyone to use the definition in RFC8349?
or
> > the IANA module?
> >
> > Tom Petch
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67