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

Greg Mirsky <gregimirsky@gmail.com> Sat, 29 June 2019 21:22 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95977120019; Sat, 29 Jun 2019 14:22:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.403
X-Spam-Level: ****
X-Spam-Status: No, score=4.403 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, GB_SUMOF=5, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-R24CsokAnT; Sat, 29 Jun 2019 14:22:40 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15E912000F; Sat, 29 Jun 2019 14:22:38 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id a21so9278467ljh.7; Sat, 29 Jun 2019 14:22:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9Q2W+1SIROIkmA9pegi/KAHbogJ2njNh+IFxa8fV/wg=; b=OonfHuOZtoKriKe3dlRw2auGqGjpEm60MHv7buP0ZMok6DYnmQ9pNWRZu7H6m4/auc pEgfFlMOduP5uSw043M76NYLlhI/5Zo2slAVgoHhSmZo5yPijCC5uCM5n6hcMc2E2wb+ 3TPAUUfRkAIQVBym19n/iFerPfKZv7VJQlyFVzI/iCsQ3aC1wk+d+FIZ+9QfrEBVGLTG 3OMMd9EyyX4kxtmu0CWSc3QV6YUUHrihBgJT29cHr8vWZ0lGcMYuuAkuTspiLO67fVJC 4LUGOyQbq9Kt3gY6fZ4e6Siw6RUv6zMiz4pMQZLDvclgdLm87MqRqjDGYdJ0K4zMPvJU 7oVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9Q2W+1SIROIkmA9pegi/KAHbogJ2njNh+IFxa8fV/wg=; b=JKap+vRiBbdhdXV3jAek/rnGXVzMYHm9+AxebDnP/nWoeCQ1gjZN8IUXMThQ/1DagK ocquzZRNJ90SHzsK6FQO6o+0xJIcF8552j1/EYMqHO9K88/h66bemQNpEMquEuNm0dy+ YFeZYgtwFPTqQLdtsJqNmqRowlCg2bRNgf1WnfQ1VB0xL1xXOETzNvcj3QOS+9OB4Ct/ jc/BGADYlkxD72ZKXDtgqVG3U/GtTbYJgkAVhidse7SW+VHUNfEacIZwSrE35aP4MwaJ HHGWpPpcvaUz70ROVHsoNcEluPFUdBXn0zAWD3oYJuLzqLPdRfkOEVhpjYaeN6A1gopX DzrQ==
X-Gm-Message-State: APjAAAWlIKtAXAGWfO8FQwSHain1U2AOZ7iFlsswG70Mbdvy8kejpEPR 1lutIbGE4qtT2FofRsZtMz+UFhzZtpjqiS4O5UU=
X-Google-Smtp-Source: APXvYqw3ghfb0Ifd5+CpCcjaztHCf8W3Bj6XWLkgRW6BddNpxu8SgOYC6NQfB0p77/oKxMVV58EN+Z/w8rJrntg3VuU=
X-Received: by 2002:a2e:6c07:: with SMTP id h7mr9872546ljc.177.1561843356871; Sat, 29 Jun 2019 14:22:36 -0700 (PDT)
MIME-Version: 1.0
References: <CAMMESsyKwB_ha85WfQJ9LiOcE3gWaAXLkocz4-f8U9jah7z=kA@mail.gmail.com>
In-Reply-To: <CAMMESsyKwB_ha85WfQJ9LiOcE3gWaAXLkocz4-f8U9jah7z=kA@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sat, 29 Jun 2019 14:22:25 -0700
Message-ID: <CA+RyBmXrQuHm8RL_3YyYVQgHDuk+0u=eYcLiT7pk=i5Z7jJVpQ@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: draft-ietf-bier-pmmm-oam@ietf.org, BIER WG Chairs <bier-chairs@ietf.org>, BIER WG <bier@ietf.org>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Content-Type: multipart/mixed; boundary="0000000000007b5227058c7cfea8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/0xkt62yMVgNAs31N3nlycIlImO0>
Subject: Re: [Bier] AD Review of draft-ietf-bier-pmmm-oam-05
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Jun 2019 21:22:48 -0000

Hi Alvaro,
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.

Regards,
Greg

PS. Attached please find the diff and the copy of the new working version
of the draft.


On Wed, Jun 26, 2019 at 11:40 AM Alvaro Retana <aretana.ietf@gmail.com>;
wrote:

