Subject: [MBONED] AD review of draft-ietf-mboned-mtrace-v2

From: Warren Kumari <[email-masked]>
Date: Mon, 30 Oct 2017 17:22:36 -0400

Hello,

Firstly, I'd like to apologize for how long it took me to review this
- I came down with a bad case of pneumonia, and was broken for a
while...

Thank you for your work on this document, it's a well written and easy
to understand
draft.  I do have a few comments that I’d like addressed before I
start IETF LC — addressing these now will avoid issues later in the
process.

Section 1.  Introduction
   Given a multicast distribution tree, tracing from a multicast source
   to a receiver is difficult, since we do not know which branch of the
[O] know which branch
[P] know on which branch
[R] readability/grammar
   multicast tree the receiver lies.

When not receiving an Mtrace2 Reply message due to
   network congestion, a broken router (see Section 5.6), or a non-
   responding router (see Section 5.7), the Mtrace2 client may resend
   another Mtrace2 Query with a lower hop count (see Section 3.2.1), and
   repeat the process until it receives an Mtrace2 Reply message.  The
   details are Mtrace2 client specific, and it is outside the scope of

[O] specific, and it is outside
[P] specific and outside
[R] readability; otherwise we would need to say “they,” and not “it,”
because we are referencing “details” (plural). That seems awkward.
   this document.

   Note that when a router's control plane and forwarding plane are out
   of sync, the Mtrace2 Requests might be forwarded based on the control
   states instead.  In which case, the traced path might not represent

[O] In which case,
[P] In this case,
[R] grammar
   the real path the data packets would follow.

Section 3.2.3.  Mtrace2 Reply
...
  The Reply message would then
   be unicasted to the Mtrace2 client specified in the Mtrace2 Client
   Address field.
   There are a number of cases an intermediate router might return a

[O]  cases an intermediate router might return
[P] cases in which an intermediate router might return
[R] I think this is what was meant.

Section 3.2.6.  Mtrace2 Augmented Response Block
...
      When the NO_SPACE error occurs on a router, the router should send
      the original Mtrace2 Request received from the downstream router
      as a Reply back to the Mtrace2 client, and continue with a new

[O] client, and
[P] client and
[R] grammar
      Mtrace2 Request.

Section 4.3.3.  Appending Standard Response Block
   ...
   The router then turns the Request
   into a Reply, and sends the Reply as described in Section 4.4.
[O] Reply, and
[P] Reply and
[R] grammar

5.8.3.  No Upstream Router
   A trace can not continue if the last Upstream Router in the trace is
[O] can not
[P] cannot
[R] grammar — unless you that optionally, it can elect not to continue… :-P
   set to 0.

5.9.  Continuing after an Error
  ...
   However, if all paths but one flow back towards the non-
   responding router, it is possible to be sure that this is the correct
[O] it is possible to be sure
[R] I don’t know what this means - perhaps "this" ?
   path.

7.3.  Packet Loss
  ...
   Since the packet counts may be
   changing as the Mtrace2 Request is propagating, there may be small
   errors (off by 1 or 2 or more) in these statistics.  However, these

[O] (off by 1 or 2 or more)
[R] limit the “or more”; otherwise, what’s the point of saying this at
all? Perhaps "on the order of 1 or 2"?
---
Again, apolgies for the delay,
W
-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 31 Oct 2017 14:04:53 +0900

Hello Warren,

Thank you very much for your review.

We will address your comments ASAP.
BTW, since this C/O date was past, we cannot submit the revised document now. Whenever the draft submission site is opened again, we will do it.
Can you chairs just wait for the IESG review process until the revision?

Regards,

Hitoshi

