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

["Ashish Dalela (adalela)" <[e-mail]>]

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.

 

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.

 

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? 

 

Regards

Lizhong