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

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Sat, 24 Sep 2016 12:09:18 +0000

Hi Xiaohu,

Target SI-BS is a optimization to perform the trace towards a specific BFER.

<Xiaohu>When initiator performs traceroute towards more than one BFER, how could it construct a trace path of a tree?

<Nagendra> The response with Sender’s handle and sequence number should help correlate the (set of) responses to the request. The downstream mapping TLV and the upstream Interface TLV provides the details about the path. How it is used to construct/display the path is an implementation matter.

<Xiaohu>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?

<Nagendra> The main intention of Target SI-BS is to make (as much) sure that the trace stays in-line to data path. A transit node with multiple ECMP may use different keys for entropy hashing which potentially includes the incoming bistring in the header and entropy value. Using the bit string of the to-be-traced BFER alone in the BIER header will end up taking a different path. But allowing the complete bistring (for any specific group for example) and using Target SI-BS and Responder BFR/BFER TLV will help trace the path towards a specific BFER. By simply changing the entropy, one may be able to detect the ECMP paths as well. As defined in section 4.2, re-uses the machinery from RFC4379 for ECMP discovery. A more detailed explanation will be included in later revision.

Thanks,
Nagendra

From: BIER <[email-masked]<mailto:[email-masked]>> on behalf of Xuxiaohu <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 23, 2016 at 11:49 PM
To: Xuxiaohu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Bier] 答复: draft-kumarzheng-bier-ping-03

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:[email-masked]] 代表 Xuxiaohu
发送时间: 2016年9月24日 11:21
收件人: [email-masked]<mailto:[email-masked]>
主题: [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