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

Greg Mirsky <gregimirsky@gmail.com> Mon, 10 December 2018 17:44 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 41A7E13110D for <bier@ietfa.amsl.com>; Mon, 10 Dec 2018 09:44:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_PASS=-0.001] autolearn=ham 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 7p6lss8jd8l8 for <bier@ietfa.amsl.com>; Mon, 10 Dec 2018 09:44:51 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 EC073130F74 for <bier@ietf.org>; Mon, 10 Dec 2018 09:44:50 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id v5so8649199lfe.7 for <bier@ietf.org>; Mon, 10 Dec 2018 09:44:50 -0800 (PST)
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=jh9CMMqNAXtRCZXPJeqctg0WtMUdXyHgAF3pIML/SJs=; b=C/4q3Yu9OOGFfDCea9XiZ9ALfJhnC6devZstEKqEkmUkU9A3w7VuxO60xLiGmjaDkr cXR0fVG25AYcge+UeIp7OOldA0oq41LnL2CCDdyfXeZs83wL+T7Pd6SgUc5/JCSpsUYb 6N4tcb0OHQynI8zCjh0IOnA8OVB5yfKvfEUZ3OFympLVswnrkAwze0MGgOSBPMg9DzeE zIHabTmwp4RG3cDp4Glv6ZtooyFismDs7mxaTZRfuR0poxitnrpebnhgN0aohxUo+SyO LBDcfYL4m1sMLEehglJngbn/9/Sl8a0xV+FAR5669NJAhuxvk1QFtS1uBV7K4sc9ZvDN Kw0Q==
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=jh9CMMqNAXtRCZXPJeqctg0WtMUdXyHgAF3pIML/SJs=; b=n3pWhwuQS6BJdbk3u8TQ3L1JSiyVENoST3nw6FC+U4CVrTFbpqkY83JeJ5OGWaFsl+ 9AuB5NzBIvtCzPYYu5/7JRa43V4kmttvX8HZ+nduYTFl0tqBRNCj74/4fvqfBygJ6dgl 6SZ6m87lI9Qx6dhPohokpoktDM6TOVjhJS0MfZU0k9tN+4r91rE2mbVDj3hLvqFv5eE6 34yXTdAH0/bNCjCUyPaJtOHiISUKIgQ47Huz3beKV4xF10i/6CY/vkF3YNPg8KRB8gSi 3bj5vssnJlBZ3508BTmJnJ2Cc0zcf9q36q0OFhT5kZXzW0SSQtxRqzIXnHe9QRdG1RHi V+7w==
X-Gm-Message-State: AA+aEWa5od4fv5cDzH0U4vkkS8rNfaj5mrRT3tvL2HEzxAKDuf2wi1Ki ctU89mlmHmiXXLU9QiIk3fIUpg5Sti/wkM7sWIg=
X-Google-Smtp-Source: AFSGD/UaVMjVY57Dun52uUXlLMbkGwUcuxE/DnrN53W/507+BQtyKxR1k7hhhySp+ofGSpHFoYc5u3lgVPR0U0wgKvY=
X-Received: by 2002:a19:a149:: with SMTP id k70mr7366699lfe.5.1544463889048; Mon, 10 Dec 2018 09:44:49 -0800 (PST)
MIME-Version: 1.0
References: <CAP+9T2uVmjUmoaL454R9f_Pm_m_TvO4ELk1LOoMoROr-UJLQFw@mail.gmail.com> <CA+RyBmUNAMrMzXcvoh8gjNKqPXPJ+2uMZhs1yUv-2fYWP1EEaQ@mail.gmail.com> <CA+RyBmWqdnM5oUmx4_NbC-go8gsia6Rz3n1ZMDKCCoEGYqRpGA@mail.gmail.com> <CAP+9T2uoo3bqaHdmtyDC44+SfDb=Afv08XSyKj16sfFLO4WgUA@mail.gmail.com> <CA+RyBmWyh8vtJgf0O2kmQ=_JCTZYHugJqkzM3SThJjMZaAdXEQ@mail.gmail.com> <CAP+9T2sxsPJX5=Vi7x_GvGG=71O1Zs1pqB4i7ULym-eug5Rjdw@mail.gmail.com>
In-Reply-To: <CAP+9T2sxsPJX5=Vi7x_GvGG=71O1Zs1pqB4i7ULym-eug5Rjdw@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 10 Dec 2018 17:44:37 +0000
Message-ID: <CA+RyBmU7Y3sur__bz85FAvkdkfZ4uU71ONS8t56VrNukHyovVQ@mail.gmail.com>
To: Suneesh Babu <suneeshbk@gmail.com>
Cc: BIER WG <bier@ietf.org>, Vero Zheng <vero.zheng@huawei.com>, Mach Chen <mach.chen@huawei.com>, suneesh@juniper.net, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Content-Type: multipart/alternative; boundary="00000000000079a9ed057cae851d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/w_p8pbg8r3UqJLzznsBvBIlXlXo>
Subject: Re: [Bier] Comments on draft-ietf-bier-pmmm-oam-04
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: Mon, 10 Dec 2018 17:44:53 -0000

