Subject: [PWE3] RtgDir review: draft-ietf-pwer-fc-encap-14.txt

From: Yaakov Stein <[email-masked]>
Date: Sun, 20 Feb 2011 14:23:32 +0000

To:
*        [email-masked]<mailto:[email-masked]>

  *   [email-masked]<mailto:[email-masked]>
Cc:
*        [email-masked]<mailto:[email-masked]>

  *   [email-masked]<mailto:[email-masked]>
Subject:
*        RtgDir review: draft-ietf-pwer-fc-encap-14.txt

Hello,
We (Yaakov and Sasha) have been selected as the Routing Directorate reviewers for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html
Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.
Document: draft-ietf-pwer-fc-encap-14.txt
Reviewers: Alexander ("Sasha") Vainshtein and Yaakov (Jonathan) Stein
Review Date:  2011/02/20
IETF LC End Date:
Intended Status: Standard Track

Summary:
We have some concerns about this document that we believe need to be addressed before publication.
Comments:

  1.  The two of us (Sasha and Yaakov) have decided to write a single joint review, in order to reduce contradictory recommendations.
  2.  In order to further reduce turnaround time, we have taken the slightly unorthodox approach of holding direct talks with one of the draft editors (David Black). As will be seen in the following, this approach has proven to be highly productive.
  3.  The draft includes multiple references to Fibre Channel (FC) standards, which hinder comprehension for those not expert in the technology. The status of these references is also somewhat problematic:
     *   [FC-BB-6] (Normative) triggers circular normative referencing between IETF and T11:
*        It is currently a T11 working document waiting for approval.
*        It can only be accessed by the interested IETF participants by sending a direct request to David Black, who is both co-editor of this draft and T11's official liaison to the IETF.
*        It uses this draft as a Normative reference and hence will be approved by T11 only after an RFC number has been assigned to this draft.
*        As this is not intended to be a downref, the responsible AD will need to explain the situation to the RFC Editor once the draft is approved for publication.

     *   [FC-FS-2] (Normative) is an approved T11 standard that can be accessed by interested IETF participants by sending a request to David Black ([email-masked]<mailto:[email-masked]>) in his official capacity as T11 liaison to IETF.
     *   [FC-SP]  is listed as a Normative reference. However, it describes the FC  Security Protocol that is, according to the draft, transparent to the FC PW. Hence it makes sense to redefine it as an Informational reference.
     *   All these references are flagged as warnings by the latest IETF nits tool.

4.    We would like to thank the authors for resolving in version 14 many issues that we had raised in the past regarding the K-codes, timing constraints, and specifically the operation of the NSP.

Major Issues:

1.    The draft refers in several places to the "reliable transport... provided by MPLS-TE/MPLS-TP". This terminology is inappropriate in the IETF where "reliable" is used in a completely different sense, especially as the draft compares the FC PW to transport of FC over TCP/IP that has been defined in RFC 3821.  The problem is aggravated by the fact that the common PWE3 technique that allows detection of lost and/or reordered PW packets (sequencing) is intentionally disabled (in Section 3.1 the draft states that the sequence number MUST be set to 0 by the sender and MUST be ignored by the receiver). We have discussed this point with the one of the draft editors and obtained agreement that the usage of the term "reliable" in this context is inappropriate. We highly recommend that the authors modify the present text by replacing the term "reliable" with the actual expectations regarding delivery of the FC PW packets (low drop rate, low chance of reordering). We also suggest adding text on the handling of lost, re-ordered and duplicate FC PW packets to the Applicability section.

2.    The draft proposes usage of "sub-rating" of FC Primitive Sequences, without specifying acceptable sub-rating factors and without explaining whether these values require coordination between the two PEs. One of the document editors has assured us that coordination is not required, but that there are limitations on sub-rating in order to avoid timeouts. We strongly suggest that the authors add some text explaining this, providing guidance regarding suitable sub-rating values.

3.    The draft requests IANA to reserve four Interface Parameter sub-TLV values for functionality that has been dropped from the draft after having been rejected by the PWE3 WG, in order to accommodate the possibility of this functionality being reintroduced at some future time. This request would be justified if there were multiple deployed pre-standard implementations supporting this functionality (as was the case for the "Martini mode" of the Frame Relay PWs). As far as we know, there is at most only one such pre-standard implementation. We suggest that the responsible AD decide on the proper course of action.
Minor Issues:

  1.  In contrast to the rest of the PWE3 documents, a dedicated Native Service Processor (NSP) block is mandatory for implementing (and even understanding) the draft. We would like to thank the authors for the much improved explanation of this NSP in the present version. However, some of the functionality of the NSP operation is similar to functions that are not considered NSP functions in other PWE3 encapsulation documents e.g.:
     *   Suppression of idle codes (in contrast, suppression of idle ATM cells is not considered as an NSP function in RFC 4717)
     *   Removal of 8b/10b encoding (in contrast, the same operation is not considered as an NSP function in RFC 4448).
We believe that a note should be added clarifying this point.

2.    The draft refers to MTU issues associated with the FC PW, but does not state whether the MTU interface parameter sub-TLV MUST, SHOULD, MAY, ..., or MUST NOT be included in the Label Mapping message during the FC PW setup. Since all FC interfaces have the same MTU, this parameter is not really needed during the setup. We suggest that the authors explicitly indicate that the Interface MTU parameter MUST NOT appear in the FC PW setup protocol exchange. (Aside: This is based on experience with RFC 5287 where the fact that it was not specified that the Interface MTU parameter MUST NOT appear in the TDM PW setup eventually led to interoperability issues). We have sent the authors proposed text to deal with this issue.

3.    The draft defines that the CRC of the FC frames MUST always be included in the PW encapsulation. However, its handling differs from the handling of FCS per RFC 4720; in particular, FC frames received with CRC errors must be transmitted over the PW. It would be nice to explicitly note this difference, and for the signaling procedure to explicitly specify non-usage of the FCS Retention Indicator Interface Parameter sub-TLV. We have sent the authors proposed text to deal with this issue.

Regards,
     Y(J)S and Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 20 Feb 2011 18:43:22 +0200

Hi all,
I confirm that the text of the review sent by Yaakov represents our common position.
I hope that this unorthodox approach to reviewing the draft is acceptable.

Regards,
     Sasha

From: Yaakov Stein [mailto:[email-masked]]
Sent: Sunday, February 20, 2011 4:24 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Alexander Vainshtein
Subject: RtgDir review: draft-ietf-pwer-fc-encap-14.txt

To:

Hello,

Summary:

Major Issues:

Regards,
     Y(J)S and Sasha