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

"Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com> Sun, 29 November 2020 11:11 UTC

Return-Path: <gengxuesong@huawei.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 5014D3A140C; Sun, 29 Nov 2020 03:11:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 EQAYSCVMBwAl; Sun, 29 Nov 2020 03:11:54 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48683A13CA; Sun, 29 Nov 2020 03:11:53 -0800 (PST)
Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CkQcm4QFwz67H79; Sun, 29 Nov 2020 19:10:00 +0800 (CST)
Received: from dggema722-chm.china.huawei.com (10.3.20.86) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2106.2; Sun, 29 Nov 2020 12:11:50 +0100
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggema722-chm.china.huawei.com (10.3.20.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Sun, 29 Nov 2020 19:11:49 +0800
Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1913.007; Sun, 29 Nov 2020 19:11:49 +0800
From: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, Michael McBride <michael.mcbride@futurewei.com>, "gjshep@gmail.com" <gjshep@gmail.com>
CC: 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>, Tony Przygienda <tonysietf@gmail.com>, draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>
Thread-Topic: draft-ietf-bier-ipv6-requirements-09
Thread-Index: AQHWvb2PJwgAGQ3A+ki4l6Du/CyxU6nPL2aAgAG+jYCAAX1egIAAdU4AgADMbQCAAEohgIAAHt4AgAAShwCAAD+pgIAAHI8AgAAOFwCAADApAIAAa1oAgAZoSwCAAd1DgIAALFSAgAFicIA=
Date: Sun, 29 Nov 2020 11:11:49 +0000
Message-ID: <963ec51b8a64422095bbe65bd52ca17f@huawei.com>
References: <CABNhwV0aZRqXP2wAweEktsibTYpHqHhDB9OTPkO+1JmyOb7-gA@mail.gmail.com> <CABFReBoFMZwcPrROMB=RbE60TsP4uajUERbE7MVTQD9AjwJ4ag@mail.gmail.com> <CABNhwV3zOqmSetuB92M=8pFFgGmEyq3KvVWat87WfDoBH4j3bg@mail.gmail.com> <MN2PR05MB598132918AFF529C955B15D3D4FE0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV2KOCHCAnFG0P-9V9g4rsz4e=aZ1WEcNSR6bTLW9OCO_A@mail.gmail.com> <MN2PR05MB5981922D4BDC641F5CF3CD20D4FD0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV1NXz8NrEvP3GYLz2PKkGNOU__D7XOOZ6_tbM03xPcNSg@mail.gmail.com> <MN2PR05MB5981824AF7424761E656D36ED4FD0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV2nzBK7YDqBHrAt_3zAZiA7VDJmw-R=wOqTet6QS=Rg0g@mail.gmail.com> <MN2PR05MB5981AEC2E508A34919BBCE6AD4FC0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV100P14rkQjqt-uNHLhcZCow6n2TL4CxReotkzVX=z-4g@mail.gmail.com> <MN2PR05MB5981E2599B59F35B6F880345D4FC0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV25Aj3yQsa171+u=uVZ8fW5n8jWf2RyR_E1BcfZRfM9Pw@mail.gmail.com> <MN2PR05MB5981F0EE725D7C7C1F048462D4FC0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABFReBoPR_KN66hh9s09AtHg5PVKJjKp7Uew6mV3Fe=nafj3MQ@mail.gmail.com> <BYAPR13MB2582AB90BCAFB158A69CBDA1F4F70@BYAPR13MB2582.namprd13.prod.outlook.com> <MN2PR05MB5981B2030531A3ADFC987F50D4F70@MN2PR05MB5981.namprd05.prod.outlook.com>
In-Reply-To: <MN2PR05MB5981B2030531A3ADFC987F50D4F70@MN2PR05MB5981.namprd05.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.105.240]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/xd_RGgwFbDrACOgIkwBbea5KvGI>
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: Sun, 29 Nov 2020 11:11:57 -0000

"
- Adopt BIERin6
- Discuss BIERv6 further
"

