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

From: <[email-masked]>
Date: Mon, 17 Jan 2022 09:55:24 +0800 (CST)

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

---

From: Dirk Trossen <[email-masked]>
Date: Mon, 17 Jan 2022 11:05:19 +0000

Hi Sandy,

Thanks for the questions. Please see inline.

Best,

Dirk

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 17 January 2022 02:55
To: Dirk Trossen <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
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,
Sandy

---

From: <[email-masked]>
Date: Tue, 18 Jan 2022 16:55:27 +0800 (CST)

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

------------------原始邮件------------------
发件人：DirkTrossen
收件人：张征00007940;[email-masked];[email-masked];[email-masked];
抄送人：[email-masked];
日 期 ：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.
Best,
Dirk
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 17 January 2022 02:55
To: Dirk Trossen <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Bier] Questions for draft-ietf-bier-multicast-http-response-06
Hi authors,
Sandy> Got it. Thank you!
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,
Sandy
Much appreciate for your answer!
[DOT] I hope I did answer your questions well.
Best regards,
Sandy

---

From: Dirk Trossen <[email-masked]>
Date: Tue, 18 Jan 2022 09:01:55 +0000

Hi Sandy,

Please see inline.

Best,

Dirk

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

Hi Dirk, 
[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.

------------------原始邮件------------------
发件人：DirkTrossen
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 17 January 2022 02:55
To: Dirk Trossen <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Bier] Questions for draft-ietf-bier-multicast-http-response-06
Hi authors,