IETF Logo Mail Archive

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

zhang.zheng@zte.com.cn Mon, 17 January 2022 01:56 UTC

Return-Path: <zhang.zheng@zte.com.cn>
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 66E253A173A for <bier@ietfa.amsl.com>; Sun, 16 Jan 2022 17:56:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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] 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 7f_QeIKCWv1K for <bier@ietfa.amsl.com>; Sun, 16 Jan 2022 17:56:03 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0A33A1739 for <bier@ietf.org>; Sun, 16 Jan 2022 17:56:02 -0800 (PST)
Received: from mxct.zte.com.cn (unknown [192.168.251.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4JcZkS6NLfz8132C for <bier@ietf.org>; Mon, 17 Jan 2022 09:56:00 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxct.zte.com.cn (FangMail) with ESMTPS id 4JcZjt5jD9z501Zr; Mon, 17 Jan 2022 09:55:30 +0800 (CST)
Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse-fl1.zte.com.cn with SMTP id 20H1tPWD078070; Mon, 17 Jan 2022 09:55:25 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid203; Mon, 17 Jan 2022 09:55:24 +0800 (CST)
Date: Mon, 17 Jan 2022 09:55:24 +0800
X-Zmail-TransId: 2af961e4cc8cd1cf646a
X-Mailer: Zmail v1.0
Message-ID: <202201170955247796647@zte.com.cn>
Mime-Version: 1.0
From: zhang.zheng@zte.com.cn
To: dirk.trossen@huawei.com, akbar.rahman@interdigital.com, chonggang.wang@interdigital.com, tte+ietf@cs.fau.de
Cc: bier@ietf.org
Content-Type: text/plain; charset="UTF-8"
X-MAIL: mse-fl1.zte.com.cn 20H1tPWD078070
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.138.novalocal with ID 61E4CCB0.000 by FangMail milter!
X-FangMail-Envelope: 1642384560/4JcZkS6NLfz8132C/61E4CCB0.000/192.168.251.13/[192.168.251.13]/mxct.zte.com.cn/<zhang.zheng@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 61E4CCB0.000/4JcZkS6NLfz8132C
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/9kGKa92GqQK6ftzr9nHlgFpHcoc>
Subject: [Bier] Questions for draft-ietf-bier-multicast-http-response-06
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 17 Jan 2022 01:56:06 -0000

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?
2, there is connection based on TCP/UDP between client and server, right? This draft will terminate the connection on CNAP and SNAP. If the payload of the TCP/UDP packet will be the payload of encapsulated BIER packet? The “Service Name” is still in this 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?
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?
Much appreciate for your answer!
Best regards,
Sandy

v2.23.0 | Report a Bug | By Email