Subject: [ippm] Rtgdir last call review of draft-ietf-ippm-route-08

From: Stewart Bryant via Datatracker <[email-masked]>
Date: Fri, 03 Jul 2020 09:46:45 -0700

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

---

From: <[email-masked]>
Date: Tue, 7 Jul 2020 05:27:36 +0000

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 <[email-masked]> 
Gesendet: Freitag, 3. Juli 2020 18:47
An: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Rtgdir last call review of draft-ietf-ippm-route-08

Reviewer: Stewart Bryant

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.

========

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

---

From: J Ignacio Alvarez-Hamelin <[email-masked]>
Date: Tue, 7 Jul 2020 10:25:40 -0300

Dear Stewart,

Here is the correction on the previous part:

======

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: [email-masked]
web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
_______________________________________________________________

P.D. Thanks Rüdiger!

> On 7 Jul 2020, at 02:27, [email-masked] wrote:
> 
> Hi Stewart,
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 9 Jul 2020 21:45:44 +0000

Thanks Rüdiger, your NEW text is in the working version.
Al

> -----Original Message-----
> From: ippm [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, July 7, 2020 1:28 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; rtg-
> [email-masked]; [email-masked]
> 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
> 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.
> 
> ========
> 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
> 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
> [email-masked]
> 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=

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 9 Jul 2020 21:51:17 +0000

Thanks Ignacio, I have added your NEW text to the working version.
Al

> From: ippm [mailto:[email-masked]] On Behalf Of J Ignacio Alvarez-
> Hamelin
> Sent: Tuesday, July 7, 2020 9:26 AM
> To: [email-masked]; [email-masked]
> web: https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__cnet.fi.uba.ar_ignacio.alvarez-2Dhamelin_&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=M3YmjIQx0fRYuePHMB4-
> eL81RTxXhx9rxjCedmHPofU&s=dxdbx5s1hKosBmwmgPBmyO4gtTyx34fo4_WDVZizodU&e=
> > 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
> > 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
> >
> >
> >
> 
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=M3YmjIQx0fRYuePHMB4-
> eL81RTxXhx9rxjCedmHPofU&s=jc0Qu5cvjWUUk-9ni2TMhivNPh4-Th1f62BrChzmkwk&e=