La lecture en ligne est gratuite
Le téléchargement nécessite un accès à la bibliothèque YouScribe
Tout savoir sur nos offres
Télécharger Lire

SM-FSM LB Comment Response, Rev 1

De
4 pages
05-356v1 -- Consolidated Comments on SM-FSM Letter BallotCompany-# Technical/ Physical Sectionlocator Problem Description Comment's suggested Proposed Resolution Proposed Editorial Page solution StatusBrocade-01 T 8 5.3 The Fabric Index tutorial Make suggested change. Accepted -- will add: "In an environment of multiple virtual and/or information is either physical Fabrics, this index provides a means to distinguish one Fabric incomplete or too thorough. It from another.explains how multiple virtual fabrics are indexed but doesBrocade-02 T 10 6 T11FspfLsrType allows a Make suggested change. To-be-discussed -- I see that table 36 in rev 7.4 says "02" is "Obsolete value of 02, indicating an AR in FC-SW-4" but that doesn't make sense while Annex D still exists summary record. That type is (and see table D.3). Note that I realise Annex D is "informative", but it obsolete in FC-SW-4 and still doesn't make sense for Annex D to be retained unchanged when should be labeled as such in it's dependent on the use of Summary LSRs -- if it provides this MIB, unless another MIB misinformation should it be labelled as "misinformative" :-).is going to be generated somewhere to explain its behavior.Brocade-03 T 11 6 T11FspfLastCreationTime is a Discuss removal, or Rejected -- T11FspfLastCreationTime is a datatype, not an object. non-FC-SW-4 value. It is an alternatively bring proposals (Note: this is indicated by its first letter being upper case.) - object ...
Voir plus Voir moins

Vous aimerez aussi

