RE: Question on draft-ietf-ipv6-rfc2011-update-10.txt

[[e-mail]]

As the editor it was not my intention that the ipv4 and ipv6 interface
tables
would be fully populated with all interfaces only those on which the ipv4 or
ipv6 protocols had been administratevly attached.  This may turn out to be
all
capable interfaces in some systems.

**

As to the difference you mention at the end of your message.  If I
understood
correctly to which statement you refer it discusses the difference between
the
interface tables from previous IPv6 mib and this mib.  In the previous mib
the ipv6ifTable attempted to replace (at least for IPv6) the ifTable.  In
the current
mib the interface tables are additional information to the ifTable.

**

If I were writing the code to handle the if and ip mibs I'd consider simply
adding
some new fields to the if structure to include the IP information.
Obviously this
may not be possible in some situations and then other implementation styles
would
need to be used.

regards,
Shawn A. Routhier

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Choudhury, Sanjaya
> Sent: Friday, September 17, 2004 12:36 PM
> To: IPv6
> Subject: RE: Question on draft-ietf-ipv6-rfc2011-update-10.txt
> 
> 
> > -----Original Message-----
> > From: C. M. Heard [mailto:[e-mail]]
> > 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
> [e-mail]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------