Subject: [PWE3] draft-ietf-pwe3-fc-encap-07 - mostly editorials

From: Stewart Bryant <[email-masked]>
Date: Sat, 29 Mar 2008 00:13:48 +0000

I have just re-read draft-ietf-pwe3-fc-encap-07.txt 
<http://tools.ietf.org/html/draft-ietf-pwe3-fc-encap-07.txt>

Most of this is just editorial.

I am concerned that this draft does not use rigorously
consistent terms through out the document. We need to make
sure we have a single name through out for this PW and
we may want to change the proposed name in the IANA text
to align with that term.

I did not go word by word through section 6.2 and section
6.3 to verify the protocol retransmission protocol.

Has anyone other than authors done a word by word
verification of these two sections?

- Stewart

               2. Introduction
                   
                 ..... One such method is FC over MPLS (FC/MPLS), which 
provides
                  an alternative to FC/IP, as well as to the various 
interconnect
                  technologies described as part of [FC-BB].

I think that you use FC/IP before you define the term

                  This section focuses on the applicability of methods 
and procedures
                  to encapsulate FC over MPLS, specifically those which 
are relevant to
"FC over an MPLS PSN" or "FC over and MPLS enabled IP PSN"
 
                  FC/MPLS provides a method for transporting FC frames 
over an MPLS-
                  based transport network, such as a packet-oriented 
transport network,
                  in this document also referred to simply as PSN.

Do you mean "MPLS based transport network" - that now has a special meaning

Note that you really should not hence use PSN as in PWE3 this is 
commonly used
to mean IP or MPLS

                  It defines the
                  encapsulation of FC Protocol Data Units (PDU) into an 
MPLS
                  pseudowire,

It is not an MPLS PW - that is something entirely different (the term 
means a
PW that carries another PW and may well be defined in PWE3 in the near 
future)
- this is an pseudowire that runs over an MPLS PSN.

                  as well as procedures for using PW encapsulation to
                  enable FC services such as SAN extension and disaster 
recovery over a
                  PSN. FC/IP, as described in [RFC3821], defines the 
mechanisms that
                  allow the interconnection of islands of FC SANs over 
IP Networks. It
                  provides a method for encapsulating FC frames 
employing FC Frame
                  Encapsulation, as defined in [RFC3643], and addresses 
specific FC
                  concerns related to tunneling FC over an IP-based network.

MPLS is normally an IP based network. Maybe you should say something 
like "pure IP network".
                   
                  FC/MPLS is being proposed to complement the currently 
available
                  standardized methods for transporting FC frames over a 
PSN.
Here you do mean PSN
 
                  Specifically, FC/IP addresses ìonly the requirements 
necessary to
                  properly utilize an IP network as a conduit for FC 
Framesî, whereas
                  FC/MPLS addresses the requirements necessary to 
transport FC over an
                  MPLS-based PSN.
I guess that by now you get my point about MPLS being an extension to
an IP network

                  An example of such a network might be a L2 PSN or a
Calling up L2 PSN will lead to concerns that we do not specify L2 PSNs 
in the IETF
 
                  packet-oriented multi-service transport network, where 
MPLS is used
                  as the universal method for encapsulating and 
transporting all type
                  of services, including mission critical FC 
applications as well as
                  other TDM and data services. Hence, a key benefit of 
FC/MPLS is that
                  it will enable the extension of FC applications to the 
carrier
                  transport space.
Maybe you should delete the para?  
                   
                  The following sections describe some of the key 
carrier requirements
                  for transporting FC frames over an MPLS-based PSN.
                    
               2.1. Transparency  
                      
                  Transparent emulation of an FC link is a key 
requirement for
                  transporting FC frames over a carrierís transport network.
Again do you mean transport network - you use the terms lots of times
 
                  Conventionally, the coupling (or pairing) of FC 
entities with those
                  pertaining to specific encapsulation methods requires 
the protocol-
                  specific entity to terminate the FC Entity. This, in 
most cases,
                  would require global address synchronization to be 
performed by the
                  operator. In addressing this requirement, and 
providing full
                  transparency, FC/MPLS defines a port-mode FC 
