Subject: Re: Interface ID in kompella-unnum-02

From: Kireeti Kompella <[email-masked]>
Date: Thu, 5 Oct 2000 12:33:10 -0700 (PDT)

Hi,

>	In draft-kompella-mpls-unnum-02.txt, the interface ID field is shown
> to be 16 bits.  Previous e-mails have suggested that the size be increased
> to 32 bits to match the SNMP ifIndex size.  Can this be increased?

16 bits should be enough to number all interfaces on a box.  If
it isn't, you have other much more serious problems (IS-IS and OSPF
cannot even carry the information (this is not even going into the
scaling issues)).  If you do get to the point where you have more
than a few thousand interfaces on a box, you probably really should
be considering bundling; this will reduce the number of interfaces
from the routing protocols point-of-view to as few as the number of
adjacent nodes.  Then number the bundles, not the actual interfaces.

> We could have ifIndex values that are larger than 16 bits.

We hereby resolve to remove all text that suggests using the SNMP
ifIndex for interface indices :-)  The only requirement for interface
indices is that indices generated by a node are unique, and that the
routing and signalling modules use the same number for an interface.
If your ifIndexes are larger than 16 bits, don't use them, generate
new indices.

Note that the requirements for SNMP indices are much stronger than
for interface indices: they need to remain stable, reusing them can
be an issue, etc., which is why ifIndexes tend to grow beyond 2^16.

Note too that the interface index cannot be made bigger than 2^24;
this is so that the distinction between IP addresses and interface
indices is clear.  Given that, and given the fact the SNMP ifIndexes
can be 32 bits, ifIndexes are ruled out as potential interface
indices.

Kireeti.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 05 Oct 2000 16:07:06 -0400

Hi,

>adjacent nodes.  Then number the bundles, not the actual interfaces.

         Not necessarily. As I and Keith M. pointed out, it is
perfectly valid for an implementation to keep track of the
last ifIndex used and continue up from there after each
reboot. So, even on the box you described above as being well
behaved, it is perfectly reasonable (and legal) to see
ifIndexes which exceed 16 bits.

>If your ifIndexes are larger than 16 bits, don't use them, generate

         This is really not a good idea from a management perspective,
especially since all of the MIBs I know of that manage any
type of interface (including all of the MPLS MIBs) rely on the
ifIndex as indexes for many tables. How does one find the interface if
it does not correspond to the ifIndex in the Interfaces MIB?

>can be 32 bits, ifIndexes are ruled out as potential interface

         Personally, this seems like a flaw in the design. The type
ifIndex has been around for quite a long time. I don't see how
the ifIndex in OSPF/ISIS was allowed to use a different size
while claiming that one could put use an ifIndex from the Interfaces
MIB.

         --tom

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 05 Oct 2000 13:40:56 -0700

Tom,
 
[clipped...]

>          Personally, this seems like a flaw in the design. 

Feel free to go to the OSPF WG, and convince them to change OSPF to
address what you perceived as "a flaw in the design". 

> The type ifIndex has been around for quite a long time.  I don't see
> how the ifIndex in OSPF/ISIS was allowed to use a different size while
> claiming that one could put use an ifIndex from the Interfaces MIB.

water under the bridge.

Yakov.

---

From: Alex Zinin <[email-masked]>
Date: Thu, 5 Oct 2000 16:36:23 -0700

Thomas,

> while claiming that one could put use an ifIndex from the Interfaces

I don't want confusion here, so let's clarify a bit.

ifIndex is 32-bit, so is the Link Data field in OSPF router-LSA.
So OSPF is fine, actually. You won't find "IfIndex" in ISIS
spec :)

But in fact we're not much concerned about legacy OSPF/ISIS,
we should be talking about TE extensions. And they also use 32 bits.
So, the size is fine again :)

Alex.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 06 Oct 2000 09:12:39 -0400

Alex,

>I don't want confusion here,

         Neither do I. *)

>So, the size is fine again :)

         Okay, perhaps I misunderstood the original
question. Thanks for the clarification.

         --Tom

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 17 Oct 2000 13:24:56 -0400

> > claiming that one could put use an ifIndex from the Interfaces MIB.

Yakov,

This may be a scalability or management limitation.  Our routers
already are designed to accommodate 560 slots (14 40 slot bays) and
will support 1120 slots in the future.  Each slot may have 16 ports or
may have switched or channelized interfaces.  [btw- yes we've tested
routers with more than 40 slots but not 14 loaded bays].

We currently number composite links (tm), which is our layer 2 bundles
with ifindex values over 2^16 so that we can avoid the number space
used for physical interfaces.  We will also number switched or
channelized virtual interfaces (sub-interfaces) in this upper number
space.

Its nice to be able to go from bay/slot/interface to physical
interface.  It is also nice not to have to add an additional more
dynamically allocated number space that is mapped to and from the
ifindex number space just because kompella-unnum-02 decided 16 bits
was plenty when it really wasn't.  Code can handle this easily but
from a management standpoint this is going to be a pain.

We can fit into the OSPF 24 bit limit but 16 is too tight.  It is not
necessary to make these numbers 16 bits.  Or at least I haven't seen
an argument other than "these are not SNMP or OSPF ifindexes".

Curtis

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 17 Oct 2000 14:11:02 -0700

Curtis,

[clipped...]

> an argument other than "these are not SNMP or OSPF ifindexes".

The next revision of the Internet Drafts on unnumbered interfaces,
on link bundling, and on TE extensions for ISIS and OSPF will support
32 bits for both Interface ID (in unnumbered and in TE extensions) 
and Component Interface ID (in link bundling).

Yakov.