RE: VLAn ID
"Les Bell" <[email protected]>
| Newsgroups | gmane.ietf.bridge |
|---|---|
| Message-ID | <[email protected]> |
This was discussed at the March meeting. The decision was to conduct an email 'ballot' to determine if anyone had any objections to using 4095 as a wildcard VLAN ID. I have not heard about the details of how, or when, this will take place. Les... "Wijnen, Bert (Bert)" <[email protected]> on 06/05/2003 18:43:42 Sent by: "Wijnen, Bert (Bert)" <[email protected]> To: Les Bell/GB/3Com, Andrew Smith <[email protected]> cc: "'Wijnen, Bert , "'Bridge-Mib , [email protected] Subject: RE: VLAn ID Les, Did you get any feedback after that March 9th meeting? If not, Can you poll Mick Seaman? Thanks, Bert > -----Original Message----- > From: Les Bell [mailto:[email protected]] > Sent: vrijdag 28 februari 2003 17:27 > To: Andrew Smith > Cc: 'Wijnen, Bert (Bert)'; 'Bridge-Mib (E-mail)'; [email protected] > Subject: RE: VLAn ID > > > > > > I have asked for the opinion of the IEEE 802.1 Task Force > Chair, Mick Seaman, on > this proposal. He believes that the use of 4095 as a > wildcard VLAN-ID would be > okay, but he wants to discuss it formally at the IEEE 802 > meeting in Dallas > (week commencing March 9). I will be attending this meeting. > > Les... > > > > > > "Andrew Smith" <[email protected]> on 27/02/2003 17:53:56 > > Sent by: "Andrew Smith" <[email protected]> > > > To: "'Wijnen, Bert \ > cc: "'Bridge-Mib \, [email protected] (Les Bell/GB/3Com) > Subject: RE: VLAn ID > > > > > Bert, > > The whole point of defining these TCs in a separate document > is to serve > "possible future (yet-undefined) needs" - why else would we bother to > break them out in a separate document or module? > > The need to use VlanIdOrAny as an index in the future seems likely to > me. It is especially likely if you believe that we're trying to set a > precedent here for how to represent "some sort of packet field or > don't-care". Personally, I think it's a bit clunky to > overload the value > like this - a separate flag object is more elegant, but, if we're > comfortable with the overloading, I'd go with Randy and say (as I did > before - maybe you missed my message?) that the syntax here should be > unsigned, not signed (I understand the practical reasons for the > non-negative-index restriction in SNMP but it is a limitation on the > SMIv2 language). I don't think there's a need to consult with IEEE 802 > on this - I think most of the people with relevant opinions > on this are > already on this thread - but that's the bridge-mib WG chair's > call if he > wants to ask himself for help. > > My opinions (I know you're looking for others though ...). > > Andrew > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Wijnen, Bert (Bert) Sent: Thursday, February 27, 2003 8:36 AM To: Randy Presuhn (E-mail) Cc: Bridge-Mib (E-mail); [email protected] Subject: VLAn ID Randy, you wrote: >To: [email protected] >cc: [email protected] (Les Bell/GB/3Com) >Subject: Re: [Bridge-mib] VLAN-ID > >Hi - > >I think it would be better if the "any" value in the *OrAny TC were >a non-negative value so that the type could be used to define an >index. There may not be a need today, but thinking ahead to >representing policy-like things wouldn't hurt. > As far as I can tell, you seem to be the only one sofar who has spoken up on the idea of not having a negative value for the "any" for the VlanIdOrAny TC that I proposed. You do not claim an immediate need, but a possible future (yet-undefined) need. S