encapsulation into an
                  MPLS PW.
Again not an MPLS PW

                  This requires the creation of an FC pseudo-wire 
emulating an
pseudowire not pseudo-wire

                  FC Link between two FC ports, appearing 
architecturally as being
                  wired to those ports, similar to the approach defined 
for FC over
                  GFPT in [FC-BB]. This results in transparent 
forwarding of FC frames
                  over the MPLS-based PSN from both the FC Fabric and 
the operatorís
                  point of view.
It's really an MPLS PSN, not an MPLS-based PSN - this applies lots of 
places.

               2.3. Traffic Engineering  
                       
                  effectively
                  enabling network operators to establish an explicit 
path over which
                  reliable frame forwarding can be guaranteed.
Your protocol makes the FC transfer reliable, but even with MPLS-TE the path
is not reliable.
     
               2.4. Security  
                   
                  FC/MPLS is designed to transparently support the 
forwarding of FC
                  frames received from the local FC port, into a 
pre-established FC PW,
                  thus effectively making the FC/MPLS emulated path less 
susceptible to
                  attacks when compared to, e.g., IP public networks.

If you do not need this sub-section - I would delete it - you have a 
security
section later where you should discuss the security issues. MPLS is 
probably not
as secure as for example an IPsec network against snooping on the data which
might be more beneficial to an attacker that  disrupting it.

               3. Reference Model
                   
                  A Fibre Channel pseudowire (PW) allows FC Protocol 
Data Units (PDUs)
                  to be carried over an MPLS network.
You need to align the terminology with the earlier section.

                   
               4. Encapsulation
                   
               4.1. The Control Word
                   
                  The Generic PW Control Word, as defined in "PWE3 
Control Word"
                  [RFC4385] MUST be used for FC PW to facilitate the 
transport of short
                  packets, and convey the flag bit defined below.

FC/MPLS PW? Also used later in the document.
What do you mean by short packets?
               
                                       1                   
2                   3
                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 
7 8 9 0 1
                  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |0 0 0 0| PT  |A|0 0|  Length   |     Sequence 
Number           |
                  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   
                   Figure 3 - Control Word structure for the one-to-one 
mapping mode
                   
                  The first three bits of the Flags field are not used 
and MUST be set
                  to 0 by the ingress PE, and MUST be ignored by the 
egress PE. There
                  is a single flag bit in use for FC PW, as specified 
below.

Do you mean the first four bits, and surely you use 4 flag bits?
                   
                  PT ñ Payload Type indication. This field identifies 
the payload type  
                       carried within the PW PDU. The following types 
are defined:
                       PT = 0: FC data frame.
                       PT = 1: FC login frame.
                       PT = 2: FC Primitive Sequence.
                       PT = 6: FC Control Frame (refer to [FC-BB]).
                   
                  A ñ The Address bit identifies the frame as either a 
command or a  
                      response. This field is used in conjunction with 
the Poll Bit of  
                      the Selective Retransmission protocol. Messages 
containing
                      commands MUST set this bit to 1. Messages 
containing responses  
                      MUST set this bit to 0. This bit MUST be set to 0 
for FC Control  
                      frames as indicated by Payload Type value of 6. 
Further details  
                      regarding the use of this flag are provided in 
section 6.
For my curiosity why is it an A(dress) bit and not a C(ommand) bit?
                   
               4.2. MTU Requirements
                   
                  The PSN MUST be able to transport the largest Fibre 
Channel
                  encapsulation frame, including the overhead associated 
with the
                  tunneling protocol. Fragmentation, described in 
[RFC4623], SHALL NOT
                  be used for FC PW, therefore the network MUST be 
configured with a
                  minimum MTU that is sufficient to transport the 
largest encapsulation
                  frame.

Is there a upper bound for this so that a PSN engineer who does not know 
FC knows
how to set the PSN  MTU?
                
               4.3. Mapping of FC traffic to PW PDU  
                   
                  Each FC frame is mapped to a PW PDU, including the 
Start Of Frame
                  (SOF) delimiter, frame header, CRC field and the End 
