FC-BB-4 Letter Ballot Comments (07-184v3)
Company number tech/edit Page Sec/table/fig locator Comment Proposed Solution Resolution Status
E Section 3.6 FC-BB-3_SONET definitions Copy from BB-3 Section 3.3 Rejected. See
Packetlight-001 Packetlight-023.
E Section 3.5.5 FC-BB-3_SONET (glossary) Copy from BB-3 Section Rejected. See
Packetlight-002 3.7.3 Packetlight-023.
E Section 4.3.4 FC-BB-3_SONET (model) Copy from BB-3 Section Rejected. See
Packetlight-003 4.3.2 Packetlight-023.
Packetlight-004 E Section 4.4.2.1 Add FC-BB-3_SONET to the Section Copy from BB-3 Section
4.4.2.1 Rejected. See
header and the FC-BB-3_IP inside Packetlight-023.
Packetlight-005 E Section 4.4.6 Add the SFC flow control Add the sentence: "FC-BB-
4_SONET devices may use
the Simple Flow Control
(SFC) protocol to temporarily
pause the transmission of
frames from a remote Rejected. See
device." Packetlight-023.
Packetlight-006 E Section 4.4.5 Add the requirement for SONET In- Add the sentence: "FC-BB-
Order-Delivery 4_SONET shall guarantee in-
order delivery of frames
within each SONET/SDH Rejected. See
provisioned path." Packetlight-023.
Packetlight-007 E Section 4.4.4 Add the Requirement for SONET Add the sentence: "FC-BB-
4_SONET has no specific
SONET service Rejected. See
QOS requirements." Packetlight-023.
Packetlight-008 E Chapter 7 Add a the SONET message formats Add the Section: ""FC-BB-
4_SONET Messages and
Formats". Copy to it the Rejected. See
content of BB-3 Chapter 5. Packetlight-023.
Packetlight-009 E Chapter 8 Add the SFC and SR flow control Copy the BB-3 Chapter 6. Rejected. See
Packetlight-023.
Packetlight-010 E Chapter 9 Add SONET Structure and Concept Copy from BB-3 Chapter 8 Rejected. See
Packetlight-023.
Packetlight-011 E Annex C Add SR Guidelines Copy from BB-3 Annex C Rejected. See
Packetlight-023.
Packetlight-012 E 2 Change History Removed SONET cancellation Remove the line: "removed
FC-BB-3_SONET specific Rejected. See
announcement text" Packetlight-023.
Packetlight-013 E 7 Introduction Add the SONET mapping Rejected. See
Packetlight-023.
Packetlight-013 E 13 Scope Add the SONET mapping Add the line: "– FC-BB-
4_SONET (FC over SONET Rejected. See
backbone network)". Packetlight-023.
Packetlight-015 E 13 Scope Add the SONET model type to the Add the Model Type: "FC-BB-
4_SONET" and its applicable
Sections and Annexes Rejected. See
table of FC-BB-4 Organization Packetlight-023.
Packetlight-016 E 15 Scope Add the figure of the components of Copy the Figure-1 from BB-3 Rejected. See
the SONET model Packetlight-023.
Packetlight-017 E 19 Section 3.1 Add the BB_SONET to the definition Change the sentence to: "A
of a B_Port Bridge Port on a device that
implements FC-BB_IP or FC-
BB_SONET and connects to
an E_Port on an FC switch" Rejected. See
Packetlight-023.
Packetlight-018 E 19 Section 3.1 Add the definition of BBW Add the definition: "BBW:
Refers to an FC-BB- Rejected. See
4_SONET device". Packetlight-023.
Packetlight-019 E 19 Section 3.1 Add the definition of FC-BB- Add the definition: "FC-BB-
4_SONET 4_SONET: A model defining
equipment that interfaces
with a Fibre Channel
switched network on one side
and a SONET/SDH network Rejected. See
on the other side". Packetlight-023.
Packetlight-020 E 19 Section 3.1 Add the FC-BBW_SONET to the
definition of: Fibre Channel Rejected. See
Backbone link Packetlight-023.
Packetlight-021 E 20 Section 3.1 Add the definition of the SFC flow Add the definition: "Simple
control Flow Control (SFC): A flow
control protocol that may be
applied between two FC-BB-
4_SONET devices across a Rejected. See
SONET WAN." Packetlight-023.
Packetlight-022 E 20 Section 3.1 Add the definition of SR flow control Add the definition: "Selective
Retransmission (SR) flow
control: A sliding window flow
control protocol that may be
applied between two FC-BB-
4_SONET devices across a
ATM/SONET WAN. SR flow
control provides for both flow
control and error recovery." Rejected. See
Packetlight-023.
T Add the Mapping and Message See the proposed solution in
encapsulation using GFPF/VCAT to document FC BB-4-
FC-BB-3_SONET Structure and GFPF.doc
Packetlight-023 Concepts chapter. Reject.
Remove rounded corners in line
around figure, like majority of figure
ENDL-001 E 2 1 Scope, Figure 1 in dpANS.
Remove rounded corners in line
around figure, like majority of figure
ENDL-002 E 3 1 Scope, Figure 2 in dpANS.
4.2 FC-BB-4 reference models,
ENDL-003 E 16 Figure 3 Add line around figure.
4.2 FC-BB-4 reference models,
ENDL-004 E 17 Figure 4 Add line around figure.
4.2 FC-BB-4 reference models,
ENDL-005 E 18 Figure 5 Add line around figure
5.2.4.1 Major components, Put figure title on same page as
ENDL-006 E 26 Figure 7 figure.
Uncheck 'Convert smooth lines to
curves' in Acrobat Distiller Advanced
5.3.3.2.4 B_Access Virtual ISL Job Settings to straighten the wavy
ENDL-007 E 35 and FCIP Links, Figure 11 lines in this figure. accepted complete
Uncheck 'Convert smooth lines to
curves' in Acrobat Distiller Advanced
5.4 FC-BB_IP Network Job Settings to straighten the wavy
ENDL-008 E 42 Topologies, Figure 14 lines in this figure. accepted complete
6.4.2.2 Initialization state
ENDL-009 E 59 machine, Figure 18 Add a line around this figure.
6.4.5 Handling of BB_SCs,
BB_SCr, and R_RDY ..., Figure
ENDL-010 E 68 19 Add a line around this figure.
6.4.6.3.3 FC-BB_PW PING and
ENDL-011 E 71 PING_ACK, Figure 20 Add a line around this figure.
There needs to be a clear statement
explaining the relationship between
FC-BB-4 and FC-BB-3. In particular,
how FC-BB-3's ATM and SONET
modes continue, but the IP and
Transparent modes are superseded
in FC-BB-4. Suggested text: "FC-BB-
4 does not replace FC-BB-3 which
remains in force for the SONET and
ATM FC Backbone transport
NN-001 Introduction (or Scope?) modes."
NN-002 Introduction X' needs to be defined.
NN-003 2.4 ITU-T Refs G.707 is now 2007
NN-004 G.7041 is now 2005
NN-005 G.7042 is now 2006
NN-006 G.783 is now 2006
NN-007 G.798 is now 2006
NN-008 G.8040 is now 2005
NN-009 G.806 is now 2006
NN-010 3.5.4 Add terms PE and MPLS/PW
First paragraph. "PE" is not a
defined term. A definition should be
NN-011 4.3.3 provided.
Second paragraph; four minor word
changes. Change: "FC-BB_PW
encapsulates byte-encoded FC
frames and selected set of Primitive
Signals and Primitive Sequences
into PW PDU for transport over the
MPLS network. FC-BB_PW utilizes a
reliable tranport of FC traffic over the
MPLS network provided by the PW
termination layer as specified in draft-
ietf-pwe3-fc-encap-02." to "FC-
BB_PW encapsulates byte-encoded
FC frames and selected sets of
Primitive Signals and Primitive
Sequences into PW PDUs for
transport over the MPLS network.
FC-BB_PW utilizes reliable transport
of FC traffic over the MPLS network
provided by the PW termination layer
as specified in draft-ietf-pwe3-fc-
NN-012 4.3.3 encap-02."
Text immediately after Figure 18.
Transition All:S1 Init. The word 'it' is
missing. Text should read: "This
transition occurs when an
initialization event occurs in a state
where it is not already handled. An
NN-013 6.4.2.2 initialization event may be:"
The sentence: "If a valid ELP,
FLOGI, or PLOGI request frame
(see FC-SW-4 and FC-LS) is
observed in either direction, then a
corresponding, direction-specific
LEM be opened:" does not read
correctly. Propose changing the end
of the sentence to "… LEM is
NN-014 6.4.3 opened:"
Insert the word "of" in the phrase: "b)
immediately upon completion the
forwarding of a frame…" such that it
reads "b) immediately upon
completion of the forwarding of a
NN-015 6.4.6.2 frame…"
In the entry: "b) insert ASFC_PAUSE
or ASFC_RESUME Primitive Signals
on word boundries; and" the word
"word" should be expanded to
"transmission word", for clarity and
NN-016 6.4.6.2 consistency.
Final paragraph, first sentence
starting "Layer 2 technologies..":
NN-017 6.4.8 "has" should be "have".
Final paragraph, second sentence
starting "All detected codeword
errors…" is not clear and needs to
NN-018 6.4.8 be reworded.
For consistency, the sentence: "If an
egress FC-BB_GFPT device is
operating as compression allowed
(see 6.4.6.3.2), the egress FC-
BB_GFPT device shall process a
frame as follows:" should be: "If an
egress FC-BB_GFPT device is
operating with compression enabled
(see 6.4.6.3.2), the egress FC-
BB_GFPT device shall process a
NN-019 6.4.10.1 frame as follows:"
T Optionally, propose a
At this point in time, Alcatel-Lucent resolution
considers that the draft is not yet in
compliance with INCITS/ANSI
Guildelines (Section 8.6 ANSI Patent
Policy (Clause I.2 Statement From
Patent Holder)). A party has
indicated to Alcatel-Lucent that they
claim intellectual property rights to a
portion of the compression
algorithms added specifically for the
FC-BB-4 draft. At the time of Alcatel-
Lucent's submission of this vote,
there has been no formal notification
to INCITS/ANSI by that party of the
assurance of their willingness to Dave to work with Bob
license under terms that "will be Snively on contacting
reasonable and demonstrably free of Hifn to resolve LoA
Lucent-001 iv unfair discrimination". issue. pending
EMC-001 E vii Introduction Red X should be a number 2
EMC-002 E vii Introduction No mention of FC_PW in Mention it.
Introduction
EMC-003 T 1 1 Scope What's a "PSN backbone network"? Describe FC-BB_PW as
Shouldn't this be specifically over being over MPLS.
MPLS accepted
EMC-004 T 3 1 Scope FC-BB_PW figure is missing Add it. accepted
EMC-005 T 6 2.5 No PW references - need to Add the FC_PW Internet-
reference the Internet-Draft at a Draft reference and whatever
minimum. else is needed. accepted
EMC-006 T 11 3.3 Missing PW definitions Add them accepted
EMC-007 T 13 3.5.4 Only 1 PW acronym Surely there are more,
starting with PSN and MPLS.
accepted
EMC-008 T 18 Figure 5 Lots of unexplained acronyms and Add text to describe what's accepted, also add lead
concepts here, starting with PSN going on in the figure. in text to figure 3, figure
Network, PE and PSN tunnels. 4, figure 5
EMC-009 T 19 4.3.3 I assume the red name of the FC Indicate somewhere that it
PW Internet Draft is a placeholder. needs to be updated to an
IETF RFC # when available.
Note that there's a T11-IETF
process issue to be worked
so that each organization can
reference the other's final accepted. Dave to
document by its appropriate contact INCITS to see if
number (INCITS # and RFC a number can be pending - INCITS BSR
#). allocated for FC-BB-4 419:200x
EMC-010 T 58 6.3 Need to actually cite the referenced Add the references to
IETF standards for MPLS appropriate MPLS standards
and consider mentioning
some of the more important
ones here. accepted
EMC-011 T 58 6.4.2.1 The FC-BB_PW definition of WAN- Check this implication. Add
Error implies that all WAN errors text to explain what's going
manifest as reception of a bad FC on if the implication is not
frame from the WAN. Is that correct.
correct? need to review
EMC-012 T 60 6.4.2.2 State S3 requires transmitting one or Explain. Complete. No change
more PING signals. How does the other than moving text
device determine how many to from the PW clause up
transmit? to the overview.
EMC-013 T 60 6.4.2.2 The sender may send multiple PING Add specification of states in
signals, but the first one causes a which PING shall be ignored
transition out of S3. What happens if appropriate. If it is possible
to the others? to transition S3 -> S1 -> S3
and receive a stale PING,
explain how to cope with this
situation, else explain why it
can't happen. Reject, multiple PINGs
may be sent.
EMC-014 T 61 6.4.2.2 "WAN link interruptions or protection Discuss delayed reaction to
events may be concealed from the WAN events in the hope that
attached FC equipment in a manner the situation is transient and
beyond the scope of this standard." correct communications will
It's not entirely beyond the scope of be restored. Specify the
the standard - the FC timeouts have applicable FC timeouts for
to be respected. loss of WAN communication
(the point at which the FC link
shall be taken down to avoid
stale FC frame delivery). Reject.
WAN_HOLDOFF_TOV
covers this case.
EMC-015 T 62 6.4.2.2 - S2:S2 WAN-PSig=Idle Why the difference between PW and Explain. Allowing a PW to Reject, IDLE
GFPT?? A PW can forward IDLEs, choose when to forward an suppression is requried
see S2:S2 FC-LOSYNC. IDLE (as GFPT) may be for PW (i.e., it is the
or FC-PSig=Idle preferable. desired behavior).
EMC-016 T 63 6.4.2.2 - S2:S2 FC-LOSYNC This is a GFPT vs. PW difference in Explain difference
that GFPT will tell the other side that somewhere.
there is an error, whereas PW may
not. need to review
EMC-017 T 72 6.4.6.3.3, Table 20 Is FC-BB-4 the authority for this, or is
I suspect that this is actually accepted, IETF is the
FC-BB-4 including this for IETF-controlled, and normative text. Dave to
convenience from the IETF Internet- reproduced here for review. (Appears BB-4
Draft convenience - if so, say so. is the authority for the
If not, at least define all the TYPE field values,
possible TYPE values headers should be
somewhere in FC-BB-4. removed)
EMC-018 T 75 6.4.8 FC-BB_PW does not reliably This may be a problem that
transmit ingress FC errors to other needs an FC-BB_PW analog
side. to the 10B_ERR character.
EMC-11 and EMC-16 are
related. need to review
EMC-019 T 75 6.4.8 "All detected codeword errors lead to Replace this discussion with
the marking of FC frames as not a correct one that allows
valid by replacing the EOF Order Set errors to be signalled outside
at egress, and to errored control an FC frame. Explain what
frame discard." Not if there isn't an happens if corruption occurs
FC frame to mark. outside an FC frame. need to review. See 07-
064v3comments.
HP-001 should say … defines 3
E vii Intro … defines X distinct ….
distinct …
HP-002 E vii Intro missing FC over PW add it
HP-003
See comments later in FC_IP about
accepted in principle,
T 2 figure 1 allowing N-port interface in the remove N-port
split e/n_port into two
FC_IP protocol, starting with HP-13
entities
HP-004 T 3 TBD missing figure for FC-BB_PW add it accepted
some references appear to be out of update or obsolete
E 4&5 2.3
HP-005 date references
some references appear to be out of update or obsolete
E 5 2.4
HP-006 date, e.g those to ATM references
see editors note about needing PW
E 6 TBD add it
HP-007 references
HP-008 E 7 3.1 missing definition of FC-BB_PW add it
in .10 the term is typed GFPT WAN
E 7 3.1.10 & 3.1.13 pick one
and in .13 its typed as GFPT_WAN
HP-009
see editors note about needing PW
E 11 TBD add it
HP-010 definitions
The sentence that starts with "The
resolve conflict by changing
FC-BB_IP models assumes the use
T 15 4.1 the phrase "...assumes the
of the TCP connections…" is in accepted, change to
…" to "...shall…"
HP-011 conflict with section 4.4.6 "…use TCP …"
How big is a non-negligible link Insert (up to a maximum of accepted in principle,
T 15 4.1
HP-012 latency? 350 ms one way) remove the (i.e. … )
HP-013 T 16 table 3 in conflict with figure 1 no change see HP-03 reject, see HP-003
remove all references to
E 18 4.3.1 class 4 frames are mentioned
class 4 as they are obsolete
HP-014
T 18 4.3.1 presumes only TCP, see also HP-11 Shall only use TCP
HP-015 accepted, see HP-011
accepted in principle,
missing paragraph on speed
look at FC-BB-2
T 18 4.3.1 negotiation (see para. 4.3.2 and add it
subclause for missing
4.3.3)
HP-016 text
rejected, a link down
condition results in a
T 19 4.3.2 & 4.3.3 missing support for link keep alive add it
WAN-Down indication
HP-017 for GFPT and pwe3
HP-018 E 20 4.4.1 & 4.4.2.1 reference class 4 support remove it
in the last sentence of the paragraph reject, the standard
there is no options suggested to already specifies that
append with: use the LKA
T 20 4.4.2.1 replce the fact that primitive LKA is used to detect
ELS.
sequences are not passed over the the state of the TCP
HP-019 IP WAN. connection.
no mention of maximum supported accepted in principle,
T 20 4.4.3 add it - see also HP-12
HP-020 latency see HP-012
Again only TCP is mentioned, if FC-
BB_IP also supports UDP then it
T 21 4.4.6 correct
should be added; see also HP-15,
HP-021 HP-11 accepted, see HP-011
Accept. Add to 4.3.1 last
paragraph: "The FC-
BB_IP device interfaces
to attached FC_Ports
Missing in the dicussion on flow are FC physical
control is the need to potentially rate interfaces operating at
T 21 4.4.6 add it standard rates. The FC-
limit within the device as a coarse
form of flow control BB_IP devices may
support automatic WAN
link speed negotiation
with the attached
HP-022 IP_Ports."
conflict between text and figure, text
only supports E or F ports while
T 23 5.1 & figure 6 figure adds N-ports; see also remove reference to N-ports
comments on loss of LKA support
HP-023 when using N-ports reject, see HP-003
HP-024 E 24 figure 7 should be in section 5.2.1 move it from section 5.4
given specific mention of non-
T 24 5.2.2 support for class 1, missing add it
statement of non-support for class 6
HP-025 accept
in the second paragraph on page 28,
there is a one to one mapping …
with allowance for multiple TCP links
T 28 5.2.4.2.4 add it
between FC-BB_IP devices. Missing
is the need to assure write order
when using more than one link
HP-026 accept
HP-027 E 29 figure 7 shows support for class 4 remove reference to class 4
another purpose of the CSM is tear
down the FC link on loss of TCP
T 29 5.2.4.4 add it
data, that is as if the IP cable were accepted in principle,
HP-028 cut. but no change
from IETF.org: RFC 4330 Simple
Network Time Protocol (SNTP)
Version 4 for IPv4, IPv6 and
OSI. D. Mills. January 2006.
update reference here and in
T 30 5.2.4.5.2.2 (Format: TXT=67930 bytes)
references up front
(Obsoletes
RFC2030, RFC1769) (Status:
INFORMATIONAL)
HP-029 accept
HP-030 E 30 5.2.4.5.2.2 reference class 4 support remove it
Is there a minimum value for 1/2
E_D_TOV? For example 5 times
T 30 5.2.4.5.2.3 add it
maximum supported one-way accepted in principle,
HP-031 latency? but no change
Since FC maintains write order within
the fabric, If multiple routes are
T 32 5.2.5 last paragraph available within the IP WAN, then the add it
write order must be maintained within
HP-032 the IP WAN. accept
HP-033 E 36 figure 12 class 4 frames are mentioned remove the references
HP-034 E 44 5.5.1.2, connection usage flags class 4 frames are mentioned remove the references
A secondary function of the CSM is
T 48 5.6.3.1 to rapidly close down links when add it accepted in principle,
HP-035 requested or loss of data. but no change
HP-036 E 49 5.6.3.2 class 4 frames are mentioned remove the references
Since FC maintains write order within
the fabric, If multiple DEs are used,
T 53 5.7.2.3 last paragraph then the write order must be add it
maintained across the combination
HP-037 of DEs. accept
While the standard does not make
use of multicast or broadcast, the
T 55 5.7.6 add it
use of those protocols by an FC-
HP-038 BB_IP device is prohibited accept
correct title is Transition S2:S2 WAN-
E 62 Transition S2:S2 WAN-PSig!=…. remove !
HP-039 PSig=...
last sentence (re-)initialization has
E 67 6.4.4 paragraph 2 reformat
HP-040 bad format (line break after the -)
This sentence describes how the
attached device might use an
alternate BB_Credit management
6.4.4 paragraph 3 - last scheme, yet then says the behavior
T 67 add it
sentence of the (Transparent) FC-BB device is
outside this standard. Instead the reject. The use of
text should read that the link is not alternate BB_Credit is
HP-041 formed. not prohibited.
the transmision of the NOS shall be
in accordance with FS-2 and not for replace the text with No change other than
T 69 6.4.5, last paragraph
a given time. IF a specific time is reference to FS-2 FC-BB-3_GFPT to
HP-042 required, then fix FS Transparent FC-BB.
add text that says the link is
what happens if the ASFC_resume dissolved and that the NOS Rejected, the case
T 70 6.4.6.2
is not received after 1/2 E_D_TOV? is tranmistted back to the where no BB_Credit
HP-043 client device occurs is covered.
Add a subsection that
describes an appropriate
What happens if there is a PING response such as after 5
T 70&71 6.4.6.3
timeout? sucsessive ping timeouts the Rejected.Using PING in
link is closed and NOS this fashion is not the
HP-044 transmitted to the clients intent.
Brocade-001 E v Foreword "200X" should be "2007" Make recommended change.
Brocade-002 E vi Foreword We have to include both the T11.3 Make recommended change.
and the T11 lists.
Brocade-003 T vii Introduction The second sentence should be Make recommended change.
changed to read:
"FC-BB-4 defines 3 distinct Fibre
Channel backbone mappings: FC
over TCP/IP, FC over GFPT, and FC
over Pseudo-Wire. accept
Brocade-004 E vii Acknowledgements If there are no people to Make recommended change.
acknowledge, the clause should be
deleted.
Brocade-005 E 4 2.1 The text of the second paragraph of Make recommended change.
2.1 is largely redundant with the text
of the first paragraph of 2.2. I would
propose that the text of the second
paragraph of 2.1 be deleted and any
additional information required in 2.2
to completely cover all the issues in
2.1 be added.
Brocade-006 T 4 2.3 These references are presently out Make recommended change.
of date and should be transferred to
approved references (2.2) as
follows:
ANSI INCITS 418-2006, Fibre
Channel - Switch Fabric - 4 (FC-SW-
4) [note that this should replace FC-
SW-3]
ANSI INCITS 424-2007, Fibre
Channel - Framing and Signaling - 2
(FC-FS-2) [note that this should
replace FC-FS]
ANSI INCITS 433-2007, Fibre
Channel - Link Services (FC-LS)
ANSI INCITS 426-2007, Fibre
Channel - Security Protocol (FC-SP)
accept
Brocade-007 T 5 2.4 The following references do not Make recommended change.
appear to be referenced anywhere in
the standard and (unless they should
have been and were not) should be
removed.
ITU-T Rec. I.356
ITU-T Rec. I.363.5
ITU-T X.25-1997
ITU-T Q.2931
ITU-T Q.2971
ITU-T Rec. G.707, G.709, G.7042,
G.7043, G.798
ITU-T Rec. G.8040
Note that these may alternatively be
moved to a bibliography if the
committee thinks they are useful
supplements, even though they are accept, but need to
not referenced. review the list
Brocade-008 T 6 2.5 The following references do not Make recommended change.
appear to be referenced anywhere in
the standard and (unless they should
have been and were not) should be
removed.
RFC 1619, 1661, 1662, 3723.
Note that these may alternatively be
moved to a bibliography if the
committee thinks they are useful
supplements, even though they are accept, but need to
not referenced. review the list
Brocade-009 T 6 2.5 Research and provide PW Make recommended change.
references as per editor's note.
These may include: RFC 4447
(clause 6.4.2.2). accept
Brocade-010 E 7 3.1.13 The English language word Make recommended change.
"comprised" is misused often enough
that it should probably be avoided. I
propose the last sentence be
rewritten to read. "Note that a Fibre
Channel Backbone link may, in some
cases, be made up of more than one
physical or logical connection."
Brocade-011 E 8 3.1.22 "an unique" should be "a unique". Make recommended change.
Brocade-012 T 9 3.2.23 The definition is a bit incomplete and Make recommended change.
should probably be expanded to
indicate that these are really to be
treated as standards. Suggest:
"Request for Comment (RFC): A
document at one stage of the IETF
standardization process.
Documents that are RFCs are the
final draft of a specification intended
to be approved as a standard or
permanent document and are usually
treated by industry as equivalent to a
standard. accept
Brocade-013 E 11 3.3.24 The English language word Make recommended change.
"comprised" is misused often enough
that it should probably be avoided. I
propose the definition be rewritten to
read. "A contiguously- or virtually-
concatenated signal group (see
T1.105-2001) made up of one or
more standardized
SONET/SDH/OTN/PDH
synchronous transport signals."
Brocade-014 T 11 3.3.26 Research and provide PW Make recommended change.
definitions as per editor's note. accept
Brocade-015 E 11 3.4 The paragraph about ISO convention Make recommended change.
numbering is probably not used in
this document and may be dropped.
If there are numbers with either
decimal points or large number
groupings, we should be careful that
they do follow the conventions and
that the paragraph not be deleted.
Brocade-016 E 12 3.5.1 "FCIP" appears in both the general Make recommended change.
and the FC-BB_IP acronyms. It
should be deleted from clause 3.5.2.
Brocade-017 E 13 3.6 The concatenation symbol does not Make recommended change.
appear to be used in this document,
at least not as a two-part bar symbol.
If that is indeed true, the symbol and
clause 3.6 should be deleted.
Brocade-018 E 13 3.7 The following keywords are not used Make recommended change.
in this document (and are fairly rare
in other documents) and should be
deleted.
"expected" is used often, but in its
ordinary English meaning and not as
a keyword. It should be deleted from
3.7.1.
"mandatory" is used only in defining
"shall" and is used in its ordinary
English meaning, not as a keyword.
It should be deleted from 3.7.4.
Brocade-019 E 73 6.4.7 The word "can" is used. "can Make recommended change.
transport" should be replaced with "is
able to transport".
Brocade-020 E 76 6.4.10.2 To avoid the word "can" and to Make recommended change.
correct the conjugation of the verb
"prevent" the last sentence should
be rewritten as "This ensures that
each FC frame may be
decompressed independently of any
other and prevents errors in one
frame from causing decompression
errors in any subsequent frames that
the receiver decompresses."
Brocade-021 T 15 4.1 The description of FC-BB_IP is quite
contorted and probably misleading.
The use of FC-BB_IP is designed as
an ISL first, and because of the
definition of B_Ports as a subset of
the E_Port definition, it is also
convenient to use FC-BB_IP for
B_Ports. The second paragraph
badly needs rewriting to more simply
and correctly provide an overview of
the FC-BB_IP distinction. I do not
have proposed wording at this time.
pending editor review
Brocade-022 E several several The word "would" is used. In all Make recommended change.
cases, the verb should be changed
to the transitive. As an example, in
clause 5.6.3.5, "When a TCP
connect request is received and that
request would add a new TCP
connection..." should be changed to
"When a TCP connect request is
received and that request adds a
new TCP connection..."
Brocade-023 E 68 6.4.5 To avoid the word "will", the Make recommended change.
sentence "Only one ELP Exchange
will lead to successful LEM closure
in both Transparent FC-BB devices"
should be rewritten to "Only one of
the ELP Exchanges leads to
successful LEM closure in both
Transparent FC-BB devices".
Brocade-024 E 18 4.3.1 Third paragraph, delete the Make recommended change.
meaningless text "as the case may
be,"
Brocade-025 E 19 4.3.2 Second paragraph, delete comma at Make recommended change.
"making no suppositions, regarding
the".
Brocade-026 E all all Propose disabling hypenation on all Make recommended change.
paragraphs. Automatic hyphenation
yields such anomalies as SO-
c/rNET, FC-c/rBB_GFPT, (re-
c/r)initialization and others.
Brocade-027 T 19 4.3.2 Last paragraph: Is there any reason Make recommended change.
that FC-BB_GFPT devices should
be allowed to NOT support link Dave to send message
speed negotiation? I propose to reflector.
changing "may" to "shall" in the last Reject. See reflector
sentence. feedback.
Brocade-028 E 19 4.3.3 The word "agnostic" is fraught with Make recommended change.
meanings that are outside the
technical scope of this document and
is ill-defined in the technical space. I
would propose that the word
"agnostic" be changed to
"independent of" in both cases it is
used, here in 4.3.3 and also in 4.3.1.
Brocade-029 E 19 4.3.3 "frames and selected set" should be Make recommended change.
"frames and a selected set".
Brocade-030 E 19 4.3.3 "tranport" s/b "transport" Make recommended change.
Brocade-031 T 20 4.4.2.2 The first sentence of the second Make recommended change.
paragraph should be deleted,
because the second and third
sentences indicate the mandatory
behavior of each of the two models.
If this comment is rejected, the "may"
must become a "shall". Editor to review.
Brocade-032 T 20 4.4.2.2 The first sentence of the third Make recommended change.
paragraph should be deleted,
because the second and third
sentences indicate the mandatory
behavior of the two models. Editor to review.
Brocade-033 T 21 4.4.3 This is the first place I noticed it, but Make recommended change.
"Transparent FC-BB" is used freely
without ever having been defined. I
would propose a glossary entry with
the following text be inserted in
clause 3.1:
Transparent FC-BB: The FC-BB-
GFPT and the FC-BB_PW protocols.
Editor to review.
Brocade-034 T 21 4.4.4 Recommend changing "may be used Make recommended change.
for all of these purposes" to "may be
used for FC-BB_PW traffic
management". Otherwise it looks Editor to review. EF
like it can be used for FC-BB_IP and PHB need to be defined
FC-BB-GFPT as well. also.
Brocade-035 T 57 6.2 The first sentence on page 57 Make recommended change.
indicates that the ITU-T standards
referenced in clause 2 define the
transport. In fact, the clause is 2.4.
There is a huge collection of
standards there. Any that are really
interesting (see Brocade 7) should
be explicitly called out here and their
relevance explained. In particular,
the SONET transport is defined by 2
or 3 of these which should be
specifically referenced and the
adaptation level is explained by one
which should be specifically
referenced. Many of the others are
relative to various management
activities and other aspects of
SONET behavior. Those should
continue as deleted by Brocade 7, or
an additional explanatory reference
should be included in 6.2 to indicate
why they are still included.
Editor to review
Brocade-036 T 57 6.2 GFPT frame compression needs a Make recommended change. Accepted, add reference
referenced standard. to sentence.
Brocade-037 T 67 6.4.4 This is merely the first place I noticed Make recommended change.
this question. The words "client-
facing buffer" are used. In a search,
I have discovered that there is no
obvious definition of client, client-
facing, or client-facing buffer
anywhere in the document, although
all three terms are used numerous
times. Two solutions are possible:
a) Define client and client-facing in
both the glossary and the
appropriate model clauses, then
verify that the terms are used in a
manner consistent with those
definitions.
b) Review all uses of the word client
and remove them, replacing them
with a less succinct description of
what is really intended.
This needs to be done in all places
where the word "client" is used. See
also Brocade 38.
Editor to review
Brocade-038 T 67 6.4.4 Suggest rewording Note 11 to: Make recommended change.
"The use of channelized ASFC (see
6.4.6) when VC_RDY flow control
has been negotiated between the
interconnected FC_Ports is not
defined in this standard." This
statement is not required to be a
note and may be included in the
normative text. Editor to review
Brocade-039 T 67 6.4.4 Inbound and Outbound have Make recommended change.
problems similar to those in Brocade
36. I assume that
"outbound/inbound" is related to
each of the transparent FC-BB
interface boxes independently and
that "outbound" means from the
FC_Port in the direction of the WAN
interface, while "inbound" means
from the WAN interface to the
FC_Port. That means that every
relevant ELS or frame is outbound at
the originating end and inbound at
the receiving end. However, that
assumption is not documented. I
propose that "inbound" and
"outbound" be explicitly defined in
the glossary, then used appropriately
in various parts of the model so that
their meaning may be properly
interpreted with respect to the LEM
and other usages. Interestingly
enough, outbound and inbound may
actually be better terms than "client
facing".
Editor to review
Brocade-040 T 68 6.4.5 I thought that I understood what Make recommended change.
"closed" and "open" meant with
respect to LEMs (with closed
meaning not working, and open
meaning established and working).
However, the use of the term
"successfully closed" on page 68
suggests that I have it backwords
and that I should be thinking about
switches and circuits instead of
software terms, such that closed =
"contact made" and operational, and
open ="contact unmade" and non-
operational. If I am confused, it is
likely that other readers may be too.
The terms "closed" and "open"
should be placed in the glossary and
properly defined. All uses of the
word should then be inspected for
consistency with those definitions
and, if inconsistent, should be
corrected or explained with other
terms appropriately. The word
"closure" should also be included in
these corrections and clarifications.
Editor to review
Brocade-041 T 68 Figure 19 The "open/closed" situation should Make recommended change.
be properly verified here, where it
appears that "open" means attempt
to make contact and "successful"
does not say whether "closed" or
"open" was the successful state.
Editor to review
Brocade-042 T 68 Figure 19 The "left hand side" and "right hand
side" descriptions of figure 19 on
page 69 are a bit vague. Would it be
better to denominate the devices as
"A" and "B" or "1" and "2" and then
use that denomination when referring
to them? accept
Brocade-043 T 68 Figure 19 The figures use the term "FC-BB- Make recommended change.
3_GFPT". I believe it should be "FC-
BB_GFPT". In addition, you really
meant to apply this to both
transparent protocols, so maybe they
should be relabeled "Transparent FC-
BB device". Alternatively, the
description, it should be clearly
stated that this is the GFPT example
and that the PW example looks
exactly the same.
accept
Brocade-044 T 67 6.4.5 6.4.5 applies to both transparent FC- Make recommended change.
BB devices, but the examples are all
GFPT examples. The examples
must be either made generic,
separate examples provided for
each, or a statement should be
made that the example is a GFPT
example, but a PW example looks accept, see Brocade-
exactly the same. 044
Brocade-045 T 69 6.4.6 This should be re-organized. 6.4.6 Make recommended change.
should be retitled "Transparent FC-
BB Primitive Signals" and contain
paragraphs 2-4 of 6.4.6.1.
A new 6.4.7 should be entitled
"Transparent FC-BB Flow Control".
6.4.7.1 should contain the text of
6.4.6.2. 6.4.7.2 should contain the
first sentence of the present 6.4.6.1.
accept
Brocade-046 T 70 6.4.6.2 The last paragraph and Note 12 are Make recommended change.
wishy-washy. The text should be
rewritten to simply say:
"Channelized ASFC is outside the
scope of this standard." and note 12
should be deleted. Is there anything
else in that paragraph that should be
saved and that is not obvious from
the simple statement above? accept and fix "see
below"
Brocade-047 T 72 6.4.7 6.4.7 and 6.4.8 should be placed one Make recommended change.
step lower in the hierarchy. The new
6.4.8 (formerly 6.4.7 before
accepting Brocade 44) should be
entitled "Adaptation of FC
information for transparent FC-BB
protocols". Then the present 6.4.7
should be changed to 6.4.8.1 and
the present 6.4.8 should be changed
to 6.4.8.2. accept
Brocade-048 T 73 6.4.7 The word "cut-through" is used as a Make recommended change.
rather odd noun. The offending
sentence should be rewritten from:
"In general, all possible cut-through
(i.e., versus frame store-and-
forward) should be implemented to
minimize overall latency, but with
compression (see table 19), it is
often necessary to buffer at least
one frame for both compression and
decompression." to "Frames should
be transferred directly through the
FC-BB device without intermediate
buffering to minimize overall latency,
except as required for compression
which may require temporary
intermediate storage for the frame
being compressed or
decompressed." accept
Brocade-049 T 74 6.4.8 The word "cut-through" is used as a Make recommended change.
rather odd noun. The offending
sentence should similarly be
rewritten to read "Frames should be
transferred directly through the FC-
BB device without intermediate
buffering to minimize overall latency."
accept
Brocade-050 T 73 6.4.7 Concerning the text "The procedures Make recommended change.
governing ... standard.", that is an
excellent idea. That harkens back to
Brocade 35. If you reference the
corresponding ITU documents, then
according to the rules of standards,
which make the references a part of
the standard, you actually drag these
definitions into the standard, making
the sentence in 6.4.7 incorrect.
Since that sentence should probably
be correct, then Brocade 35 should
be accepted and the ITU references
should neither be mentioned nor
included, except possibly as part of a
bibliography.
Editor to review
Brocade-051 E 74 6.4.8 First sentence: "by transparent Make recommended change.
encapsulating" s/b "by transparently
encapsulating". accept
Brocade-052 E 74 6.4.8 "in-order" should be "in order" Make recommended change.
Brocade-053 E 75 6.4.8 An invalid EOF is described. I Make recommended change.
believe the invalid EOF should be
explicitly specified as EOFa or
EOFni.
Brocade-054 E 75 6.4.10 This should be retitled to FC frame Make recommended change.
compression encoding. A similar
pushdown of the hierarchy should be
performed as in Brocade 46 and a
new clause should be provided to
indicate that FC-BB_PW does not
perform compression.
Brocade-055 T 76 6.4.10.2 Just curiosity, can 8B10B streams as Make recommended change.
short as 2112 bytes get any useful
compression, or is this a pipe Over 2:1 compression is
dream? achieved.
Brocade-056 T 77 Annex A. These codes are used and specified Make recommended change.
for FCIP, but the only other place
they are used is the AAL5 adaptation
layer which is in the FC-BB_SONET
protocol which is not included in the
standard. This begs for the question
as to whether or not the annex
should be included in FC-BB-4 if it is
included in FC-BB-3. Alternatively, it
begs for the question as to why the
FC-BB_SONET definition is not
included in FC-BB-4. I believe there
will be another comment that
requests re-inclusion of FC-
BB_SONET, but if that comment is
rejected, than it may be correct to
also remove this annex.
accept, remove annex A
Brocade-057 T 79 Annex B. I believe that it may be necessary to Make recommended change.
indicate which standards specify the
interoperability features a, b, and c.
Otherwise, it may not be clear
exactly which features are being
discussed. Note that d already has accept, add reference to
that reference. a), b), c)
There seem to be some people
confused about the removal of
SONET from FC-BB-4. In T11 we
usually don't leave active
technologies behind in an older So with this in mind, SONET
standard. This type of thing just should either be obsoleted in
confuses customers, and sends the FC-BB-4, or it should be put Rejected. See
QLogic-001 T Many Many wrong message. back in. Packetlight-023.
Omit all reference to the
header,
Replace the two headers
(BB_Header and
SR_Header) with a single
Figure 20 is not in synch with the last header - FC Encapsulation Editor to review the
Corrigent-Late001 T 71,72 Figure 20 and Table 20 FC over PW IETF draft. Header (4 bytes). PWE3 draft.