Re: [netmod] Address Family versus Address Family
On Fri, 2018-11-23 at 12:03 +, tom petch wrote: > - Original Message - > From: "Ladislav Lhotka" > Sent: Wednesday, November 21, 2018 12:13 PM > > > tom petch 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 "" 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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Address Family versus Address Family
- Original Message - From: "Ladislav Lhotka" Sent: Wednesday, November 21, 2018 12:13 PM > tom petch 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 "" 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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Address Family versus Address Family
tom petch 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 "" 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 > > 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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod