Re: [Bier] BIERv6 and BIERin6 OAM support discussion

Gyan Mishra <> Thu, 26 November 2020 04:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 612AD3A0980 for <>; Wed, 25 Nov 2020 20:47:27 -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 o-MQQ4KwgUtv for <>; Wed, 25 Nov 2020 20:47:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 139F13A097B for <>; Wed, 25 Nov 2020 20:47:24 -0800 (PST)
Received: by with SMTP id x15so547609pll.2 for <>; Wed, 25 Nov 2020 20:47:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Frceed6xRtVlwzpcdbT0ivNbSdjsuNRW7zAuo+mqXz4=; b=sMhjdMh/116BxeytTRN5M0WDaE/caaVsmyXAVI8W4gYPw0NErpoLZUTqo3oQjVNyBL HMjZkN8fwlr836nv4Wb2/Hmq7GtpYDusVBEBZTXaNLEIKIy/xQTjoGD1arPZq2i5aWGb +qGXW/dbl7asL1P7pJ+U1uf4sY8uHE8y7zecnJeEZnZbbCAMj817NiZ9Mj3EHlWuvlku eUA503cC8XL5gPsNO2BHyiAXgtz+IItS06f5tLuhjLnF+HYVuAOUl320c18A/aTg+xso ctBLShx4N+ChG8BXj19Eg8nKtQaS1jlWgw6c8LqPVhwtcYFRGyD8meOi9xbMjYzbeDXf ZCbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Frceed6xRtVlwzpcdbT0ivNbSdjsuNRW7zAuo+mqXz4=; b=CTn4fv2DYfg6ABozYmTFRhscAS2yIXuvROVjyqFQyb72ys2ofNM0TaeLqqs9NRqN/j H7+4naOQedC7wp8847jQvj4VpD1l2JSDS0YlcEsvglSU3UFAReJqdbqzRzYX9+2d/avr 8AD7Z17jKqgdBy2Q35aoAl5JCC2DLKfctlxSt+HcbEojF2QKOraT1Lfj604oqrVOr7rg fW5T5mfPV2cFOViBMQVk80gXjlrnrj5NexSCrDaVc7tsGFY/ZCq1kylPRXosxWhedlyX wDXfdezX7+ZzxD2MYGPa3Zio/iTAs9LtSBPkoojKShkzZ0D6POj6iKWc6cTvJA/+Ql/4 nGsA==
X-Gm-Message-State: AOAM532KxPSd+r4N0BapeobNjr7oOUqYHcLA+DMJhSaWAvQ2Vjv+Cyx3 K6YQ7WEFxkCQGwoR//PO3mZeBn7mSoQKwKYNxAp1mQdJJZQ=
X-Google-Smtp-Source: ABdhPJwo+V9dtnUi/SgxoCpq0d+t6qebYrdjo1hn7mvrMX97A93ul8LnUrnuTX0LF7CVSENMTscBuGybNbLB/AMcLog=
X-Received: by 2002:a17:902:7c01:b029:d8:ee2a:ce88 with SMTP id x1-20020a1709027c01b02900d8ee2ace88mr1223216pll.22.1606366044062; Wed, 25 Nov 2020 20:47:24 -0800 (PST)
MIME-Version: 1.0
From: Gyan Mishra <>
Date: Wed, 25 Nov 2020 23:47:13 -0500
Message-ID: <>
To: BIER WG <>, Greg Mirsky <>, Greg Shepherd <>, Gyan Mishra <>, Michael McBride <>, Tianran Zhou <>, Tony Przygienda <>, Xiejingrong <>
Content-Type: multipart/alternative; boundary="0000000000006f886005b4fb3d10"
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 04:47:27 -0000

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.
   of OAM BIER tools is essential for the productive operation of BIER


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.




*Gyan Mishra*

*Network Solutions A**rchitect *

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