dotted-quad is very much suitable to represent the router ID for various protocols including LDP. This maintains the backward compatibility and is of uint32 type.
Cheers, Rajiv > On Mar 2, 2016, at 5:42 AM, Benoit Claise (bclaise) <bcla...@cisco.com> wrote: > >> On 2/26/2016 1:13 PM, Acee Lindem (acee) wrote: >> Hi Benoit, Lada, >> >> On 2/26/16, 3:32 AM, "netmod on behalf of Benoit Claise (bclaise)" >> <netmod-boun...@ietf.org on behalf of bcla...@cisco.com> wrote: >> >>> Hi Lada, >>> >>>> 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. >>> From what I understand below, this is not an acceptable solution. >>> I'm sure the routing experts will confirm this. >> At least for the OSPF Router ID (RFC 2328) and the BGP Identifier (RFC >> 4271), the dotted-quad type matches the semantics of the protocols. The >> value is not necessarily a routable address and solely a unique 32-bit >> identifier within the protocol routing domain that is commonly expressed >> in dotted quad format. What is the problem with using this YANG type? > uint32 sure, but what is the conclusion regarding dotted-quad? > On one side, I hear: dotted-quad is suitable because it's uint32 and does NOT > have the semantics of an IPv4 address. > On the other side, I hear: we should not even display the identifier as an > IPv4 address. > > The routing experts should tell us if the dotted-quad type is appropriate. > > Regards, Benoit >> >> Thanks, >> Acee >> >>> Regards, Benoit >>>> Lada >>>> >>>>> On 25 Feb 2016, at 13:41, Benoit Claise <bcla...@cisco.com> 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 >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
