Last Call Review of draft-ietf-teas-rsvp-te-li-lb-03
review-ietf-teas-rsvp-te-li-lb-03-genart-lc-davies-2015-02-09-00

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