Dear Stewart, Here is the correction on the previous part: ====== This procedure requires to compute quartile values "on the fly" using the algorithm presented in [P2]. Minor English issue - missing text after requires ====== NEW This procedure requires the algorithm presented in [P2] to compute quartile values "on the fly”. Regards, J. Ignacio _______________________________________________________________ Dr. Ing. José Ignacio Alvarez-Hamelin CONICET and Facultad de Ingeniería, Universidad de Buenos Aires Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina +54 (11) 5285 0716 / 5285 0705 e-mail: ihameli@xxxxxxxxxxxxxx web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ _______________________________________________________________ P.D. Thanks Rüdiger! > On 7 Jul 2020, at 02:27, Ruediger.Geib@xxxxxxxxxx wrote: > > Hi Stewart, > > Thanks, you are right, there are more options and the text should reflect that. I've reviewed the section and suggest some more clarifications below. > > Regards, Ruediger > > OLD > 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]). Both methods allow load sharing > information to be decoupled from routing information. Thus, an MPLS > traceroute is able to check how packets with a contiguous number of > ECMP relevant addresses (and the same destination) are routed by a > particular router. The minimum number of MPLS paths traceable at a > router should be 32. Implementations supporting more paths are > available. > > NEW > Late deployments may support a so called > "Entropy label" for this purpose. State of the art deployments base > their choice of an ECMP member interface on the complete MPLS label stack > and on IP addresses up to the complete 5 tuple IP header information (see > Section 2.4 of [RFC7325]). Load Sharing based on IP information decouples > this function from the actual MPLS routing information. Thus, an MPLS > traceroute is able to check how packets with a contiguous number of > ECMP relevant IP addresses (and an identical MPLS label stack) are forwarded by a > particular router. The minimum number of equivalent MPLS paths traceable at a > router should be 32. Implementations supporting more paths are > available. > . > > > > > -----Ursprüngliche Nachricht----- > Von: Stewart Bryant via Datatracker <noreply@xxxxxxxx> > Gesendet: Freitag, 3. Juli 2020 18:47 > An: rtg-dir@xxxxxxxx > Cc: ippm@xxxxxxxx; last-call@xxxxxxxx; draft-ietf-ippm-route.all@xxxxxxxx > Betreff: Rtgdir last call review of draft-ietf-ippm-route-08 > > Reviewer: Stewart Bryant > Review result: Has Issues > > 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 > > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
