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

Tony Przygienda <tonysietf@gmail.com> Fri, 20 November 2020 05:36 UTC

Return-Path: <tonysietf@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 A8E893A189B; Thu, 19 Nov 2020 21:36:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 TdciByv2AzSD; Thu, 19 Nov 2020 21:36:23 -0800 (PST)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 B70743A18BA; Thu, 19 Nov 2020 21:36:17 -0800 (PST)
Received: by mail-il1-x12b.google.com with SMTP id z14so5795619ilm.10; Thu, 19 Nov 2020 21:36:17 -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=5uJsqnLYRjGnLEm5hshiNl3xpvBVYE7MDOYutuBDHxg=; b=D8KJ0pRd7CwHUJ1co0rEy3Wc/jF5I+X6ChUtQTZHVBQmXyGNORTHjZABU4zKPX1UW3 mk2DQ2KUu+e9yRPsBnBZ3KVPLKCsk43GjyPtVqrVIwlIjD67ynx6d0FjA+f7IZgeloid hrpCMrFkYil/9JPywyUC7ZdV5vUTEDFs3+cMGL1HHeajKrOpIFaRMWTE5cycVdCpgtKy D8cNx+V/DnZgJ/ONxgVZzVuq+J6kC1zpWAvvAcQdgwX2L8DLK24Lgodr6ibmrj3hn8gc 4o1ZhkYRbAg+F7XYKSUDaYluLejHh45xtFLGC3bIms2L+pgnVw+vrkF2cJqouH0Z2E59 5QYw==
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=5uJsqnLYRjGnLEm5hshiNl3xpvBVYE7MDOYutuBDHxg=; b=cPGRco4bU9rUOp43abha15qWrQwkZIi6G7hzZcuX35sE7ITuxDLbvcaBITXge4VjfV nTtWQMA94pQn6kSzlNCxF73gSdol3fzBY1/IUpmEz1BRe0IFA1MLDSffelGuLzt8UZPZ NmWTxtNFNCcR9bYWkfFWj345fnLoZ4whlFI9PHTns1K00SuyKeYwfm8wrwY0kQl+72M7 xUQ7kK4ICORgRRPaa4sYEOFWUUDpeK/zCpPTdu8U7I5coIjw28QwrEf/f7pEDbMu67Ne j8mGzAELxyUR6jUVzfcetWl99h7jQLBXM/+iiuhYndRIwv/gdyJdogGLB8lA5JT0gx95 aIBg==
X-Gm-Message-State: AOAM533wMp0NChOGmL0BxkFPM7JH9oIvJJ8+32JMTgnflLW+Ztvlin6K z06To6zBRUErgCyuFlGMyUR4qm87BBWdPOYdYsQ=
X-Google-Smtp-Source: ABdhPJwrUft/4dJLfU9D6jkOfgoWWTTXa++nmAZZXaEUAqQuLczz6qO145c/Pp2Yl673h+7ByHOPRYqkc554zHWSVaQ=
X-Received: by 2002:a92:2454:: with SMTP id k81mr7921500ilk.156.1605850576695; Thu, 19 Nov 2020 21:36:16 -0800 (PST)
MIME-Version: 1.0
References: <CABNhwV0aZRqXP2wAweEktsibTYpHqHhDB9OTPkO+1JmyOb7-gA@mail.gmail.com> <MN2PR05MB5981CEBAA6AB7329350293EED4E10@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV26CqDs8vwT=mcPQMVGVTFLVEOgVYtaYZyuyNiBFMYGcw@mail.gmail.com> <MN2PR05MB5981CB5AB50C0641A54DDCDAD4E00@MN2PR05MB5981.namprd05.prod.outlook.com> <CABFReBqJ5HVUBzbNv-LjYsCqjdvtNvXtdOjCscGftkBrVtbEmA@mail.gmail.com>
In-Reply-To: <CABFReBqJ5HVUBzbNv-LjYsCqjdvtNvXtdOjCscGftkBrVtbEmA@mail.gmail.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Thu, 19 Nov 2020 21:35:40 -0800
Message-ID: <CA+wi2hMTxELaf6MQv2ocdp7nxeOusW_dv6hUZ6O2uRZa=ob6Qg@mail.gmail.com>
To: Greg Shepherd <gjshep@gmail.com>
Cc: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, Gyan Mishra <hayabusagsm@gmail.com>, Alvaro Retana <aretana.ietf@gmail.com>, BIER WG <bier@ietf.org>, "EXT-zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>, draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>
Content-Type: multipart/related; boundary="00000000000030686d05b483395d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/cLTaZ3JY2mvqrdOZZZUH-A8-sm8>
Subject: Re: [Bier] 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: Fri, 20 Nov 2020 05:36:28 -0000

