Re: [Bier] BIERv6 and BIERin6 OAM support discussion

Gyan Mishra <> Thu, 26 November 2020 05:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B8F073A0B0B for <>; Wed, 25 Nov 2020 21:38:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BsdbeYhlTtQR for <>; Wed, 25 Nov 2020 21:38:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C6DC83A0B0A for <>; Wed, 25 Nov 2020 21:38:01 -0800 (PST)
Received: by with SMTP id w16so744742pga.9 for <>; Wed, 25 Nov 2020 21:38:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=lkuGUgRKuKfMjwO8Q1H2P3ab7Ytob3blgDMp1XOmpR4=; b=WR19r9CvSuzn6pbqHky2hLCOkJ40gl8DqnvJDAXj2NWCM/psMs5yrOr8qRAue/FOhb +INAF2Ht/SlTu/MJEd3aea39D5xIX1ieCVFSneDQi80tEAwW5UkuxILWgHnAscnM+VUH LPWHxA5spD4q9+XWSINYJe/PPuxgWLeQTsrQ4LSl6aBPSMBofm4oLWG3OjwjV3npREpq lTiw9VJDSMstD5PTIVVmIOpCHDQfXCuakuOl8zHtoopRnOX+IQG6ilFvv3M8N9mDoihD 5cZVWd0xrsTVf+Auw/4maox+6AqdGi3JtCZl06iW28jlSSduOC9UrWXWvG/0hn5z38Ot xE1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=lkuGUgRKuKfMjwO8Q1H2P3ab7Ytob3blgDMp1XOmpR4=; b=n7chD5uPmjR7FS03R87UV3cXg19tTjVUWVZl6LgzHuGL17clIZ/3ZlphXC1dRvrXxc 8r07xC9L9V5iyUJS90Vw6J2PnTmpiICLWhT64oAvlxpvEkz6keM/8suJw83ZHt7vqS6u uuJjILluKrht3ZjeIxYi50gO+tsjZ5sXx9I0Gce297lOTDnFCUx9Jt8Mz3kckHl63jb4 W05fgypG5Pa290+7++KNePKJRr4chT9djtb4MHzxWkcZNsOCMxWkSKP+1cI7XOsW8ly6 DVzo2cIOVI5Z8eFLeV0ZcfqnEtRgCAg0mMGYufZumjEgaKNiUDxukkVHQAb2SHs97Ax+ yB1w==
X-Gm-Message-State: AOAM533h7cvylabQ5y/kUITSgNxV6iYCukop+Y9oAx9AhzOBgjL73Hul 9dIl5XIUghHI7S1hC6r+xxwthHO1UCHjT/i5f30sZmvg544=
X-Google-Smtp-Source: ABdhPJx9+Eebb8TvM+bBEGJ750d9OpDrpkh2Om6kW3+hEoIBfrJyxR78UAp3O9y6GuMeW2VoNo6rtak5lxhiPe7QknI=
X-Received: by 2002:a65:56c8:: with SMTP id w8mr1227060pgs.383.1606369081059; Wed, 25 Nov 2020 21:38:01 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Thu, 26 Nov 2020 00:37:50 -0500
Message-ID: <>
To: BIER WG <>, Greg Mirsky <>, Greg Shepherd <>, Gyan Mishra <>, Michael McBride <>, Tianran Zhou <>, Tony Przygienda <>, Xiejingrong <>
Content-Type: multipart/alternative; boundary="000000000000746fe205b4fbf282"
Archived-At: <>
Subject: Re: [Bier] BIERv6 and BIERin6 OAM support discussion
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Nov 2020 05:38:04 -0000


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?



On Wed, Nov 25, 2020 at 11:47 PM Gyan Mishra <> 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.
> -- 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
> <> 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
> <>
> :
>    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.
>    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
> --
> <>
> *Gyan Mishra*
> *Network Solutions A**rchitect *
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
> --


*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD