[PWE3] comments on draft-ietf-pwe3-fc-encap-09

[Stewart Bryant <[e-mail]>]

LC for this document finished some time ago.

This document is pretty well there, but does need
another pass to address the issues I highlight.

To provide clarification about a couple of them.

You need to make it much clearer earlier in the text
why you need a new method of running FC over MPLS, since
I am sure some reviewer will cite RFC3821 over MPLS as
a viable solution to FC over MPLS. You do get there, but
not before the reviewer will have asked themselves the
question. You really need to address this up front. You
can also point to the work on MPLS-TP to further
enhance your case, since this needs to work without
IP in the data-plane.

You also need to address the statement about the
about a lossless PSN path, since there is no such thing
and the statement will get pounced on.

Mostly the rest is minor stuff such as nits
incorrect references and references needed.

I don't think these needs another LC, but it does need
another version.

- Stewart

 
 
     Encapsulation Methods for Transport of Fibre Channel frames 
                          Over MPLS Networks
                   draft-ietf-pwe3-fc-encap-09.txt
 
 

 
Abstract
   
   A Fibre Channel pseudowire (PW) is used to carry Fibre Channel frames
   over an MPLS network. This enables service providers to offer
   "emulated" Fibre Channel services over existing MPLS networks.
SB> This comment applies here and in the intro.
SB> You can run RFC3821 over MPLS, so you need to add some
SB> small amount of text saying why the additional mode is
SB> needed.
   This
   document specifies the encapsulation of Fibre Channel PDUs within a
   pseudowire. It also specifies the common procedures for using a PW to
   provide a Fibre Channel service. The mechanisms controlling the
   reliable transport of Fibre Channel PW over MPLS networks are
   specified in a companion document [FC-flow].
   

 
1. Introduction
   
   As metro transport networks migrate towards a packet-oriented network
   infrastructure, the PSN is being extended in order to allow all
   services to be transported over a common network infrastructure. This
   has been accomplished for services such as Ethernet [RFC4448], Frame
   Relay [RFC4619], ATM [RFC4717] and SONET/SDH [RFC4842] services.
   Another such service, which has yet to be addressed, is the transport
   of Fibre Channel (FC) frames over the PSN. This will allow network
   service providers to transparently carry FC services over the packet-
   oriented network, along with the aforementioned data and TDM
   services.
SB> See above WRT why we need the new mode
   
 
   
   FC/IP, as described in [RFC3821] and [FC-BB], 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 a pure IP network.
   
   Fibre Channel pseusowire (FC PW) is being proposed to provide a
   method for transporting FC frames over an MPLS network.
SB> Again you can do this with the above method
 
   
   FC PW complements the currently available standardized methods for
   transporting FC frames over a PSN. Specifically, FC/IP addresses
   "only the requirements necessary to properly utilize a pure IP
   network as a conduit for FC Frames", whereas FC PW addresses the
   requirements necessary to transport FC over an MPLS PSN. An example
   of such a network might be a 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 PW is that it will enable the extension of FC
   applications to the carrier space.  

SB> You eventually get to the point.
SB> I would restructure the intro so it's clear up front
SB> why you need a new way to carry FC over MPLS.
 
   The following sections describe some of the key carrier requirements
   for transporting FC frames over an MPLS PSN.


    
1.1. Transparency 
      
   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 PW
   defines a port-mode FC encapsulation into a PW.
SB> The above is not clear. It's probably that I am unfamiliar
SB> with FC, but then most of the next stage reviewers will be
SB> similarly unfamiliar.

This requires the
   creation of an FC pseudowire emulating an 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 PSN from
   both the FC Fabric and the operator's point of view.

SB> OK - I get this, but it took a lot more thinking about
SB> than it should have, could you look at rewording/rewording
SB> the section to provide more clarity.
   

   
1.3. Traffic Engineering 
      
  
   FC PW defines the mapping of FC frames into a PW, implicitly assuming
   the use of MPLS-TE for the explicit provisioning of an FC PW over the
   MPLS PSN. This enables the operator to guarantee the performance and
   availability of the emulated FC link. 