> Dear authors:
>
> I just finished reading this document.  I was looking forward to reviewing
> a short and straight-forward document, but ended this one with many
> questions and concerns.  Please take a look at the details.
>
> I'm starting with some overall issues/concerns:
>
> (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.

>
> (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.

>
> (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].
>
>
>
> Given these issues (and others identified below), I am inclined to return
> this document to the WG to consider the Status, applicability, the
> relationship to other work items, etc.  I will wait for an initial response
> to these comments before doing so.
>
> Thanks!
>
> Alvaro.
>
>
> [*] draft-ietf-ippm-multipoint-alt-mark is an ippm WG item and one of the
> authors is also an author of rfc8321 and of this document.
>
> [1]
> https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/
> [2]
> https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/shepherdwriteup/
>
>
>
>
> [Line numbers from idnits.]
>
> ...
> 15 Abstract
>
> 17   This document describes a hybrid performance measurement method for
> 18   multicast service over Bit Index Explicit Replication (BIER) domain.
>
> [nit] s/over Bit Index Explicit Replication (BIER) domain/through a Bit
> Index Explicit Replication (BIER) domain
>
GIM>> Agree. And removed '(BIER)'.

>
>
> ...
> 70 1.  Introduction
>
> 72   [RFC8279] introduces and explains Bit Index Explicit Replication
> 73   (BIER) architecture and how it supports forwarding of multicast data
> 74   packets.  [RFC8296] specified that in case of BIER encapsulation in
> 75   MPLS network a BIER-MPLS label, the label that is at the bottom of
> 76   the label stack, uniquely identifies the multicast flow.  [RFC8321]
> 77   describes hybrid performance measurement method, per [RFC7799]
> 78   classification of measurement methods.  Packet Network Performance
> 79   Monitoring (PNPM), which can be used to measure packet loss, latency,
> 80   and jitter on live traffic.  Because this method is based on marking
> 81   consecutive batches of packets the method often referred to as
> 82   Marking Method (MM).
>
> [nit] s/explains Bit Index Explicit/explains the Bit Index Explicit
>
> [nit] s/encapsulation in MPLS network/encapsulation in an MPLS network
>
> [nit] s/describes hybrid performance/describes a hybrid performance
>
> [nit] s/[RFC7799] classification of measurement methods./RFC7799's
> classification of measurement methods [RFC7799].
>
> [nit] s/Packet Network Performance Monitoring (PNPM), which can be
> used/The method, called Packet Network Performance Monitoring (PNPM), can
> be used
>
> [nit] s/the method often referred/the method is often referred
>
GIM>> Yes on them all.

>
> [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.

>
> 84   This document defines how marking method can be used on BIER layer to
> 85   measure packet loss and delay metrics of a multicast flow in MPLS
> 86   network.
>
> [nit] s/used on BIER layer/used on the BIER layer
>
> [nit] s/in MPLS network/in an MPLS network
>
GIM>> Done.

>
> 88 2.  Conventions used in this document
>
> 90 2.1.  Terminology
> ...
> 99   MM: Marking Method
>
> [minor] It looks like MM is only used in the Introduction...
>
GIM>> Yes, removed MM.

>
>
> ...
> 111 3.  OAM Field in BIER Header
>
> 113   [RFC8296] defined the two-bit long field, referred to as OAM,
> 114   designated for the marking performance measurement method.  The OAM
> 115   field MUST NOT be used in defining forwarding and/or quality of
> 116   service treatment of a BIER packet.  The OAM field MUST be used only
> 117   for the performance measurement of data traffic in BIER layer.
> 118   Because the setting of the field to any value does not affect
> 119   forwarding and/or quality of service treatment of a packet, the
> 120   marking method in BIER layer can be viewed as the example of the
> 121   hybrid performance measurement method.
>
> [major] "designated for the marking performance measurement method"
>  rfc8296 clearly says that this document is an example of a document that
> may define the non-default use of the bits.  It doesn't designate the use
> of the bits in any way.
>
GIM>> Yes, this draft is an example of how the OAM field can be used.
Here's the update:
OLD TEXT:
   [RFC8296] defined the two-bit long field, referred to as OAM,
   designated for the marking performance measurement method.
NEW TEXT:
   [RFC8296] defined the two-bits long field, referred to as OAM.  The
   OAM field can be used for the marking performance measurement method.

>
> [major] "The OAM field MUST NOT be used in defining forwarding and/or
> quality of service treatment of a BIER packet."  This sentence seems to
> paraphrase rfc8296.  Is that the intent?  If so, that is not what rfc8296
> says: it is not Normative in the same way.
>
> If not, then I'm not sure what the Normative statement is.
>
> In general, it seems to me that there is no value in that text in this
> document.  Note that the paragraph ends with "because the setting of the
> field to any value does not affect forwarding and/or quality of service
> treatment of a packet...", which is a statement in line with rfc8296, then
> there doesn't seem to be a need to include the Normative sentence at all...
>
GIM>> I agree and have deleted the two sentences with the Normative
language.

>
> [major] "The OAM field MUST be used only for the performance measurement
> of data traffic in BIER layer."  What is the intended Normative action of
> this sentence?  It seems to me that it wants to avoid other uses of the OAM
> field...but without updating rfc8296, which says that the use of the field
> "in other than the default manner is OPTIONAL".  IOW, this statement
> contradicts rfc8296.
>
GIM>> Removed the sentence. The updated text (see above) is as follows:
NEW TEXT:
   The OAM field can be used for the marking performance measurement
method.
>
>
> If you intend for the statement to only apply to implementations of this
> document, then you don't need to even include it: the document itself is
> about specifying the use of the OAM field (for nodes that support it).
>
> [minor] "Because the setting of the field...the marking method in BIER
> layer can be viewed as the example of the hybrid performance measurement
> method."  I don't understand how the conclusion is drawn (based on the
> setting of the field)...nor how this relates to the text in the
> Introduction where it basically says that PNPM, which is a hybrid
> performance measurement method is known as MM... ??
>
GIM>> RFC 8321 described how PNPM can be applied in the IPv4 network as a
hybrid PM method. The intent of this sentence is to note that by using the
OAM field PNPM in BIER domain can be characterized as hybrid PM method as
well. Would the updated sentence be clearer:
   Because the setting of the field to any value does not affect
   forwarding and/or quality of service treatment of a packet, using the
   OAM field for PNPM in BIER layer can be viewed as the example of the
   hybrid performance measurement method.

>
> 123   The Figure 1 displays format of the OAM field
>
> [major] Please be explicit in saying that this is how this document
> defines the OAM field.
>
GIM>> Would the following be better:
   Figure 1 displays the interpretation of the OAM field defined in this
   specification for the use by PNPM method.

>
> 125    0
> 126    0   1
> 127   +-+-+-+-+
> 128   | L | D |
> 129   +-+-+-+-+
>
> 131                 Figure 1: OAM field of BIER Header format
>
> 133   where:
>
> 135   o  L - Loss flag;
>
> 137   o  D - Delay flag.
>
> [minor] Please add a forward reference to where the meaning and use of
> these flags is specified.
>
> [minor] The name of these flags doesn't really represent loss/delay...
>
> 139 4.  Theory of Operation
>
> 141   The marking method can be successfully used in the multicast
> 142   environment supported by BIER layer.  Without limiting any
> generality
> 143   consider multicast network presented in Figure 2.  Any combination
> of
> 144   markings, Loss and/or Delay, can be applied to a multicast flow by
> 145   any Bit Forwarding Router (BFR) at either ingress or egress point to
> 146   perform node, link, segment or end-to-end measurement to detect
> 147   performance degradation defect and localize it efficiently.
>
> [nit] "The marking method can be successfully used in the multicast
> environment supported by BIER layer."  Sounds like a marketing statement...
>
GIM>> Dropped "successfully" to make it more engineer-speak.

>
> [major] "Any combination of markings...can be applied...by any Bit
> Forwarding Router (BFR)..."  rfc8296 says that the "bits are set...by the
> BFIR and are not modified by other BFRs".  What is the assumption?  Please
> be clear!
>
GIM>> The updated text:
   Any combination of markings can be
   applied to a multicast flow by the Bit Forwarding Ingress Router (BFIR)
...

>
> 149                           -----
> 150                         --| D |
> 151                 -----  /  -----
> 152               --| B |--
> 153              /  -----  \  -----
> 154             /           --| E |
> 155   -----    /              -----
> 156   | A |---                -----
> 157   -----    \            --| F |
> 158             \  -----   /  -----
> 159              --| C |--
> 160                -----   \  -----
> 161                         --| G |
> 162                           -----
>
> 164                        Figure 2: Multicast network
>
> 166   Using the marking method, a BFR creates distinct sub-flows in the
> 167   particular multicast traffic over BIER layer.  Each sub-flow
> consists
> 168   of consecutive blocks, consisting of identically marked packets,
> that
> 169   are unambiguously recognizable by a monitoring point at any BFR and
> 170   can be measured to calculate packet loss and/or packet delay
> metrics.
> 171   It is expected that the marking values be set and cleared at the
> edge
> 172   of BIER domain.  Thus for the scenario presented in Figure 2 if the
> 173   operator initially monitors A-C-G and A-B-D segments he may enable
> 174   measurements on segments C-F and B-E at any time.
>
> [major] What are sub-flows?  This question was asked in the Shepherd
> review, but no clarification made it into the document.  Note that §4.1
> talks about "alternate flows" -- is that the same thing?  And §4.2 uses
> "monitored flow"...
>
GIM>> The updated text is as follows:
   Using the marking method, a BFIR creates distinct sub-flows in the
   particular multicast traffic over BIER layer.  Each sub-flow consists
   of consecutive blocks of identically marked packets.  For example, a
   block of N packets, with each packet being marked as X, is followed
   by the block of M packets with each packet being marked as Y.  These
   blocks are unambiguously recognizable by a monitoring point at any
   Bit Forwarding Router (BFR) and can be measured to calculate packet
   loss and/or packet delay metrics.

>
> [nit] s/monitors A-C-G/monitors the A-C-G
>
GIM>> Done

>
> [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.

>
> [3] https://mailarchive.ietf.org/arch/msg/bier/0rn7_VSjJQPRAOxSSfnGp-kFWBE
>
>
> 176 4.1.  Single Mark Enabled Measurement
>
> [major] rfc8321 uses "Single-Marking" (not Single Mark).  Please be
> consistent.
>
GIM>> Changed throughout the draft s/Single Mark/Single-Marking/

>
> 178   As explained in the [RFC8321], marking can be applied to delineate
> 179   blocks of packets based either on the equal number of packets in a
> 180   block or based on equal time interval.  The latter method offers
> 181   better control as it allows better account for capabilities of
> 182   downstream nodes to report statistics related to batches of packets
> 183   and, at the same time, time resolution that affects defect detection
> 184   interval.
>
> [nit] s/in the [RFC8321]/in [RFC8321]
>
GIM>> Done

>
> 186   If the Single Mark measurement used to measure packet loss, then the
> 187   D flag MUST be set to zero on transmit and ignored by monitoring
> 188   point.
>
> [nit] s/measurement used/measurement is used
>
> [nit] s/ignored by monitoring/ignored by the monitoring
>
GIM>> Done and done

>
> [major] In this document I don't see a way to discover (or detect from the
> signaling) what methodology is in use.  All the nodes in the network (or at
> least the ones doing measurement) MUST then be configured beforehand.  Is
> that true?  Please be explicit about those type of requirements.  An
> rfc5706-type Operational Considerations section would be ideal -- look
> specially at §2.
>
GIM>> Yes, your understanding that all measurement points must be
configured is absolutely correct. I've added the text in the new section
Operational Considerations.

>
> 190   The L flag is used to create alternate flows to measure the packet
> 191   loss by switching the value of the L flag every N-th packet or at
> 192   certain time intervals.  Delay metrics MAY be calculated with the
> 193   alternate flow using any of the following methods:
>
> 195   o  First/Last Packet Delay calculation: whenever the marking, i.e.
> 196      value of L flag changes, a BFR can store the timestamp of the
> 197      first/last packet of the block.  The timestamp can be compared
> 198      with the timestamp of the packet that arrived in the same order
> 199      through a monitoring point at downstream BFR to compute packet
> 200      delay.  Because timestamps collected based on order of arrival
> 201      this method is sensitive to packet loss and re-ordering of
> packets
>
> [nit] s/at downstream BFR/at a downstream BFR
>
> [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.

>
> 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).

>
> [major] "This method...[has a] limitation [which] could be overcome by
> reducing the duration of the block by means of a highly optimized
> implementation of the method."  What does that mean?  How is it done?
>
GIM>> The idea is that if the the number of packets in the block is
smaller, i.e. duration is shorter, then the calculated value of the average
delay better reflects maximum and minimum delay values of that block's
duration. But to use the shorter blocks will require more efficient
implementation of the method, preferably the one that uses HW support. The
new text is to explain the idea as follows:
      This limitation of producing only the
      single metric could be overcome by reducing the duration of the
      block.  As a result, the calculated value of the average delay
      will better reflect the minimum and maximum delay values of the
      block's duration time.

>
> [major] What considerations should be taken into account when deciding the
> length of time, or number of packets, to be used in each monitored flow?
> Please include this information in the Operational Considerations section.
>
GIM>>

>
> 217 4.2.  Double Mark Enabled Measurement
>
> [major] rfc8321 uses "Double-Marking" (not Double Mark).  Please be
> consistent.
>
GIM>> Updated throughout the document.

>
> 219   Double Mark method allows measurement of minimum and maximum delays
> 220   for the monitored flow but it requires more nodal and network
> 221   resources.  If the Double Mark method used, then the L flag MUST be
> 222   used to create the alternate flow, i.e. mark larger batches of
> 223   packets.  The D flag MUST be used to mark single packets to measure
> 224   delay jitter.
>
> [major] "If the Double Mark method used, then the L flag MUST be
> used...The D flag MUST be used..."   There's no Normative value in the use
> of MUST here.  If appropriate, please use Normative language to indicate
> *how* the flags are used instead.  s/MUST/must
>
GIM>> After re-reading these sentences I think that it can be expressed
without even "must". Please let me know if the updated text is acceptable
(please note that flags have been renamed as S(ingle-Marking) and
D(ouble-Marking).
   If the Double-Marking method used, then the S flag is
   used to create the sub-flow, i.e., mark blocks of packets.  The D
   flag is used to mark single packets within a block to measure delay
   and jitter.


>
> 226   The first marking (L flag alternation) is needed for packet loss and
> 227   also for average delay measurement.  The second marking (D flag is
> 228   put to one) creates a new set of marked packets that are fully
> 229   identified over the BIER network, so that a BFR can store the
> 230   timestamps of these packets; these timestamps can be compared with
> 231   the timestamps of the same packets on a second BFR to compute packet
> 232   delay values for each packet.  The number of measurements can be
> 233   easily increased by changing the frequency of the second marking.
> 234   But the frequency of the second marking must be not too high in
> order
> 235   to avoid out of order issues.  This method is useful to measure not
> 236   only the average delay but also the minimum and maximum delay values
> 237   and, in wider terms, to know more about the statistic distribution
> of
> 238   delay values.
>
> [major] "the frequency of the second marking must be not too high"  What
> is "too high"?
>
GIM>> I think it is finding a balance between a number of measurements to
make metrics more representative of the network conditions experienced by
the monitored flow and, on the other hand, the volume of traffic added by
collecting the measurement data. Perhaps the updated text removes the
ambiguity of "too high":
   The number of measurements can be
   easily increased by changing the frequency of the second marking.  On
   the other hand, the higher frequency of the second marking will cause
   a higher volume of the measurement data being transported through the
   BIER domain.  An operator should consider and balance both effects.

>
> 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. Also, a more compact
marking method has been proposed in
draft-mizrahi-ippm-compact-alternate-marking
<https://datatracker.ietf.org/doc/draft-mizrahi-ippm-compact-alternate-marking/>;.
This method allows the measurement of packet loss and packet delay using
one-bit long field.

>
> 254 6.  Security Considerations
>
> 256   This document list the OAM requirement for BIER-enabled domain and
> 257   does not raise any security concerns or issues in addition to ones
> 258   common to networking.
>
> [major] "This document list the OAM requirement for BIER-enabled
> domain..."  That is not what this document does!
>
GIM>> Updated, please find the new text below.

>
> [major] "common to networking"  That's a very wide statement -- do you
> have a reference?
>
> [major] You should at least point to rfc8296.
>
> [major] I would also like to see a pointer to rfc8321, and a discussion of
> how the concerns there apply (or not) to the BIER application.
>
GIM>> Please review the updated Security Considerations section:
 6.  Security Considerations

   Regarding using the marking method, [RFC8321] stressed two types of
   security concerns.  First, the potential harm caused by the
   measurements, is a lesser threat as [RFC8296] defines OAM field used
   by the marking method so that the value of "two bits have no effect
   on the path taken by a BIER packet and have no effect on the quality
   of service applied to a BIER packet."  Second security concern,
   potential harm to the measurements can be mitigated by using policy,
   suggested in [RFC8296], to accept BIER packets only from trusted
   routers, not from customer-facing interfaces.

   All the security considerations for BIER discussed in [RFC8296] are
   inherited by this document.
>
>
>
> ...
> 283 8.2.  Informative References
> ...
> 295   [RFC8321]  Fioccola, G., Ed., Capello, A., Cociglio, M.,
> Castaldelli,
> 296              L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
> 297              "Alternate-Marking Method for Passive and Hybrid
> 298              Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
> 299              January 2018, <https://www.rfc-editor.org/info/rfc8321>;.
>
> [major] This reference must be Normative.
>
GIM>> Done.