Well, I’m glad that the work on requirements draft, albeit as product found
wanting in AD’s assessment, has led to clarification of the crucial
questions that e'one seems to agree need to be asked.

It surprised me then mildly that my co-chair had to explicitly lay out the
semantics of what was a clear direction spelled out during the meeting but
that’s all well to get e’one better in sync I guess. Needless to say I am
sharing his assessment and questions put to the room entirely.

Some things that I think need explicit spelling out IMO after the last few
meetings (since I’m not sure e’one in the process internalized that) is
that WG is not here to tell people they cannot work on something whatever
the perception seems to be, IETF doesn’t work that way. People go sideways
and build stuff based on what we publish/develop in open source and for
their customers in all kind of ways which may be neither fitting into an
architecture, consensus or interest of a WG all the time. And that’s
wonderful and more power to them, RFCs are free to download and they are
just RFCs, they are not stone tablets brought from the mountain. However,
and that's a big however, _if_ a work is looking for WG adoption and
ultimately RFC status, the IETF process kicks in and the process has been
here and well debugged over 30 years and that’s why Internet was built IME.
The process is unusual in the way that it resists pretty well pressure
based on non-technical claims, exceedingly poor architectural choices,
chair shopping, padding of communication channels with “I participated only
once to send a +1 to a list”, ad-hominem attacks and similar shenanigans
that have been all tried over and over again. In the same vein the process
tends to weigh based on reputation of “who said what in which context”';
such reputation being built on community service and sound work over many
years. And sometimes hard calls are made based on rough consensus called by
people that are here to steer stuff and nudge it along the way. Sure, it’s
easy to standardize and build “something”, it’s very hard to keep it going
operationally @ Internet scale for 20 years and lots of those lessons are
unfortunately scar tissue not easily transferred except at level of
RFC1925. Last point to emphasize is that BIER is not the average set of
RFCs, we have been handed the permission to go into the hourglass of the
Internet, something that happens every 15 years or so. The stuff we deliver
is as fundamental as MPLS or IP forwarding plane and as PS has to meet
toughest architectural standards to prevent a melt-down of non-orthogonal,
under’spec’ed solutions leading to poor operational properties @ scale and
non-interoperable solutions which long-term serves no'one well that relies
on IP technology to support high quality infrastructure @ scale.

--- tony



On Thu, Nov 19, 2020 at 9:39 AM Greg Shepherd <gjshep@gmail.com> wrote:

> GS - Inline:
>
> On Thu, Nov 19, 2020 at 3:26 AM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper.net> wrote:
>
>> Hi,
>>
>>
>>
>> One thing that I want to emphasize at the top is that existing solution
>> (referred to as BIERin6) is not v4 specific. It is v4/v6 orthogonal.
>>
>>
>>
>> Please see zzh2> below.
>>
>>
>>
>> *From:* Gyan Mishra <hayabusagsm@gmail.com>
>> *Sent:* Wednesday, November 18, 2020 5:19 PM
>> *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>; Greg Shepherd <
>> gjshep@gmail.com>gt;; Tony Przygienda <tonysietf@gmail.com>om>;
>> draft-ietf-bier-ipv6-requirements <
>> draft-ietf-bier-ipv6-requirements@ietf.org>
>> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>>
>>
>>
>> *[External Email. Be cautious of content]*
>>
>>
>>
>>
>>
>> Hi Jeffrey
>>
>>
>>
>> Please see in-line below
>>
>>
>>
>> On Wed, Nov 18, 2020 at 11:29 AM Jeffrey (Zhaohui) Zhang <
>> zzhang@juniper.net> wrote:
>>
>> Hi Gyan,
>>
>>
>>
>> Please see zzh> below.
>>
>>
>>
>> *From:* Gyan Mishra <hayabusagsm@gmail.com>
>> *Sent:* Wednesday, November 18, 2020 10:14 AM
>> *To:* Alvaro Retana <aretana.ietf@gmail.com>om>; BIER WG <bier@ietf.org>rg>;
>> Greg Shepherd <gjshep@gmail.com>om>; Jeffrey (Zhaohui) Zhang <
>> zzhang@juniper.net>gt;; Tony Przygienda <tonysietf@gmail.com>om>;
>> draft-ietf-bier-ipv6-requirements <
>> draft-ietf-bier-ipv6-requirements@ietf.org>gt;; EXT-zhang.zheng@zte.com.cn <
>> zhang.zheng@zte.com.cn>
>> *Subject:* draft-ietf-bier-ipv6-requirements-09
>>
>>
>>
>> *[External Email. Be cautious of content]*
>>
>>
>>
>> All
>>
>>
>>
>> I would like to thank the Greg, Tony and Alvaro on their pointers and
>> guidance this morning to help move the ball forward with the requirements
>> draft.
>>
>>
>>
>> What I heard from Greg which rang out loud and clear and I mentioned to
>> the requirements authors that today we have BIER MPLS where the BIER header
>> is encoded into MPLS label stack layer 2 1/2 and we also have non MPLS BIER
>> Ethernet ether type 0xAB37.
>>
>>
>>
>> So why do we need non MPLS BIER encapsulation in an IPV6 environment as
>> that IPv6 environment can be supported by non MPLS BIER Ethernet.  The case
>> and point here is that eventually just as ATM and Frame Relay now live in
>> the technology graveyard so will at some point in time as SRv6 matures will
>> become the end all be all “core transport” mechanism for all operators.  So
>> that being said we need a another encapsulation method to carry BIER , and
>> per RFC 8296 that gap is filled with Non MPLS BIER Ethernet encapsulation
>> today which will work for future SRv6 transport once MPLS goes by the
>> wayside.
>>
>>
>>
>> Zzh> First of all, the requirement draft does **not** mention SRv6 **at
>> all**, and that’s a draft that have been worked on for almost two years.
>>
>>      Gyan>As we worked on the revision 7 we did discuss SRv6, however we
>> did not add to the draft as a requirement because it’s supported today with
>> BIER Ethernet which is my point as to the “why” do we need Non MPLS BIER in
>> IPV6 environment.  Also in IPV6 environment since SRV6 uses the IPV6
>> forwarding plane there should not be any issue with it working.  We can
>> revisit if we want to add as a requirement and I think their is merit to
>> add.
>>
>>
>>
>> Zzh2> As I mentioned below, even if SRv6 is added to the requirement,
>> existing solution will still work nicely with it, still with nice
>> independent layering separation, and without the issues with
>> draft-xie-bier-ipv6-mvpn, and actually w/o the need for procedures in that
>> draft.
>>
>> Zzh> Secondly, SRv6 will still be on top of L2 links (whatever modern or
>> graveyard L2 links). When BIER can work over L2 links directly, why bother
>> add another layer.
>>
>>
>>
>>      Gyan>Agreed.  That is my point why do we need IP encapsulation is
>> the big question we need to answer in the draft.
>>
>> Zzh> Finally, even if one wants to do SRv6 between BFIR and BFER just
>> because SRv6 is taking over the world, it can be done with clean layering.
>> Taking MVPN/EVPN with SRv6 as an example, you can first put on SRv6 header
>> with a well-known multicast locator and a func/arg portion identifying the
>> VPN. You can do fragmentation/ESP/whatever with it and then hand it to BIER
>> for replication across the network, just like how you send an SRv6 packet
>> across L2 links. This will avoid the problem of having to use the source
>> address for identifying VPNs (I’ll follow up on my previous comments on
>> draft-xie-bier-ipv6-mvpn).
>>
>>
>>
>> Gyan> Agreed.  We have to work on BIER IPv6 MVPN draft.
>>
>>
>>
>> Zzh2> We actually don’t need that one with BIERin6 😊
>>
>> Zzh> Notice that this transporting SRv6 multicast over BIER (L2.5) just
>> like transporting SRv6 unicast over L2.
>>
>>     Gyan> Agreed.  I don’t see any issue with SRv6 with BIERin6
>> independent model
>>
>> Zzh> Then, when BIER needs to go over non-BFRs and IPv6 tunnels are used
>> for that, BIER itself can be over IPv6 tunnels (just like over any other
>> tunnels like MPLS or even L2TP if one will). That’s the beauty of clear and
>> independent layering.
>>
>> Gyan> Agreed
>>
>> At the beginning of the presentation Greg corrected me and stated that
>> that after the BIERin6 independent model draft was published, that the
>> requirement draft came about to build a set of requirements as to the “why”
>> we need BIER to work in a non MPLS BIER in an IPv6 environment when we
>> already have the BIER Ethernet encapsulation that fits the bill and works.
>>
>>
> GS - See my previous email response. The reqs draft came about after the
> BIERv6 draft was published, not after BIERin6. The WG had no issues with
> BIERin6 draft, other than limited WG interest at that time so it sat on
> ice. When BIERv6 draft was published, many concerns were raised, the
> conversations began looping in confusing miss-information twisters:
> Transitional mechanism? Not transitional? "Integrated" into the v6 fwd
> plane?, etc.. So it was clear we needed a document to follow to ensure we
> are all hearing and agreeing to the same information.
>
>
>> Zzh> It’s more like why we need to require IP encapsulation.
>>
>>  Gyan> As IPv4 is being eliminated from the core as we speak with
>> proliferation of IPv6 in the core even before SRv6,  LDPv6 and SR-MPLSv6
>> the direction is softwire mesh framework v4 or v6 edge over a v6 core.  So
>> if we are now or future it’s more like IPv6 not IP which implies IPv4
>> implicitly but could mean either IPv4 or IPv6.  I have a draft in BESS that
>> eliminates IPv4 at the edge using RFC 5549 next hop encoding vendor
>> consortium of interoperability testing so IPv4 will be soon eliminated from
>> P core and PE edge.
>>
>>
>> https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4nlri-ipv6nh-use-cases/
>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mishra-bess-ipv4nlri-ipv6nh-use-cases/__;!!NEt6yMaO-gk!WB6X0WzZxH1qWs9j87NdQcGlaSKn_5HG6ElV5zZjQxxrEKa9i-NlVPrqqnfW3sSZ$>
>>
>>
>>
>> zzh2> Indeed the real question is why do we need IPv4/v6 encapsulation.
>>
>> So that’s the million $$ question we are trying to solve here with the
>> requirements draft.
>>
>>
>>
>>
>>
>> As for the IPV6 6MAN questions, I was brought on board by Mike McBride as
>> the IPv6 SME as well as multicast SME - but point being member of 6MAN for
>> many years so a go between liaison with 6MAN related to any questions
>> regarding following the IPV6 specification for extension header usage per
>> RFC 8200.  Both solutions drafts had been reviewed by myself and 6MAN and
>> no technical issues were found regarding the solutions.
>>
>>
>>
>> Zzh> BIERv6 **can** be make to work, but at this time many of us are not
>> convinced that it is needed, and it does have its complications (both at
>> BIER layer itself and at flow overlay layer like with MVPN/EVPN – we can
>> have separate discussion on that). There are many 6MAN people with
>> different opinions – some say BIERv6 is good (from IPv6 point of view) and
>> some others will point out its problems even just from IPv6 point of view
>> (even when not considering BIER/MVPN).
>>
>> Gyan> I have discussed BIERv6 with many folks on 6MAN as well and the
>> response is the solution is  sound no issues.  We can discuss on separate
>> thread.
>>
>> Zzh2> I now see new emails on the BIER list about that.
>>
>> 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.
>>
>> We need to add some more meat in the introduction or maybe even a
>> separate section as to what gap is being filled by non MPLS BIER in IPv6
>> environment using IPv6 encapsulation and encoding the BIER header versus
>> Non MPLS BIER Ethernet.  Also maybe use the requirements section to see if
>> a new requirement that maybe a gap that is not covered by non MPLS BIER
>> Ethernet that can be covered by non MPLS BIER in an IPv6 environment.
>>
>>
>>
>> Zzh> Shouldn’t we just list the requirements in the requirements section,
>> and then evaluate different solutions using the requirements draft as
>> guidance?
>>
>>  Gyan>  Greg and Tony can correct me but from what I heard is that we
>> need to answer the “why” do we need Non MPLS BIER solution in an IPV6
>> environment as we already have the L2 Non MPLS BIER Ethernet solution that
>> will work for any next header encapsulation type and will support IPv6.  So
>> that goes for any IPv6 environment solution including BIERin6 - why do we
>> need it.  So I and some of the other authors agree that is missing so we
>> need to add verbiage around that which is separate from the requirements
>> section.
>>
>> Zzh2> The real questions are: 1) why do we need IPv6 encapsulation
>> (BFIR->BFER or between adjacent BFRs) 2) Even if you do, where do you put
>> the BIER header. 1) is a requirement question, and 2) is a solution
>> question.
>>
>>
> GS - ^^^This. Thanks Jeffrey.
>
>
>> Zzh2> With BIERin6, 2) has the clean, simple layering property: if you do
>> need BFIR->BFER IPv6 encapsulation, IPv6 is the BIER payload; if you need
>> BFR->BFR encapsulation (either directly or indirectly connected), BIER is
>> the IPV6 payload.
>>
>> At the end of the call when we rolled through the last two drafts and
>> went into overtime I heard the ask for call for adoption for BIERin6
>> independent model.
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/
>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zhang-bier-bierin6/__;!!NEt6yMaO-gk!TOnu1Jmv8QPEdOl5pPzFJK-hl8nqGL6C2I94f4HdluKFdjsXQOc5-qph9Dk4t1B7$>
>>
>>
>>
>> I would not think we are ready to adopt any non MPLS BIER in IPV6
>> environment solution if we still do not have the requirements set as to the
>> gap that is being filed and problem being solved that cannot be done today
>> with non MPLS BIER Ethernet.
>>
>>
>>
>> Zzh> After almost two years of requirement work, we’ve identified a set
>> of mandatory/optional requirements. My presentation aims at showing that
>> BIERin6 addresses all those requirements with the **existing** solution
>> so it is good for the WG to adopt the mature solution, instead of leaving
>> people an impression that we don’t have a solution.
>>
>>      Gyan> Given what Greg and Tony stated as far as the requirements
>> draft as what is missing related to the “why” we need any IPv6 environment
>> solution I think “any” means any which include BIERin6.  We may need some
>> clarification from the chairs on this.
>>
>>
>>
>> Zzh2> My understanding is the question is “why we need IPv6
>> encapsulation” (especially BFIR->BFER). BIERin6 does not
>>
> require BFIR->BFER encapsulation, but it works nicely with that.
>>
>
> GS - ^^^And this. As I said before, the WG had NO issues with BIERin6. The
> reqs draft came about as a means to document the WGs direction in this
> space in the light of BIERv6.
>
> Zzh> As for BIERv6, maybe after additional requirements work we’ll
>> eventually agree that there is a need for it and then it could be adopted
>> at that time. That should not block the progressing of BIERin6 until we
>> find a need for BIERv6 😊
>>
>>
>>
>> Gyan> My POV is the requirements draft applies to both solutions on the
>> table.  So if we have not answered the why how can we have any solution let
>> alone adopt any.  It does sound like a setback but it could easily be a
>> quick silver lining that immediately moves both drafts to WG adoption.  I
>> think if we update the introduction section to answer the “why” question
>> and then maybe a round of cleanup of the requirements section I think we
>> can move the ball forward on the requirements draft and that would allow
>> both solutions drafts to adopted.
>>
>>
>>
>> My take is I don’t think the BIERin6 is exempt from having to meet the
>> requirements laid out in the requirements draft which includes “why” have
>> we spent 2 years developing a solution which we don’t even know why we need
>> it.  I would say both solutions are in the same boat.
>>
>>
>>
>> Zzh2> The requirements draft certainly applies to both solutions. My
>> points are: 1) so far all the requirements listed in the draft are
>> satisfied by BIERin6 2) The main question from the chairs is “why we need
>> IPv6 encapsulation”
>>
>
> GS - Yes, this is the original and lingering question.
>
>
>> Zzh2> As I mentioned above, BIERin6 does not require IPv6 encapsulation,
>> though it can nicely work with IPv6 encapsulation.
>>
>> Zzh2> As a result, I don’t see why BIERin6 needs to be held back – why
>> should we hold back BIERin6 until you find a requirement that warrants
>> BIERv6? If that requirement does come up, BIERv6 can be adopted at that
>> time.
>>
>> Zzh2> BTW, my understanding is that if BIERv6 were not brought up, we
>> would not have needed the requirements draft work 😊
>>
>> 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.
>>
>>
>>
>> The flip side of the comment above is that if we are ready to adopt and
>> we decided we can skip answering the “why” questions, so then do we need
>> the requirements draft at all if that’s the case as we have made the
>> decision to go with a single solution and are closing the door on any other
>> options.  If the latter then we hang tight on any adoption of any solution
>> and wait till the requirements draft is completed and adopted followed by
>> moving forward with adopting any solutions.
>>
>>
>>
>> Zzh> As I mentioned in my presentation, additional solutions can be
>> pursued but only if they offer significant advantages. Otherwise, why
>> should IETF/vendors/operators spend time on them? So we indeed have a “why”
>> question – why BIERv6.
>>
>>  Gyan> Agreed.  But I still think we have the which comes first the
>> chicken or the egg.  The chicken being BIERin6 or the egg being finalizing
>> the requirements draft.  I am not trying to hold up BIERin6 from WG
>> adoption but that is my take from the chairs.
>>
>>
> GS - Curious to hear your thoughts now that I've added clarity as to "what
> the chairs said", and to the overall history of the process.
>
> Thanks,
> Greg
>
>
>> Zzh2> To rephrase, the why question for the requirements draft is “why
>> IPv6 encapsulation”, and that answers “why BIERv6” question. Again, BIERin6
>> works nicely with IPv6 encapsulation as well.
>>
>> Zzh2> Jeffrey
>>
>> Zzh> Thanks.
>>
>> Zzh> Jeffrey
>>
>>
>>
>> Kind Regards
>>
>>
>>
>> Gyan
>>
>>
>>
>>
>>
>> --
>>
>> [image: Image removed by sender.]
>> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!TOnu1Jmv8QPEdOl5pPzFJK-hl8nqGL6C2I94f4HdluKFdjsXQOc5-qph9DU3E7y5$>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>>
>> *M 301 502-1347 **13101 Columbia Pike*
>> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!WB6X0WzZxH1qWs9j87NdQcGlaSKn_5HG6ElV5zZjQxxrEKa9i-NlVPrqqq6twCEV$>
>>   Silver Spring, MD
>> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!WB6X0WzZxH1qWs9j87NdQcGlaSKn_5HG6ElV5zZjQxxrEKa9i-NlVPrqqq6twCEV$>
>>
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>> --
>>
>> [image: Image removed by sender.]
>> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!WB6X0WzZxH1qWs9j87NdQcGlaSKn_5HG6ElV5zZjQxxrEKa9i-NlVPrqqisVX69W$>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>>
>>
>> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>>
>>
>>
>> Juniper Business Use Only
>>
>