Hi Suneesh,
if the marking removed at the edge of the initial AltMark measurement
domain, then adding the new measurement points would require communicating,
coordinating more state than if the AltMark domain matches the BIER domain
from the beginning. Would you agree?

Regards,
Greg

On Mon, Dec 10, 2018 at 5:27 PM Suneesh <suneeshbk@gmail.com> wrote:

> Hi Greg,
>
> Thanks, I'm a little confused about the following statement on clearing
> the marking.
> <snip>
> It is expected that the marking values be set and cleared at the edge of
> BIER domain.
> </snip>
>
> Is it edge of BIER domain or edge of measurement domain(link or segment or
> end to end).  Please let me know.
>
> Regards,
> Suneesh
>
> On Mon, Dec 10, 2018 at 9:48 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
>> Hi Saneesh,
>> thank you for your feedback. Please kindly consider the update to the
>> draft reflected in the attached diff. Please let us know if the changes
>> address your comments.
>>
>> Regards,
>> Greg
>>
>> On Mon, Nov 26, 2018 at 4:31 PM Suneesh <suneeshbk@gmail.com> wrote:
>>
>>> Thanks Greg for the update, please find my comments inline below.
>>>
>>> Regards,
>>> Suneesh
>>>
>>> On Thu, Nov 22, 2018 at 12:09 AM Greg Mirsky <gregimirsky@gmail.com>
>>> wrote:
>>>
>>>> Now with the updated address to reach Giuseppe.
>>>>
>>>> On Wed, Nov 21, 2018 at 10:37 AM Greg Mirsky <gregimirsky@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Suneesh,
>>>>> thank you for the feedback and the detailed questions. Please find my
>>>>> responses and notes in-line below tagged GIM>>.
>>>>>
>>>>> Regards,
>>>>> Greg
>>>>>
>>>>> On Mon, Nov 19, 2018 at 9:24 AM Suneesh <suneeshbk@gmail.com> wrote:
>>>>>
>>>>>> 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?
>>>>>>
>>>>> 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?
>>>>>
>>>> Suneesh>>> Agreed
>>>
>>>>
>>>>>> 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?
>>>>>>
>>>>> GIM>> We use the term "sub-flow" as you've described in b).
>>>>>
>>>> Suneesh>>> Would be great if we can capture in the draft for more
>>> clarity
>>>
>>>> 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
>>>>>>
>>>>> GIM>> You're right, 1 or even 2 would not be useful. 3 packets? May
>>>>> be.
>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>> 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.
>>>>>
>>>> Suneesh>> Please consider adding it to the draft
>>>
>>>>
>>>>>> 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>
>>>>>>
>>>>>>
>>>>> GIM>> I think it would be too restrictive. One may want to measure
>>>>> performance of BIER OAM.
>>>>>
>>>> Suneesh >>> I understood your point. Thanks.
>>>
>>>
>>>> Regards,
>>>>>> Suneesh
>>>>>>
>>>>>