05-356v1 -- Consolidated Comments on SM-FSM Letter Ballot
Company-# Technical/
Editorial
Physical
Page
Sectionlocator
Problem Description
Comment's suggested
solution
Proposed Resolution
Proposed
Status
Brocade-01
T
8
5.3
The Fabric Index tutorial
information is either
incomplete or too thorough.
It
explains how multiple virtual
Make suggested change.
Accepted -- will add: "In an environment of multiple virtual and/or
physical Fabrics, this index provides a means to distinguish one Fabric
from another.
Brocade-02
T
10
6
T11FspfLsrType allows a
value of 02, indicating an AR
summary record.
That type is
obsolete in FC-SW-4 and
should be labeled as such in
this MIB, unless another MIB
is going to be generated
somewhere to explain its
behavior.
Make suggested change.
To-be-discussed -- I see that table 36 in rev 7.4 says "02" is "Obsolete
in FC-SW-4" but that doesn't make sense while Annex D still exists
(and see table D.3).
Note that I realise Annex D is "informative", but it
still doesn't make sense for Annex D to be retained unchanged when
it's dependent on the use of Summary LSRs -- if it provides
misinformation should it be labelled as "misinformative" :-).
Brocade-03
T
11
6
T11FspfLastCreationTime is a
non-FC-SW-4 value.
It is an
object apparently used in
multiple places, where the
time is related to sysUpTime,
which is not imported or
defined anywhere.
It also
falls into that category of
parameters created by the
MIB not used by Fibre
Channel and therefore of
uncertain value, availability, or
usefulness.
It is also not
given a conformance rating
that I was able to find.
Discuss removal, or
alternatively bring proposals
into FC-SW-5 that create a
value for it.
By the way, this resembles
the LSR Age function
defined in FC-SW-4.
Rejected -- T11FspfLastCreationTime is a datatype, not an object.
(Note: this is indicated by its first letter being upper case.) -
t11FspfCreateTime is an object which is in the mandatory
t11FspfGeneralGroup and which has T11FspfLastCreationTime as its
syntax. - t11FspfCreateTime serves as the discontinuity timestamp for
the Counter32 objects in the same table, as recommended by RFC
2578 (section 7.1.6), and therefore is implicitly required based on
having those counters. - the reference to sysUpTime is implicitly
imported through the definition of TimeStamp which is IMPORTed. -
while checking on this resolution, I realised that
T11FspfLastCreationTime is a TC which needs to be defined with
TimeTicks as its syntax, not TimeStamp.
I will fix this.
DotHill-01
E
Document needs to be nit
checked prior to submitting to
IETF.
See
http://www.ietf.org/ID-
Checklist.html.
Also run ID
nits tool at
http://ietf.levkowetz.com/tools/
idnits/.
Accepted
McDATA-1
E
15
t11FFspfChecksu
mErrors
"occurred on this in this
Fabric" is wrong.
delete the text in quotes and
the sentence reads well.
We don't need to say "in
this Fabric" all the time.
It's
superfluous.
This happens
in many places and should
be checked for the whole
document.
Partially-Accepted -- will change to: "detected locally (and therefore
discarded) on this Fabric". (this also includes the change due to
McDATA-9 below.) It may be redundant to say "in this Fabric" all the
time, but it is correct, and I prefer to err on the side of redundancy
rather than risk misunderstandings based on implicit-ness.
It's only
three extra words -- omitting them wouldn't reduce the number of lines,
i.e., it wouldn't save any paper.
(Also, see McDATA-8 and McDATA-12
below for why this kind of redundancy is needed.)
McDATA-2
T
19
RetransmitInterval What is an unacknlowledged
link update
Change Link Update to
LSU.
Accepted -- according to FC-SW-4 table 206 it should be:
"unacknowledged LSR".
McDATA-3
E
23
SetToDefault
every every s/b every
Accepted.
McDATA-4
E
26
Incarnation
Number
with largest incarnation s/b
with the largest incarnation.
Accepted.
McDATA-5
E
30
changes
changes s/b changes
Accepted.
McDATA-6
T
14
LsRefreshTime
LsRefreshTime and
FSPFMaxAge should be read
only since there is no way to
change this on the Fabric at
once.
Change MAX-ACCESS to
Read-only for
LsRefreshTime and
FspfMaxAge.
Accepted.
McDATA-7
T
15
MaxAgeDiscards
Does this include the LSRs
that are discarded on arrival
or just ones that time out on
the Switch.
Any LSR is too
vague.
Instead of specifying any
LSR, specify that it is the
combination of frames that
arrived with an Age of
MaxAge or when an LSR
ages out.
Accepted -- just the ones which reach MaxAge; "any LSR" was
intended to mean any type of LSR (but that's probably obvious).
So, I
propose:
"The number of LSRs discarded due to their age reaching
t11FspfMaxAge ...
McDATA-8
E
15
PathComputations Is this calculations per Fabric
or Switch?
change "invoked" to
"invoked by this Switch"
Accepted -- this is a columnar object in the t11FspfTable which is
INDEX-ed by Switch and Fabric.
Thus, will change to: "... invoked by
this Switch on this Fabric ..."
McDATA-9
T
15
Checksumerrors
Is this the count of checksum
errors found on the switch or
discarded by the switch or
both.
please specify.
Accepted -- t11FspfChecksumErrors has a REFERENCE clause
pointing to FC-SW-4 section 8.5.4 which says: "When an LSR is
received with a bad checksum, the LSR shall be ignored." Will change
to: "detected locally (and therefore discarded) on this Fabric". (this also
includes the change due to McDATA-1 above.)
McDATA-10
T
16
FSPF AdminStatus What is the behavior when
FSPF is 'down'?
I don't think
this is standardized, so we
shouldn't have this state.
Remove
t11FspfAdminStatusFSPFif
AdminStatus, and
t11FspfOperStatus.
To-be-discussed -- we have agreed to have static routes be visible (and
optionally configured) via the SM-RTM MIB -- doing so was an implicit
consequence of agreeing to have separate MIBs for SM-RTM and SM-
FSM. Thus, when FSPF is 'down', and no other routing protocol is
being used, the routing occurs according to the static routes.
Thus,
t11FspfAdminStatus & t11FspfOperStatus are needed.
McDATA-11
T
26
LSRAge
This definition is incorrect
since this is the time since the
LSR originator created it.
Change the description to
reality.
Rejected -- FC-SW-4 section 8.5.1 begins: "The LSRage field indicates
how long a particular instance of an LSR has been in the database ..."
McDATA-12
T
27
LSR Links and
FSPFLinkNumber
LSRLinks and LinkNumber
seem to be the same thing.
What is the difference
between these two?
Please clarify.
Rejected -- the DESCRIPTION for t11FspfLsrLinks includes the words
"... associated with this LSR", whereas t11FspfLinkNumber is a scalar
object, i.e., each row in the t11FspfLinkTable is counted in the only
instance of t11FspfLinkNumber as well as in one and only one of the
many instances of t11FspfLsrLinks.
VRTS-001
E
5
3
A reference is needed for a
FSPF defininition
Add a reference to [FC-SW-
4] near the bottom of page 5
Accepted -- will add the text: "FSPF is defined in section 8 of [FC-SW-
4]."
VRTS-002
E
8
5.3
The first sentence of the last
paragraph implies that a
(single) port of a FC switch is
connected to multiple fabrics?
Is this true? Also such is
unclear given that both
physical and virtual fabrics
are referenced in the previous
paragraph.
It is quite possible, and may
even be likely, that
a
Fibre
Channel switch will have
ports connected to more
than 1 physical or virtual
Fabrics.
Accepted -- it is certainly true for multiple Virtual Fabrics.
Whether it is
true for physical Fabrics is debatable because it is dependent on the
definition of a physical Fabric, and I'm unaware of such a definition.
However, the proposed wording change to: "It is quite possible, and
may even be likely, that a Fibre Channel switch will have ports
connected to multiple virtual and/or physical Fabrics.
VRTS-003
T
8
5.3
The reference to
t11FamFabricIndex is
incorrect
Replace by t11FabricIndex
(see [FC-FAM-MIB]) or
t11fspfFabricIndex as
appropriate.
Accepted.
VRTS-004
E
9
6 IMPORTS
The RTM and VRM MIBS
import InterfaceIndex from the
IF-MIB. Both are correct - is
there a reason for them to be
different?
Make all 3 MIBs consistent
in absence of a reason for
them to be different.
Accepted -- the difference in the IMPORTS clauses is a side-effect --
the RTM-MIB defines a new object, t11FcRouteInterface, with syntax
InterfaceIndex, whereas the FSM-MIB uses ifIndex itself.
Since in both
cases, the usage is for an object specified in an INDEX clause, an
SNMP message will only ever include the value, never the OID, in each
of these cases, i.e., the two different definitions are identical "on the
wire".
For consistency, I propose to define a new object t11FspfIfIndex
in the t11FspfIfTable which will be used in its INDEX clause instead of
ifIndex.
VRTS-005
E
13
REFERENCE
Clauses
The revision of FC-SW-4
referenced is given in the
Normative References. Does
it need to be repeated in each
reference clause?
Remove revision
Accepted.
Un pour Un
Permettre à tous d'accéder à la lecture
Pour chaque accès à la bibliothèque, YouScribe donne un accès à une personne dans le besoin