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? 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
