From andrew@extremenetworks.com Mon Jul 19 14:40:05 1999 Received: from sheltie.cisco.com (sheltie.cisco.com [171.69.219.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29239 for ; Mon, 19 Jul 1999 14:40:04 -0400 (EDT) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by sheltie.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id LAA06974 for ; Mon, 19 Jul 1999 11:08:15 -0700 (PDT) Received: from beasley.cisco.com (beasley.cisco.com [171.69.11.49]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id LAA14437 for ; Mon, 19 Jul 1999 11:08:37 -0700 (PDT) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by beasley.cisco.com (8.8.8/2.6/Cisco List Logging/CISCO.GATE.1.1) with ESMTP id LAA15243 for ; Mon, 19 Jul 1999 11:08:12 -0700 (PDT) Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id LAA01714 for ; Mon, 19 Jul 1999 11:13:44 -0700 (PDT) Received: (from smap@localhost) by proxy2.cisco.com (8.8.7/8.8.5) id LAA22807 for ; Mon, 19 Jul 1999 11:07:48 -0700 (PDT) Received: from sol.extremenetworks.com(216.52.8.2) by proxy2.cisco.com via smap (V2.0) id xma022737; Mon, 19 Jul 99 18:07:39 GMT X-SMAP-Received-From: outside Received: by ftp.extremenetworks.com with Internet Mail Service (5.5.2448.0) id <36G72Q6H>; Mon, 19 Jul 1999 11:06:01 -0700 Message-ID: From: Andrew Smith To: "'Mehul Dholakia'" Cc: p8021@hepnrc.hep.net, "'bridge mib'" Subject: RE: GARP Applicant controls Date: Mon, 19 Jul 1999 11:05:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Mehul, This is a question for the IETF's Bridge MIB working group, not for IEEE 802.1. You are correct in identifying the SNMP MIB objects that control the GARP applicants. Andrew **************************************************************** Andrew Smith tel: +1 (408) 579-2821 Extreme Networks fax: +1 (408) 579-3000 3585 Monroe St. http://www.extremenetworks.com Santa Clara CA 95051-1450 em: andrew@extremenetworks.com **************************************************************** > -----Original Message----- > From: Mehul Dholakia [mailto:md@mtghouse.com] > Sent: Friday, July 16, 1999 4:54 PM > To: p8021@hepnrc.hep.net > Subject: GARP Applicant controls > > > Hello all, > > I was just going through the .1p and .1q MIB definitions and > I dont see > anything for the GARP Applicant administrative control > (normal/no_protocol). > > I do see the following note: > > Bridge.ApplicantAdministrativeControl not provided per-attribute > (e.g. per-VLAN, per-Group). > Only > per-{device,port,application} > control is > provided in this MIB. > > Is the per-{device,port,application} control referred to in > the note, the > dot1qPortGvrpStatus and dot1dPortGmrpStatus objects ? > > Thanks, > Mehul > -- > Meetinghouse Data Communications > Email: md@mtghouse.com > Phone: (207) 439 7660 x12. > From steves@wrs.com Thu Jul 22 10:19:09 1999 Received: from rhine.cisco.com (rhine.cisco.com [171.69.43.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22579 for ; Thu, 22 Jul 1999 10:19:08 -0400 (EDT) Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by rhine.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id GAA09206 for ; Thu, 22 Jul 1999 06:47:10 -0700 (PDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id GAA07543 for ; Thu, 22 Jul 1999 06:56:01 -0700 (PDT) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id GAA13524 for ; Thu, 22 Jul 1999 06:47:09 -0700 (PDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id GAA07178 for ; Thu, 22 Jul 1999 06:47:33 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id GAA11123 for ; Thu, 22 Jul 1999 06:47:07 -0700 (PDT) Received: from unknown(204.181.204.2) by proxy3.cisco.com via smap (V2.0) id xma011109; Thu, 22 Jul 99 06:47:01 -0700 X-SMAP-Received-From: outside Received: from wrs.com (chewey.dallas.wrs.com [204.181.204.83]) by salween.dallas.wrs.com (8.9.3/8.9.3) with ESMTP id IAA11375 for ; Thu, 22 Jul 1999 08:38:32 -0500 (CDT) Message-ID: <37971FA4.17F7C476@wrs.com> Date: Thu, 22 Jul 1999 08:41:56 -0500 From: steve shadix X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: bridge-mib@external.cisco.com Subject: question about dot1qForwardAll/dot1qForwardUnregistered tables Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I am in the process of implementing support for the 802.1Q MIB and am having some confusion over the behavior associated with the dot1qForwardAllTable and dot1qForwardUnregisteredTable. I am trying to determine the actual effect these tables should have on the forwarding of multicast traffic. I have read and re-read the spec and the MIB but at this point do not feel confident that I have a full (or even half-full) understanding of these objects. Any insight or information would be greatly appreciated. My simplistic (probably overly simplistic) understanding of the operation is as follows (all objects are in same VLAN context): - If a packet is received for which a static address entry (dot1qStaticMulticastAddress) exist, it would be forwarded based on the port list defined by dot1qStaticMulticastEgressPorts with no regard for set of ports defined by the dot1qForwardAllPorts or dot1qForwardUnregisteredPorts objects. What about ports that had been added dynamically (i.e. ports that were not included in the dot1qMulticastForbiddenEgressPorts and had subsequently been added via GMRP) ? - If a packet is received for a dynamically registered multicast address it would be forwarded to all ports the address had been registered on as well as the set of ports included in the dot1qForwardAllPorts object. - If a packet is received for an address for which there is not a static entry or a dynamically registered entry it would be forwarded on the set of ports included in the dot1qForwardUnregisteredPorts object and (this is where I'm really confused...) the set of ports included in the dot1qForwardAllPorts object. For example, assume a switch with 8 ports, all ports in forwarding state and all the information below is for a single VLAN: dot1qForwardAllPorts port list contains ports 2 and 3 dot1qForwardUnregisteredPorts port list contains ports 4 and 5 The filtering database contains: Static multicast address 1 (MC1) with ths following egress port configuration: dot1qStaticMulticastEgressPorts : ports 6, 7 Dynamically registered multicast address (MC2) : registered on ports 7, 8 Scenario 1: A packet is received on port 1 with a destination address of MC1. Should it only be forwarded on ports 6 and 7 ? Scenario 2: A packet is received on port 1 with a destination address of MC2. Should it be forwarded on ports 2, 3, 7 and 8 ? Scenario 3: A packet is recieved on port 1 with an destination address for which there is no entry in the filtering database. Should this packet be forwarded on ports 2, 3, 4 and 5 ? Thanks for your assistance, Steve Shadix Wind River Systems Dallas, TX From andrew@extremenetworks.com Thu Jul 22 22:54:58 1999 Received: from quisp.cisco.com (quisp.cisco.com [171.69.95.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09943 for ; Thu, 22 Jul 1999 22:54:58 -0400 (EDT) Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by quisp.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id TAA08094 for ; Thu, 22 Jul 1999 19:13:49 -0700 (PDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id TAA09020 for ; Thu, 22 Jul 1999 19:22:41 -0700 (PDT) Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id TAA19407 for ; Thu, 22 Jul 1999 19:13:48 -0700 (PDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id TAA09016 for ; Thu, 22 Jul 1999 19:22:40 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id TAA09891 for ; Thu, 22 Jul 1999 19:13:47 -0700 (PDT) Received: from sol.extremenetworks.com(216.52.8.2) by proxy3.cisco.com via smap (V2.0) id xma009889; Fri, 23 Jul 99 02:13:42 GMT X-SMAP-Received-From: outside Received: by ftp.extremenetworks.com with Internet Mail Service (5.5.2448.0) id <36G728DK>; Thu, 22 Jul 1999 19:12:04 -0700 Message-ID: From: Andrew Smith To: "'steve shadix'" , bridge-mib@external.cisco.com Subject: RE: question about dot1qForwardAll/dot1qForwardUnregistered table s Date: Thu, 22 Jul 1999 19:11:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Steve, It's a complicated topic as you have noticed. I assume you've attempted to digest section 8.11 of IEEE 802.1Q - heavy going isn't it? Now take a pepto-bismol. See below. > -----Original Message----- > From: steve shadix [mailto:steves@wrs.com] > Sent: Thursday, July 22, 1999 6:42 AM > To: bridge-mib@external.cisco.com > Subject: question about > dot1qForwardAll/dot1qForwardUnregistered tables ... > My simplistic (probably overly simplistic) understanding of the > operation > is as follows (all objects are in same VLAN context): > - If a packet is received for which a static address entry > (dot1qStaticMulticastAddress) exist, it would be forwarded based > on > the port list defined by dot1qStaticMulticastEgressPorts with no > regard for set of ports defined by the dot1qForwardAllPorts or > dot1qForwardUnregisteredPorts objects. What about ports that had > been > added dynamically (i.e. ports that were not included in the > dot1qMulticastForbiddenEgressPorts and had subsequently > been added > > via GMRP) ? There are 3 states for a given static {MAC,VID,port} entry: Fixed, Forbidden and Dynamic. Table 8-7 says that your first example would be Forwarded if the port is in Fixed (i.e. in dot1qStaticMulticastEgressPorts) and it would be Filtered if the port is Forbidden (i.e. in dot1qMulticastForbiddenEgressPorts). If the port is in neither list, then it is more complex: if the port is in the dot1qForwardAllPorts list then the packet is Forwarded; if the port has been added dynamically by GMRP then it is Forwarded; if the port is in the dot1qForwardUnregisteredPorts list but has not been registered by GMRP then it is Forwarded; otherwise the packet is Filtered. [This is actually a slightly simplistic explanation since the actual value of dot1qForwardAllPorts is constrained by dot1qForwardAllStaticPorts and dot1qForwardAllForbiddenPorts. Similarly for dot1qForwardUnregisteredPorts. See table 8-6 for details on these]. Phew! > - If a packet is received for a dynamically registered multicast > address > it would be forwarded to all ports the address had been > registered > on as > well as the set of ports included in the dot1qForwardAllPorts > object. Correct. > - If a packet is received for an address for which there is not a > static > entry or a dynamically registered entry it would be forwarded on > the set > of ports included in the dot1qForwardUnregisteredPorts > object and > (this is where I'm really confused...) the set of ports included > in the > dot1qForwardAllPorts object. Correct I think (last column of table 8-7): it would be forwarded to any port in dot1qForwardUnregisteredPorts OR in dot1qForwardAllPorts. Hope that is clear (???). Tables 8-6 and 8-7 say it all: in 802.1 parlance it is all "clear but non-obvious". Andrew **************************************************************** Andrew Smith tel: +1 (408) 579-2821 Extreme Networks fax: +1 (408) 579-3000 3585 Monroe St. http://www.extremenetworks.com Santa Clara CA 95051-1450 em: andrew@extremenetworks.com **************************************************************** From ENCR@fridaysStockPicks.com Mon Jul 26 21:42:30 1999 Received: from quisp.cisco.com (quisp.cisco.com [171.69.95.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27320 for ; Mon, 26 Jul 1999 21:42:30 -0400 (EDT) From: ENCR@fridaysStockPicks.com Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by quisp.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id SAA22388; Mon, 26 Jul 1999 18:02:12 -0700 (PDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id SAA25205; Mon, 26 Jul 1999 18:11:16 -0700 (PDT) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id SAA02968; Mon, 26 Jul 1999 18:02:11 -0700 (PDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id SAA26869; Mon, 26 Jul 1999 18:08:48 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id SAA19915; Mon, 26 Jul 1999 18:02:10 -0700 (PDT) Received: from ats2-79.worldramp.net(207.30.147.179) by proxy3.cisco.com via smap (V2.0) id xma019871; Tue, 27 Jul 99 01:02:04 GMT X-SMAP-Received-From: outside DATE: Mon, 26 Jul 1999 21:04:24 -0500 Message-ID: Subject: HOT STOCK PICK (adv.) To: $user@external.cisco.com X-Reply-To: ENCR@fridaysStockPicks.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Encounter.com, Inc. (OTC BB: ENCR)http://fridaysstockpicks.com/ The Stock is currently trading at only 32 cents! Upside potential is tremendous! Their current fiscal year earnings (May 31, 2000) are projected at 36 cents per share, justifying a future share price of $4.00 to $6.00 in the next twelve months. Company operates singlestogo.com interactive singles matching web site! Company is licensing it's name to and internet gaming casino and will participate in a revenue sharing of highly profitable online gambling business!!!!! ENCR is positioned to become the world's leading provider of online services to the huge global singles market, concentrating on 'voice personals', online dating, theater & event booking, Internet gaming, and the multi-billion travel industry. Read the analysis on this fascinating company at http://fridaysstockpicks.com/ From scoya@ns.cnri.reston.va.us Tue Jul 27 15:50:23 1999 Received: from sheltie.cisco.com (sheltie.cisco.com [171.69.219.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19893 for ; Tue, 27 Jul 1999 15:50:23 -0400 (EDT) Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by sheltie.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id MAA18393 for ; Tue, 27 Jul 1999 12:13:56 -0700 (PDT) Received: from beasley.cisco.com (beasley.cisco.com [171.69.11.49]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id MAA20762 for ; Tue, 27 Jul 1999 12:23:02 -0700 (PDT) Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by beasley.cisco.com (8.8.8/2.6/Cisco List Logging/CISCO.GATE.1.1) with ESMTP id MAA07585 for ; Tue, 27 Jul 1999 12:13:53 -0700 (PDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id MAA20738 for ; Tue, 27 Jul 1999 12:22:56 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id MAA27074 for ; Tue, 27 Jul 1999 12:13:47 -0700 (PDT) Received: from odin.ietf.org(132.151.1.176) by proxy3.cisco.com via smap (V2.0) id xma027059; Tue, 27 Jul 99 19:13:44 GMT X-SMAP-Received-From: outside Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18153; Tue, 27 Jul 1999 15:06:32 -0400 (EDT) Message-Id: <199907271906.PAA18153@ietf.org> To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: bridge-mib@external.cisco.com From: The IESG Subject: Protocol Action: Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions to Proposed Standard Date: Tue, 27 Jul 1999 15:06:32 -0400 Sender: scoya@ns.cnri.reston.va.us The IESG has approved the Internet-Draft 'Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions' as a Proposed Standard. This document is the product of the Bridge MIB Working Group. The IESG contact persons are Bert Wijnen and Randy Bush. Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing MAC bridges based on the IEEE 802.1D-1998 MAC Bridges and IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes several MIB modules in a manner that is compliant to the SMIv2 [V2SMI]. Working Group Summary This document represents the consensus of the BRIDGE WG. Protocol Quality The document was reviewed for the IESG by Dave Harrington. Note to RFC Editor: 1. The IESG requests the RFC Editor to replace the abstract section with the following text: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines two MIB modules for managing the new capabilities of MAC bridges defined by the IEEE 802.1D-1998 MAC Bridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'Enhanced Multicast Filtering' components of IEEE 802.1D-1998. The other MIB module defines objects for managing IEEE 802.1Q VLANs. Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes several MIB modules in a manner that is compliant to the SMIv2 [V2SMI]. This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent) RFC 1525 [SBRIDGEMIB]. 2. The IESG requests the RFC Editor to change the reference (in reference section) [INTERFACEMIB] from RFC1573 to RFC2233 which obsoleted the 1573 3. Note that Les Bell (one of the authors) has the nroff source in which he has already made these changes.