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, and sometimes
 on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see

 

​

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir







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-pals-mpls-tp-pw-over-bidir-lsp-06


Reviewer: Daniele Ceccarelli


Review Date: April 25 2016


IETF LC End Date: -


Intended Status: Standard Track







Summary:

 










I have some minor concerns about this document that I think should be resolved before publication.








Comments:










What the drafts is proposing as protocol modification is clear and also the operation section are pretty straighforward. What needs to be improved is the introduction part, which should be reviewed by a native
 English speaker. Also the IANA section should be made clearer. 







Major Issues:










No major issues found







Minor Issues:










Abstract: “In addition, the user traffic may traverse through multiple transport networks.” Maybe is worth elaborating a bit this sentence saying that the extensions defined in this draft apply both to SS-PW
 and MS-PW.




In the abstract it is said that a PW is linked to an LSP but then in the intro it is said that the PW binding is to a tunnel. Can you clarify this? I’d say that it should be linked to a tunnel, right?




Intro:   “PW-to-PSN Tunnel binding has become increasingly common and important in many deployment scenarios”. I guess you mean an automatic binding done via a signaling protocol?




What do you mean with “may traverse through different routes”? I suggest leaving “may traverse multiple networks or domains.




Intro and Figure 1: could be example be made a bit more generic with a network between the PEs? With directly connected PEs it doesn’t seem a realistic and generic enough example.




Intro: suggest removing “As mentioned above”.





 The name of the draft explicitly mentions MPLS-TP but in the rest of the draft there is no mention of it, just the much more general Packet Switching Network term is used.





Section 2:   “This document defines a new optional TLV, PSN Tunnel Binding TLV, to communicate tunnel/LSPs selection and binding requests between PEs. “ The binding request is between PEs? Or between an PW
 and a Tunnel (or LSP?) between two PEs?




Section 2: Strict binding vs Co-routed binding: from the description it seems that the first one is strict and the second one is “loose” (in the sense that the PE can accept the request or not). Don’t both
 apply to co-routed LSPs?




Section 2: ”The terminology "LSP" is  identical to the "LSP tunnel" defined in Section 2.1 of [RFC3209],  which is uniquely identified by the SESSION object together with  SENDER_TEMPLATE (or FILTER_SPEC)
 object that consists of LSP ID and Tunnel endpoint address.” Why is the draft considering only signaled LSPs? Doesn’t it apply also to centrally provisioned ones? (e.g. NMS or SDN).




Section 2.1: “LDP Label Mapping message” missing reference. And why the Type field starts with 1 and 0?







Nits:










Abstract s/




traverse through multiple/




traverse multiple




Introduction: “Pseudowire (PW) Emulation Edge-to-Edge (PWE3)”. I suggest removing (PW), it’s already included into PWE3.




Intro: s/




a bidirectional circuits/




a bidirectional circuit




Intro: suggest rephrasing: “Bidirectional LSPs share fate and simplify the routing of a protection path also consisting of bidirectional   LSPs because working and protection paths have to be disjoint.”




Intro: s/




there are a large number/




there is a large number




Intro:s/to be carried/are carried




Intro:s/there are a number/there is a number




Intro: s/ traffic belongs/traffic belonging




Intro: (suggestion) s/(PE1-P3-PE2)/ (PE2-P3-PE1) since we are speaking about directionality it makes more sense to list the nodes of the path in the reverse direction.




Intro: s/ The similar problems/A similar problem




Intro: s/ won't/does not




Intro: s/ In this document, it introduces/This document introduces




BR


Daniele