RE: dot1dStpPortPathCost32

Hi,

Can we resolve this (and any other issues) on the mailing list before
IETF61, please? 

These mib modules are already three years behind the charter schedule.

We want to start the WG last call before IETF61, not wait until IETF61
to start discussing possible solutions. 

dbh

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of David B Harrington
> Sent: Tuesday, November 02, 2004 12:02 PM
> To: 'Les Bell'; [email protected]
> Cc: [email protected]
> Subject: RE: [Bridge-mib] dot1dStpPortPathCost32
> 
> I'm not very knowledgeable about the new object, but I think 
> the support should be conditionally mandatory, and the 
> condition should spell out that one or the other should be used.
> 
> An alternative would be to have different compliance caluses, 
> one to support the older compliance rules and another to 
> support the new compliance rules, but if there's only one 
> object that would be mandatory in the new clause, that 
> doesn't seem worth it.
> 
> dbh
>  
> 
> -----Original Message-----
> From: [email protected]
[mailto:[email protected]]
> On Behalf Of Les Bell
> Sent: Tuesday, November 02, 2004 4:50 AM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: [Bridge-mib] dot1dStpPortPathCost32
> 
> 
> 
> 
> Use of the 32-bit path cost was defined in both 802.1w (RSTP) 
> and 802.1t.
> 802.1t was a collection of enhacements to Bridges, including 
> those that support legacy STP.  So the 32-bit path costs do 
> not just apply to RSTP.
> 
> I think you are right that dot1dStpPortPathCost32 should be 
> conditionally mandatory, but for any Spanning Tree 
> implementation that supports 32-bit path costs, not just for RSTP.
> 
> Implementations that support 32-bit path costs should not use 
> the 16-bit path cost object, dot1dStpPortPathCost, but I am 
> not sure what is the best way to deal with this.  Are we 
> allowed to allocate a special value to indicate it is not in 
> use?  I think it would be safer to return an SNMP error 
> indicating the old object is not supported.
> 
> Les...
> 
> 
> 
> 
> 
> Juergen Schoenwaelder <[email protected]>@ietf.org on
> 22/10/2004
> 12:05:23
> 
> Please respond to [email protected]
> 
> Sent by:  [email protected]
> 
> 
> To:   [email protected]
> cc:
> Subject:  [Bridge-mib] dot1dStpPortPathCost32
> 
> 
> The revised BRIDGE-MIB adds dot1dStpPortPathCost32 and makes 
> it mandatory. I think this is broken since existing deployed 
> implementations won't support that object and thus are not
compliant.
> Can someone please explain in which situations the increased range
of
> dot1dStpPortPathCost32 is actually needed?
> Is this only relevant for rapid spanning tree? In that case, 
> I think the object should be conditionally mandatory for 
> boxes that do rapid spanning tree and the old one stays 
> current, probably with a special value to use in case 
> dot1dStpPortPathCost32 actually has the larger path cost.
> 
> Please give advise.
> 
> /js
> 
> --
> Juergen Schoenwaelder             International University Bremen
> <http://www.eecs.iu-bremen.de/>        P.O. Box 750 561, 28725
Bremen,
> Germany
> 
> _______________________________________________
> Bridge-mib mailing list
> [email protected]
>  https://www1.ietf.org/mailman/listinfo/bridge-mib
> 
> 
> 
> 
> 
> _______________________________________________
> Bridge-mib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/bridge-mib
> 
> 
> 
> _______________________________________________
> Bridge-mib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/bridge-mib
>