Last Call Review of draft-ietf-teas-rsvp-te-srlg-collect-02

Request Review of draft-ietf-teas-rsvp-te-srlg-collect
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-09-24
Requested 2015-09-11
Authors Fatai Zhang, Oscar de Dios, Matt Hartley, Zafar Ali, Cyril Margaria
Draft last updated 2015-09-21
Completed reviews Genart Last Call review of -02 by Elwyn Davies (diff)
Genart Last Call review of -06 by Elwyn Davies (diff)
Secdir Last Call review of -02 by Paul Hoffman (diff)
Opsdir Last Call review of -02 by Niclas Comstedt (diff)
Opsdir Last Call review of -04 by Niclas Comstedt (diff)
Assignment Reviewer Elwyn Davies 
State Completed
Review review-ietf-teas-rsvp-te-srlg-collect-02-genart-lc-davies-2015-09-21
Reviewed rev. 02 (document currently at 08)
Review result Not Ready
Review completed: 2015-09-21


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-teas-rsvp-te-srlg-collect-02.txt
Reviewer: Elwyn Davies
Review Date: 2015/09/13
IETF LC End Date: 2015/09/24
IESG Telechat date: (if known) -


Not ready for publication.  The main problem appears to be that the use 

of SRLG ID RRO sub-objects in Resv messages seems to be an 

afterthought.  It needs to be covered in the introduction.  It is also 

not clear how nodes are informed that SRLG information needs to be added 

to Resv messages.  I am also concerned that the ordering constraints 

imposed on RRO sub-objects by various different standards (at least this 

one and RFC 7571 - there may be others that I am not aware of) may 

become overly complex and potentially mutually incompatible.  When I 

reviewed the draft that subsequently became RFC 7571 earlier this year 

there were already internal issues with sub-object ordering that had to 

be sorted out - checking that ordering constraints do not result in a 

deadly embrace could get quite complicated if more specifications add to 

the RRO stack.

Major issues:

What is an SRLG ID?  OK, it is a 4 octet (opaque) data item. However, 

the specification says nothing about how it might be used to convey the 

SRLG information.  I *guess* that this may be because this is just a 

handy facility that can be used in whatever way an implementation 

chooses - but if so it would good to say this.  Maybe an example of how 

the authors envisage it might be used, maybe in the context of the use 

case in s1.1 would be helpful.


    The SRLG Collection flag is meaningful on a Path message.  If the
    SRLG Collection flag is set to 1, it means that the SRLG information
    SHOULD be reported to the ingress and egress node along the setup of
    the LSP.

I am unclear how the Path message is going to impart SRLG information to 

both ends of the LSP as my understanding of RSVP is that the Path 

message travels only in one direction along the path of the LSP.  ...

Ah, when I read down towards the end of s5.1, it appears that the SRLG 

info may be in Resv messages as well, and might be collected during the 

processing of the Resv message along the (reverse) path. According to 

RFC 3209, the presence of an RRO in the Path message will trigger the 

addition of an RRO to the Resv message, but this does not tell the nodes 

that SRLG information ought to be added. Presumably the SRLG Collection 

flag should be set somewhere in a suitable place in the Resv message 

also.  But where?  The text above says the flag is only meaningful on 

Path messages!!  Maybe the RRO Attributes sub-object might be relevant 


The draft needs to talk about both directions and uni-/bidirectional 

LSPs from an earlier point in the document.

Minor Issues:

s5: RRO Sub-object ordering constraints.  In s4.2, a number of ordering 

constraints are specified indicating where the SRLG info objects should 

be placed in the stack of RRO sub-objects.  Section 5 does not discuss 

what should happen if the receiving node detects that the sub-objects 

don't match the specified ordering constraints.  A more general issue is 

whether there are interactions with ordering constraints from other 

specifications that use RRO sub-objects - for example, RFC 7571 has some 

quite complex ordering constraints.  There is also the following text in 


    o  For Path and Resv messages for a bidirectional LSP, a node SHOULD
       include SRLG sub-objects in the RRO for both the upstream data
       link and the downstream data link from the local node.  In this
       case, the node MUST include the information in the same order for
       both Path messages and Resv messages.  That is, the SRLG sub-
       object for the upstream link is added to the RRO before the SRLG
       sub-object for the downstream link.

It strikes me that using one of the reserved bits in the SRLG sub-object 

to explicitly identify whether a sub-object applies to the upstream or 

downstream direction would make things less error prone and reduce the 

ordering constraint which might get quite complicated as time goes on if 

new RRO sub-objects continue to be added.

Nits/editorial comments:

General: Just checking: does this specification apply to basic MPLS or 

only to the extended Generalized MPLS?  It would be good to be clear 

about the scope up front.

General: Bringing out the IANA temporary allocations at every point 

where they apply in Sections 4.1, 4.2, 5.1  and 8 is undesirable as it 

will have to be edited out by the RFC Editor increasing the scope for 

error.  OK this is not a big risk but it would simplify things if the 

body text had the expected final form and the temporary allocation text 

notes were confined to a special section that was marked for removal by 

the RFC Editor.

General: s/byte/octet/g

Abstract: Probably ought to mention (G)MPLS explicitly and expand TE.

s1, para 1:  It would be good to expand TE explicitly (as Generalized 

MPLS Traffic Engineering) again.

s3: Using RFC 2119 language here is inappropriate - they are 

design/usage issues not testable protocol features.

s4.1, para 1: s/indicate nodes/indicate to nodes/

s4.1 and s4.2, last para in each case: s/The rules of the/The rules for 

the/ (2 places)

s5.1, paras 2 and 3: s/and the SRLG Collection Flag set/with the SRLG 

Collection Flag set/ (2 places)

s5.1, last para: Need to expand FA acronym.

s6.1: It would be useful to repeat the policy configurations mentioned 

in s5 in this section.

s6.2, para 1: s/SRLG ids/SRLG IDs/  [please check that there aren't any 

other cases].