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

[Lizhong Jin<[e-mail]>]

> Alexander Vainshtein <[e-mail]> wrote 2012/06/14 
23:41:11:

> 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.
[Lizhong] OK, accept. Thank you.

Lizhong



> 
> Regards,
>      Sasha
> 
> From: Alexander Vainshtein 
> Sent: Thursday, June 14, 2012 6:23 PM
> To: 'Lizhong Jin'
> Cc: [e-mail]; rtg-
> [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]; rtg-
> [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]> 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 ¨C 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.