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

[Alexander Vainshtein <[e-mail]>]

Lizhong, hi again!

I have read the updated draft, and it looks OK. There just an additional minor comment on the text that deals with  to MS-PWs.


The draft says "When S-PE receives a label request message from a remote PE, it MUST advertise the request message to the other remote PE." The intention is clear, but I suggest to consider changing it to something like "When an S-PE receives a label request message from one of its adjacent PEs (be it S-PE or another T-PE), it MUST send a matching label request message it is other adjacent PE (again, it may be an S-PE or a T-PE)". This modification, if it suits you, would serve two purposes:

-          It would clarify that an S-PE relays Label Request messages from one of its neighbors to the other one, and does not care (indeed, it does not usually know) whether these neighbors are T-PEs or S-PEs

-          It avoids the term "advertise" which, IMHO, does not apply to what label request messages do.

Regards,
     Sasha

From: Alexander Vainshtein
Sent: Thursday, June 14, 2012 6:23 PM
To: 'Lizhong Jin'
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt

Lizhong hi,
Lots of thanks for a prompt response.

Please see some answers inline below (brown italics).

I will read the new version and provide additional comments later, hope this is OK.

Regards,
     Sasha

From: Lizhong Jin [mailto:[e-mail]]
Sent: Thursday, June 14, 2012 12:48 PM
To: Alexander Vainshtein
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt


Hi Sasha,
Thank you very much for the valuable comments. Please see my reply inline below.
I also attached the modified version for your check and reference.

Regards
Lizhong



Alexander Vainshtein <[e-mail]<mailto:[e-mail]>> wrote 2012/06/14 13:23:59:

> 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.
[Lizhong] agree, and we will change the second and third text fragment to reflect this.
[[[Sasha]]] OK.


>
> 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.
[Lizhong] the remote one will not send label withdraw after acknowledging with label release, because "liberal label retention" mode is applied.
The sending label release message by local PE is not necessary to wait for the release from remote. Will clarify this in the draft.
[[[Sasha]]] I am not sure liberal label retention really applies here - IMHO it just says that unused label advertisements received by an NE are retained. And it seems that RFC 447 is not very clear on procedures for tearing down a PW. But as long as you clarify this point, it is not really important for this draft.

>
> 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.
[Lizhong] yes, ordered mode follows ordered label distribution mode in RFC5036. And I agree, referencing RFC6073 would be more clear. And yes, the draft is also updating RFC6073.
[[[Sasha]]] I am not sure ordered label distribution in 5036 really applies here, because my reading of 5036 suggests that it is used (or not used) per LSR.  I suspect that this may be the reason for the authors of 6073 not to mention it but explicitly define the process instead. But, as I have said, the procedure you've specified looks OK.


>
>  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.
[Lizhong] the first text fragment defines the requirement, and the second gives an usecase according to the first text. What if we move the use case to another sub-section, so as to make it more clear?
[[[Sasha]]] I wonder if the second fragment really adds much to the first one (which defines the procedure). But as long as (1) it is clearly specified what is the normative specification and what is the use case, and (b) the use case is fully consistent with the normative specification, it is OK.


>
>  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.
[Lizhong] we will change the "control word" to "use of control word" in the draft, and make it clear.
[[[Sasha]]] Sounds OK.


>
> 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.
>
>

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.