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

Gyan Mishra <hayabusagsm@gmail.com> Wed, 25 November 2020 15:40 UTC

Return-Path: <hayabusagsm@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 72F303A18E7 for <bier@ietfa.amsl.com>; Wed, 25 Nov 2020 07:40:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
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: 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 JwQsfLm0GppM for <bier@ietfa.amsl.com>; Wed, 25 Nov 2020 07:40:09 -0800 (PST)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 256353A18E4 for <bier@ietf.org>; Wed, 25 Nov 2020 07:40:09 -0800 (PST)
Received: by mail-pg1-x529.google.com with SMTP id t21so2770802pgl.3 for <bier@ietf.org>; Wed, 25 Nov 2020 07:40:09 -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=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; d=1e100.net; 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: <d518b2ac16a2468e8aa80bf77d0bc5d9@huawei.com> <MN2PR05MB598184BEDEE585C2519A36D9D4FA0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV1peU2gZGDfpeP3OV4_Cz=7K0TVBWw+OQQe2TR=-NJF=g@mail.gmail.com>
In-Reply-To: <CABNhwV1peU2gZGDfpeP3OV4_Cz=7K0TVBWw+OQQe2TR=-NJF=g@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 25 Nov 2020 10:39:57 -0500
Message-ID: <CABNhwV0A+aNgQyMWLbTnsvZeGH2EWOvtDg97a_V3=S4vtifOSg@mail.gmail.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
Cc: BIER WG <bier@ietf.org>, "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
Content-Type: multipart/alternative; boundary="000000000000f8494605b4f03d65"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/D_v1ADJ232vWWdCzIOb1PIZ52Ag>
Subject: Re: [Bier] What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09
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: Wed, 25 Nov 2020 15:40:12 -0000

On Wed, Nov 25, 2020 at 10:29 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> Please see Gyan2>
>
> On Wed, Nov 25, 2020 at 8:56 AM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper.net> wrote:
>
>> Please see zzh> below.
>>
>> -----Original Message-----
>> From: Xiejingrong (Jingrong) <xiejingrong@huawei.com>
>> Sent: Tuesday, November 24, 2020 10:27 PM
>> To: Gyan Mishra <hayabusagsm@gmail.com>om>; Jeffrey (Zhaohui) Zhang <
>> zzhang@juniper.net>
>> Cc: BIER WG <bier@ietf.org>
>> 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 [mailto:hayabusagsm@gmail.com]
>> Sent: Wednesday, November 25, 2020 9:34 AM
>> To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
>> Cc: Alvaro Retana <aretana.ietf@gmail.com>om>; BIER WG <bier@ietf.org>rg>;
>> EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Tony Przygienda <
>> tonysietf@gmail.com>gt;; draft-ietf-bier-ipv6-requirements <
>> draft-ietf-bier-ipv6-requirements@ietf.org>gt;; gjshep@gmail.com
>> 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
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



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