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

["Malis, Andrew G \(Andy\)" <[e-mail]>]

Sasha,

Many thanks. We'll wait until the end of IETF last call and then take
action as directed by the ADs, who may have review comments of their own,
as well as the rest of the IESG.

Cheers,
Andy

On 6/14/2012 14:23 , "Alexander Vainshtein"
<[e-mail]> wrote:

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.