Re: [Bier] BIERv6 and BIERin6 OAM support discussion

Greg Mirsky <gregimirsky@gmail.com> Thu, 26 November 2020 22:12 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 D35993A1101 for <bier@ietfa.amsl.com>; Thu, 26 Nov 2020 14:12:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.087
X-Spam-Level:
X-Spam-Status: No, score=-1.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] 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 XijaAl6rle52 for <bier@ietfa.amsl.com>; Thu, 26 Nov 2020 14:12:39 -0800 (PST)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 2FAEF3A10FC for <bier@ietf.org>; Thu, 26 Nov 2020 14:12:39 -0800 (PST)
Received: by mail-lj1-x22e.google.com with SMTP id t22so3874462ljk.0 for <bier@ietf.org>; Thu, 26 Nov 2020 14:12:39 -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=lMYibH1eeSivpl4Eeei9EyCyy6CCa9mP7teKl/q1Kic=; b=G5Suiv3dHgmr7bc7aJGXpm04m24L18dz+YD3aed87+6TtKeJj1jcCT7ddiq2pAcaWp urgAuiTTahkOr3OYcFYfHhR0gMEk8uzPp1wV/WThQYaoNZtGEgodAlq5nhdFXIp+gl70 u85zXBz0l2Xo17kWqDNCcpcIYaf12QGAPoiw2X3wcCxOsZd+msBcUtWXYWaCbDk0gIuh QeCZXGCJXe7NypFlWa/+BX45noaIn+nfO8Uy2hG8azC/PeRW7U2SC53aanieImzX16Qa sCRWWj8eXxcDoPOt5zluRg7sWHQzcS6qN4q4vkTgsSjoNYnClFJM7oodgI3WjlSm7uAg yHdQ==
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=lMYibH1eeSivpl4Eeei9EyCyy6CCa9mP7teKl/q1Kic=; b=NVMrJDvHVa7yzqoaRKWw3Ex0CRnaurGrQSjRu23ZwNNJhWlfKHzeOp6b4c6KZc0J33 9O7nwP4CDjVuGE4T3+PvAHZbfmMBCNbsopUNc5bBfI6Z+yGj9Fw4UGpZXCLvupwtfWQ5 wniZH0wEPOrzAAKTosAM8hTPZPqBZqMY1EpGM4FYMIDJGrJ9jWueTxKxbUDgW6Kqnc4i dOfiCUL9KpIs/8n90/jCvOFk9lJzzExwAyiGPBEs0UAxOMXMZ9v68sTIzV5UGCS7n7eJ j4jqwiZ0X2rjbxhcLjtGmfoOZr8XB0rOyLQE+trgKievH+5aHh0QYcQHpKxD6hh2gNEI M82g==
X-Gm-Message-State: AOAM531cgqYcd9joJOG7QVUwi+a9DRB4ni7WON0gfkY3ucA3QR8rLp2R vY7oIMi9KzkLI1ARVcA06LKcISyafsbs24MKkY4=
X-Google-Smtp-Source: ABdhPJxZJbzJ9ZikO6VDOsrlU7/B/JdTaAVGpnk8Jqp8Z3sfcg9L2K6cgH6HzPEC8N/reY4z2gTQj5f3nKVoHhd3Qeg=
X-Received: by 2002:a2e:9694:: with SMTP id q20mr2022395lji.279.1606428757176; Thu, 26 Nov 2020 14:12:37 -0800 (PST)
MIME-Version: 1.0
References: <CABNhwV17gK0-OVthEa=JMmYmHS5+oXi9_W5=H-PqR5qiRDp38g@mail.gmail.com> <CABNhwV3-BSjdqdqxoqTJ8+xf+gM9OC21ZuPTZBJyJWzbSS+Apg@mail.gmail.com> <59b4b540151d4030bd646f0cf694b22d@huawei.com>
In-Reply-To: <59b4b540151d4030bd646f0cf694b22d@huawei.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 26 Nov 2020 14:12:25 -0800
Message-ID: <CA+RyBmVPz0aMbMU4jiZ+8O9qVdw0+Jiveqt764FOOQndYuVnng@mail.gmail.com>
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, BIER WG <bier@ietf.org>, Greg Shepherd <gjshep@gmail.com>, Michael McBride <michael.mcbride@futurewei.com>, Tony Przygienda <tonysietf@gmail.com>, "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
Content-Type: multipart/alternative; boundary="0000000000006db70105b509d7f3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/XQv2ED9CrkKXZ37QNZs2vzMZMd0>
Subject: Re: [Bier] BIERv6 and BIERin6 OAM support discussion
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: Thu, 26 Nov 2020 22:12:42 -0000

