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 protected]> wrote:
> 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
>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
