Re: [Bier] Questions for draft-ietf-bier-multicast-http-response-06

Dirk Trossen <> Tue, 18 January 2022 09:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE9E43A12BF for <>; Tue, 18 Jan 2022 01:02:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RBK_OFZDzWkc for <>; Tue, 18 Jan 2022 01:02:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 439E13A12BD for <>; Tue, 18 Jan 2022 01:02:01 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4JdN3v6VQ6z67yK4; Tue, 18 Jan 2022 16:58:51 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.21; Tue, 18 Jan 2022 10:01:56 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.21; Tue, 18 Jan 2022 09:01:56 +0000
Received: from ([]) by ([]) with mapi id 15.01.2308.021; Tue, 18 Jan 2022 09:01:55 +0000
From: Dirk Trossen <>
To: "" <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Re:[Bier] Questions for draft-ietf-bier-multicast-http-response-06
Thread-Index: AQHYC0VPSrSH3me45Uu6lBjGopBGCKxnDGeQgAFvVICAAAGhsA==
Date: Tue, 18 Jan 2022 09:01:55 +0000
Message-ID: <>
References:, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Bier] Questions for draft-ietf-bier-multicast-http-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 09:02:06 -0000

Hi Sandy,

Please see inline.



-----Original Message-----
From: [] 
Sent: 18 January 2022 09:55
To: Dirk Trossen <>
Subject: Re:[Bier] Questions for draft-ietf-bier-multicast-http-response-06

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. 
[DOT] indeed, this would be needed. 

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.
[DOT] Yes, it is, sorry for skipping the explanation of this acronym.

日 期 :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 <>;;;
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,