Skip to main content

Last Call Review of draft-ietf-teas-rsvp-te-li-lb-03

Request Review of draft-ietf-teas-rsvp-te-li-lb
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-02-18
Requested 2015-02-04
Authors Jie Dong , Mach Chen , Zhenqiang Li , Daniele Ceccarelli
I-D last updated 2015-02-09
Completed reviews Genart Last Call review of -03 by Elwyn B. Davies (diff)
Genart Telechat review of -03 by Elwyn B. Davies (diff)
Opsdir Last Call review of -03 by Menachem Dodge (diff)
Assignment Reviewer Elwyn B. Davies
State Completed
Request Last Call review on draft-ietf-teas-rsvp-te-li-lb by General Area Review Team (Gen-ART) Assigned
Reviewed revision 03 (document currently at 05)
Result Almost ready
Completed 2015-02-09
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Please resolve these comments along with any other Last Call comments
you may receive.

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:

Minor issues:

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:


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 


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:

   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:


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

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:

  desired loopback is strictly identified
  node at which loopback is desired is a strict hop in the explicit route
  it provides strict identification
  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).