Hi Benoit, this was discussed a while ago in this thread:
https://mailarchive.ietf.org/arch/msg/netmod/TehrMAboX-cMmmX537rs81DNl3I tl;dr: The WG decision then was to introduce a new type in ietf-inet-types, namely "dotted-quad", that explicitly does NOT have the semantics of an IPv4 address - it is an uint32 number that's expressed in the dotted quad format, which is what most router platforms accept as routerID via CLI. Lada > On 25 Feb 2016, at 13:41, Benoit Claise <[email protected]> wrote: > > Dear all, > > Sorry for the delay (mix of vacation and business travel). > > Let me try to summarize the situation as I see it: > - From the routing RFCs, BGP Identifier, OSPF router ID, TE identifier, and > LSR identifiers are all an unsigned integers. > - We need consistency for the router ID and identifier in YANG leaf/typedef > - The OSPF MIB module has defined > RouterID ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "A OSPF Router Identifier. > Note that the Router ID, in OSPF, has the same format > as an IP address, but identifies the router independent > of its IP address." > SYNTAX IpAddress > > > ospfRouterId OBJECT-TYPE > SYNTAX RouterID > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A 32-bit integer uniquely identifying the > router in the Autonomous System. > By convention, to ensure uniqueness, this > should default to the value of one of the > router's IP interface addresses. > > As Adrian mentioned: it is NOT an IP address but the MIB module uses the > notational formatting of n IP address for display purposes. > - An IPv4 address as OSPF router ID doesn't make sense in an IPv6 environment > > Based on this, I believe that: > - We must not associate an IP address semantic with the router ID > - Based on Brian's feedback (which I agree with) "As long as the YANG module > does not specify a format that makes the routerID display like an IPv4 > address", it was probably a mistake to have defined RouterID as IpAdress in > OSPF MIB module. > - Interestingly, https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-20 > contains: > > grouping router-id { > description > "This grouping provides router ID."; > leaf router-id { > type yang:dotted-quad; > description > "A 32-bit number in the form of a dotted quad that is used by > some routing protocols identifying a router."; > reference > " > RFC 2328 > : OSPF Version 2."; > } > } > > This should be an uint32 number. > - An union-based solution is a bad compromise > From draft-raza-mpls-ldp-mldp-yang-02 > leaf lsr-id { > type union { > type yang:dotted-quad; > type uint32; > } > description "LSR ID."; > > > > Since the question was asked: as AD, I would support uint32 everywhere. > > Now, practically, how to move forward? > - Either all drafts reference draft-ietf-netmod-routing-cfg-20 (with the > uint32 modification), > - Or you create a "Common Routing YANG Data Types", similarly to RFC 6991 > including the router IDs. I see already many typedef in > draft-raza-mpls-ldp-mldp-yang-02 > - Or you define you own types in your own draft > > But, if we have agreement on the uint32, let's document this now > somewhere/somehow, and let's not revisit this on regular basis (yes, I see it > coming...) > A few lines of explanation in the draft would already help for example, in an > operational section, explaining to people the mapping of the MIB OSPF > RouterID to the YANG object > > Regards, Benoit >> Hi Adrian, >> >> On 2/16/16 7:53 AM, Adrian Farrel wrote: >> >>> Hi Brian, >>> >>> I said I wasn't going to participate in this discussion :-) >>> >> Nice try. ;) >> >> >>>>> I should not respond to questions that I don't fully understand, but: >>>>> >>>>> the BGP Identifier is an unsigned integer >>>>> the OSPF router ID is an unsigned integer >>>>> >>>> I assume the above is based on the YANG definition of OSPF routerID. RFC >>>> 4750 says the routerID is an IPv4 address. Is that an issue? >>>> >>> To quote from 4750... >>> >>> RouterID ::= TEXTUAL-CONVENTION >>> STATUS current >>> DESCRIPTION >>> "A OSPF Router Identifier. >>> Note that the Router ID, in OSPF, has the same format >>> as an IP address, but identifies the router independent >>> of its IP address." >>> SYNTAX IpAddress >>> >>> So it explicitly says it is NOT an IP address but the MIB module uses the >>> notational formatting of n IP address for display purposes. >>> >>> I think this is done because the router ID is often chosen to be an IP >>> address of the router, and because it is easier for humans to deal with >>> a.b.c.d where each element is a 3-digit number less than 256, than it is to >>> manage a single number in the range 0 to 2^32 -1. >>> >>> >> The above is the textual convention, whereas the following is the actual >> OSPF routerID... >> >> ospfRouterId OBJECT-TYPE >> SYNTAX RouterID >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "A 32-bit integer uniquely identifying the >> router in the Autonomous System. >> By convention, to ensure uniqueness, this >> should default to the value of one of the >> router's IP interface addresses. >> >> So the MIB actually says the default is to use an IPv4 address... >> >> All that being said, my point was further along where I said: >> >> >>>> I am not concerned with what the operator will choose as his/her >>>> routerID value. I am concerned with what format options will be >>>> associated with the routerID in the yang module. As long as the format >>>> options does not allow display in dotted decimal notation, I am fine. >>>> >> As long as the YANG module does not specify a format that makes the >> routerID display like an IPv4 address, I am fine. >> >> Brian >> >> >> > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