SB> You use MPLS-TE to provision the LSP, not the PW.


   
   FC requires a reliable transmission mechanism between FC entities. 
   This implicitly assumes a lossless media with high availability.
   This, however, cannot always be guaranteed in best effort networks
   where FC frames are at times transported over sub-optimal paths.
   Bearing this in mind, FC PW relies on MPLS-TE to create an emulated
   FC link over a packet-oriented network, effectively enabling network
   operators to establish an explicit path to enhance frame transmission
   performance.

SB> First you just said you need TE
SB> Second TE will not give you a lossless path.
SB> TE gives you b/w reservation, a defined path, FRR, which
SB> are useful to you, but not lossless path.
SB> I think the point that you need to make is that TE
SB> is a better appoximation to a lossless math than
SB> conventional hop-by-hop routing and that this appox
SB> is a sufficient approx to the required lossless
SB> service to provide a satisfactor emulation of such
SB> a path for these purposes.
   
   
2. Reference Model
   
   FC PW allows FC Protocol Data Units (PDUs) to be carried over an MPLS
   network. In addressing the issues associated with carrying a FC PDU
   over an MPLS network, this document assumes that a pseudowire has
   been set up by some means outside of the scope of this document. This
   MAY be achieved via static provisioning, or using the signaling
   protocol as defined in [RFC4447].

SB> I don't like the out of scope bit above - particularly
SB> as you describe new RFC4447 types.
SB> Surely you simply need to say the PW may be provisioned
SB> statically, or through signaling as described in RFC4447.

   FC PW emulates a single FC link between exactly two endpoints. This
SB> A FW PW....
   document specifies the emulated PW encapsulation for FC.
   
   Figure 1 describes the reference models which are derived from
   [RFC3985] to support the FC PW emulated services.
   
   For the purpose of the discussion in this document PE1 will be
   defined as the ingress router, and PE2 as the egress router. A layer
   2 PDU will be received at PE1, encapsulated at PE1, transported,
   decapsulated at PE2, and transmitted out on the attachment circuit of
   PE2.

SB>Presumably you mean an FC PDU, or an FC L2 PDU?
 

3. Encapsulation
   
   This specification provides port to port transport of FC encapsulated
   traffic. The following FC connections (as specified in [FC-BB]) are
   supported over the MPLS network:
       - N-Port to N-Port
       - N-Port to F-Port
       - E-Port to E-Port
   
   FC Primitive Signals and FC-Port Login handling by the NSP function
   within the PE is defined in [FC-BB].

SB> You need to give the reader an idea what an N-Port and an E-Port is.

   
  
3.3. Mapping of FC traffic to PW PDU
   

   
                           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
      +---------------------------------------------------------------+
      |                    FC PW Control Word                         |
      +---------------------------------------------------------------+
      |                  FC Encapsulation Header                      |
      +---------------+-----------------------------------------------+
      |   SOF Code    |                   Reserved                    |
      +---------------+-----------------------------------------------+
      |                                                               |
      +-----                      FC Frame                        ----+
      |                                                               |
      +---------------------------------------------------------------+
      |                              CRC                              |
      +---------------+-----------------------------------------------+
      |   EOF Code    |                   Reserved                    |
      +---------------+-----------------------------------------------+

SB> Where is it defined how to calc the CRC and what it covers?
   
          Figure 4 - FC frame encapsulation within PW PDU
    

 
   
 
   
4. Signaling of FC Pseudowires
   
   [PWE3-CONTROL] specifies the use of the MPLS Label Distribution
   Protocol, LDP, as a protocol for setting up and maintaining
   pseudowires. This section describes the use of specific fields and
   error codes used to control FC PW.
   
   The PW Type field in the PWid FEC element and PW generalized ID FEC
   elements MUST be set to "FC Port Mode" as requested in section 8
   below.

SB> I think that it is section 7
   
   
4.1. Interface Parameters for FC PW
   
4.1.1. SR Poll Timeout (T1)
   
   The Selective Retransmission (SR) Poll Timeout (Parameter ID = TBA by
   IANA) is defined in section 6.3.5. The parameter length is 4 bytes.
   The parameter value indicates the poll timeout in units of 1
   millisecond.

SB> That must be section 6.3.5 of the other document
SB> Same comment for T2, N2, k in sections below.
SB>
 

SB> Please run the verbose version of id-nits and make sure that all
SB> issue are not-applicable or are addressed.