Hi Tianran,
you are right, IP/UDP encapsulation is one of the options to encapsulate
BIER active OAM messages and it was considered when we've worked on
draft-ietf-bier-ping
<https://www.ietf.org/archive/id/draft-ietf-bier-ping-07.txt> (the updated
version is coming soon). But we've decided to not use it and define BIER
OAM header (Section 3.1 of the draft-ietf-bier-ping):

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Ver  | Message Type  | Proto |             Reserved          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        OAM Message Length                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                  Message Type Dependent Data                  ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

BIER WG has agreed and that is now the encapsulation of BIER OAM whether it
is BIER Echo Request/Reply, a BFD Control message, or a STAMP'
Session-Sender's message. Hope that clarifies the context of my question
How does BIERv6 support BIER OAM?

Regards,
Greg

On Wed, Nov 25, 2020 at 10:52 PM Tianran Zhou <zhoutianran@huawei.com>
wrote:

> Hi Greg,
>
>
>
> Thanks for your interest on OAM. Let me reply your question here.
>
>
>
> @Gyan, thanks for folking this thread.
>
>
>
> The way to encapsulate OAM message is very generic, just like MPLS ping
> and MPLS p2mp ping.
>
> OAM message is in IP+UDP after Bier.
>
> A highlight of this way is it could also apply to draft-ietf-bier-php.
>
>
>
> Cheers,
>
> Tianran
>
>
>
>
>
>
>
>
>
> *From:* Gyan Mishra [mailto:hayabusagsm@gmail.com]
> *Sent:* Thursday, November 26, 2020 1:38 PM
> *To:* BIER WG <bier@ietf.org>rg>; Greg Mirsky <gregimirsky@gmail.com>om>; Greg
> Shepherd <gjshep@gmail.com>om>; Gyan Mishra <hayabusagsm@gmail.com>om>; Michael
> McBride <michael.mcbride@futurewei.com>om>; Tianran Zhou <
> zhoutianran@huawei.com>gt;; Tony Przygienda <tonysietf@gmail.com>om>;
> Xiejingrong (Jingrong) <xiejingrong@huawei.com>
> *Subject:* Re: BIERv6 and BIERin6 OAM support discussion
>
>
>
> Greg
>
>
>
> With RFC 8296 Non MPLS BIER Ethernet next header 0xAB37  and optIonal
> BIERin6 encapsulation single hop or multi hop tunnel the BIER header is
> present either after Ethernet header in the latter or after the IPv6 header
> in BIERin6 and is present to encode OAM value for proto fied.
>
>
>
> With BIERv6 there is not any “BIER” encapsulation layer as the BIER header
> is encoded in IPV6 extension header DOH header.  As it is not encoded in
> the IPV6 packet header and is part of IPv6 header as is an extension
> header, OAM will not work natively with BIERv6.
>
>
>
>
>
> Jingrong and Xuesong
>
>
>
> Please shed some light on how OAM would work with BIERv6?
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Wed, Nov 25, 2020 at 11:47 PM Gyan Mishra <hayabusagsm@gmail.com>
> wrote:
>
> RE: BIER in IPV6 environment OAM support
>
>
>
> ***Tonys email related to OAM requirement***
>
>
>
> Quick correction here as to OAM. OAM is worked on and multiple quite
> extensive & well-written drafts dealing with OAM aspects are adopted/in
> flight since quite a while (I count 4 adopted & 1 individual). BIER has
> been specifically architected with multicast OAM in mind which is
> non-trivial such as MTU discovery (we have 2 drafts for a good reason &
> discussion is pending) and dealing with OAM when we're dealing with mp2mp
> trees (which BIER basically is or can be used at). One of the reasons BIER
> found interest in the set of people that need/like it is that they were
> looking for very tight OAM guarantees in orders of microseconds and that
> without highly specific hardware designed for it is very difficult (and
> packet format, that's why OAM is first order citizen in BIER in terms of
> bits provided e.g. for marking purposes and can be found in a very specific
> offset. to support the OAM desired HW has to process and generate
> sub-microseconds trains.
>
>
>
> As far as I saw there was not much on the radar in terms of anything
> comparable in SRv6 OAM work beside "SID-ping" if the intention is to rely
> on SRv6 to deal with that problem. But of course I may have missed some
> draft. Even if they work on unicast OAM I may express my profound doubts
> there will be interest or focus to solve OAM for SRv6 becoming a L3
> multicast transport with the type of OAM BIER needs on top.
>
>
>
> As to desired OAM, I think we have an OAM requirements draft adopted with
> quite a list of industry authors since quite a bit. this draft has WG
> consensus and has to be satisfied.
>
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-bier-oam-requirements/?include_text=1
>
>
>
> -- tony
>
>
>
> Greg Mirsky update request to BIER IPv6 Requirements draft:
>
>
>
> Dear All,
>
> I apologize for jumping into this discussion but have someone said "OAM"?
> :)
>
> I much appreciate what our co-chair (and contributor to BIER OAM) had to
> say about the state of BIER OAM work. I agree with Tony's summary that our
> joint efforts already created the toolset of the distinctive solutions for
> BIER OAM. We've followed draft-ietf-bier-oam-requirements
> <https://datatracker.ietf.org/doc/draft-ietf-bier-oam-requirements/> to
> define the comprehensive set of OAM mechanisms that support proactive and
> on-demand failure detection and localization using both BFD and echo
> request/reply. Also, as Tony mentioned, we have drafts on path MTU
> discovery in the BIER environment and application of the Alternate Marking
> method for the packet delay and packet loss measurement in a BIER domain.
> In my opinion, the section on OAM in draft-ietf-bier-ipv6-requirements is
> helpful. I have a question on the intention of the following wording:
>
> .... by specifying a new method for the same functionality.
>
> If there's, for example, WG draft on proactive failure detection in the
> BIER network using p2mp BFD with unsolicited notifications, why would we
> entertain the idea of defining a new protocol or method for the same
> purpose? I think that the ability to use BIER OAM solutions as defined in
> their respective drafts already accepted by the WG (and some even passed
> WGLC) is the litmus test for any proposed method of realizing BIER in IPv6
> network. Thus I propose the following change of Section 3.1.4
> <https://tools.ietf.org/html/draft-ietf-bier-ipv6-requirements-09#section-3.1.4>
> :
>
> OLD TEXT:
>
>    BIER OAM tools like [I-D.ietf-bier-ping] and [I-D.ietf-bier-pmmm-oam]
>    should be supported, either directly using existing methods, or by
>    specifying a new method for the same functionality.  They are likely
>    to be needed in normal BIER deployment for diagnostics.
>
> NEW TEXT:
>
>    BIER OAM tools defined in WG document, for example,
>
>    [I-D.ietf-bier-ping] and [I-D.ietf-bier-pmmm-oam],
>    must be supported as defined in the respective specifications.
> Consistency
>
>    of OAM BIER tools is essential for the productive operation of BIER
> networks.
>
>
>
>
>
> Regards,
>
> Greg
>
>
>
>
>
> RE:  Greg Mirsky start of BIER IPv6 OAM discussion related to the two IPV6
> environment solutions
>
>
>
> Hi Tianran,
>
> I just recently read both proposals - BIERin6 and BIERv6. Understandably,
> I was interested in how each solution handles BIER OAM.
>
> draft-zhang-bier-bierin6 explains that:
>
>    BIER has its own OAM function, so generally the IPv6 OAM function is
>    not needed.
>
> And I agree with that conclusion. BIER OAM will work because BIER header
> is used as defined in RFC 8296, including using OAM value in the Proto
> field.
>
> draft-xie-bier-ipv6-encapsulation states that:
>
>         How BIER-PING is supported in BIERv6
>         encapsulation without using this Proto field is outside the
>         scope of this document.
>
> That left me with many questions. Thus, from my point of view, BIERv6
> needs to demonstrate how BIER OAM, as defined in numerous WG drafts, works
> in BIERv6 domain. Without that, I cannot compare the two proposals fairly.
>
>
>
> Regards,
>
> Greg
>
>
>
>
>
>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>