Last Call Review of draft-ietf-pals-endpoint-fast-protection-04
review-ietf-pals-endpoint-fast-protection-04-opsdir-lc-hares-2016-12-24-00

Request Review of draft-ietf-pals-endpoint-fast-protection
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-12-06
Requested 2016-11-23
Authors Yimin Shen, Rahul Aggarwal, Wim Henderickx, Yuanlong Jiang
Draft last updated 2016-12-24
Completed reviews Genart Last Call review of -04 by Dale Worley (diff)
Secdir Last Call review of -04 by Chris Lonvick (diff)
Opsdir Last Call review of -04 by Susan Hares (diff)
Rtgdir Early review of -00 by Mach Chen (diff)
Rtgdir Early review of -00 by John Drake (diff)
Tsvart Last Call review of -04 by David Black (diff)
Assignment Reviewer Susan Hares 
State Completed
Review review-ietf-pals-endpoint-fast-protection-04-opsdir-lc-hares-2016-12-24
Reviewed rev. 04 (document currently at 05)
Review result Has Nits
Review completed: 2016-12-24

Review
review-ietf-pals-endpoint-fast-protection-04-opsdir-lc-hares-2016-12-24

I have reviewed this document as part of the Operational directorate's  ongoing effort to review all IETF documents being processed by the IESG.  These

comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

 

Status: Ready  with minor editorial nits  - 

 

Caveat 1: The ADs should read the minor considerations below.

Caveat 2:  I do not have operational experience with this type of technology.   My operational review is based on general operational principles

 

Comments: Thank you for this well-written document.  It is the type of document I would expect from Yimin, Rahul, Wim, and Yuanlong.  This document has very few changes with the bulk of the text indicating where this technology would be applied.

 

Minor considerations (For ADs to read.   No suggested changes to document).

 

A few comments should be underscored for the ADs reviewing this text:

 

1.       Active-Active and active-standby text has been considered -  The active-active path assumes CE will handle getting traffic on backup or normal path and reordering.  This is a reasonable cased based on the recommendation for ECMP handling in link failure.  

 

2.       ECMP handling suggests that link failure on PE as node failure on PE.    

 

The combination of the two should limit the number of out of order packets received by the CE.   This conclusion was reached based on the reviewers work with TRILL specifications, but not based on real operational experience.   If this is working in operational networks, then the knobs are probably sufficient.

 

Editorial nits:  

1.       Page 10  - style makes difficult reading of sentence  (very minor nit).

 

OLD /A PLR MUST Be able to detect a failure by using a rapid mechanism, such as physical layer failure detection, Bidirectional failure detection (BFD) [RFC5880], etc. /

 

 

NES /A PLR MUST Be able to detect a failure by using a rapid mechanism, such as physical layer failure detection, Bidirectional failure detection (BFD) [RFC5880], and others/

 

2.       Page 32 – difficult to parse sentence

 

      Old/For Encoding type, 1 is defined for PWid FEC element format, and 2 is defined for the Generalized PWid FEC Element format [RFC4447]./

 

      New/ For type encoding type, the following two values are defined within this document:

-          Type 1 for PWid FEC element format (see section 6.4.1.), and

-          Type 2 for Generalized PWid FEC Element format [RFC4447].