Subject: Comment on draft-kompella-mpls-unnum-01.txt

From: Bora Akyol <[email-masked]>
Date: Wed, 20 Sep 2000 12:30:51 -0700

The definition of interface ID in this draft as 16 bits conflicts with
OSPF-TE draft which recommends using SNMPifindex at 3 bytes for this
purpose. ISIS-TE draft does not cover this case at all.

Can we reconcile to something that is consistent?

Bora

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 20 Sep 2000 12:43:07 -0700

Bora,

> purpose. 

The OSPF-TE draft needs to be fixed.

> ISIS-TE draft does not cover this case at all.

I think it does - from draft-ietf-isis-traffic-02.txt: 

5.3 Sub-TLV 8: IPv4 neighbor address

   This sub-TLV contains a single IPv4 address for a neighboring router
   on this link.  This sub-TLV can occur multiple times.

   If the interface being advertised for Traffic Engineering purposes is
   unnumbered, the first two octets of the IPv4 neighbor address sub-TLV
   are set to zero and the next two octets are set to the interface ID
   of the unnumbered interface. 

> Can we reconcile to something that is consistent?

I'll get in touch with the authors of OSPF-TE and ask them to
fix their document.

Yakov.

---

From: Bora Akyol <[email-masked]>
Date: Wed, 20 Sep 2000 13:49:37 -0700

Yakov

You are correct, I was working off of 01 version of the ISIS-TE draft. So
OSPF-TE draft gets fixed, then all three will be consistent.

Thanks

Bora

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 20 Sep 2000 13:50:44 -0700 (PDT)

An SNMP ifIndex will not fit inside 3 bytes.
 
Keith.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 20 Sep 2000 14:12:59 -0700

Keith,

> An SNMP ifIndex will not fit inside 3 bytes.

Taking this point of view, an SNMP ifIndex wouldn't fit in anything
less than 4 bytes. Yet, in OSPF with unnumbered links ifIndex is
carried in the same field as a plain IP address So, when this field
carries the value 33620225, is that an IP address (2.1.1.1) or an
ifIndex (33620225) ?

Yakov.

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 20 Sep 2000 22:52:13 -0700 (PDT)

Yakov,

I don't know about OSPF, the protocol, but the OSPF MIB (RFC 1850)
uses different MIB objects to hold an IP address and an ifIndex value.
For example,

    ospfIfIpAddress OBJECT-TYPE
        SYNTAX   IpAddress
        MAX-ACCESS   read-only
        STATUS   current
        DESCRIPTION
           "The IP address of this OSPF interface."
       ::= { ospfIfEntry 1 }

    ospfAddressLessIf OBJECT-TYPE
        SYNTAX   Integer32
        MAX-ACCESS   read-only
        STATUS   current
        DESCRIPTION
           "For the purpose of easing  the  instancing  of
           addressed   and  addressless  interfaces;  This
           variable takes the value 0 on  interfaces  with
           IP  Addresses,  and  the corresponding value of
           ifIndex for interfaces having no IP Address."
       ::= { ospfIfEntry 2 }

ifIndex was originally defined (in RFC 1066) as INTEGER, which was
later refined (in RFC 1563) as:

   InterfaceIndex ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS       current
       DESCRIPTION
               "A unique value, greater than zero, for each interface
               or interface sub-layer in the managed system.  It is
               recommended that values are assigned contiguously
               starting from 1.  The value for each interface sub-
               layer must remain constant at least from one re-
               initialization of the entity's network management
               system to the next re-initialization."
       SYNTAX       Integer32

and Integer32 is defined as:

   Integer32 ::=
           INTEGER (-2147483648..2147483647)

So, it's unlikely, but increasingly possible, that ifIndex values can
be as large as 2147483647.

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 21 Sep 2000 08:02:26 -0700 (PDT)

FYI.  In response to my message below, I received a private email
saying:

     It is more likely than you think. I once worked on a device which
     did not reuse ifIndexes across reboots until it had to. It
     basically kept a maxIfIndex var in nvram. It continued up until it
     hit 32bits worth of numbers, and only then would it roll-over to 1.

and I believe that's an unusual but compliant implementation.

Keith.