Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>

[Tony Przygienda <[e-mail]>]

On Mon, Jul 15, 2019 at 12:39 AM Xiejingrong <[e-mail]> wrote:

> Please see my comments below:
>
>
>
> *From:* Tony Przygienda [mailto:[e-mail]]
> *Sent:* Monday, July 15, 2019 3:04 PM
> *To:* Senthil Dhanaraj <[e-mail]>
> *Cc:* Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]>;
> Xiejingrong <[e-mail]>; BIER WG <[e-mail]>;
> [e-mail]; Antoni Przygienda <[e-mail]>
> *Subject:* Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>
>
>
>
> if your router can do BIER fast path IPv6 is not an interesting option no
> matter which draft.
>
> [XJR] That’s not true. The interest in BIER-IPv6-fast-path is strong.
> There is no problem of “interest” or “requirement”. The problem is the lack
> of convinced  “technology” or “solution”.
>

enlighten me where you saw that except being personally convinced it's cool
... And what is the specific reason customer would want that
complexity/cost of v6 option processing silicon compared to ether/mpls
encaps.


> one would either carry native ether or MPLS rather than trying to build
> IPv6 fast path with header options @ arbitrary place,
>
> probably misaligning bitmasks and ultimately forcing 4K buffers on v6
> option processing in silicon which may be fun but it is expensive, complex
> fun.
>
> [XJR] The proposals are not as good as expected,  or could not do it in a
> simple and inexpensive way! I guess this is the point.
>

yupp. MPLS/Ether will be as inexpensive as it can be and shares same
processing block.


> [XJR] Well I think, using a preceding BIER-Specific IPv6 Address in IPv6
> DA can solve the problem perfectly.
>
> [XJR] This is the way SRv6/SRH do, *which first introduces the fast-path
> processing of extension header*, without recognition the pattern of the
> EHs and the TLVs, but simply ‘process the desired packet, and drop the
> undesired packet’!
>

BIER is neither SRv6 nor SRH so your point here is?

BIER is a L2.5 hop-by-hop multicast switching technology that should be
tunneled otherwise. v6 enaps (where we really abuse v6 as L1 transport) is
only justified if ether/mpls cannot be implemented but chips can do very
simple v6 processing and there is not high throughput requirement (albeit
one could build bierin6 fast-path in silicon obviously). Obviously bierin6
gives you the nice trick to tunnel it to a v6 destination without
establishing a real tunnel but it's really just a by-product and not its
main goal

--- tony


>