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

Reply via email to