Lucy, Thank you very much for the detailed comments.
Replies are inserted below: On Fri, Jan 29, 2016 at 10:38 AM, Lucy yong <[email protected]<mailto:[email protected]>> wrote: First of all, I support the draft to be published as RFC. It addresses a useful application. Here are some comments for the improvement. General: - NVO3 may have multi-homing NVE configuration, please address that each mcast method is able to support multi-homing NVEs. [Linda] Multicast in Multi-homing environment will be processed exactly the same way as the uni-cast in multi-homing environment because the target (egress NVA) is provided by the NVA. If one TS is attached to multiple NVEs, the NVA can provide all the NVEs that can reach the TS, the ingress NVE can use ECMP to choose the egress NVE for data frames destined towards the TS. I can add a sentence to the draft to state this fact: "In Multi-homing environment, i.e. multiple NVEs can reach a specific TS, the NVA will provide all the NVEs that can reach the TS. The ingress NVE can choose one of the egress NVEs for the data frames destined towards the TS." - It is necessary to elaborate security concerns in section 7 when using mcast methods in nvo3 environment - Several citations refer to old drafts, should point to the corresponding RFCs. - Terms: Tenant system, TSS, hosts, VM, are used in the draft here and there, suggest making consistent or state out at beginning that they mean the same entity. [Linda] Thanks, Add the sentence in Section 2: "In this draft, TS, host, and VM are used interchangeably to represent an end system that originate or terminate data packets. " In Section 3.2, the following text is unclear: ....When the members of a multicast group are outside the NVO3 domain, it is necessary for NVO3 gateways to keep track of the remote members of each multicast group. The NVEs then communicate these mappings to the NVA. Even if the membership is not communicated to the NVA, if it is necessary to prevent hosts attached to an NVE that have not subscribed to a multicast group from receiving the multicast traffic, the NVE needs to maintain the multicast group membership. Suggested text as follow: ...When the members of a multicast group are outside the NVO3 domain, it is necessary for NVO3 gateways to keep track of the remote members of each multicast group. The NVEs and gateways communicate the interested multicast groups to the NVA. To prevent hosts attached to an NVE that have not subscribed to a multicast group from receiving the multicast traffic, the NVE needs to maintain the multicast group membership. [Linda] Thanks. I will change it in the next version. In section 3.4, need a reference to BIER solution. [Linda] yes. Section 5.1 case may happen to all mcast methods, not only to the method in 3.3, clarify which mcast solution still can work and which will not. In addition, clarify what are TSS router and TS's router. [Linda] You are correct. Thank you very much. Linda Cheers, Lucy From: nvo3 [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Bocci, Matthew (Nokia - GB) Sent: Friday, January 22, 2016 6:16 AM To: Bocci, Matthew (Nokia - GB); NVO3 Cc: [email protected]<mailto:[email protected]> Subject: Re: [nvo3] WG last call for draft-ietf-nvo3-mcast-framework-01 WG I am going to let this last call run for a couple more weeks as I have not seen any comments. The new closing date is Friday 5th Feb 2016. Regards Matthew From: Dacheng Zhang <[email protected]<mailto:[email protected]>> on behalf of Matthew Bocci <[email protected]<mailto:[email protected]>> Date: Tuesday, 5 January 2016 at 10:40 To: NVO3 <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [nvo3] WG last call for draft-ietf-nvo3-mcast-framework-01 This email begins a two week working group last call for draft-ietf-nvo3-mcast-framework-01.txt. Please review the draft and post any comments to the NVO3 working group list. If you have read the latest version of the draft but have no comments and believe it is ready for publication as an Informational RFC, please also indicate so to the WG email list. This working group last call will close on Friday 21st January 2016. Best regards Matthew and Benson _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
