Re: BIER in IPv6 --- draft-zhang-bier-bierin6-04

[Tony Przygienda <[e-mail]>]

On Thu, Mar 26, 2020 at 2:26 AM <[e-mail]> wrote:

> Hi Gyan,
>
>
> Please find my answer by [Sandy2]. :-)
>
>
> Thanks,
>
> Sandy
>
>
> <http://www.zte.com.cn/>
> 原始邮件
> *发件人：*GyanMishra <[e-mail]>
> *收件人：*张征00007940;
> *抄送人：*[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;
> *日 期 ：*2020年03月26日 17:09
> *主 题 ：**Re: BIER in IPv6 --- draft-zhang-bier-bierin6-04*
>
>
> On Thu, Mar 26, 2020 at 4:08 AM <[e-mail]> wrote:
>
>> Hi Gyan,
>>
>>
>> Thank you very much for your comments!
>>
>> Sorry for the late response.
>>
>> Please find my answer with [Sandy] inline. :-)
>>
>>
>> Thanks,
>>
>> Sandy
>>
>>
>> 原始邮件
>> *发件人：*GyanMishra <[e-mail]>
>> *收件人：*Tony Przygienda <[e-mail]>;
>> *抄送人：*6MAN <[e-mail]>;BIER WG <[e-mail]>;张征00007940;
>> *日 期 ：*2020年03月25日 08:36
>> *主 题 ：**Re: 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?
>>
>> [Sandy]: Sorry. No. The two solutions are used to solve one use case. And
>> there is no relationship between the Bitstringlength in BIER header and the
>> position in IPv6 header.
>>
>     Gyan> Ok.  The one use case is for being able to tunnel over hardware
> not supporting BIER and so for that you have the two tunnel options.  The
> two tunnel types are link local or GUA and both are multi hop tunnels -
> Correct?
>
>> [Sandy2]: Yes. If you think they are all tunneling. :-)
>>
>
Yes, critical point. We are _not_ "tunneling" in case of LL to LL BIERin6
in fact for all practical purposes (tunnel assumes fragmentation/security
etc which BIER architecture does NOT presume from L2 header, we do not
expect Ethernet to fragment or encrypt BIER). IPv6 is basically used the
same way we use ethernet, it's poor man's "L2 header" that allows standard,
non-extended silicon to throw stuff to slow path to process if silicon
doesn't support BIER (will be reality for e.g. cheap WiFi routers for ages
to come I think). If silicon does support BIER fast path can be taken as
well with bierin6 but if silicon supports BIRE we have L2 encaps which
arguably should be used rather than twisting ipv6.

BIER architecture uses unicast tunnels to get frames across parts of
network without BIER support as well. Now, here the bierin6 is irresistibly
convienent to just stick a BFR prefix as destination and hop over routers
without even signalling a tunnel and then it is a unicast tunnel from BIER
perspective. Kind of like SR or SRv6 or MPLS tunnel (which need to be
differntatied from BIER running natively over MPLS labels) but for v6 no
special HW support is needed so that's neat ;-) SR/SRv6/IP forwarding/GRE
are just unicast tunnels to BIER.

--- tony