Subject: Re: [Bridge-mib] dot1dStpPortPathCost32

From: "Les Bell" <[email-masked]>
Date: Tue, 2 Nov 2004 09:50:14 +0000

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-masked]>@ietf.org on 22/10/2004
12:05:23

Please respond to [email-masked]

Sent by:  [email-masked]

To:   [email-masked]
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-masked]
 https://www1.ietf.org/mailman/listinfo/bridge-mib

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Nov 2004 17:24:54 +0100

> costs, not just for RSTP.

OK, that language makes sense.
 
> old object is not supported.

I guess we need to discuss this next week. I know that this issue was
discussed before, but we have to make a real engineering decision here.
There are several issues involved as far as I can tell:

a) Formally, we are not expected (or even allowed?) to add objects while
   moving from Draft to Standard. So this needs careful consideration
   from the IETF procedures perspective and support by the AD.

b) According to the SMIv2 rules, we can't change the range of the
   original 16 bit object and have to introduce the new object as
   done in the current ID. Your question what implementations should
   do that support 32-bit path costs with the old object requires
   consideration. Not sure there is a path cost which can be used
   as a special value (and doing so would most likely change existing
   semantics) so the requirement might indeed be not to support that
   object (at least if the value is outside the range).

c) It would be nice to know what existing implementations do. I guess
   that implementation wise simply removing the range restriction is
   probably the easiest thing to do on the agent. It is hard to judge
   whether this seriously impacts real-world managers interoperability.
   If there are implementations which did follow this approach, then 
   this might be important information to consider.

/js

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 2 Nov 2004 12:02:21 -0500

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-masked] [mailto:[email-masked]]
On Behalf Of Les Bell
Sent: Tuesday, November 02, 2004 4:50 AM
To: [email-masked]
Cc: [email-masked]
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-masked]>@ietf.org on
22/10/2004
12:05:23

To:   [email-masked]
cc:

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

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 2 Nov 2004 14:47:11 -0500

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David B Harrington
> Sent: Tuesday, November 02, 2004 12:02 PM
> To: 'Les Bell'; [email-masked]
> Cc: [email-masked]
> 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
>  
> 
> 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.
> 
> 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...
> 
> 
> 
> 
> 
> The revised BRIDGE-MIB adds dot1dStpPortPathCost32 and makes 
> it mandatory. I think this is broken since existing deployed 
compliant.
> 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
> 
> --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Nov 2004 21:23:12 +0100

> Can we resolve this (and any other issues) on the mailing list before

Will be hard, but we can try.
 
> These mib modules are already three years behind the charter schedule.

Yes. But since the IETF meeting is next week, I would say that this week 
does not cause any significant delay.
 
> to start discussing possible solutions. 

Lets try to collect possible solutions:

a) We remove the 32-bit path cost, move the BRIDGE-MIB to Standard and
   start a new MIB module which defines the new object.

a') We remove the 32-bit path cost, move the BRIDGE-MIB to Standard and
   tell the IEEE or who cares that they have to address this issue.

b) We agree to change the range restriction by declaring that an error
   or bug fix (even though it really is not, well yeah ...). We don't
   introduce a new object, stepping of course formally on SMIv2 rules.

c) We do what the document currently does (introducing a new object) 
   and move the whole MIB module back to Proposed.

d) We do what the document currently does and move forward, looking for 
   the IESG feedback. Note that RFC 2026 says that a Draft standard "is 
   normally considered to be a final specification, and changes are 
   likely to be made only to solve specific problems encountered." 
   Perhaps this is a specific problem encountered...

e) We drop the whole document and just stick to RFC 1493.

Any options I did forget?

Any ideas how to select the winner?

/js

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 4 Nov 2004 10:33:06 -0500

OK, Let me start a discussion here. This is important for a consensus
check, so please read and respond.

My experience has been working for an equipment vendor. I have worked
in both the embedded system space and the pure vendor-neutral software
solution space. Here is what I have learned from that experience.

Mib module official status becomes important on the agent side first;
once a mib hits PS it's a valid target for inclusion in project plans
(for those products that include the managed functionality). While
some mib modules get implemented from an I-D, the RFC publication
finalizes the design and an RFC# is marketable. Advancement to DS or
FS makes little difference - if the functionality is in the box, the
mib module should be done fairly soon after the functionality is
available, and if there is an RFC-level standard, that's good. The
tweaking that occurs between PS and DS and between DS and FS makes
little difference to an equipment vendor (except as non-marketable
maintenance work).

MIB modules become important to vendor-neutral software developers
when enough equipment vendors support the MIB module to make it
worthwhile directly supporting it, and there is customer demand for
consistent management of the functionality. Most vendor-neutral
software vendors use table-driven or model-driven designs that largely
hide whether the implementation is the industry standard MIB module or
a proprietary MIB module with similar capabilites. The status of a MIB
module standard is largely irrelevant; the customer demand exists or
it doesn't.

So, we are now faced with a decision to publish the SMIv2 version of
RFC1493 **with no semantic changes** or to publish an updated MIB
module that reflects the current underlying IEEE standard better, by
supporting 32-bit PathCost rather than only the 16-bit PathCost.

How many people on this list actually care whether the standard status
is at PS or DS or FS, and why? Will advancing the standards level have
an **actual** impact on whether the implementation is done by your
company? Would recycling the MIB module at PS have a negative effect
on your company and its revenue stream? Would the benefit of having a
MIB module that is more current with IEEE standards offset any
negatives of recycling at PS?

If you are not associated with a company, but rather a university or
an open-source product or whatever, will the status level have a real
impact on what you do?

Ultimately the question to be answered is: Should we diminish the
functionality in order to advance the document in the standards track,
or should we add the 32-bit functionality even if we have to recycle
at Proposed?

Thanks,
David Harrington
[email-masked]
Bridge-mib co-chair

> From: Juergen Schoenwaelder [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, November 02, 2004 3:23 PM
> To: David B Harrington
> Cc: [email-masked]; 'Les Bell'; [email-masked]
> Yes. But since the IETF meeting is next week, I would say 
> that this week does not cause any significant delay.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Nov 2004 21:38:51 +0100

> an open-source product or whatever, will the status level have a real

Most open source projects are driven by individual interests and in
the bridge context, it is usually the MIBs that the vendors have 
implemented that count. (While there are open source briding
implementations around, they usually do not come with an SNMP
management interface since they run on general purpose boxes.)

So standards status is largely irrelevant as far as I am concerned. 
Migration between versions is however an issues since we are like 
everybody else concerned about interoperability and we typically 
dislike to have complex code just because standards were never 
finished or made the coexistance rather complicated. 

In summary, I think open source coders look at these issues like 
probably most other management application writers, except that
we have more freedom to ignore some proprietary solutions by just
telling people why we do not support certain things. (You can't
do that in a commercial setting I guess.)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Nov 2004 22:14:31 +0100

> costs, not just for RSTP.

OK, I have created another group and this makes the support for
dot1dStpPortPathCost32 conditionally mandatory.
 
> old object is not supported.

dot1dStpPortPathCost is Integer32 (1..65535). Is there a value (e.g.,
65535) which can be picked for this purpose? What do implementation do?

/js