I will leave all the technical issues for BIERin6 in another thread to make the discussion coherent. But I can't see the process mentioned above makes any sense. All the optional solutions are supposed to be evaluated on the same footing. If both technically practical and meet all the requirements, both should be accepted. Besides the technical considerations mentioned above, I believe there should not be any other factors that interfere with the WG process.

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] 
Sent: Sunday, November 29, 2020 5:54 AM
To: Michael McBride <michael.mcbride@futurewei.com>; gjshep@gmail.com
Cc: 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>; Tony Przygienda <tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

To clarify, there is no gap in the BIERin6 solution (besides the new "next header" code point). It's just that some text are needed to explain how the requirements are met with the BIERin6 solution - whether it is a requirement already listed in the current requirements draft, or have been brought up in recent mailing list discussions (I know of two in recent discussions).

BIERin6 is based on RFC 8296 (plus the new "next header" code point for IPv6 encapsulation), and is a generic solution with the following properties:

1. clean layering - BIER over L2/tunnel and it can carry different payload types including SRv6 2. IPv4/IPv6 independent (of course you need different signaling) 3. L2 independent - as long as the L2 header can indicate with a code point that a BIER header follows 4. tunnel type independent - as long as the tunnel header can indicate with a code point that a BIER header follows 5. can work one-hop or multi-hop tunnels nicely 6. can work with SRv6 based services nicely

With the above, there is simply no need for another solution in my view. Of course the WG can continue discussing BIERv6 and may determine that it is nice to have BIERv6 as well, but we should not bundle them together when it comes to adoption. That's why I suggested in the last BIER session the following:

- Adopt BIERin6
- Discuss BIERv6 further

Jeffrey

-----Original Message-----
From: Michael McBride <michael.mcbride@futurewei.com>
Sent: Saturday, November 28, 2020 2:15 PM
To: gjshep@gmail.com; Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: 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>; Tony Przygienda <tonysietf@gmail.com>; 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 Greg,

>Thank you Jeffrey and Gyan for sticking with the thread of the conversation to advance the discussion. It's clear now that all of the requirements >discussed so far can be addressed by the BIERin6 draft if we flesh out the discussed gaps.

>I would like to see Jeffrey and Gyan take over as primary authors of
>BIERin6 to include the gaps discussed here so that it fully encompases the requirements so far described, for WG adoption.

I'm sure I'm misinterpreting. What it sounds like you are saying is "I want bierin6 to be adopted so let's fix the gaps so we can begin". Since both solutions meet the requirements, I'm hoping you meant "Let's fix the gaps in bierin6 so we can begin adoption calls for both bierv6 and bierin6".

mike


On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
wrote:

> Hi Gyan,
>
>
>
> Great that we reached consensus on BIERin6.
>
> Now there are two lingering points alluded to in this thread, but 
> given it’s been such a long and deeply nested tread, I’ll start a new 
> thread about it.
>
>
>
> Thanks.
>
> Jeffrey
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Monday, November 23, 2020 1:32 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>; 
> EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda < 
> tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < 
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey
>
>
>
> That’s the last of my questions related to BIERin6.
>
>
>
> I thank you for taking the time to go over the BIERin6 draft in detail.
>
>
>
> We have reached consensus as well as are in sync,  and I now have a 
> better understanding of BIERin6.
>
>
>
> During the discussions I did mention that maybe in BIERin6 optional
> IPv6 tunneling should be removed, as it seemed to create some 
> confusion, but now I am clear and as both the L2/tunnel and IPv6 
> L3/tunnel encapsulation single hop or multi hop tunnel both have the 
> clean BIER layering and complement each other I agree they belong together in the same draft.
>
> Even though L2/tunnel exists today as part of RFC8296 it makes sense 
> to be part of the overall BIERin6 solution.
>
>
>
> I am clear on the two IANA code points requests required for the 
> optional
> IPV6 encapsulation option.
>
>
>
> Over the course of this thread we did touch on some technical reasons 
> why
> IPV6 encapsulation is necessary which I you mentioned in some of your 
> responses.
>
>
>
> Overall throughout the discussions I agree that BIERin6 IPV6 tunnel 
> option and BIERv6 are not transitional and are long term solutions and 
> there are reasons why that we can add to the requirements draft as to 
> why IPV6 encapsulation is necessary below:
>
>
>
> - Operator requirement for IPV6 encapsulated packets  and not L2 
> encapsulation.
>
> -FRR
>
>
>
> I think we are all set to start updating the Requirements draft.
>
>
>
> In-line Gyan6>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Sun, Nov 22, 2020 at 10:39 PM Jeffrey (Zhaohui) Zhang < 
> zzhang@juniper.net> wrote:
>
> Gyan,
>
>
>
> Please see zzh6> below.
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Sunday, November 22, 2020 9:49 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>; 
> EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda < 
> tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < 
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Jeffrey
>
>
>
> Agreed we have reached a consensus.
>
>
>
>
>
> Few more questions to iron out understanding.
>
>
>
> In line gyan4>
>
>
>
> Zzh6> Apparently there are still disconnects 😊
>
>  Gyan> Thank you for all the detailed responses.  We are in sync now!
>
> On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) Zhang < 
> zzhang@juniper.net> wrote:
>
> Hi Gyan,
>
>
>
> Yes I believe we’ve reached consensus.
>
>
>
> Please see zzh5> below about some details.
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Sunday, November 22, 2020 4:19 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>; 
> EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda < 
> tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < 
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey
>
>
>
> This has been a very informative exchange and extremely helpful for 
> all of us to get onto the same page from a basic understanding POV.
>
>
>
> Much appreciated all your help and feedback helping clarify my confusion.
>
>
>
> I am answering in-line but now connecting the dots how is in today’s 
> RFC
> 8296 Non MPLS BIER Ethernet going to transport IPv6?
>
>
>
> From your answers below it cannot work as we need two IANA code point 
> one for IPv6 next header type and ICMPv6.
>
>
>
> Zzh5> The existing model/concept works except that we need to two code
> points if IPv6 tunneling is used for either getting over non-BFRs or 
> for FRR. One may deem non-BFR as a short-term scenario but FRR will be 
> here for the long run.
>
>
>
>     Gyan4>I am a little confused here with the code points.  For
> BIERin6 “L2” BIER scenario RFC 8296 Non MPLS BIER Ethernet Ether type 0xAB37.
>
>
>
> Ethernet -0xAB37 l BIER | IPv6 | payload
>
>
>
> Zzh6> Note that IPv6 header is not needed – it should be Ethernet
> Zzh6> -0xAB37
> l BIER | payload. Of course, if SRv6 style VPN must be used, then IPv6 
> header may be inserted between BIER and payload, only for the SRv6 
> style VPN purpose.
>
> Gyan> Understood
>
> Ethernet -0xAB37 l BIER l ICMPv6 | payload
>
>
>
> Zzh6> ICMP was mentioned not for encapsulation but for the following:
>
>  Gyan6>Understood
>
> Zzh6> 2.1.  IPv6 Options Considerations
>
>
>
>    For directly connected BIER routers, IPv6 Hop-by-Hop or Destination
>
>    options are irrelevant and SHOULD NOT be inserted by BFIR on the
>
>    BIERin6 packet.  In this case IPv6 header, Next Header field should
>
>    be set to TBD.  Any IPv6 packet arriving on BFRs and BFERs, with
>
>    multiple extension header where the last extension header has a 
> Next
>
>    Header field set to TBD, SHOULD be discard and the node should
>
>    transmit an ICMP Parameter Problem message to the source of the
>
>    packet (BFIR) with an ICMP code value of TBD10 ('invalid options 
> for
>
>    BIERin6').
>
>
>
> In this particular scenario where adjacent BFRs support Ethernet link 
> layer in an IPV6 environment and  IPv6 or ICMPv6 encapsulation and the 
> need for the next header code point above is the packet format:
>
>
>
> Excerpt from RFC 8296
>
>
>
>    Therefore, if a non-MPLS BIER packet is encapsulated in an Ethernet
>
>    header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC5332 
> <https://urldefense.com/v3/__https://nam11.safelinks.protection.outloo
> k.com/?url=https*3A*2F*2Furl__;JSUl!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetp
> u3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PLU1AClK$
> defense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc5332__%3B!!
> NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ8
> 4ssHlj%24&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C97b8a34
> 14dbe40bd528708d892e35223%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7
> C637420852351965804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8EiHsMns5Jut
> 7s6EmZvJSxvEwUuJKdtE8PbMZyYRBiQ%3D&amp;reserved=0>].  IEEE
>
>    has assigned Ethertype 0xAB37 for non-MPLS BIER packets.
>
>
>
>
>
> In the case of BIERin6 optional encapsulation option, in case where 
> operators requires packets forwarded in IPv6 or tunneling over Non BFR 
> packet format below:
>
>
>
> IPv6 outer header l BIER l Data
>
>
>
> So here the next header is BIER so corresponding next header code point.
>
>
>
>
>
> So below is for both cases IANA code point allocation for “L2” next 
> header where next header is IPv6 or ICMPV6, and then the optional IPv6 
> encapsulation option where the next header is BIER.
>
>
>
> Would those be two separate IANA code point requests I what I see from 
> the packet format.
>
>
>
> IANA L2 scenario:
>
> 2 code point requests for L2 for next header IPv6 and ICMP
>
>
>
> Zzh6> I don’t follow what you’re talking about. If BIER header follows
> Zzh6> L2
> header directly, no new code point is needed. It’s just “Ethernet
> 0xAB37 | BIER | payload”.
>
>
>
>     Gyan6> Agreed.
>
>
>
> IANA optional IPv6 scenario:
>
> 1 code point request for IPv6 for next header BIER
>
>
>
> Zzh6> If IPv6 encapsulation is used, either on between directly 
> Zzh6> connected
> BFRs or indirectly connected BFRs, a new “next header” code point is 
> needed for BIER.
>
>  Gyan6>Understood
>
>
> 5
> <https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fhtml*2Fdraft-zhang-bier-bierin6-07*section-5__*3BIw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH*24&amp;data=04*7C01*7Cmichael.mcbride*40futurewei.com*7C97b8a3414dbe40bd528708d892e35223*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637420852351965804*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=nEiVnnCjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0*3D&amp;reserved=0__;JSUlJSUlJSUlKiUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetpu3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PHwxls5N$ >.
> IANA Considerations
>
>
>
>
>
>    IANA is requested to assign a new "BIER" type for "Next Header" in
>
>    the "Assigned Internet Protocol Numbers" registry.
>
>
>
>    IANA is requested to assign a new "BIERin6" type for "invalid
>
>    options" in the "ICMP code value" registry.
>
>
>
>    IANA is requested to assign a new "BIER IPv6 transportation
> Sub-sub-
>
>    TLV" type in the "OSPFv3 BIER Ethernet Encapsulation sub-TLV"
>
>    Registry.
>
>
>
>    IANA is requested to set up a new "BIER IPv6 transportation
> Sub-sub-
>
>    sub-TLV" type in the "IS-IS BIER Ethernet Encapsulation sub-sub-TLV"
>
>    Registry.
>
>
>
>
>
> My point is that the IANA allocation is different as the next header 
> is different for the L2 scenario where next header is IPv6 or ICMPV6, 
> and IPv6 encapsulation scenario where the next header is BIER.
>
>
>
> Zzh6> If BIER header follows L2 header directly, BIER Ethertype is 
> Zzh6> used
> (assuming Ethernet is the L2).
>
>  Gyan>Understood
>
> Based on this point I am making could we just do a RFC8296 bis version 
> and add the IANA code points for IPv6 and ICMPv6.
>
>
>
> Zzh6> Given the confusion/contention that have happened in the last 
> Zzh6> two
> years, it is much better to specifically have a spec dedicated to 
> supporting BIER in IPv6.
>
>  Gyan6> I think now looking at it holistically speaking I can now see 
> parity between the L2/tunnel and L3/tunnel both also having the clean 
> layering.  So I can see why adding existing L2/tunnel to BIERin6 even 
> though it already exists made sense to bundle into BIERin6 total 
> solution

Juniper Business Use Only