Re: [Bier] draft-ietf-bier-ipv6-requirements-09

Tony Przygienda <> Thu, 19 November 2020 07:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCE693A109A; Wed, 18 Nov 2020 23:09:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, 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 UqdC092ACkd3; Wed, 18 Nov 2020 23:09:11 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8C153A1093; Wed, 18 Nov 2020 23:09:10 -0800 (PST)
Received: by with SMTP id w10so4388803ilq.5; Wed, 18 Nov 2020 23:09:10 -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 :cc; bh=R4T04ww7FhULIqynX5i5zfmwtSWqfYSuaabCo0BGKk0=; b=RnhWu2BaMaQReK/3Vn5Sk87eDt+rxYsqy5Qu3kYb+K0w2VKclsZFhPyUEULAhmeiuY ffZUluQUBGTMv5BTl9z/ZHhoOlfCwvulIkEB3l+B3BH8pUmuZF/h9VRXkPeVIoktMJr3 ClXxkMoMQFeE4KzN1SRdfdyJJTBsJUrc1FIln0qIRbvsJyoVyPMeP3MsmPlqH6iZXrHR vsywffkfO8Z7MmtxVpTyHH8UiNhiB66EdXN8tR8pzWvK7nkh9Tz97eDmYvkF27O2aMgq vBjZfL1L9UzGTgLSpmm5J4pBXn+WQXWjGCMnYrVf5q7sGtemrr/nbypZTYYr6GqHVUiE F4hQ==
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:cc; bh=R4T04ww7FhULIqynX5i5zfmwtSWqfYSuaabCo0BGKk0=; b=o0KvZ56ZPevYliQQhb1bozf9OMzG7aqEISJGb6rFzv2J+9AFcqw76DDQ79V6Ykfg5O RZ2Cu6hZz2EP8RIvJWLsDbNG0JUPNuNodLne/b6nEWBX0rxSsb9A7gB87l71qM32hzqx kzlb/OvQH26QI8mTukZ7dD8urZg20opCjZ3KTMuuguNVF4xYmsrxKj58UTarYySXzrQY X6/YQk8klrvOz8JBiIjhYw2SSCw4W2v+3mti2dn02Ye2XX8pfFxHcRDJwykr/QLK/hJt TC8v68c2VAAgwayY6oGlQv7MSUflTOzuIMtOP9qrdJBEleYqD8jXv1DLESkXBNPHuUe+ YeBg==
X-Gm-Message-State: AOAM530kjr4XkNNfLjtVbieMDX5wjmOKxmL8Jh3YGTM1h9ALMNEuaBgm WWplP6KtzBaql5gasog0UL94NHdRiwHn10deB7s=
X-Google-Smtp-Source: ABdhPJx/8yiZ+QVpX4Ob334IyYEgW3pVwdZerMvACjIvzjgv8RIyCe62ZKKy/dlib4Y9tzraV6EASSaIwDBKQmcdJZE=
X-Received: by 2002:a92:2454:: with SMTP id k81mr4018589ilk.156.1605769750115; Wed, 18 Nov 2020 23:09:10 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Tony Przygienda <>
Date: Wed, 18 Nov 2020 23:08:33 -0800
Message-ID: <>
To: Alvaro Retana <>
Cc: Gyan Mishra <>, "Jeffrey (Zhaohui) Zhang" <>, draft-ietf-bier-ipv6-requirements <>, Greg Shepherd <>, "" <>, BIER WG <>
Content-Type: multipart/alternative; boundary="0000000000008c011e05b47067cb"
Archived-At: <>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09
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, 19 Nov 2020 07:09:13 -0000

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

On Wed, Nov 18, 2020 at 7:50 PM Alvaro Retana <>

> On November 19, 2020 at 3:18:58 AM, Gyan Mishra wrote:
> Hi!
> Just a couple of comments.
> > On Wed, Nov 18, 2020 at 11:29 AM Jeffrey (Zhaohui) Zhang wrote:
> ..
> > > From: Gyan Mishra
> > > Sent: Wednesday, November 18, 2020 10:14 AM
> ...
> > > > Alvaro mentioned as far as the list of requirements that they were
> > > > fairly basic but maybe needed some more meat behind it such as the
> > > > “support various L2 link types” but we did not specify. In previous
> > > > versions we stated L2 agnostic and then switched to various but being
> > > > vague on which L2. Alvaro also mentioned why OAM should be a
> > > > requirement. We may want to add a sentence on justification as to
> why we
> > > > picked BIER IPv6 requirements as required versus optional.
> > >
> > > Zzh> I actually don’t think L2 link types is a key issue. Whatever
> modern
> > > L2 links that an operator wants to use, it’ll need to be supported
> both by
> > > IPv6 and BIER, and it is as simple as adding a codepoint for the L2
> header
> > > to indicate whether the next header is IP/MPLS/BIER/whatever (again –
> the
> > > beauty of clear and independent layering).
> > >
> > Gyan> I don’t think Alvaro was saying there was any issue but just
> pointing
> > out that we did not specify which link types. We can discuss with authors
> > what link types we should add explicitly.
> <individual hat on>
> It was Loa, not me, who raised the point about the L2 requirement
> being vague.  I do agree with him.  I also agree with Jeffrey on his
> point that "modern L2 links that an operator wants to use, it’ll need
> to be supported".  To me, this then becomes another general
> requirement -- unless there's a special reason to add or exclude
> something.
> I did say that the mandatory requirements are general and broad.  For
> example, "support the BIER architecture" is obvious, and I assume both
> solutions do.  BTW, "deployments with BIER-incapable routers" is also
> covered in rfc8279.
> My comment about OAM was along the lines of the fact that there is no
> standard BIER OAM mechanism defined.  It seems like a stretch to
> require BIER functionality that has not been defined.  A better
> approach might be to explain the required functionality (for example,
> continuity, liveliness, etc.).
> ...
> > > Zzh> With the above consideration, I would say the “suggested next
> steps”
> > > in my presentation is quite reasonable.
> > >
> > Gyan> Let’s have the chairs and AD chime in on this thread.
> <AD hat on.>
> As I mentioned on the call, my opinions on this thread are as an
> individual.  The Chairs are more than capable of providing direction
> and don't need me for that.
> Thanks!
> Alvaro.