I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: Reviewer: draft-ietf-teas-rsvp-te-li-lb-03.txt Review Date: 2015/02/08 IETF LC End Date: 2015/02/18 IESG Telechat date: (if known) - Summary: Almost ready with a number of nits. As somebody who has very sketchy knowledge of RSVP-TE and GMPLS, I found the discussion of specification of the identity of the loopback node in an ERO to be very confusing. The phrase "strictly identify" doesn't really express what is going on to somebody who is not deeply familiar with the topic. An example of the relevant parts of a PATH message might help if that could be managed. What I think is an unfortunate typo ("mode" instead of "node" in s3.2) sent me off on a wildgoose chase looking for specifications of loopback modes. I am still not absolutely certain that this *is* a typo! Major issues: None Minor issues: None. Nits/editorial comments: General: For the avoidance of doubt for IANA, it would be desirable to identify the five "TBA" values as TBA-1 to TBA-5 wherever they occur. General: s/in ADMIN_STATUS/in the ADMIN_STATUS/ (10 cases) Abstract: s/as control plane/for the control plane/ s1, para 1 and last para: s/in Multiprotocol/in the Multiprotocol/ s1,para 2: s/as control plane/for the control plane, s/e.g./e.g.,/ s1, last para: /For MPLS-TP network/For a network supporting MPLS-TP/ s1, last para: Although the formal definitions of LI and LB are given in the 2 RFCs referenced, it would help with the understanding of this draft to add short explanation, such as: ADD: An LSP that is locked, using LI, is prevented from carrying user data traffic. The LB function can only be applied to an LSP that has been previously locked. s2.1: s?the lock/unlock?the lock/unlock status?, s2.1: RFC 3471 calls ADMIN_STATUS "Administrative Status". RFC3473 uses ADMIN_STATUS but the two terms are never formally linked together. I suggest: s/in ADMIN_STATUS/in the Administrative Status (ADMIN_STATUS) / s3.1, para 1: Technically, the A bit isn't defined in this draft: Suggest: s/bit defined above/bit used as specified above/ s3.2, para 2: Need to expand acronym: ERO s3.2, para 2: OLD: The ingress MUST ensure that the desired loopback mode is strictly identified in the ERO. Am I right that "mode" is a typo? Should it be "node" rather than "mode? I couldn't see anything about "loopback modes" in RFC 5860 or RFC 6371. After much head scratching I came to the conclusion that "node" was the right answer... If not then please explain where modes are defined. Continuing on the basis that the word s/b "node"... I think this would be clearer as follows: NEW The ingress node MUST ensure that the node where loopback is intended to occur is marked as a strict hop (i.e., not a loose hop) in the ERO. s3.2, para 3: the node MUST check that the desired loopback is strictly identified by verifying that the L bit is set to 0 in both the ERO Hop Attributes subobject and the prior subobject. The prior subobject MUST also be checked to ensure that it provides strict identification. What would the prior subobject likely be? Would it be possible to give an example of what the RSVP message would contain in the way of objects and subobjects? This would help with understanding this section. As with the previous comment, the phrase 'strictly identified' is not very clear. Maybe: OLD: desired loopback is strictly identified NEW: node at which loopback is desired is a strict hop in the explicit route OLD: it provides strict identification NEW: it identifies a strict hop in the explicit route s3.2, para 3: Currently, the type value MUST be verified to be less than 32, and for type values 1 and 2 the prefix length MUST be 32 and 128 respectively. It would be better to use the names of the types (1 = IPv4, 2 = IPv6) that would make it clearer why the lengths are as they are specified. Is it possible to explain why the type has to be less than this apparently arbitrary limit of 32? And hence what allocation constraints ought to be applied in the future - this might need a change in the IANA allocation rules that should be specified in this document. s5: In line with "modern" policy, the discussion in para 3 of s5 of draft-ietf-teas-lsp-attribute-ro-01 could be thought of a "Privacy Considerations" rather than strictly Security Considerations. Please consider separating out a privacy discussion and referencing the discussion in draft-ietf-teas-lsp-attribute-ro-01 (which should in turn talk about Privacy Considerations).