IETF Logo Mail Archive

[Bier] 答复: draft-kumarzheng-bier-ping-03

Xuxiaohu <xuxiaohu@huawei.com> Sat, 24 September 2016 03:49 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FA612B030 for <bier@ietfa.amsl.com>; Fri, 23 Sep 2016 20:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.536
X-Spam-Level:
X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQm43BrmbRlt for <bier@ietfa.amsl.com>; Fri, 23 Sep 2016 20:49:27 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619F212B1FD for <bier@ietf.org>; Fri, 23 Sep 2016 20:49:26 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CWU97720; Sat, 24 Sep 2016 03:49:24 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 24 Sep 2016 04:49:23 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Sat, 24 Sep 2016 11:49:09 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Xuxiaohu <xuxiaohu@huawei.com>, "bier@ietf.org" <bier@ietf.org>
Thread-Topic: draft-kumarzheng-bier-ping-03
Thread-Index: AdIWErn8Abf9fLzeSYWORUII+R312wAAtzJA
Date: Sat, 24 Sep 2016 03:49:08 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB1DF1C@NKGEML515-MBX.china.huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB1DEE0@NKGEML515-MBX.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB1DEE0@NKGEML515-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.184.181]
Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB1DF1CNKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.57E5F7C5.000D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: ff3b599d75422e34fe696fe09b03b09a
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/9bNa1MpwdOZWUtqZUx48VYDupzA>
Subject: [Bier] 答复: draft-kumarzheng-bier-ping-03
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Sep 2016 03:49:29 -0000

BTW, I’m also wondering the real value of the BIER traceroute functionality in real BIER networks.

It said in the draft that

“In trace route mode, Initiator MAY
   include Target SI-Bitstring TLV to control the path trace towards any
   specific BFER or set of BFERs.”

When initiator performs traceroute towards more than one BFER, how could it construct a trace path of a tree? When initiator performs traceroute towards a single BFER, the trace path may be totally different from the real path of a BIER packet could containing that BFER and other BFERs, so what’s the real value of BIER traceroute in practice?

Best regards,
Xiaohu

发件人: BIER [mailto:bier-bounces@ietf.org] 代表 Xuxiaohu
发送时间: 2016年9月24日 11:21
收件人: bier@ietf.org
主题: [Bier] draft-kumarzheng-bier-ping-03

Hi co-authors of this draft,

I’m curious to know the rationale of the choice that “ BIER OAM is defined in a way that it stays within BIER layer by following directly the BIER header without mandating the need for IP header.” In other words, what’s the real benefit of eliminating the IP header? Anyway, you would need IP protocol stack on each BFR, especially for reply mode 2 (i.e., Reply via IPv4/IPv6 UDP packet). In addition, I’m also wondering the necessity of Reply mode 3 (i.e., Reply via BIER packet). In other words, why does “the Initiator intend to validate the return BIER path” since the forward and return BIER paths between two BFRs may be totally asymmetric?

Best regards,
Xiaohu

v2.23.0 | Report a Bug | By Email