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

Hi Ice,

Firstly, I'm glad to see that your IPv6-BIER draft somehow echoes my previous statement about the similarity between the BIER header and the IPv6 header (see below):

https://www.ietf.org/mail-archive/web/bier/current/msg00101.html
https://www.ietf.org/proceedings/92/slides/slides-92-bier-1.pdf

That's a great progress!:) IMO.

Secondly, the major difference between the IPv6-BIER encapsulation and the generic BIER encapsulation (https://tools.ietf.org/html/draft-xu-bier-encapsulation-05) is that the former makes the BIER as a special use of IPv6 while the latter makes the BIER as another network layer in parallel with IPv6 but with many similarities. I agree that allowing legacy routers to forward IPv6-BIER packets as normal IPv6 packets is a major merit of the IPv6-BIER although this merit is only applicable to IPv6 but not IPv4. However, in addition to those drawbacks pointed by Eric in his previous email, the associated costs include but not limited to:

1) The Bitstring length is not flexible any more since the Bitstring is restricted within the 128-bit long destination IPv6 address.
2) The BIER header format is not future-proven any more due to the lack of a version field dedicated for BIER. Or do you want to some bits within the destination IPv6 address as a BIER-specific version? If so, it would further suppress the available space for the Bitstring field. Or do you want to consume more IPv6 address space to make room for BIER?
3) It introduces modifications to the current mature IPv6 forwarding procedure branch. 
4) Due to the reusage of the IPv6 header format, the encapsulation overhead is unnecessary increased especially in IPv4 networks (e.g., use the 128-bit long IPv6 source address instead of 16-bit BFIR-id to indicate the sender).

Best regards,
Xiaohu

-----邮件原件-----
发件人: BIER [mailto:bier-bounces@ietf.org] 代表 Xuxiaohu
发送时间: 2016年9月22日 9:49
收件人: IJsbrand Wijnands
抄送: bier@ietf.org; Pierre Pfister; Eric C Rosen
主题: [Bier] 答复: New Version Notification for draft-pfister-bier-over-ipv6-00.txt

Hi Ice,

Could you please illustrate how to translate/transform an IPv6-BIER packet into a set of IPv6 unicast packets by setting only one bit? BTW, what's the payload of the IPv6-BIER packet in your example? In other words, what's the value of the Next-Header field of the IPv6-BIER header?

Best regards,
Xiaohu

-----邮件原件-----
发件人: IJsbrand Wijnands [mailto:ice@cisco.com] 
发送时间: 2016年9月21日 18:28
收件人: Xuxiaohu
抄送: Eric C Rosen; bier@ietf.org; Pierre Pfister
主题: 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

_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier