Re: [Bier] BIER in IPv6 --- draft-zhang-bier-bierin6-04

Tony & Sandy

So is the idea proposed in the two drafts mentioned for BIER IPv6 support
of encoding the BIER header up to 256 bit mask for BFER encoding schema
supporting up to I believe 128 BFERs per set - to encode the BIER header
into the DO EH -  and then for directly connected neighbor the outer header
IPv6 encapsulation 1 hop tunnel used link local source and destination -
for non directly connected neighbors IPv6 encapsulation use multi hop
tunnel with GUI SA and DA.  In both tunnel cases being mutually exclusive
the link local tunnel would have TTL 1 and multi hop would have appropriate
 >1 ttl.

So this is 2 different solutions for 2 different use cases.  Correct?

Just as with BIER IPv4 with BIER IPv6, the IGP extensions would flood the
BIER info to build BIFT forwarding table to build the stateless MDT trees.

In the case of SRv6 with disjoint BIER where traffic steering is required
to signal SRV6 topology the last header would be set to TBD.  So that last
header would in non SRv6 IPv6 topology the Last header would be the DO EH
with the BIER header encoded. So with SRv6 how is the BIER header encoded?

For SRv6 support I am guessing we have to update the programming draft for
an end type sid instantiation flavor variation for a new BIER SID?

I am just thinking comparing BIER for v4 to BIER for v6 is there any way
you could accomplish the same with v6 and not do any IPv6 tunneling and
just add the L 2 1/2 BIER header and propagate the BIER header info into
the IGP to build the BIFT forwarding table just as you do with BIER v4.

I can see for egress node BFER support the intermediate nodes and maybe
even end  node may not have to support BIER - but now if tunneling is used.

Is that the business justification for tunneling or maybe some other reason
intrinsic to IPv6 I am missing.

Am I totally off base??

Gyan

On Sun, Mar 22, 2020 at 11:24 PM Tony Przygienda <tonysietf@gmail.com>
wrote:

> That's a currently ongoing discussions between the auhtors (cc:'ing bier
> as well)
>
> LL has advantages
> * the packet cannot "escape" even if it has TTL > 1
> * such a scheme can work purely with ND
> * it's hard to "send out the wrong interface" albeit v6 allows AFAIR to
> have same link local on multiple interfaces
>
> Originally the draft did not even allow for global addressing (since we
> want to use v6 as L2-substitute here just like MPLS & non-MPLS
> encapsulations are used in BIER) but this has a nice side effect of
> allowing to "jump over non-BIER routers" if addressed to bier prefix (which
> I personally think should be the only allowed global v6 used, otherwise we
> may end up with BIER frames in funky places and possible "holes" in the
> replication fabric). Obviously strictly speaking it's not necessary since
> BIER can be carried in plethora of normal unicast tunnels  but bunch of
> co-auhtors joined and the consensus was to allow it
>
> --- tony
>
>
>
> On Sun, Mar 22, 2020 at 8:15 PM <zhang.zheng@zte.com.cn> wrote:
>
>> Hi Xuesong,
>>
>>
>> Thank you for your question!
>>
>> The LL address is used by direct connected neighbor.
>>
>> For the neighbor which is not direct connected, the wider range address
>> should be used.
>>
>>
>> Thanks,
>>
>> Sandy
>>
>>
>> 原始邮件
>>
> *发件人：*Gengxuesong(GengXuesong) <gengxuesong@huawei.com>
>> *收件人：*张征00007940;6man@ietf.org <6man@ietf.org>;
>> *日 期 ：*2020年03月23日 11:03
>> *主 题 ：**RE: Re:BIER in IPv6 --- draft-zhang-bier-bierin6-04*
>>
> Hi Sandy and authors of draft-zhang-bier-bierin6:
>>
>>
>>
>> I have some questions about the section 2 when reading the draft. It is
>> mentioned that:
>>
>> “If... The destination address in IPv6 header SHOULD be the neighbor's
>> link-local address.
>>
>> Otherwise... the destination address SHOULD be the BIER prefix of the BFR
>> neighbor.”
>>
>> Seems like the draft proposes 2 methods of IPv6 header encapsulation.
>>
>> Could these 2 methods be combined ? If not, what's the use case and
>> design consideration for each method?
>>
>>
>>
>> Best Regards
>>
>> Xuesong
>>
>>
>>
>>
>>
>>
>>
>> *From:* ipv6 [mailto:ipv6-bounces@ietf.org]*On Behalf Of *
>> zhang.zheng@zte.com.cn
>> *Sent:* Saturday, March 21, 2020 1:43 PM
>> *To:* 6man@ietf.org
>> *Subject:* Re:BIER in IPv6 --- draft-zhang-bier-bierin6-04
>>
>>
>>
> Hi,
>>
>> As co-author of BIERin6 (draft-zhang-bier-bierin6-04), before you read
>> the draft, please let me introduce BIER technology to you at first:
>>
>> BIER technology, as defined in RFC8279, it's a new multicast technology.
>> The principle is achieving multicast forwarding by hop-by-hop execution.
>>
>> BIER is a transport protocol, not just a function. As defined in RFC8296,
>> BIER has it's own ethernet encapsulation with ethernet type 0xAB37, and
>> also it can be travelled by MPLS encapsulation.
>>
>> BIER has it's own OAM function, ECMP function and traceability. etc.
>> through BIER header defined in RFC8296.
>>
>>
>>
>> For travelling through IPv6 only enviroment, we'd like to travel BIER
>> packet by IPv6 encapsulation.
>>
>> In draft-zhang-bier-bierin6-04, we want to just use a new Next Header
>> type for BIER header carrying.
>>
>> We want to bring the minimum impact on IPv6 existed execution, and the
>> maximum flexibility for header interoperability.
>>
>> So if you have any question about draft-zhang-bier-bierin6-04, or about
>> BIER technology itself, please tell me. I'am glad to explain them to you.
>>
>>
>>
>> Thanks,
>>
>> Sandy
>>
>>
>>
> 原始邮件
>>
> *发件人：*TonyPrzygienda <tonysietf@gmail.com>
>>
>> *收件人：*Michael McBride <michael.mcbride@futurewei.com>;
>>
> *抄送人：*6man@ietf..org <6man@ietf.org> <6man@ietf.org>;
>>
> *日 期 ：*2020年03月19日 01:12
>>
>> *主 题 ：Re: BIER in IPv6*
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>> <BIER WG chair hat on>
>>
>>
>>
>> The specific ask here is for the 6man to look over both drafts, i.e.
>>
>>
>>
>> draft-zhang-bier-bierin6
>>
>>
>>
>> and
>>
>>
>>
>> draft-xie-bier-ipv6-encapsulation
>>
>>
>>
>> and verify whether they conform to published IPv6 standards or raise
>> objections/concerns.
>>
>>
>>
>> The requirements document is currently under active work/comments and
>> does not represent any final or wide-consensus state so an opinion on its
>> state is appreciated but it should not be used as any final or binding list
>> of requirements as to the targeted solution in BIER WG
>>
>>
>>
>> thanks
>>
>>
>>
>> --- tony
>>
>>
>>
>> On Tue, Mar 17, 2020 at 9:20 PM Michael McBride <
>> michael.mcbride@futurewei.com> wrote:
>>
>> Hello,
>>
>>
>>
>> The bier wg could use your ipv6 recommendations. We’ve worked on various
>> solutions to transport a bier header in ipv6. We decided to pause and
>> create a requirements document (draft-ietf-bier-ipv6-requirements) to help
>> steer us towards the right solution(s). In that drafts appendix we have a
>> fairly good summary of the various solutions.
>>
>>
>>
>> We’ve started to rally behind two solutions which meet the majority of
>> the requirements: draft-xie-bier-ipv6-encapsulation (bier header in ipv6
>> EH) and draft-zhang-bier-bierin6 (bier header as payload using ipv6 NH).
>> The bier chairs today asked to punt the bierv6 topic to 6man for advice
>> before adopting any of these solutions.
>>
>>
>>
>> So here we are seeking your advice. The most simple approach would
>> probably be to give
>> https://datatracker.ietf.org/doc/draft-ietf-bier-ipv6-requirements/ a
>> look and scroll down to the appendix to see a summary of the various
>> solutions we’ve been considering.
>>
>>
>>
>> thanks!
>>
>> mike
>>
>>
>>
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com