Re: [Bier] New Version Notification for draft-pfister-bier-over-ipv6-00.txt

Hi Xiaohu,

I would say that one of the big benefits is that an IPv6 BIER encoded packet can be translated/transformed into a set of IPv6 Unicast packets (just one bit set) at the egress of the network very easily. This is very beneficial when running BIER between servers and avoids the need for MLD and DR/DF election between the Server and the router.

Thx,

Ice.

> On 21 Sep 2016, at 12:09, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> 
> Hi Ice,
> 
> If I understand your draft correctly, it talks about embedding BIER within IPv6 rather than transporting BIER over IP. The beauty of this approach is that all information needed for BIER forwarding is now directly contained in the received BIER packet. As a result, there is no need to retrieve them from the MPLS-BIER label and distribute the MPLS-BIER label mappings. However, what's the major advantage over the generic BIER header as defined in https://tools.ietf.org/html/draft-xu-bier-encapsulation-05 from your point of view?
> 
> Best regards,
> Xiaohu
> 
> -----邮件原件-----
> 发件人: BIER [mailto:bier-bounces@ietf.org] 代表 IJsbrand Wijnands
> 发送时间: 2016年9月20日 22:30
> 收件人: Eric C Rosen
> 抄送: bier@ietf.org; Pierre Pfister
> 主题: Re: [Bier] New Version Notification for draft-pfister-bier-over-ipv6-00.txt
> 
> Hi Eric,
> 
> Many thanks for your comments. A few responses inline.
> 
>> Sometimes an idea that seems clever at first just doesn't work out when the details are examined.  The idea of using addresses that are unicast addresses in one context but multicast addresses in another falls into this category.  Inevitably a host will put a multicast address into an IP source address field, because the host
> 
> Maybe we can consider registering a new IPv6 address space for BIER. I think a lot of your concerns would be addressed. That way we don’t get in the way with already defined unicast behaviour and still leaves it open to treat the packet as unicast in some specific cases, like with tunnelling through non-BIER nodes.
> 
>> Any BIER encapsulation needs to be able to support the features that are in the architecture.  
> 
> And we should not be afraid to allow exceptions and/or updates to the architecture draft if necessary.
> 
>> An implementation that doesn't support SI is not compliant with the architecture.
> 
> By allocating part of the “prefix” for the SI/SD identifier we can make this work just fine IMO. Since the SI/SD here is manually defined and the BitString length is fixed, I think there is really only need for one of them. If we call that SI or SD (or something else) we can argue about :-)
> 
> Thx,
> 
> Ice.
> 
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier