Subject: Address families - who owns them?

From: tom petch <[email-masked]>
Date: Thu, 15 Nov 2018 13:02:38 +0000

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 15 Nov 2018 15:31:26 +0100

Hi Tom,

I think no one "owns" address families across protocols.

Those are per protocol specific entities and essentially even between
protocols they have not much in common (except name which is likely a bit
of trigger for confusion here).

Example:

Take OSPFv3 AFs (on octet):

+-------------+----------------------+--------------------+
            | Value/Range | Designation          | Assignment Policy  |
            +-------------+----------------------+--------------------+
            | 0           | Base IPv6 Unicast AF | Already assigned   |
            |             |                      |                    |
            | 1-31        | IPv6 Unicast AFs     | Already assigned   |
            |             | dependent on local   |                    |
            |             | policy               |                    |
            |             |                      |                    |
            | 32          | Base IPv6 Multicast  | Already assigned   |
            |             |                      |                    |
            | 33-63       | IPv6 Multicast AFs   | Already assigned   |
            |             | dependent on local   |                    |
            |             | policy               |                    |
            |             |                      |                    |
            | 64          | Base IPv4 Unicast AF | Already assigned   |
            |             |                      |                    |
            | 65-95       | IPv4 Unicast AFs     | Already assigned   |
            |             | dependent on local   |                    |
            |             | policy               |                    |
            |             |                      |                    |
            | 96          | Base IPv4 Multicast  | Already assigned   |
            |             |                      |                    |
            | 97-127      | IPv4 Multicast AFs   | Already assigned   |
            |             | dependent on local   |                    |
            |             | policy               |                    |
            |             |                      |                    |
            | 128-255     | Unassigned           | Standards Action   |
            +-------------+----------------------+--------------------+

then take BGP AFs:  It reuses general notion of IETF AFs which is two
octets.

Number Description Reference Registration Date
0 Reserved
1 IP (IP version 4)
2 IP6 (IP version 6)
3 NSAP
4 HDLC (8-bit multidrop)
5 BBN 1822
6 802 (includes all 802 media plus Ethernet "canonical format")
7 E.163
8 E.164 (SMDS, Frame Relay, ATM)
9 F.69 (Telex)
10 X.121 (X.25, Frame Relay)
11 IPX
12 Appletalk
13 Decnet IV
14 Banyan Vines
15 E.164 with NSAP format subaddress [ATM Forum UNI 3.1. October
1995.][Andy_Malis]
16 DNS (Domain Name System)
17 Distinguished Name [Charles_Lynn]
18 AS Number [Charles_Lynn]
19 XTP over IP version 4 [Mike_Saul]
20 XTP over IP version 6 [Mike_Saul]
21 XTP native mode XTP [Mike_Saul]
22 Fibre Channel World-Wide Port Name [Mark_Bakke]
23 Fibre Channel World-Wide Node Name [Mark_Bakke]
24 GWID [Subra_Hegde]
25 AFI for L2VPN information [RFC4761][RFC6074]
26 MPLS-TP Section Endpoint Identifier [RFC7212]
27 MPLS-TP LSP Endpoint Identifier [RFC7212]
28 MPLS-TP Pseudowire Endpoint Identifier [RFC7212]
29 MT IP: Multi-Topology IP version 4 [RFC7307]
30 MT IPv6: Multi-Topology IP version 6 [RFC7307]
31-16383 Unassigned
16384 EIGRP Common Service Family [Donnie_Savage] 2008-05-13
16385 EIGRP IPv4 Service Family [Donnie_Savage] 2008-05-13
16386 EIGRP IPv6 Service Family [Donnie_Savage] 2008-05-13
16387 LISP Canonical Address Format (LCAF) [David_Meyer] 2009-11-12
16388 BGP-LS [RFC7752] 2013-03-20
16389 48-bit MAC [RFC7042] 2013-05-06
16390 64-bit MAC [RFC7042] 2013-05-06
16391 OUI [RFC7961] 2013-09-25
16392 MAC/24 [RFC7961] 2013-09-25
16393 MAC/40 [RFC7961] 2013-09-25
16394 IPv6/64 [RFC7961] 2013-09-25
16395 RBridge Port ID [RFC7961] 2013-09-25
16396 TRILL Nickname [RFC7455] 2014-09-02
16397-65534 Unassigned
65535 Reserved

BGP during MP-BGP extension came with defintion of SAFIs and I guess one
can claim that BGP "owns" SAFI defintions (well for now :). But I guess you
are pointing out the lack of consistency for AFI definitions here

To me it looks like the definition of ticket format for say IPv4 human.
Across plane rides, train or busses you still see a ticket for the same
entity, but there is nothing in common across all of them :).

Cheers,
R.

On Thu, Nov 15, 2018 at 2:03 PM tom petch <[email-masked]> wrote:

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

---

From: tom petch <[email-masked]>
Date: Thu, 15 Nov 2018 16:26:18 +0000

----- Original Message -----
From: "Robert Raszuk" <[email-masked]>
Sent: Thursday, November 15, 2018 2:31 PM

> of trigger for confusion here).

Robert,

Yeah, that is my impression.

But,

1 - we have an IANA-maintained register of them, which suggests
something that is agreed IETF-wide (or at least part thereof)

2-  RFC8349 "A YANG Data Model for Routing Management", which is
intended to be the basis for routing OAM, with YANG, says
"   o  The data model should be suitable for the common address
families"
as if there was a common understanding of what the term means.

So, triggers for confusing me.

Tom Petch

>             |             |                      |
|
>             |             | policy               |
|
>             |             |                      |
|
>             |             |                      |
|
>             |             | policy               |
|
>             |             |                      |
|
>             |             |                      |
|
>             |             | policy               |
|
>             |             |                      |
|
>             |             |                      |
|
>             |             | policy               |
|
>             |             |                      |
|
> >      base "address-family"; description  "IPv4 RIB address
amily.";  }
> >        description "Base identity from which identities describing
LISP