headers
Les Bell | 7 Aug 2002 09:47
Picon

Re: IETF-54 meeting


Mike, thanks for your comments on draft-ietf-bridge-bridgemib-smiv2-03.txt.  I
shall try to respond to your first issue on dot1dStpPortEnable.

> 1) dot1dStpPortEnable
>    I believe there needs to be some text added to the front matter
>    to describe the relationship between ifAdminStatus and dot1dStpPortEnable.
>    What is the relationship between ifAdminStatus and dot1dStpPortEnable?
>      a) none,
>      b) represent same value (as embodied in cisco catalyst implementation)
>      c) represent different layers (port level, vs protocol level) (kzm
expectation?)
>
>    background info: http://www.macfaden.com/ietf/bridge-test-results.txt
When you raised this before, there did not seem to be a consenus for a
definition that would satisfy everyone.  One of the original authors of RFC1493,
Anil Rijsinghani, indicated that c) was the correct answer, but did not
elaborate on how this affects things like handling of STP BPDUs, or forwarding
of traffic.

My own interpretation is as follows:

  If dot1dStpPortEnable is set to enabled(1) the port should participate
  normally in Spanning Tree and in forwarding traffic.

  If dot1dStpPortEnable is set to disabled(2) the port should not
  participate in Spanning Tree, received BPDUs should be discarded, and
  the port should not participate in Layer 2 forwarding of traffic,
  although it may participate in Layer 3 forwarding.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Les Bell | 7 Aug 2002 09:55
Picon

dot1dStpPortPriority


Mike, in response to you second issue...

> 2) dot1dStpPortPriority
>    The wording could be more specific as to what the issue is.
>    It currently reads:
>
>     "The value of the priority field which is contained in
>      the first (in network byte order) octet of the (2 octet long) Port ID.
>      The other octet of the Port ID is given by the value of
>      dot1dStpPort.  On newer bridges, permissible values are 0-240, in
>      steps of 16."
>
> I don't believe this change is backward compatible at all.  You can't
> simply change the values one can use.  This entirely new semantic requires
> a new object.  I simply can't see IESG MIB module reviewers accepting
> this a change. And exactly what is a "newer bridge" anyway?

The IEEE 802.1 WG chose the new implementation of the Port Priority to allow it
to be backward compatible with the currently deployed implementations, with the
intention that existing SNMP applications could still use the same object to
manage it.  The caveat is that, in a new agent implementation, i.e. an agent
that implements 802.1t/802.1w , some values may be rejected with a "bad value"
error, if it cannot accept the value given.

Perhaps one way to address this issue is to leave the DESCRIPTION of
dot1dStpPortPriority unchanged from RFC1493 and to define the more limited set
of values in a conformance clause for agents that support 802.1t/802.w.

Les...
(Continue reading)

Permalink | Reply | 501 comments |
headers
Les Bell | 7 Aug 2002 14:00
Picon

Re: RowStatus in draft-ietf-bridge-ext-v2-00


I think you are right.  We need to add a RowStatus variable to each of these
tables.

Les...

"Ilan Yerushalmi" <IlanY <at> radlan.com> on 07/08/2002 09:44:21

Sent by:  "Ilan Yerushalmi" <IlanY <at> radlan.com>

To:   Les Bell/GB/3Com
cc:
Subject:  RowStatus in draft-ietf-bridge-ext-v2-00

Hi,

I have a question regarding draft-ietf-bridge-ext-v2-00:
Isn't RowStatus variable is missing in dot1vProtocolGroupTable and
dot1vProtocolPortTable Tables? If not, how can I delete an entry in those
tables?

Thank you,
Ilan
Permalink | Reply | 0 comments |
headers
Michael MacFaden | 7 Aug 2002 19:07

Re: IETF-54 meeting

