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

Dirk Trossen <> Mon, 17 January 2022 11:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19AC63A1ACD for <>; Mon, 17 Jan 2022 03:05:30 -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 74Q3HEBCMzuY for <>; Mon, 17 Jan 2022 03:05:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 808753A1ACE for <>; Mon, 17 Jan 2022 03:05:24 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4Jcpw61fCdz67kNP; Mon, 17 Jan 2022 19:05:10 +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; Mon, 17 Jan 2022 12:05:20 +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; Mon, 17 Jan 2022 11:05:20 +0000
Received: from ([]) by ([]) with mapi id 15.01.2308.021; Mon, 17 Jan 2022 11:05:20 +0000
From: Dirk Trossen <>
To: "" <>, "" <>, "" <>, "" <>
CC: "" <>
Thread-Topic: [Bier] Questions for draft-ietf-bier-multicast-http-response-06
Thread-Index: AQHYC0VPSrSH3me45Uu6lBjGopBGCKxnDGeQ
Date: Mon, 17 Jan 2022 11:05:19 +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: Mon, 17 Jan 2022 11:05:30 -0000

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.

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. 
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. 

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.

Much appreciate for your answer!
[DOT] I hope I did answer your questions well.

Best regards,