> 2017/10/31 6:22, Warren Kumari <[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 30 Oct 2017 23:36:30 -0700

Hitoshi- Warren will be taking the draft to IETF LC, and as he mentions, 
it's best to address these items now to avoid issues later in the process.

I think it's OK to wait until the cutoff is over to resubmit.

Lenny Giuliano
Juniper Networks
Herndon, VA
703-786-3398

On Tue, 31 Oct 2017, Hitoshi Asaeda wrote:

| Hello Warren,
| 
| Thank you very much for your review.
| 
| We will address your comments ASAP.
| BTW, since this C/O date was past, we cannot submit the revised document now. Whenever the draft submission site is opened again, we will do it.
| Can you chairs just wait for the IESG review process until the revision?
| 
| Regards,
| 
| Hitoshi
| 
| 
| > 2017/10/31 6:22, Warren Kumari <[email-masked]> wrote:
| > 
| > Hello,
| > 
| > Firstly, I'd like to apologize for how long it took me to review this
| > - I came down with a bad case of pneumonia, and was broken for a
| > while...
| > 
| > 
| > Thank you for your work on this document, it's a well written and easy
| > to understand
| > draft.  I do have a few comments that I’d like addressed before I
| > start IETF LC — addressing these now will avoid issues later in the
| > process.
| > 
| > 
| > Section 1.  Introduction
| >   Given a multicast distribution tree, tracing from a multicast source
| >   to a receiver is difficult, since we do not know which branch of the
| > [O] know which branch
| > [P] know on which branch
| > [R] readability/grammar
| >   multicast tree the receiver lies.
| > 
| > When not receiving an Mtrace2 Reply message due to
| >   network congestion, a broken router (see Section 5.6), or a non-
| >   responding router (see Section 5.7), the Mtrace2 client may resend
| >   another Mtrace2 Query with a lower hop count (see Section 3.2.1), and
| >   repeat the process until it receives an Mtrace2 Reply message.  The
| >   details are Mtrace2 client specific, and it is outside the scope of
| > 
| > [O] specific, and it is outside
| > [P] specific and outside
| > [R] readability; otherwise we would need to say “they,” and not “it,”
| > because we are referencing “details” (plural). That seems awkward.
| >   this document.
| > 
| >   Note that when a router's control plane and forwarding plane are out
| >   of sync, the Mtrace2 Requests might be forwarded based on the control
| >   states instead.  In which case, the traced path might not represent
| > 
| > [O] In which case,
| > [P] In this case,
| > [R] grammar
| >   the real path the data packets would follow.
| > 
| > Section 3.2.3.  Mtrace2 Reply
| > ...
| >  The Reply message would then
| >   be unicasted to the Mtrace2 client specified in the Mtrace2 Client
| >   Address field.
| >   There are a number of cases an intermediate router might return a
| > 
| > [O]  cases an intermediate router might return
| > [P] cases in which an intermediate router might return
| > [R] I think this is what was meant.
| > 
| > Section 3.2.6.  Mtrace2 Augmented Response Block
| > ...
| >      When the NO_SPACE error occurs on a router, the router should send
| >      the original Mtrace2 Request received from the downstream router
| >      as a Reply back to the Mtrace2 client, and continue with a new
| > 
| > [O] client, and
| > [P] client and
| > [R] grammar
| >      Mtrace2 Request.
| > 
| > Section 4.3.3.  Appending Standard Response Block
| >   ...
| >   The router then turns the Request
| >   into a Reply, and sends the Reply as described in Section 4.4.
| > [O] Reply, and
| > [P] Reply and
| > [R] grammar
| > 
| > 5.8.3.  No Upstream Router
| >   A trace can not continue if the last Upstream Router in the trace is
| > [O] can not
| > [P] cannot
| > [R] grammar — unless you that optionally, it can elect not to continue… :-P
| >   set to 0.
| > 
| > 5.9.  Continuing after an Error
| >  ...
| >   However, if all paths but one flow back towards the non-
| >   responding router, it is possible to be sure that this is the correct
| > [O] it is possible to be sure
| > [R] I don’t know what this means - perhaps "this" ?
| >   path.
| > 
| > 
| > 7.3.  Packet Loss
| >  ...
| >   Since the packet counts may be
| >   changing as the Mtrace2 Request is propagating, there may be small
| >   errors (off by 1 or 2 or more) in these statistics.  However, these
| > 
| > [O] (off by 1 or 2 or more)
| > [R] limit the “or more”; otherwise, what’s the point of saying this at
| > all? Perhaps "on the order of 1 or 2"?
| > ---
| > Again, apolgies for the delay,
| > W
| > -- 
| > I don't think the execution is relevant when it was obviously a bad
| > idea in the first place.
| > This is like putting rabid weasels in your pants, and later expressing
| > regret at having chosen those particular rabid weasels and that pair
| > of pants.
| >   ---maf
| > 
| > _______________________________________________
| > MBONED mailing list
| > [email-masked]
| > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=3edLGzdsQxcFpVJH9_zNcVA5vyzKmcwscKD72Nw3laY&s=i5OB_xGccMzEPkQ6JqRclxJpQiUKQKYB14TvVuDwsxA&e=
| 
| _______________________________________________
| MBONED mailing list
| [email-masked]
| https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=3edLGzdsQxcFpVJH9_zNcVA5vyzKmcwscKD72Nw3laY&s=i5OB_xGccMzEPkQ6JqRclxJpQiUKQKYB14TvVuDwsxA&e=
|

---

From: Warren Kumari <[email-masked]>
Date: Tue, 31 Oct 2017 13:24:17 -0400

> I think it's OK to wait until the cutoff is over to resubmit.

Yup -- otherwise, because this is my fault (and the changes are all
editorial) I'll approve submission if you want to submit before the
cuffoff opens again.
If so, please make sure to let me know.

W