[RTG-DIR] RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt

[Alexander Vainshtein <[e-mail]>]

Hello,
I have been selected as the Routing Directorate reviewer 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-pwe3-cbit-negotiation-03.txt
Reviewer:   Alexander ("Sasha") Vainshtein
Review Date:   13.06.12
IETF LC End date:  15.06.12
Intended Status:  Standards Track 


SUMMARY:

I think that the document is generally in good shape and almost ready for publication. 
However, I have some minor technical concerns as well as some editorial ones which, IMHO, should be resolved before publication.

MAJOR ISSUES:  None

MINOR ISSUES:

Technical:

 The actual C-bit negotiation protocol (extension of what has been defined in RFC 4447) is presented in the document 3 (three) times:

 -  In Section 3, items i) to iii) and the paragraph immediately following these items. This text uses the IETF capitalized requirement level terms (MUST) and hence looks like the normative definition of the protocol

 -   In the same Section, items 1 to 5. This text refers to an (IMHO not very informative) Figure 1 but does not contain the IETF capitalized requirement level terms. 

 - In Appendix A. This Appendix contains a block diagram of the C-bit negotiation procedure that follows/illustrates the text in items 1) - 7) of Section 3.

  The difference between the presumably normative definition and two others is that the first one explicitly states:  "Local PE MUST send a label withdraw message to remote PE if it has previously sent a label mapping, and wait until receiving a label release from the remote PE".  
 (Note: "Local PE" in the document is the PE that has changed configuration of CW usage (in this case, from NOT PREFERRED to PREFERRED.)

 The two other fragments do not mention waiting for the label release message from the remote PE, i.e. are not fully consistent with the normative one.

 My interpretation of the LDP procedures as per RFC 5036 is that an LSR that sends a label withdraw message MUST wait for the acknowledging    label release message from the peer, i.e. the presumed normative definition is correct. And in any case I think that all the all the descriptions of the protocol (texts, block diagrams etc.) must be fully consistent.

I also suggest to clarify whether sending the label release message by the local PE above should wait for the label release message from the remote PE if label withdraw message has been sent.  I expect that, upon receiving the label withdraw message from the local PE, the remote one, in addition to acknowledging it with a label release message would also immediately send its own label withdraw message to the local PE which would then, in its turn, send label release message back.

Editorial:

 1. With regard to multi-segment PWs, the draft says that "the (label) request message MUST be processed in ordered mode". It is not clear to me whether this refers to ordered label distribution mode of LDP as defined in RFC 5036, or to something else. At the same time, the procedure defined in the draft is compliant with the common PW label distribution procedures as defined in RFC 6073, so I suggest to consider referencing RFC 6073 (there is no such reference in the draft) instead of using a potentially misleading term. I also wonder if this draft should not be considered as updating RFC 6073 in addition to updating RFC 4447.

 2. As mentioned above, there are two text fragments defining the new C-bit negotiation procedure in the draft. I suggest to consider merging them into a single text that consistently uses the IETF capitalized terms for requirement levels while avoiding such vague terms as "could"  (e.g., " PE2 could wait for PE1 label  binding before sending its label binding with C-bit set"). Having a single text fragment that defines the procedure would also reduce the potential for inconsistencies.

 3. The text, as written, does not clearly distinguish between the PW control word (as a field in the packet) and the PW control word *use* in a PW instance. In most cases this is not a problem, since the draft is all about the CW use. However, there are several cases when this may result in misinterpretation, e.g. (the next two items are copy and paste quotes from the draft):

 -    When the peer PE successfully processed the label withdraw and label release, and removed the remote label binding, it MUST reset its local control word with the configured one... 

 - When Local PE changes its control word from PREFERRED to NOT PREFERRED...

(Please note also that *preferred* PW control word is defined in RFC 4385, but the meaning is completely different from one implied here).

I suggest to consider clarifying that these (and possibly some other) fragments refer to the PW CW usage and not to format or content of the CW. There is clearly more than one way to do that. IMHO and FWIW the most unambiguous one would be to define the relevant state variables of the PW end points (configured, transmitted and received C-bit) and to use them in the definition of the procedure, but this is definitely for the authors to decide.

Nits:  None found by the IETF draft checker.
 
Regards,
     Sasha
This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.