SM-FSM LB Comment Response, Rev 1

Roger Cummings

Description

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 ...

Informations

• Publié par: Acti
• Nombre de lectures: 14
• Langue: English

Extrait

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.