> -----Original Message-----
> From: C. M. Heard [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 15, 2004 1:16 PM
> To: Choudhury, Sanjaya
> Cc: IPv6
> Subject: Re: Question on draft-ietf-ipv6-rfc2011-update-10.txt
<snip....>
> In other words, why not include IPv4 and IPv6 layers in the
> ifStackTable, and
> allow them to be dynamically manipulated.
>
> Partly, the reason is historical. When the MIB-II was first
<snip....>
It is true that historically, IPv4 and IPv6 layers has not been
included in the ifStackTable, now the question is should they be?
As we know, the "interface stacking" concept has been as very
flexible and useful tool to effectively manage system interfaces. I
can think of the following reasons for such a change:
[Note:Infact RFC2465 kind of introduced this concept for IPv6.]
1. Scalability Issue:
---------------------
With the introduction of the logical/virtual interfaces, a single
system can host thousands of "IP capable" interfaces. As per the
RFC2011-update, all of these show up in the ipv4InterfaceTable, even
if user never intends to configure IP over them!! A snmp-walk by a NMS
of this table can be very expensive and difficult to use.
By using a unique index in the ipv4InterfaceTable, user has explicit
control over the interface over which he can enable IP. This will make the
ip4InterfaceTable more scalable and usable (fewer entries).
2. System Resources Issue:
-------------------------
Depending on implementation, supporting thousands of "unused" entries
in the ipv4InterfaceTable can consume system resources.
3. User control
---------------
There may be cases, where IP can be configured at multiple lower layer
interfaces (IP on ppp-over-rfc1483-over-ATM vs IP over rfc1483-over-ATM).
User based on his deployment scenarios may choose one of these interfaces
to configure IP on.
[After all, the interface stacking concept has allowed NMS platforms (and
administrators) manage the interfaces below the IP layer efficiently for a
long time!]
4. Ability to Stack
------------------
By modeling the IP layer as "IP interfaces" stacked on top of some lower
layer interface allows stacking of IPv6 interfaces over IPv4 interfaces [
RFC2465]
In future, this model can be extended to allow other "higher layer
interfaces"
to be stacked on IP layer -primarily to let users/NMS manage the interfaces
uniformly.
5. Model
--------
Current MIB models the IP layer as "IP properties and address associated
with a layer2 interface". The proposed approach models it as "IP interface
with IP specific properties and addresses stacked on a lower layer" (as
defined in RFC2465 for IPv6 case).
Did I mis-interpret the draft-2011-update? It does have one statement that
states that there is a "difference" between the ipv6InterfaceTable and
ipv6IfTable, but I am not sure what it means!!
Thoughts?
Thanks,
sanjay
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
