Subject: Re: [Bridge-mib] Question of link aggregation groups in Q-Bridge portList

From: "chungwei wu" <[email-masked]>
Date: Tue, 11 Dec 2001 10:44:42 -0800

Hi Michael,

Should the port number in portList be equal to the dot1dBasePort?

For example, if the 30th bit is set, how does EMS know which port is set?

Look like they need to be the same, otherwise, another mapping is required.

Thanks in advance.
Regards,
Chungwei

>From: Michael MacFaden <[email-masked]>
>To: chungwei wu <[email-masked]>
>CC: [email-masked]
>Subject: Re: [Bridge-mib] Question of link aggregation groups in Q-Bridge 
>portList
>Date: Mon, 10 Dec 2001 14:56:52 -0800
>
>On Mon, Dec 10, 2001 at 10:24:24AM -0800, chungwei wu wrote:
> >I am currently working on the Q-Bridge MIB and Link Aggregation Group 
>task,
> >and have a question about the portList port mapping in the Q-Bridge MIB. 
>I
> >hope you guys could share some of your valuable thoughts on this.
> >
> >Question: Should Q-Bridge portList accommodate both physical port and 
>Link
> >Aggregation Group?
>
>I believe it already does. A dot1dBasePortNumber from rfc1493 which
>is represented with the aggregate object "portList" in 2674 may be abstract 
>or
>physical. It may or may not be related to an ifIndex which also
>may or may not be physical.
>
> >I think the port in Q-Bridge should cover both physical port and logical
> >link aggregation groups. If a switch supports upto 96 physical ports and 
>32
> >LAGs, the lenght of portList would be 128 bits.
>
>Indeed. And it gets interesting when one actually takes two ports
>that are currently assigned a dot1dBasePortNum then are removed
>from the bridge and added to the LAG, thus creating a new dot1dBasePortNum.
>
>So the bit length of a PortList can be dynamic..
>note: dot1dBasePortTable can be sparse too.
>
>Here is our implementation's documentation:
>http://www.nmops.org/download/rs-snmp-mgmt.pdf page 63.
>
>It is an interesting with what to include in the
>dot1dBasePortTable. A device that supports many
>different technologies besides bridging may also lead to diffferences
>in what shows up across vendors or a given vendor's products
>in the dot1dBasePortTable. If seen that some devices include
>all ports that can possibly bridge, others include ports that bridging 
>packets,
>while others include ports that are bridging packets and running
>a control protocol such as stp...
>
>Regards,
>Mike MacFaden
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

_______________________________________________
Bridge-mib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bridge-mib

---

From: Michael MacFaden <[email-masked]>
Date: Tue, 11 Dec 2001 15:24:52 -0800

>Should the port number in portList be equal to the dot1dBasePort?

By definition.

RFC 2674, section 3.4.2, page 15:
   Each port is uniquely identified by a port number.  A port number has
   no mandatory relationship to an interface number, but in the simple
   case a port number will have the same value as the corresponding
   interface's interface number.  Port numbers are in the range
   (1..dot1dBaseNumPorts).

>Look like they need to be the same, otherwise, another mapping is required.

Precisely.  EMS will typically read dot1dBasePortTable to track
the set of "ports" that make up the 802 transparent bridge. 

dot1qVlanCurrentTable then maps dot1dBasePortNums to FDB which 
then is mapped to VID.

Next, zero or more instances of Spanning Tree Protocol may be employed. 
In such cases, the BRIDGE-MIB contains the first instance, and 
the Entity MIB may be used to track subsequent instances of STP. 

BTW, same goes for OSPF MIB module. ISIS MIB module however chose to fix their 
table indexing to natively support multiple instances.

The SNMPCONF working group draft:
http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-bcp-07.txt 
has some commentary/examples on the above... 

Regards,
Mike MacFaden