Re: [Bier] AD Review of draft-ietf-bier-pmmm-oam-05

Greg Mirsky <> Mon, 01 July 2019 17:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC4BB12084A; Mon, 1 Jul 2019 10:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KxXwXWe8vP0Z; Mon, 1 Jul 2019 10:39:42 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A420A12084B; Mon, 1 Jul 2019 10:39:41 -0700 (PDT)
Received: by with SMTP id a9so9390232lff.7; Mon, 01 Jul 2019 10:39:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4S+eK0cV6B6SEl3dsfr9qEqMH9vp1zFFhIqNZeku5yM=; b=HM4yNGsswbeh3o4whXHqDtrJ46XCAiFxeDAoN/zTYW//8tHNWzuzPHVZXip8MHirdg 0+06BehbNcjPG1Gp7fOwvGWWzOu4Kuzw/sAI/rK+2W+byfbfqMYn7q2ToFCL01JQ04cm hNu/yTHn1vNLTPkRWeZ3xl32wUIwr70Kl94nmv8alV0cGpTdxON6g9Yead/JRhyrQEbh FxH/1/8jYyldqU2Treq/UuslnUVllrU2tGwxz+HIY9xMjTIHFcd8OxyYRiBfGtwFYfqI ii0FlQqW7lXiVgfiQt83ck5Z/bYe9sr/0T9tGgQyNcacTuH4kNqNquVLz+skpsZEDn11 OqEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4S+eK0cV6B6SEl3dsfr9qEqMH9vp1zFFhIqNZeku5yM=; b=I6BGgihB2riB9FIIZvzkniT9N11rpvToOt5PQPExzYcEixg+wSVo9vtM+JfA9kAEhj TLsZRf155PSJ5rTz7Pd+PyEBoup98DGr5vm1PzFS1SqVstigY504y4FxdAKADa6AVG7c VXjcJEURU4gVoUTAKp+yn8OUWK+btF9gGAZCX3wIgt7HdfAxhsxWatZYIt745WlpjVoj azTUzWlU4nEj7pxeiY1oz8xovs/F+j8Mx1XJoPSw86md7Amzrblt0+fg3ydpM9KI5E+b Lf6kjLVyBNWsKG5kv6rK/DXKtrpZT3Gz0/h1JC5dWAvIxtdsCw9uKk6+TNrKUuueAMHz nhNA==
X-Gm-Message-State: APjAAAXMRQdDgT6ROiRZnn9kDcVqZh5zvu7kkY9fj6uSF05GEdi1OYX9 W0UxhQrnN4TzdJSyCIBYOg79ASvo88DC3ueJIpY=
X-Google-Smtp-Source: APXvYqwf4tSrHa6ksT6QxoorMGgG6OoLWE/i7d0dEVPDV3mxUxOUdBbbRDnmrDCrJR1CBU2x/Bo5wCe8M7rOOo2NKcQ=
X-Received: by 2002:ac2:5609:: with SMTP id v9mr11713206lfd.27.1562002779574; Mon, 01 Jul 2019 10:39:39 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Mon, 1 Jul 2019 10:39:28 -0700
Message-ID: <>
To: Alvaro Retana <>
Cc:, Giuseppe Fioccola <>, BIER WG <>, BIER WG Chairs <>
Content-Type: multipart/alternative; boundary="000000000000d0981d058ca21ce5"
Archived-At: <>
Subject: Re: [Bier] AD Review of draft-ietf-bier-pmmm-oam-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Jul 2019 17:40:01 -0000

Hi Alvaro,
thank you for your kind consideration of the proposed updates and sharing
additional comments. The new version has bee posted. We'll prepare for the
discussion at BIER meeting in Montreal. Please find my follow-up notes
in-line tagged GIM2>>.

Best regards,

On Mon, Jul 1, 2019 at 7:57 AM Alvaro Retana <>; wrote:

> On June 29, 2019 at 5:22:37 PM, Greg Mirsky ( wrote:
> Greg:
> Hi!
> many thanks for your review, detailed questions, and the most helpful
> suggestions. I've prepared the updated new version to address the nits,
> minor and major issues you've pointed out. Please find my answers, notes
> in-lined tagged GIM>>. We, the authors, will discuss your other comments
> and respond to them soon.
> As I mentioned before, I will be returning the document to the WG for
> additional work.  Please submit an update in line with your responses — I
> think there are improvements, but the large underlying issues remain, which
> is what I want the WG to discuss.  I will return the document as soon as
> you submit the update.
> I have a couple of comments inline.
> Thanks!
> Alvaro.
> ...
> (1) This document uses the PNPM method described in rfc8321, which makes
>> that RFC a required Normative reference because it "must be read to
>> understand or implement the technology" [1].  Note that some of my comments
>> below are precisely about being explicit with the use of PNPM; the text
>> talks about the marking method in general...
> GIM>> Moved to the Normative section of referenced documents.
> That’s a required first step…but the question of this document’s status is
> the bigger one:
> (2) The use of PNPM results then in the fact that this document cannot be
>> on the Standards Track because rfc8321 is Experimental.  In general,
>> downward references are possible, but I don't think this is one of those
>> cases.  The Shepherd writeup for rfc8321 [2] states that "the measurement
>> utility of this extension still is to be demonstrated at a variety of
>> scales in a plurality of network conditions."  As far as I can tell, that
>> hasn't been demonstrated, nor specific information about the completion of
>> the experiment was included in the RFC text.  I didn't see the topic of the
>> document status discussed in the WG -- nor am I aware of discussions about
>> the maturity of rfc8321 in the ippm WG.  The result is then that this
>> document should be either Informational or Experimental.
>> (3) Before digging further into the status of rfc8321, I want to ask the
>> question of the applicability of PNPM to multicast traffic, is it?  On one
>> hand, I see that rfc8321 reports that the "methodology has been used
>> experimentally in Telecom Italia's network and is applied to
>> multicast...".  On the other hand, draft-ietf-ippm-multipoint-alt-mark [*]
>> starts by saying that rfc8321 "can be applied only to point-to-point
>> flows".  I think that we could stretch the use of PNPM to monitor
>> (referring to Figure 2) both A-C-G and A-C-F using a single set of markings
>> at A...but that piece of the methodology is not specified in the document.
> GIM>> I think that the characterization of the method described in RFC
> 8321 in draft-ietf-ippm-multipoint-alt-mark must be revised. The multipoint
> draft discusses methods needed to use the Alternate Marking method in cases
> with multiple marking nodes, i.e., mp2p and mp2mp use cases. RFC 8321
> addressed use case with a single marking node in the network and such use
> cases fir with p2p and p2mp scenarios.
> It would be a good idea then to clarify those scenarios here, with respect
> to the BIER application…. I couldn’t find an explicit discussion of those
> scenarios in rfc8321: I searched for p2mp, p2p, multipoint, multi-point…
GIM2>> Yes, RFC8321 would have been the most appropriate for such
discussion. Will work on adding some of it in this document and work with
authors of draft-ietf-ippm-multipoint-alt-mark (with the help from

> (4) Finally, what is the relationship between this document and
>> draft-ietf-bier-oam-requirements?  How does this document address the
>> requirements?  Why isn't draft-ietf-bier-oam-requirements even mentioned?
> GIM>> Added reference to specific requirements in the Introduction section:
>    The method, called Packet Network Performance Monitoring
>    (PNPM), can be used to measure packet loss, latency, and jitter on
>    live traffic complies with requirements #5 and #12 listed in
>    [I-D.ietf-bier-oam-requirements].
> Ok…but I-D.ietf-bier-oam-requirements lists 14 total requirements, many of
> them with “MUST”.  What about them?
GIM2>> The Alternate-Marking method is to support performance monitoring
and cannot be used to detect failures in a network, which is the task for
the Fault Management OAM protocols. Also, as a hybrid OAM method, it cannot
be used proactively, i.e., without the data flow being present in the
network. But I agree, more requirements listed can be referenced, i.e.,
related to the manageability of OAM in BIER. Will work on that for the next

> ...
> [major] It's not clear to me whether PNPM is known as *the* Marking
>> Method, or if it is simply *a* marking method.  Please clarify.  I note
>> that the later mentions to "marking method" are all in lower case, which
>> seem to imply something generic -- if referring to PNPM, it would be better
>> to do it explicitly.
> GIM>> Changed to "a marking method". Removed MM from the Terminology
> section.
> The text in general talks about “marking method”, not PNPM…it would be
> better if the Normative sections talked about PNPM and not just a marking
> method.
GIM2>> I've re-checked RFC 8321 and it looks that the term PNPM is used
only once in the document. To be consistent with the terminology of RFC
8321, I think, this draft should refer to the Alternate-Marking Method
(AMM) rather than "marking method". What do you think?

> ...
> [major] "...if the operator initially monitors A-C-G and A-B-D segments he
>> may enable measurements on segments C-F and B-E at any time."  How?  A
>> similar question was asked in the Shepherd's review, and the answer
>> included this: "the AltMark domain may be arbitrary and not identical to
>> the BIER domain. But from operational PoV, I believe, it is useful to apply
>> AltMark at BFIR and then clear them by removing BIER encapsulation at
>> BFERs." [3]  However, the document doesn't have any type of discussion
>> related to the existence of multiple types of domains, or their
>> congruence...much less operational guidance.  Please be explicit about the
>> potential different domains, their relationship to the specification in
>> rfc8296 and provide operational guidance in an Operational Considerations
>> section.
> GIM>> Added the Operational Consideration section.
> Assuming that A is the BFIR, the new section doesn’t explain the
> measurement of C-F, for example.
GIM2>> I clearly missed this question. The explanation can be provided (I
could have added it in the new version if I've taken time to read your
comments in details) with a simple update to the last sentence:
   Thus for the
   scenario presented in Figure 2 if the operator initially monitors the
   A-C-G and A-B-D segments he may enable measurements on segments C-F
   and B-E at any time.
   Thus for the
   scenario presented in Figure 2 if the operator initially monitors the
   A-C-G and A-B-D segments he may enable measurements on segments C-F
   and B-E at any time by configuring the monitoring point on nodes F or E.

> ...
> [major] "this method is sensitive to packet loss and re-ordering of
>> packets"  It will be important to point at the Considerations section from
>> rfc8321.  It would be ideal to do so in the Operational Considerations
>> section.
> GIM>> Appreciate your feedback on the new section in the updated version
> of the draft.
> I think of an Operational Considerations section as one that gives
> operators guidance on the use of the feature.  In this case, pointing at
> rfc8321 helps provide some background, but it doesn’t help the operator in
> actual settings like deciding the length of time, or number of packets, to
> be used in each monitored flow.
>> 203   o  Average Packet Delay calculation: an average delay is calculated
>> 204      by considering the average arrival time of the packets within a
>> 205      single block.  A BFR may collect timestamps for each packet
>> 206      received within a single block.  Average of the timestamp is the
>> 207      sum of all the timestamps divided by the total number of packets
>> 208      received.  Then the difference between averages calculated at two
>> 209      monitoring points is the average packet delay on that segment.
>> 210      This method is robust to out of order packets and also to packet
>> 211      loss (only a small error is introduced).  This method only
>> 212      provides a single metric for the duration of the block and it
>> 213      doesn't give the minimum and maximum delay values.  This
>> 214      limitation could be overcome by reducing the duration of the
>> block
>> 215      by means of a highly optimized implementation of the method.
>> [minor] "Then the difference between averages calculated at two
>> monitoring points is the average packet delay on that segment."  Maybe my
>> math is rusty, but I would have thought the average delay to be the average
>> of the averages, not the difference.  ??
> GIM>> I think that the text needs improvement to clarify the math used
> here:
>       Then the difference between the average packet arrival
>       time calculated for the downstream monitoring point and the same
>       metric but calculated at the upstream monitoring point is the
>       average packet delay on the segment between these two points.
>> [minor] "only a small error is introduced"  This seems to be a statement
>> of faith: no proof or justification.
> GIM>> The new text to explain that conclusion added:
>       This method is robust to out of order packets and also to packet
>       loss on the segment between the measurement points (packet loss
>       may cause a minor loss of accuracy in the calculated metric
>       because the number of packets used is different at each
>       measurement point).
> This is true but only as the BIER traffic is “forked off”.
> ...
> 240 5.  IANA Considerations
>> 242   This document requests IANA to register format of the OAM field of
>> 243   BIER Header as the following:
>> [major] §3 calls these bits L and D.
> GIM>> Missed to update Section 3 to 'S' and 'D'. Should be fixed now.
>> [major] If you're assigning values to all the bits in the field, then a
>> registry is not needed.
>> [major] If you want to set up a registry to avoid others using the bits
>> in different ways, then that requires an Update to rfc8296.  The way I read
>> rfc8296 is that there could be multiple ways of using the field.  I also
>> didn't see this type of discussion in the WG archive.
>> 245
>> +--------------+---------+--------------------------+---------------+
>> 246   | Bit Position | Marking | Description              | Reference
>> |
>> 247
>> +--------------+---------+--------------------------+---------------+
>> 248   |      0       |    S    | Single Mark Measurement  | This document
>> |
>> 249   |      1       |    D    | Double Mark Measurement  | This document
>> |
>> 250
>> +--------------+---------+--------------------------+---------------+
>> 252                     Table 1: OAM field of BIER Header
>> [major] §3 uses a different description, which seems inline with §4.
>> Also, the use of a single bit doesn't indicate (according to §4) the type
>> of measurement done.
> GIM>> I recall that the naming of the flags was discussed and there was a
> suggestion to use more generic names than Loss and Delay because other
> performance metrics can be measured using this method.
> My point was that the name doesn’t reflect the use for what is described
> in this document.  In the Double-Marking case, for example, both flags are
> used.
> As I mentioned above, if this document wants to define the use of the bits
> in general, then an Update to rfc8296 will be needed.  Personally, I don’t
> think that is the best direction…specially since the a priori configuration
> (and not in-line signaling) is used for the nodes to know which OAM method
> is being used.  But that is just my personal opinion…the WG can decide
> something different.
> GIM>> Also, a more compact marking method has been proposed in
> draft-mizrahi-ippm-compact-alternate-marking
> <>;.
> This method allows the measurement of packet loss and packet delay using
> one-bit long field.
> Ok…but that draft is not mentioned in this document?  Are you suggesting
> that the compact marking method could be used instead (?) of what is
> defined in rfc8321?  This obviously needs more WG discussion as well.