Skip to main content

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 revision 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
I-D last updated 2016-12-24
Completed reviews Genart Last Call review of -04 by Dale R. Worley (diff)
Secdir Last Call review of -04 by Chris M. 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 L. Black (diff)
Assignment Reviewer Susan Hares
State Completed
Request Last Call review on draft-ietf-pals-endpoint-fast-protection by Ops Directorate Assigned
Reviewed revision 04 (document currently at 05)
Result Has nits
Completed 2016-12-24
review-ietf-pals-endpoint-fast-protection-04-opsdir-lc-hares-2016-12-24-00
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].