Who owns address families?

RFC8294 creates a YANG module for IANA to maintain which is tied into
the IANA registry of Address Families giving a long list of Address
Families as enumeration.  This RFC definition is used by
 draft-ietf-isis-yang-isis-cfg
 draft-ietf-ospf-yang
 draft-ietf-pim-yang
So far so good.

However, I think of AF as essentially BGP in origin and when I look at
draft-ietf-idr-bgp-model
I see
     identity AFI_SAFI_TYPE {
       description "Base identity type for AFI,SAFI tuples for BGP-4";

     identity IPV4_UNICAST {
       base AFI_SAFI_TYPE;
etc.
I note that this uses identity, as opposed to enumeration, which is the
preferred way of such things with YANG now and that it owes nothing to
the IANA maintained registry of Address Families.

This I-D has a common author with
draft-ietf-i2rs-rib-data-model
and again does not use the IANA definitions but instead

   identity address-family {description  "Base identity from which all
RIB
        address families are derived.";  }

   identity ipv4-address-family {
     base "address-family"; description  "IPv4 RIB address family.";  }

   identity ipv6-address-family
   { base "address-family"; description "IPv6 RIB address family."; }

   identity mpls-address-family {
     base "address-family"; description  "MPLS RIB address family."; }
...
a similar but different set of identities for address families.

draft-ietf-l2sm-l2vpn-service-model-10
is similar but different

  identity address-family {
    description "Identity for an address family.";   }

  identity ipv4 {
    base address-family;
    description "Identity for IPv4 address family.";   }

  identity ipv6 {     base address-family;
    description  "Identity for IPv6 address family.";   }

  identity vpn-topology {
    description       "Base identity for VPN topology.";   }
......

Or again
draft-ietf-lisp-yang-10

     identity lisp-address-family {
       description "Base identity from which identities describing LISP

address
          families are derived."; }

     identity no-address-afi {
       base lisp-address-family;  description "IANA Reserved.";  }

     identity ipv4-afi {
       base lisp-address-family; description "IANA IPv4 address
family.";      }

     identity ipv4-prefix-afi {
       base lisp-address-family;
       description   "IANA IPv4 address family prefix.";      }

     identity ipv6-afi {
       base lisp-address-family; description  "IANA IPv6 address
family.";      }
...........


Meanwhile, RFC8349 " A YANG Data Model for Routing Management" defines
     identity address-family {
       description   "Base identity from which identities describing
address
          families are derived."; }

So far so good again, but it only adds

     identity ipv4 { base address-family;
       description "This identity represents an IPv4 address
y.";      }

     identity ipv6 {  base address-family;
       description "This identity represents an IPv6 address
amily.";  }

and none of the other hundred or so.  The IANA Considerations of this
RFC makes no mention of Address Families.

This is of course all valid YANG and will coexist happily inside a
device but a user may not be so happy to have half a dozen or more
conflicting definitions of address family alongside an IANA registry
which is but little used.  Also, this is of course also a perfectly
valid way of working for the IETF, never do something once if you can do
six different ways, but I am not sure that it improves The Internet!

Tom Petch

_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to