Subject: [Tsv-art] Fwd: 2 really urgent review requests

From: Martin Stiemerling <[email-masked]>
Date: Thu, 26 Oct 2017 11:21:41 +0200

used a wrong sender address...

-------- Weitergeleitete Nachricht --------
Betreff: 2 really urgent review requests
Datum: Thu, 26 Oct 2017 09:55:29 +0200

An: [email-masked]

Hi all,

There are two drafts with a request by Mirja to review them, but these 
two drafts are on the telechat today:

draft-ietf-bier-mpls-encapsulation-11
draft-ietf-6man-maxra-03

I am full loaded today and won't be able to read them, but does anybody 
else have a free slot before 3 pm CEST to briefly review these two or 
one of these drafts?

Thanks in advance,

   Martin

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Thu, 26 Oct 2017 11:01:11 +0000

I have quickly scanned through draft-ietf-6man-maxra-03, even if this is outside my area of expertise. 

I think the document has to better describe the impact of setting K to a large value (K >> 3), as a large K increases seems to increase the amount of needless traffic and could theoretically even result in congestion (or needless energy consumption).

Specifically, Section 3 explains that "K~=1 gives 99% reliability, K~=2 gives 99.99% reliability, and K~=3 gives 99.9999% reliability - the latter should be good enough for a lot of scenarios". I don't think there is a major issue for these values of K. But as far as I understand , what is missing is an explicit statement regarding the downside of larger values of K .

Specifically, I believe that in Section 4.  "Updates to RFC4861" ...

   As explained in Section 3, the relationship between MaxRtrAdvInterval
   and AdvDefaultLifetime must be chosen to take into account the
   probability of packet loss.

... some additional guidance should be added regarding the tradeoff of reliability and needless traffic (or energy consumption).

As a nit, I wonder about the unit of "MaxRtrAdvInterval" in ...

   MaxRtrAdvInterval MUST be no greater than 65535.  AdvDefaultLifetime
   MUST either be zero (the router is not to be used as a default
   router) or be a value between MaxRtrAdvInterval and 65535.

According to RFC 4861 the parameter "MaxRtrAdvInterval" is in seconds but this is missing here.

Anyway, I could just spent 15min on the doc...

Michael

> -----Original Message-----
> From: Tsv-art [mailto:[email-masked]] On Behalf Of Martin
> Stiemerling
> Sent: Thursday, October 26, 2017 11:22 AM
> To: [email-masked]
> Subject: [Tsv-art] Fwd: 2 really urgent review requests
> 
> There are two drafts with a request by Mirja to review them, but these two
> drafts are on the telechat today:
> 
> else have a free slot before 3 pm CEST to briefly review these two or one of
> these drafts?
> 
> Thanks in advance,
> 
>    Martin
> 
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 26 Oct 2017 14:07:20 +0200

Hi Micheal,

thanks! That's very helpful. Can we just ‚officially‘ assign this review to you and you enter these comments in the datatracker accordingly, such that the authors will also know about it and be able to fix it…?

Mirja

> Am 26.10.2017 um 13:01 schrieb Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]>:
>

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Thu, 26 Oct 2017 12:12:10 +0000

You can assign me if that helps 

Michael

> From: Mirja Kuehlewind (IETF) [mailto:[email-masked]]
> Sent: Thursday, October 26, 2017 2:07 PM
> To: Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]>
> Cc: Martin Stiemerling <[email-masked]>; [email-masked]
> Subject: Re: [Tsv-art] 2 really urgent review requests
> 
> Hi Micheal,
> 
> thanks! That's very helpful. Can we just ‚officially‘ assign this review to you
> and you enter these comments in the datatracker accordingly, such that the
> authors will also know about it and be able to fix it…?
> 
> Mirja
> 
> 
> > I think the document has to better describe the impact of setting K to a
> large value (K >> 3), as a large K increases seems to increase the amount of
> needless traffic and could theoretically even result in congestion (or needless
> energy consumption).
> >
> > Specifically, Section 3 explains that "K~=1 gives 99% reliability, K~=2 gives
> 99.99% reliability, and K~=3 gives 99.9999% reliability - the latter should be
> good enough for a lot of scenarios". I don't think there is a major issue for
> these values of K. But as far as I understand , what is missing is an explicit
> statement regarding the downside of larger values of K .
> >
> > ... some additional guidance should be added regarding the tradeoff of
> reliability and needless traffic (or energy consumption).
> >
> >> There are two drafts with a request by Mirja to review them, but
> >> these two drafts are on the telechat today:
> >>
> >> I am full loaded today and won't be able to read them, but does
> >> anybody else have a free slot before 3 pm CEST to briefly review
> >> these two or one of these drafts?
> >>
> >> Thanks in advance,
> >>
> >>   Martin
> >>