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

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Tue, 14 Sep 2004 12:49:39 -0400

Hi! I will appreciate if somebody can help me the following questions:

	Q1:The description associated with "ipv4InterfaceIfIndex" implies
	that it is same as the IF-MIB table's  ifIndex of the  _lower
	layer_" interface on which IPv4 is being configured. Is this 
	interpretation correct?

	Q2:A row in the "ipv4InterfaceTable" represents the IPv4 attributes
	associated with a existing layer2/lower_layer interface. Is this 
	interpretation correct?

	    Q2.1 [If Q2 assumption is correct] All the lower layer
interfaces
	            that are capable of IPv4 will show up in the
"ipv4InterfaceTable"
		without user intervention. Is this assumption correct ?

	    Q.2.2 [If Q2 assumption is correct] An entry in the
"ipv4InterfaceTable"
		 _does not_ represent an IPv4 interface, rather a IPv4
capable interface
	 	 is this assumption correct?

	Q3. [If Q1 & Q2 are correct] Why not represent each entry in the 
	"ipv4InterfaceTable" as an IPv4 Interface (with its own index
-shared with MIB-II
	or from its own space), where user explicitly decides to create an
IPv4 
	interface on a specific lower layer interface?

Thanks,
sanjay

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

---

From: "Naidu, Venkata" <[email-masked]>
Date: Wed, 15 Sep 2004 10:07:11 -0400

Hi Sanjay,

-> 	Q1:The description associated with 
-> "ipv4InterfaceIfIndex" implies
-> 	that it is same as the IF-MIB table's  ifIndex of the  _lower
-> 	layer_" interface on which IPv4 is being configured. Is this 
-> 	interpretation correct?

  Correct.

-> 	Q2:A row in the "ipv4InterfaceTable" represents the 
-> IPv4 attributes
-> 	associated with a existing layer2/lower_layer 
-> interface. Is this 
-> 	interpretation correct?

  Correct.

-> 	    Q2.1 [If Q2 assumption is correct] All the lower layer
-> interfaces
-> 	            that are capable of IPv4 will show up in the
-> "ipv4InterfaceTable"
-> 		without user intervention. Is this assumption correct ?

  Correct.

-> 	    Q.2.2 [If Q2 assumption is correct] An entry in the
-> "ipv4InterfaceTable"
-> 		 _does not_ represent an IPv4 interface, rather a IPv4
-> capable interface
-> 	 	 is this assumption correct?
 
  Correct.

-> 	Q3. [If Q1 & Q2 are correct] Why not represent each 
-> entry in the 
-> 	"ipv4InterfaceTable" as an IPv4 Interface (with its own index
-> -shared with MIB-II
-> 	or from its own space), where user explicitly decides 
-> to create an
-> IPv4 
-> 	interface on a specific lower layer interface?

  I am not sure what that separate index for IPv4 interface 
  Table achieves. If IPv4 is enabled on that interface (whether
  explicitly or implicitly), then ipv4InterfaceEnableStatus is set, 
  otherwise reset.

  I would look at ipv4InterfaceTable differently. There is no 
  concept of an 'IP interface', any where in the MIB literature 
  before. An interface, by default, represents a layer 1 and 
  layer 2 information. If IPv4 or IPv6 (layer 3) is configured 
  on an interface, then IP specific information is augmented 
  to the ifTable. All that the new draft does is, differentiation
  of IPv4 and IPv6 specific information on an interface.

  Note also that, there can be many IPv4 and/or IPv6 addresses
  configured on an interface (i.e., for any MIB-II ifindex), so,
  ipAddressTable will have multiple entries for a single MIB-II
  ifindex (which is always the case for IPv6). But, there will
  be only one entry for ipv4InterfaceTable and ipv6InterfaceTable
  for every MIB-II ifindex.

  Hope this helps.

Venkata.

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 15 Sep 2004 10:15:43 -0700 (PDT)

In a message dated 14 Sept 2004 12:49:39 -0400 Sanjaya Choudhury wrote:
> Hi! I will appreciate if somebody can help me [with] the following
> questions:
> 
 
If you mean "lower layer" in the sense used in the ifStackTable then
the answer is no.  ipv4InterfaceIfIndex (or ipv6InterfaceIfIndex) is
supposed to point to whatever layer delivers packets to the IPv4 (or
IPv6) protocol machine.  Typically this would be a layer at the top
of the ifStackTable, although that will in fact be a layer 2
interface that resides below the IP layer.
 
To make this clear, let's consider the case of a 10GBASE-W Ethernet
interface.  This interface will use the WAN Interface Sublayer, and
according to RFC 3637, the layering model embodied in the ifStackTable
(and ifInvStackTable) will look like this:
 
          _____________________________   _
         |    LLC Layer                |  |
         +-----------------------------+  |
         |    MAC Layer                |  |
         +-----------------------------+  > 1 ifEntry
         |    Reconciliation Sublayer  |  |   ifType: ethernetCsmacd(6)
         +-----------------------------+  |
         |    Physical Coding Sublayer |  |
         +-----------------------------+  +
         |    Path Layer               |  > 1 ifEntry
         +-----------------------------+  +   ifType: sonetPath(50)
         |    Line Layer               |  |
         +-----------------------------+  |
         |    Section Layer            |  > 1 ifEntry
         +-----------------------------+  |   ifType: sonet(39)
         |    Physical Medium Layer    |  |
          -----------------------------   -
 
It is possible, via the MAU-MIB (RFC 3636), to dynamically switch a MAU
between 10GBASE-W and 10GBASE-X operation, if the underlying MAU hardware
supports that capability.  When that switch is made, the lower layers in
the above diagram are destroyed, or at least disconnected from the upper
layer.  In that case the ethernetCsmacd(6) - which is the sublayer that
delivers IP packets -- is all that remains.  From this example I think
it is clear why the only logical place for ipv4InterfaceIfIndex (or
ipv6InterfaceIfIndex) to point is the ethernetCsmacd(6), and not one of
the lower sublayers.
 
If you consider cases that involve multiplexing or inverse multiplexing you
will come to the same conclusion.
 
It _is_ true that ipv4InterfaceIfIndex (or ipv6InterfaceIfIndex) will point
to a layer 2 interface that is "below" the IP layer.  However, the IP layer
(if I understand the designers' intent) is _not_ represented as a separate
layer in the ifStackTable.
 
>       associated with a existing layer2/lower_layer interface. Is this 
 
Yes, subject to the above.

>           Q2.1 [If Q2 assumption is correct] All the lower layer interfaces
>           that are capable of IPv4 will show up in the "ipv4InterfaceTable"
 
>           "ipv4InterfaceTable" _does not_ represent an IPv4 interface, rather
>           a[n] IPv4 capable interface [...] is this assumption correct?
 
This has been my understanding.  Perhaps the IP MIB design team members can
confirm.
 
>       -shared with MIB-II IPv4 or from its own space), where user explicitly
>       decides to create an interface on a specific lower layer interface?
 
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 invented, there
was no ifSTackTable, and there were no per-interface IP statistics.  The
ifStackTable came later, when it because clear that it was needed to represent
things like Frame Relay and X.25 virtual circuits.  Per-interface statistics
postdate that.
 
It would be possible to do the type of manipulations you want, but an auxiliary
MIB module would be needed to do it.  For an example of how that might be done
see RFC 3201.
 
Mike Heard

---

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Fri, 17 Sep 2004 15:36:18 -0400

> -----Original Message-----
> From: C. M. Heard [mailto:[email-masked]]
> 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....>
> 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