Re: [Bier] Questions for draft-ietf-bier-multicast-http-response-06 Tue, 18 January 2022 08:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEA6D3A13F4 for <>; Tue, 18 Jan 2022 00:56:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JHotV6b1cM7L for <>; Tue, 18 Jan 2022 00:56:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA4EB3A1329 for <>; Tue, 18 Jan 2022 00:56:18 -0800 (PST)
Received: from (unknown []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4JdN0w6P45z81H58 for <>; Tue, 18 Jan 2022 16:56:16 +0800 (CST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4JdN0K5SrVz501R4; Tue, 18 Jan 2022 16:55:45 +0800 (CST)
Received: from ([]) by with SMTP id 20I8tRGh013075; Tue, 18 Jan 2022 16:55:27 +0800 (GMT-8) (envelope-from
Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid203; Tue, 18 Jan 2022 16:55:27 +0800 (CST)
Date: Tue, 18 Jan 2022 16:55:27 +0800 (CST)
X-Zmail-TransId: 2af961e6807fa5792317
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
From: <>
To: <>
Cc: <>, <>, <>, <>
Content-Type: text/plain; charset="UTF-8"
X-MAIL: 20I8tRGh013075
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04- with ID 61E680B0.002 by FangMail milter!
X-FangMail-Envelope: 1642496176/4JdN0w6P45z81H58/61E680B0.002/[]/<>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 61E680B0.002/4JdN0w6P45z81H58
Archived-At: <>
Subject: Re: [Bier] =?utf-8?q?Questions_for=C2=A0draft-ietf-bier-multicast-ht?= =?utf-8?q?tp-response-06?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Jan 2022 08:56:39 -0000

Hi Dirk, 
Thank you very much for your answers! 
Please find my comments with Sandy> below. 
And I have two more questions:
1, seems like the draft discusses the situration which SH is collocated with BFIR/BFER, and the draft mentions: 
"If the additional function of SH cannot be added to normal routers,
   then SH can be deployed as a separate function outside the routers.
   In such scenario an interface between SH and BFIR or BFER needs to be
But there is no detailed description about the interface between SH and BFIR/BFER. 
If some description can be added for the detail of the interface? In the separated situation, seems like the BFIR/BFER needs specific function to do with the packet. 
2, if the "FQDN" mentioned in this draft is the acronym of "Fully Qualified Domain Name"? I don't find the explanation in the draft.

日 期 :2022年01月17日 19:05
主 题 :RE: [Bier] Questions for draft-ietf-bier-multicast-http-response-06
Hi Sandy,
Thanks for the questions. Please see inline.
-----Original Message-----
From: []
Sent: 17 January 2022 02:55
To: Dirk Trossen <>om>;;;
Subject: [Bier] Questions for draft-ietf-bier-multicast-http-response-06
Hi authors,
Thank you for your draft! IMO this draft is very interesting.
I know little about HTTP, so I’m not clear with some contents in the draft.
My questions are:
1, if there is multicast signaling between CNAP and SNAP in the existed situation without BIER deployment, PIM or other protocol?
[DOT] There is no explicit signaling for the multicast but instead the multicast (return) path is built purely at the SNAP from the information provided in forward direction coming from the CNAPs of the clients.
Sandy> Got it. Thank you!
2, there is connection based on TCP/UDP between client and server, right? This draft will terminate the connection on CNAP and SNAP.
[DOT] Yes
If the payload of the TCP/UDP packet will be the payload of encapsulated BIER packet?
[DOT] Indeed, the TCP payload, i.e., the HTTP request, is the payload used for the BIER packet in forward direction.
The “Service Name” is still in this payload, right?
[DOT] That's been added to it, yes.
Sandy> Do you mean additional information (such as URI) will be added in the payload? So the BIER payload is not only the original payload of TCP/UDP packet, new info for distinguishing is added between BIER header and the original payload, right? 

3, seems like the “Service Name” will be the key for BFIR and BFER to setup the mapping relationship, will this key will be exchanged among all the BFIR and BFER in case of there is no SDN/PCE controller?
[DOT] The 'service name' (more correctly, a request-level identifier) is indeed used for the mapping relationship since it allows for identifying 'same' requests at the SNAP.
Sandy> Got it. As you said, there is no explicit signaling between CNAP and SNAP, SNAP uses the request-level id for BFERs mapping. 
4, the “PATH ID” seems like a value of local significance, if this value is used for PCE controller to distribute the mapping relation of “Service Name” and associated BFERs? This value won’t be signaling among BFIR and BFERs, right?
[DOT] The PATH ID is only used for PCE signaling of the forward path (from CNAP to SNAP) since the return path is purely logically computed as a combination of the relevant PATH IDs of the forward requests.
Sandy> Got it. Thank you!
Best regards,
Much appreciate for your answer!
[DOT] I hope I did answer your questions well.
Best regards,