Re: [Bier] What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Gyan Mishra <> Wed, 25 November 2020 15:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72F303A18E7 for <>; Wed, 25 Nov 2020 07:40:11 -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 JwQsfLm0GppM for <>; Wed, 25 Nov 2020 07:40:09 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 256353A18E4 for <>; Wed, 25 Nov 2020 07:40:09 -0800 (PST)
Received: by with SMTP id t21so2770802pgl.3 for <>; Wed, 25 Nov 2020 07:40:09 -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=GpFd8ocvH+f3vr0RdSfiGNNvRFkofZTRGVYr9Tx7584=; b=kJVY2VztublzYfz1shGCRTA1ZlaHnQu19nbK1d5b9pp8KBKu0HdWC/F3vGeSvGe8Yq xlXk8me9rvMkYjBP3qAhBijQGxRl4YeDJBLSLz1bXVLsqg9j6+IhKPtSJP6pq9ZHRoFJ Zzjj/MoFE+t0dNijl0iJzBhLTjYk8Doij75FhzyOVIIx+fiQcOBN9lJyRCR16LOixO9L xcvr05hHtouHkRWmBWmGhjGlHQb6d0AZsx9qZIMdssrP06nOjuMy0tLfbsLb/EbalHG3 yUnPyePnfr5hH9AeoNROD6TtoPl0RKbg7V14CuSjYQnM0rV9UJZ0pwOILRCxnQfx483t FnQQ==
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=GpFd8ocvH+f3vr0RdSfiGNNvRFkofZTRGVYr9Tx7584=; b=h8PrK5v+gInXrTEibrErh8MfoJq5t84T+EisVlzNLcb0j68NPhldY/z0yL5XNOTxaa FkhBr4lGZI+TEA928b3hzKWrUs2msehThq9oMHLjjr5LJXcjAco6CW8RAe0k3VyHWc55 jbkbm4S7YH1sa9+bZwBr0Xm1B/9SuI3eaG7rJbmmNGx8QaM+ZdIvAn+JoCKcElMXrtIF DIm7un7M2NjwxbZHe29rnoIDGB7kXaINK/3hjTbKrVWDy3dXhaqB4nqYAeAxgfFe7PXt CfAH4B3FaQ1cD7l12F//b+OgTxsdJbb6MoVtVInIcI4nrsKdH1PIgamTEWeryTbfRBCs hjcA==
X-Gm-Message-State: AOAM531iACELXpMl/Nd01wtCL2lMYgIrB735oy+y4y8AQH6+xTIXKuMp FZocjKhN1YJHgpA9i+P5SQjPpk8CxMtlaoGXWyk=
X-Google-Smtp-Source: ABdhPJyrlhCxbEQtz0Ef/DtCgmcFCLslHa928mPjse/WRRo4YiytMqK1ZWF/nNJ8g2pNHgcTh2t87OEoL1lG89Wjfug=
X-Received: by 2002:a65:4241:: with SMTP id d1mr3450038pgq.18.1606318808384; Wed, 25 Nov 2020 07:40:08 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Wed, 25 Nov 2020 10:39:57 -0500
Message-ID: <>
To: "Jeffrey (Zhaohui) Zhang" <>
Cc: BIER WG <>, "Xiejingrong (Jingrong)" <>
Content-Type: multipart/alternative; boundary="000000000000f8494605b4f03d65"
Archived-At: <>
Subject: Re: [Bier] What does BIERin6 propose to satisfy the requirements? //RE: 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: Wed, 25 Nov 2020 15:40:12 -0000

On Wed, Nov 25, 2020 at 10:29 AM Gyan Mishra <> wrote:

> Please see Gyan2>
> On Wed, Nov 25, 2020 at 8:56 AM Jeffrey (Zhaohui) Zhang <
>> wrote:
>> Please see zzh> below.
>> -----Original Message-----
>> From: Xiejingrong (Jingrong) <>
>> Sent: Tuesday, November 24, 2020 10:27 PM
>> To: Gyan Mishra <>om>; Jeffrey (Zhaohui) Zhang <
>> Cc: BIER WG <>
>> Subject: What does BIERin6 propose to satisfy the requirements? //RE:
>> draft-ietf-bier-ipv6-requirements-09
>> [External Email. Be cautious of content]
>> (to make clean, raise a new topic)
>> I am confused too by the claiming a solution can do everything and it is
>> an "existing" solution, while requesting allocation of IPv6 Next Header /
>> IPv4 Protocol value which is non-trivial.
>> Zzh> Comparing requesting a "next header" value for BIER, and specifying
>> an IPv6 DOH to encode BIER and standardizing draft-xie-bier-ipv6-mvpn,
>> which is more trivial?
>     Gyan2> BIERv6 follows RFC 8200 specification in using DOH to encode
> BIER for hop by hop en route processing.  MPLS BIER has an RFC 8556 for
> MVPN even though it follows standard MVPN procedures RFC 6513 6514.  Non
> MPLS BIER is not any different in that respect but also requires as in IPv6
> environment uses SRv6 BGP Overlay Service.  I think BIERin6 would require a
> draft as well for the optional IPv6 encapsulation for SRv6 environment as
> well.
>> Zzh> I want to point out that w/o draft-xie-bier-ipv6-mvpn, BIERv6 is not
>> complete.
>     Gyan> In fact MVPN we all agreed is not a requirement as BIER can be
> used for single tenant global table multicast GTM as well.
>> We need to know, what does *the* BIERin6 draft propose, and how does
>> *the* BIERin6 draft satisfy the bier-ipv6-requirements.
> Take req-1 as an example, suppose there are PPP-over-SONET(POS, RFC2615)
>> links in an IPv6 network, can the existing RFC8296 solve ? What does *the*
>> BIERin6 draft propose to solve ?
>> Zzh> How does IP work with POS? PPP header has a proto field - a new code
>> point would be assigned for BIER. That is not IPv6 specific.
>     Gyan2> Jingrong’s point is that when BFRs do not use L2 Ethernet
> “already defined solution” in RFC 8296, is when BIERin6 should be used is
> which defined IPv6 encapsulation one hop tunnels. The MAJOR problem we have
> with including an existing solution RFC 8296 L2 “Non MPLS BIER Ethernet” is
> that it is existing and thus overshadows a need for for IPv6 encapsulation
> and to use existing solution and as written in BIERin6 that IPv6
> encapsulation is “optional”.  Why should IPv6 encapsulation be optional
> with BIERin6?  The latter L2 solution has existed since Day 1.  We are
> defining a new solution for IPv6 environment with BIERin6.  The case and
> point here is that most operators in the last 15 years have decommissioned
> all TDM based with Metro Ethernet services.  So in essence with draft
> BIERin6 the way it is written IPv6 encapsulation single hop or multi hop
> tunnels would never be used by operators.
> So then you might as well remove IPv6 encapsulation from the draft as it’s
> an option that would never be used.  Once you do that you are left with RFC
> 8296 use case informational draft and questionable if that is even
> necessary.
> The way BIERin6 is written today it would be very difficult to advance for
> WG adoption.
>> Please note in my question the word *the* does not include anything that
>> RFC8296 can solve. Any existing RFC8296 solution is not belonging to *the*
>> BIERin6 proposal. Please tell us *the* BIERin6 proposal.
>> Zzh> *The* BIERin6 proposal is BIER over L2 and/or tunnels (IPv6 or not).
>> In case of IPv6 tunnels, new code points are needed and that's why it needs
>> to be on standards track, as I already explained.
>     Gyan> The way it’s written IPv6 encapsulation one hop tunnels would
> never be used by operators as it’s overshadowed by RFC 8296.  The way
> BIERin6 reads it as L2 RFC 8296 can be used for multi hop funnels in case
> of Non BFRs as well.  Even if the operator requires BIER to be carried in
> IPv6 it would be doubtful that would get utilized for one hop tunnels as
> it’s easier to just use RFC 8296 L2 for one hop or tunnel.  In essence the
> IPV6 encapsulation would never be used by operators with BIERin6.
> If you think about it BIERIn6 is by definition an oxymoron.  Reason being
> is that with RFC 8296 included as part of BIERin6, BIER header is the outer
> envelope encapsulation so it would be more accurate to say “BIERout6” as
> IPv6 is the payload of BIER in L2 RFC 8296.  The only relevant piece that
> makes sense in every way to be part of BIERin6 is “in” being the keyword
> where the outer encapsulation is IPv6 and BIER is next header thus the “in”
> in BIERin6.
>> Zzh> I had also explained already, why BIERin6 needs to explicitly spell
>> out using *existing* solution (concept, not code point) for IPv6 network -
>> we've wasted two years on this.
>     Gyan> Well hopefully we don’t waste another 2 year on BIERin6 or I
> guess really should be called BIER-in-out-6.

      Gyan2> Another clever way to look at is that BIER-in-out-6 is a way
to squash IPv6 encapsulation with smoke and mirrors as if a there is in a
pretentious way a néw solution is being developed, where in essence we are
actually quite the contrary, as this is the trickery game  “optional”
verbiage to provide a lead on “carrot” if you will that IPv6 encapsulation
is in the spec but really in all truthfulness let it be told the spec is
really BIERout6.

>  I am not in favor of adoption of  BIERin6 the way the draft is written
> today.  We really have to remove the references to RFC 8296 to make this
> draft even viable.
>> Thanks
>> Jingrong
>> -----Original Message-----
>> From: Gyan Mishra []
>> Sent: Wednesday, November 25, 2020 9:34 AM
>> To: Jeffrey (Zhaohui) Zhang <>
>> Cc: Alvaro Retana <>om>; BIER WG <>rg>;
>> <>cn>; Tony Przygienda <
>>>gt;; draft-ietf-bier-ipv6-requirements <
>> Subject: Re: draft-ietf-bier-ipv6-requirements-09
>> Jeffrey
>> About the two lingering points it does shed light on something that has
>> been disturbing me with the BIERin6 solution.
>> I thought about this some more and I think what creates a lot of
>> confusion in my mind with BIERin6 solution is the L2/tunnel component.
>> As the main reason is that the L2/tunnel exists today with RFC 8296 “Non
>> MPLS BIER Ethernet” with the special allocated next header code point to
>> account for BIER next header 0xAB37.
>> I honestly think the L2 should be removed from the BIERin6 draft so that
>> the optional IPV6 encapsulation is no longer “optional” in the draft as
>> that now is the draft.
>> This also provides the “IPv6 encapsulation” commonality with BIERv6 at
>> least showing clearly that their is a strive for commonality and parity
>> between the two solutions.
>> Also the “muddying” of the water is eliminated by removing L2 making the
>> solution crystal clear to operators.
>> Kind Regards
>> Gyan
>> Juniper Business Use Only
> --
> <>
> *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