IETF Logo Mail Archive

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

Xuxiaohu <xuxiaohu@huawei.com> Sat, 24 September 2016 04:08 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 B7E1B12B0F9 for <bier@ietfa.amsl.com>; Fri, 23 Sep 2016 21:08:40 -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 Ep32Fcyg62A3 for <bier@ietfa.amsl.com>; Fri, 23 Sep 2016 21:08:38 -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 CE9BA12B277 for <bier@ietf.org>; Fri, 23 Sep 2016 21:08:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CWU99125; Sat, 24 Sep 2016 04:08:35 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 24 Sep 2016 05:08:34 +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 12:08:30 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Thread-Topic: [Bier] draft-kumarzheng-bier-ping-03
Thread-Index: AdIWErn8Abf9fLzeSYWORUII+R312///f6CA//91SdA=
Date: Sat, 24 Sep 2016 04:08:29 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB1DF43@NKGEML515-MBX.china.huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB1DEE0@NKGEML515-MBX.china.huawei.com> <CA+RyBmV85oPNBE32Qyy0Cg3Z0Bvv3N2A+FfukwRJChKj=bb64w@mail.gmail.com>
In-Reply-To: <CA+RyBmV85oPNBE32Qyy0Cg3Z0Bvv3N2A+FfukwRJChKj=bb64w@mail.gmail.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_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB1DF43NKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.57E5FC44.004C, 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: c5c8eee12f3eb5f61369321537cd8630
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/SkX045X2a9Birqlz4uz1FSwP5MI>
Cc: "bier@ietf.org" <bier@ietf.org>
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 04:08:41 -0000

Hi Greg,

Thanks for your response.

Although BIER has the BFIR-id, it seems much simpler and consistent to keep the request and reply message within the same format.

If I understand RFC7110 correctly, it’s only applicable in the directional LSP case. However, is there any directional path concept in the BIER case?

Best regards,
Xiaohu

发件人: Greg Mirsky [mailto:gregimirsky@gmail.com]
发送时间: 2016年9月24日 11:42
收件人: Xuxiaohu
抄送: bier@ietf.org
主题: Re: [Bier] draft-kumarzheng-bier-ping-03

Hi Xiaohu,
thank you for your thoughtful questions.
Ensuring that active OAM is in-band with data, i.e. is fate-sharing, being monitored significantly simplifies defect localization.
For the case of MPLS encapsulation preserving IP header has no apparent benefit as BIER header carries BFIR ID.
As RFC 7110 demonstrated, there are benefits of controlling path used for Echo Reply. I think that in the future version we'll provide more details regarding use of different Reply modes.

Regards,
Greg

On Fri, Sep 23, 2016 at 8:21 PM, Xuxiaohu <xuxiaohu@huawei.com<mailto:xuxiaohu@huawei.com>> wrote:
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

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

v2.23.0 | Report a Bug | By Email