Re: [Bier] 答复: comments on draft-ietf-bier-mpls-encapsulation

Hi Xiaohu,

Please see zzh> below.

From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Thursday, June 22, 2017 2:11 AM
To: Tony Przygienda <tonysietf@gmail.com>
Cc: BIER (bier@ietf.org) <bier@ietf.org>; Eric Rosen <erosen@juniper.net>
Subject: [Bier] 答复: comments on draft-ietf-bier-mpls-encapsulation

Hi Tony,

Many initial rationales of using BIER-labels to retrieve SI/Sub-domain values rather than encoding them directly in the BIER packet has been shaken:

1)    The use of the BIER-label as a lookup key was thought better than the use of the combination of SI, Sub-domain and BSL as a lookup key from the BIFT lookup efficiency perspective. Initially, the MPLS-BIER label is used to retrieve SI, Sub-domain and BSL values. However, the BSL value has now been encoded directly in the BIER header. As a result, the MPLS-BIER label is now only used to retrieve SI/Sub-domain values. Therefore, the advantage of the BITF lookup efficiency is gone.

Zzh> Please see the following text on page 8:

   BSL:

      This 4-bit field encodes the length in bits of the BitString.

      Note: When parsing the BIER header, a BFR MUST infer the length of
      the BitString from the BIFT-id, and MUST NOT infer it from the
      value of this field.  This field is present only to enable off-
      line tools (such as LAN analyzers) to parse the BIER header.

2)    There was no need to request an Ethernet type code for the BIER header due to the BIER-MPLS label. Now since the WG has decided to specify a non-MPLS encapsulation anyway. The advantage of avoiding the assignment of an Ethernet type code is gone as well.

Zzh> Since we want to be able to support BIER in a non-MPLS environment, we have to request an ethernet type code. That does not mean a critical pillar of the BIER-MPLS label method is gone.

3)    It was possible to add additional fields into the BIER forwarding decision by using the MPLS-BIER label as an indirection. However, since the BIER header itself has a version field and the BIER specifications are now defined as Experimental rather than Standard Track, and most importantly, there has been no hardware implementation of BIER yet AFAIK, the above advantage is much trivial.

Zzh> Even though the version number could increase, we don’t want to spin new hardware too often, right?

Jeffrey

Hence, I think it’s worthwhile for the WG to revaluate the necessity of introducing the BIER-label into the BIER header, especially when the WG has agreed to define a generic BIER header.

Best regards,
Xiaohu

发件人: Tony Przygienda [mailto:tonysietf@gmail.com]
发送时间: 2017年6月21日 15:10
收件人: Xuxiaohu
抄送: Eric C Rosen; BIER (bier@ietf.org<mailto:bier@ietf.org>)
主题: Re: [Bier] comments on draft-ietf-bier-mpls-encapsulation

Xiaohu, the BIER mailing list archived several discussions dealing with that very issue and a widely announced interim has been held to converge the different strains of thought. I suggest to reference the according mail archives/meeting minutes for documentation how the consensus process ran its due course ...

thanks

--- tony

On Tue, Jun 20, 2017 at 7:13 PM, Xuxiaohu <xuxiaohu@huawei.com<mailto:xuxiaohu@huawei.com>> wrote:
Hi all,

It's great to see that the concept of non-MPLS encapsulation is eventually accepted by the WG. However, the current non-MPLS BIER header as defined in draft-ietf-bier-mpls-encapsulation has no significant difference from the MPLS-BIER header, IMHO. The major change is just to rename the 20-bit MPLS label as the Bit Index Forwarding Table (BIFT) ID with realignment of fields. That's to say, no matter in the MPLS-BIER header or the non-MPLS-BIER header, the SI and Sub-domain values which are needed for BIFT lookup are not explicitly contained in the BIER packet. My question is why not directly encode the SI and Sub-domain in the BIER packet?

Best regards,
Xiaohu

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

--
We’ve heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.
—Robert Wilensky