Thanks Rüdiger, your NEW text is in the working version. Al > -----Original Message----- > From: ippm [mailto:ippm-bounces@xxxxxxxx] On Behalf Of > Ruediger.Geib@xxxxxxxxxx > Sent: Tuesday, July 7, 2020 1:28 AM > To: stewart.bryant@xxxxxxxxx > Cc: draft-ietf-ippm-route.all@xxxxxxxx; last-call@xxxxxxxx; rtg- > dir@xxxxxxxx; ippm@xxxxxxxx > Subject: Re: [ippm] Rtgdir last call review of draft-ietf-ippm-route-08 > > 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 > > > > _______________________________________________ > ippm mailing list > ippm@xxxxxxxx > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIGaQ&c=LFYZ- > o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=qNM9jZFj- > xxOd1SGl1pwVCkR4PTrs1m7OAeEE5RYB54&s=DoM7hYZ2yxM0ntZm- > QfGsfFEAfpfX8HGP86rl-bttPc&e= -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