Of Frame (EOF)
                  delimiter, as shown in figure 4. SOF and EOF frame 
delimiters are
                  encoded as specified in [FC-BB].
Is the CRC defined there also?
                                      
                  FC Primitive Sequences are encapsulated in a PW PDU 
containing the
                  encoded K28.5 character, followed by the encoded 3 
data characters,
K28.5 needs a reference, so does ordered sets (below)
                  as shown below. A PW PDU may contain one or more FC 
encoded ordered
                  sets.

                  FC Control frames are transported over the PW, by 
encapsulating each
                  frame in a PW PDU. The FC header MUST contain a FC PW 
Control Word,
I think you mean the FC/MPLS PW header must....
                  with PT = 6

               5.1.1. SR Poll Timeout (T1)
               5.1.2. SR Response Timeout (T2)                    
               5.1.3. SR Poll Retries (N2)
               5.1.4. SR Window Size (k)
You saw my questions on these in the IANA note about the length definitions.

               6.1.2. Data Sender Protocol  
                   
                  In case the transmission rate is equal to CIR for a 
period greater
                  than RTT, and transmitted frames are still lost in 
transit, as
                  indicated to the sender by receiving SREJ frames, the 
sender SHOULD
                  signal PW status of ìBandwidth resources unavailableî 
(refer to IANA
                  registry of STATUS CODE NAME SPACE) as specified in 
[RFC4447], and
                  SHOULD shut the PW down for a duration of at least 
R_A_TOV, as
                  described in Section 6.5 of [RFC3985]. If the PW has 
been set up
                  using the PWE3 control protocol [RFC4447], the regular 
PW teardown
                  procedures SHOULD be used. After this period the PW 
MAY be restarted.

See my comment to the list
 
                  If within R_A_TOV after restarting the PW congestion 
is encountered
Where is R_A_TOV defined?

               7. Security Considerations
                   
                  This document specifies only encapsulations, and not 
the protocols
                  used to carry the encapsulated packets across the PSN. 
Each such
                  protocol may have its own set of security issues 
[RFC4447] [RFC3985],
                  but those issues are not affected by the 
encapsulations specified
                  herein. Note that the security of the emulated service 
will only be
                  as good as the security of the PSN.

I think that this is going to need lot more work to get it approved.

               8. Applicability Statement
                   
                  FC PW allows the transport of point-to-point Fibre 
Channel links
I think that you mean FC/MPLS
                  while saving PSN bandwidth.
                   
                  - The pair of CE devices operates as if they were 
connected by an
                    emulated FC link. In particular they react to 
Primitive Sequences
                    on their local ACs in the standard way.
Do you mean emulated FC link, or FC link - you are designing an emulator 
here.
 
                  - The PSN carries only FC data frames and a single 
copy of a
Surely the FC/MPLS PW carries the FC data frames, and the PSN carries the
                    Primitive Sequence. Idle Primitive Signals 
encountered between FC
                    data frames, and long streams of the same Primitive 
Sequence are
                    suppressed over the PW thus saving the BW.
                   
                  FC PW traffic can traverse controlled (i.e., providing 
committed
                  information rate for the service) networks and 
uncontrolled (i.e.,
                  providing excess information rate for the service) 
networks. In case
                  of FC PW traversing an uncontrolled network, it SHOULD 
provide TCP-
                  friendly behavior under network congestion (refer to 
Congestion
                  Control section for further details).
Why SHOULD and not MUST?
                    .
 
========

_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: [email-masked]
Date: Fri, 28 Mar 2008 21:53:41 -0400

One comment:
>                    
>                   FC PW traffic can traverse controlled (i.e.,
providing committed
uncontrolled (i.e.,
networks. In case
>                   of FC PW traversing an uncontrolled network, it
SHOULD provide TCP-
Congestion
>                   Control section for further details).

I think that's going to need to be a MUST, congestion control needs to
be a MUST, even
for controlled networks (even if EIR = CIR, the congestion control
mechanisms are
what look for lost frames indicating that CIR cannot be maintained), and
the shutdown
procedures when CIR cannot be retained also need to be a MUST.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3