Re: [netmod] Address Family versus Address Family

Ladislav Lhotka <lhotka@nic.cz> Fri, 23 November 2018 14:07 UTC

Return-Path: <lhotka@nic.cz>
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 70793130E00 for <netmod@ietfa.amsl.com>; Fri, 23 Nov 2018 06:07:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 t8ZsuSPzDsmn for <netmod@ietfa.amsl.com>; Fri, 23 Nov 2018 06:07:29 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 73A8F129AB8 for <netmod@ietf.org>; Fri, 23 Nov 2018 06:07:28 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 3F241642DE; Fri, 23 Nov 2018 15:07:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1542982046; bh=Ek6S5L1WOoYjZILSF0X6FCK/w9gvHkoLW4ycCdsHiTY=; h=From:To:Date; b=sU6K3FHtLu5vEchRvMGckOTm+wxYGDLmeUar5rqzL5l5OmUnhA/NbHOfx4CBxisC4 /9xqLXhFvnKiF0/3Ptp7SWHRFxegBV/iDzlvXUO+Rbx2D02H3jvxCvNTS2nbqUTS1d vOPuwG3w5ziCl2SveZtzsmWxzET1ZzFkK+sxz9AE=
Message-ID: <a9159e6eb54b2172a0bcde6316aab92ce71ae2de.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: tom petch <ietfc@btconnect.com>, "netmod@ietf.org" <netmod@ietf.org>
Date: Fri, 23 Nov 2018 15:07:26 +0100
In-Reply-To: <019f01d48324$44356bc0$4001a8c0@gateway.2wire.net>
References: <033101d4818e$08689dc0$4001a8c0@gateway.2wire.net> <87wop6sk6k.fsf@nic.cz> <019f01d48324$44356bc0$4001a8c0@gateway.2wire.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/3qnGutHLfL-YP47aGcAlSPvEm64>
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 14:07:32 -0000

On Fri, 2018-11-23 at 12:03 +0000, tom petch wrote:
> ----- 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?

I am not sure that the approach with enumeration + union types can be classified
as more sophisticated. It is true though that it helps in the two main cases
where the enumeration by itself may be limiting:

- the NETCONF/RESTCONF server uses an old revision of the registry-based YANG
module but the device already supports a new revision of the registry

- experimental entries that are not in the registry

In both cases the missing type can be referred to using a number.

I would say that a module that is designed as a 1:1 mapping of an IANA registry
could generally use this approach.

Identities would be clearly better if they are defined in a truly distributed
manner. In your case, a YANG module that defines configuration and state data
for a particular tunnel type would also define the identity for that type. The
advantage of this approach is that a "type" parameter is restricted to only
those values that the server really implements.

Lada

> 
> 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
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67