Re: [netmod] Address Family versus Address Family

[Ladislav Lhotka <[e-mail]>]

On Fri, 2018-11-23 at 12:03 +0000, tom petch wrote:
> ----- Original Message -----
> From: "Ladislav Lhotka" <[e-mail]>
> Sent: Wednesday, November 21, 2018 12:13 PM
> 
> > tom petch <[e-mail]> 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
> > > [e-mail]
> > > 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