----- Original Message ----- From: "Robert Raszuk" <[email protected]> Sent: Thursday, November 15, 2018 2:31 PM
> 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). 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 > 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 amily."; } > > > > 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
