Re: [dc] Comment of draft-dalela-dc-requirements

[Lizhong Jin<[e-mail]>]

Hi Ashish,
Please see inline below. Thanks.

Lizhong
 

"Ashish Dalela (adalela)" <[e-mail]> 写于 2012/01/10 18:26:04:

> Hi Lizhong,
> 
> Please see inline.
> 
> Thanks, Ashish
> 
> From: [e-mail] [mailto:[e-mail]] On Behalf Of 
> Lizhong Jin
> Sent: Monday, January 09, 2012 8:30 PM
> To: Ashish Dalela (adalela)
> Cc: Lizhong Jin; [e-mail]
> Subject: [dc] Comment of draft-dalela-dc-requirements
> 
> Hi Ashish,
> I have several comments to this requirement. Thanks.
> 
> Section 5.3, Multi-tenancy problem. From my side, the multi-tenancy 
> problem is not only the scalability of segmentation-ID problem, it 
> is also required to isolate performance and security among multi-
> tenant. For example, one tenant should not suffer denial-of-service 
> attacks by other tenant within same datacenter. A detailed example 
> is, the huge broadcast traffic from one tenant should not influence 
> the performace and availability of other tenants.
> 
> [AD] Ok, will add this to the multi-tenancy section.
> 
> Section 5.3, "The use of L3 VRFs also poses similar challenges of 
> scaling". The challenge for VRF is quite different with VLAN. The 
> challenge for VRF is the scalability of forwarding table. And you 
> also said:"With VRFs, these entries will be present even if there is
> no traffic from a host to other hosts in the VRF". I think this 
> could be optimized that the FIB would store only active route 
> entries, while the RIB would store all route entries.
> 
> [AD] Others have expressed reservations about these “dynamically 
> learnt” entries. E.g. if a IP scanning attack is launched to unknown
> IP addresses, it will load the control plane, although there is 
> nothing in the RIB. But, in any case, we are just trying to define 
> the problem and optimizations are a solution are possible. I will 
> modify the VRF statement to reflect your concern.
> 
> [AD] The same scaling concern also exists in the L2/VLAN case where 
> a MAC address has to be learnt. They are host routes, either L2 or 
> L3 or done via some sort of encapsulation.
[Lizhong] yes, agree
> 
> Section 5.5, last paragraph about mobility. It seems that this 
> paragraph is not much related with "network convergence", but is 
> about "host mobility impact to the network resource". 
> 
> [AD] This paragraph is describing what happens when a whole server 
> is replicated (not just a single VM). This will happen in case of 
> disaster recovery. Note that in this case there is change to host 
> routes, but also change to network routes (the routes to reach the 
> virtual switch have changed). Let me know if this needs to be 
> reworded or clarified more.
[Lizhong] if you refer the virtual switch and firewall relocation as 
network convergence, then the word is OK.
> 
> While I find that, section 5.1 is about the "host mobility impact to
> L2/3 forwarding", 5.10 is about the "host mobility impact to 
> forwarding tables". Suggest to re-organize the three parts which are
> all related with impact of host mobility.
> 
> [AD] Agree with your comment. Section 5.5 describes control plane 
> scale while 5.10 describes forwarding plane scale issues. Section 5.
> 1 is overlapping. Would you suggest removing 5.1? 
[Lizhong] merging 5.1 to 5.10 is OK.
> 
> Regards
> Lizhong


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.