Subject: [Bier] Comments on draft-ietf-bier-pmmm-oam-04

From: Suneesh <[email-masked]>
Date: Mon, 19 Nov 2018 22:53:50 +0530

Hi Greg,

I have following comments on PMMM draft, please share your thoughts.

Q1. Can you please share how the draft is viewed as a hybrid model?

Ref: Section-3:

<snip>
   the marking method in BIER layer can be viewed as the example of the
   hybrid performance measurement method
</snip>

Q2. Can you please define what is meant by sub-flows
   a). Is the sub-flow set of flows on which marking method is applied OR
   b). sub-flow-1 with say marking 0 and sub flow-2 with say marking 1 OR
   c). Being a hybrid model, draft proposes to duplicate the multicast
stream which is having marking and treated those as sub-flows?

Ref: Section-4: Theory of Operation
<snip>
   Using the marking method a BFR creates distinct sub-flows in the
   particular multicast traffic over BIER layer
</snip>

Q3. Is there any recommended values for 'number of packets' or/and 'time
duration' for alternate marking method
    a). Just to know what is recommended to avoid say number of
packets/time duration = 1

Q4. Lets say that the nodes is like A->B->C->D->F->G->H->I, the segment of
interest is B->C->D for performance measurement
  a). Does the alternate marking values will clear from node D onwards?
  b). If not, what is recommended if we wish to measure between G->H->I

Ref: Section-4: Theory of Operation

<snip>
  Any combination of markings, Loss and/or Delay, can be applied to a
multicast flow by
  any Bit Forwarding Router (BFR) at either ingress or egress point to
   perform node, link, segment or end-to-end measurement to detect
   performance degradation defect and localize it efficiently.
</snip>

Q5. Can we somewhere capture that 'proto' field of BIER header should not
be "OAM request/reply", though we are using OAM bits in header.

<snip>
   The OAM field MUST be used only
   for the performance measurement of data traffic in BIER layer.
</snip>

Regards,
Suneesh

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 21 Nov 2018 10:37:17 -0800

Hi Suneesh,
thank you for the feedback and the detailed questions. Please find my
responses and notes in-line below tagged GIM>>.

Regards,
Greg

> Q1. Can you please share how the draft is viewed as a hybrid model?
GIM>> RFC 7799 provided the definition of active and passive measurement
methods. Hybrid methods are "in between" these two groups. Even though the
Alternate marking in BIER domain may use already preallocated field, it
does change the content of the header by applying the marking values in the
OAM field. Thus it is neither passive, nor active method but "in between",
i.e., hybrid. Would you agree?

> stream which is having marking and treated those as sub-flows?
GIM>> We use the term "sub-flow" as you've described in b).

> packets/time duration = 1
GIM>> You're right, 1 or even 2 would not be useful. 3 packets? May be.

>   b). If not, what is recommended if we wish to measure between G->H->I
GIM>> Very good question. It is expected that the marking values be cleared
at the edge of BIER domain and thus an operator may enable measurements on
segment G-H-I at any time.

>    for the performance measurement of data traffic in BIER layer.
GIM>> I think it would be too restrictive. One may want to measure
performance of BIER OAM.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 21 Nov 2018 10:39:46 -0800

Now with the updated address to reach Giuseppe.

On Wed, Nov 21, 2018 at 10:37 AM Greg Mirsky <[email-masked]> wrote:

>> Q4. Lets say that the nodes is like A->B->C->D->F->G->H->I, the segment
>> of interest is B->C->D for performance measurement
> GIM>> Very good question. It is expected that the marking values be
> cleared at the edge of BIER domain and thus an operator may enable
> measurements on segment G-H-I at any time.
>
>>

---

From: Suneesh <[email-masked]>
Date: Mon, 26 Nov 2018 22:01:20 +0530

Thanks Greg for the update, please find my comments inline below.

Regards,
Suneesh

On Thu, Nov 22, 2018 at 12:09 AM Greg Mirsky <[email-masked]> wrote:

> Suneesh>>> Agreed

> Suneesh>>> Would be great if we can capture in the draft for more clarity

> Suneesh>> Please consider adding it to the draft

>>> Q5. Can we somewhere capture that 'proto' field of BIER header should
>>> not be "OAM request/reply", though we are using OAM bits in header.
>>>
>>> <snip>
> Suneesh >>> I understood your point. Thanks.