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

Greg Mirsky <gregimirsky@gmail.com> Wed, 21 November 2018 18:37 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 905981294D0 for <bier@ietfa.amsl.com>; Wed, 21 Nov 2018 10:37:33 -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 MjylN5iRa9JN for <bier@ietfa.amsl.com>; Wed, 21 Nov 2018 10:37:31 -0800 (PST)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 C147212426A for <bier@ietf.org>; Wed, 21 Nov 2018 10:37:30 -0800 (PST)
Received: by mail-lj1-x230.google.com with SMTP id 83-v6so5704207ljf.10 for <bier@ietf.org>; Wed, 21 Nov 2018 10:37:30 -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=MUDzNgl279iO7aWdP8dlVTi8ZynzmDjwM355SOSfcTU=; b=M3ZSG8W6h99tUeHT7XB5qbkZn4NkK3fikJBUMGKBcfbT4UUu2o6x/0X2lWJJ9cBwwJ rjW/LRbpaZueDDQAS14vG+5oFVyOjHcJ6FcnC9kWp/8iNPsv5bc4V1BJB08me0ubK1SI acnV3b0FmGO3DT5ZGdCeWnORVg7UFbcTl87ePGen6bxM4IA3ocjoclJHtg5TkObmILx8 lTdqcpPqXVOCBFk9xlQ2apY4DmoobU1yonheqDvq6IJzPQIyh49721tZIy5OfE4R5W4O CTADPei4VWuRvd51HWAgiUm3TxjndOBPrRPDtBbJQX39kF2L8lgoARvrVbqqsM9g+JWP PZ7w==
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=MUDzNgl279iO7aWdP8dlVTi8ZynzmDjwM355SOSfcTU=; b=cHwcnyxsX9cG295pPNcvB92pE7nZjgQnDe5JdZ+q+PR2jWRYxIKTbwWXGQVF7/UAjE wKFHKVGCDSHG8mL1IZg41HIt8vDF37JF2sWBC48TsGZrWWd0joJXuVLGx7pWvNhRs751 E31vbToWarCoWg0/W5sM9iLlEVFJCTKqZ40RZJ0cOLIv7N5VtTJVG9pUOsEYvrHlhvUX ixxPysx/37B+HKU+TWLL+7UQgkbvZDtfWgAegVG7YEaHz7ysKYHj32c4ZSjH9lDgCSh1 Sxy9bhJXTlXKCzUd400Ml1fsrtpqPWCooWg0vS6IfyLs6YI1nOAULdCp4pKro3NCbpFk eFdA==
X-Gm-Message-State: AA+aEWYozg7nngQyj5W5NoeuA5FePzYMLbbWOEaZ9MPcC2nRRN++4h/q EWl4K8ChUFcM3JDXRata8W8Y9EhsbMEk/StmbJ8=
X-Google-Smtp-Source: AFSGD/WwxYNted7GGX4pl0HIA6ORrrrmyTVvkFI5wOpHpofrwey9n7+WaydzRR/jCYciSwdjiINQM8jEf6/R/Uo7zK4=
X-Received: by 2002:a2e:851a:: with SMTP id j26-v6mr4708340lji.163.1542825448733; Wed, 21 Nov 2018 10:37:28 -0800 (PST)
MIME-Version: 1.0
References: <CAP+9T2uVmjUmoaL454R9f_Pm_m_TvO4ELk1LOoMoROr-UJLQFw@mail.gmail.com>
In-Reply-To: <CAP+9T2uVmjUmoaL454R9f_Pm_m_TvO4ELk1LOoMoROr-UJLQFw@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 21 Nov 2018 10:37:17 -0800
Message-ID: <CA+RyBmUNAMrMzXcvoh8gjNKqPXPJ+2uMZhs1yUv-2fYWP1EEaQ@mail.gmail.com>
To: suneeshbk@gmail.com
Cc: BIER WG <bier@ietf.org>, Vero Zheng <vero.zheng@huawei.com>, Mach Chen <mach.chen@huawei.com>, "Fioccola Giuseppe (giuseppe.fioccola@telecomitalia.it)" <giuseppe.fioccola@telecomitalia.it>, suneesh@juniper.net
Content-Type: multipart/alternative; boundary="000000000000d280d8057b310abd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/Ewhgh0xKnTloPDdkXfoEccJO7vo>
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: Wed, 21 Nov 2018 18:37:34 -0000

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?

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

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

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

>
> Regards,
> Suneesh
>