On Wed, Aug 07, 2002 at 08:47:20AM +0100, Les Bell wrote:
>Mike, thanks for your comments on draft-ietf-bridge-bridgemib-smiv2-03.txt.  I
>shall try to respond to your first issue on dot1dStpPortEnable.
[snip]
>My own interpretation is as follows:
>
>  If dot1dStpPortEnable is set to enabled(1) the port should participate
>  normally in Spanning Tree and in forwarding traffic.
>
>  If dot1dStpPortEnable is set to disabled(2) the port should not
>  participate in Spanning Tree, received BPDUs should be discarded, and
>  the port should not participate in Layer 2 forwarding of traffic,
>  although it may participate in Layer 3 forwarding.
>
>I would like to hear the views of the group, to see if they agree or disagree
>with this interpretation.  I would particularly like to hear the views of the
>original authors of RFC1493.

I agree and believe this 'clarifying' text resolve 
the existing incompatiblities between vendor implementations.

Thank you,
Mike MacFaden
Permalink | Reply | 501 comments |
headers
Michael MacFaden | 7 Aug 2002 19:56

Re: dot1dStpPortPriority

On Wed, Aug 07, 2002 at 08:55:03AM +0100, Les Bell wrote:
>> 2) dot1dStpPortPriority
>>    The wording could be more specific as to what the issue is.
>>    It currently reads:
>>
>>     "The value of the priority field which is contained in
>>      the first (in network byte order) octet of the (2 octet long) Port ID.
>>      The other octet of the Port ID is given by the value of
>>      dot1dStpPort.  On newer bridges, permissible values are 0-240, in
>>      steps of 16."
>>
>> I don't believe this change is backward compatible at all.  You can't
>> simply change the values one can use.  This entirely new semantic requires
>> a new object.  I simply can't see IESG MIB module reviewers accepting
>> this a change. And exactly what is a "newer bridge" anyway?
>
>The IEEE 802.1 WG chose the new implementation of the Port Priority to allow it
>to be backward compatible with the currently deployed implementations, with the
>intention that existing SNMP applications could still use the same object to
>manage it.  The caveat is that, in a new agent implementation, i.e. an agent
>that implements 802.1t/802.1w , some values may be rejected with a "bad value"
>error, if it cannot accept the value given.
>
>Perhaps one way to address this issue is to leave the DESCRIPTION of
>dot1dStpPortPriority unchanged from RFC1493 and to define the more limited set
>of values in a conformance clause for agents that support 802.1t/802.w.

I still feel the correct "SNMP" solution is to create a new
object and deprecate the old. However this approach may be acceptable
if everyone thinks the following impact would be reasonable
(Continue reading)

Permalink | Reply | 501 comments |
headers
Michael MacFaden | 8 Aug 2002 00:50

Re: Re: dot1dStpPortPriority

On Wed, Aug 07, 2002 at 10:56:17AM -0700, Michael MacFaden wrote:
>Test:
>
>for (i = 0; i <= 255; i++)
>   set dot1dStpPortPriority.X = i; 
>
>Expected Results:
>
>Device mode   | Mgmt App  | result
>802.1D          802.1D       ok   
>802.1D          802.1t/w     ok  (new apps can know the semantic changes) 
>802.1t/w        802.1D       bad value returned for values  241-255
>
>This appears surprising and I am not sure exactly how inocuous 
>the impact would be using an old 802.1D app against 802.1t/w bridges.
> 
>I would support a semantic change to dot1dStpPortPriority.X if we 
>had had the convention of using capabilities bits as found in
>rfc2674 / dot1dDeviceCapabilities such that a
>1493 based app would query a specific bit to know exactly what mode
>the bridge was in before performing any such set operation.

Bert Wjinen pointed out the draft text says '..in steps of 16' 
so the range for bad values would actually include more than 
the listing I presented above. 

Mike
Permalink | Reply | 0 comments |
headers
Phil Roberts | 27 Aug 2002 20:44

Nomcom call for volunteers


The members of the IESG and IAB and the IETF chair are selected
by a nominations committee made up of volunteers from the
IETF community.  The nominations committee is now in the process
of being formed and volunteers are being accepted until Sep 6.
Please see (http://www.ietf.org/nomcom/msg19765.html)
for information if you are interested in volunteering 
to be on the nominations committee.
Permalink | Reply | 0 comments |

Gmane