Skip to main content

Last Call Review of draft-ietf-ippm-route-08
review-ietf-ippm-route-08-rtgdir-lc-bryant-2020-07-03-00

Request Review of draft-ietf-ippm-route
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2020-07-03
Requested 2020-06-22
Requested by Alvaro Retana
Authors José Ignacio Alvarez-Hamelin , Al Morton , Joachim Fabini , Carlos Pignataro , Ruediger Geib
I-D last updated 2020-07-03
Completed reviews Rtgdir Last Call review of -08 by Stewart Bryant (diff)
Secdir Last Call review of -08 by Watson Ladd (diff)
Assignment Reviewer Stewart Bryant
State Completed
Review review-ietf-ippm-route-08-rtgdir-lc-bryant-2020-07-03
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/SqTxr417TIUSLQ0OhdZogQ9ZbN4
Reviewed revision 08 (document currently at 10)
Result Has issues
Completed 2020-07-03
review-ietf-ippm-route-08-rtgdir-lc-bryant-2020-07-03-00
This is a well written document with a technical point that needs addressing
and a couple of small nits, other than that it is ready to go.

========
Early deployments may support a so called
   "Entropy label" for this purpose.  State of the art deployments base
   their choice of an ECMP member based on the IP addresses (see
   Section 2.4 of [RFC7325]).

The entropy label is a relatively modern concept and I am not sure how widely
it is deployed. Older routers used either a hash on the labels as far down the
stack as they could reach (the goal was to include the BoS label this was a VPN
or a PW), or (more commonly) reached over the label stack (sometimes
incorrectly) and hash on the five tuple of the payload.

======
This procedure requires to compute quartile values "on the fly" using
the algorithm presented in [P2].

Minor English issue - missing text after requires
======
For reasons pointed out by one of the other reviewers, it is a pity that Class
C is used, but it seems to be well embedded in the technology and would be
difficult to change.
=======
Nits says that there is a requirements language problem. I think that may be
that it is simply in the wrong place. It would be good if it were fixed to
prevent other reviewers also needing to deal with this point