Re: [dc] Elevator Pitch (was: Scoping the Interim meeting)

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

Xuxiaohu,

I'm trying to avoid getting into a specific solution at this point, as the request is to offer problem statements. 

Here are a couple of more requirements to the below:

-----------------------

Eighth, the packet forwarding scheme must be able to use all available paths to a destination (ECMP). This is for load-balancing available paths and maximizing utilization of available bandwidth. In a way that implies turning off STP because STP blocks many paths. The requirement holds true for intra-dc and inter-dc forwarding. The intra-dc is governed by server-to-server (east-west) flows, and inter-dc due to many users and bursts.

Ninth, there should be mechanisms to guarantee network SLAs in a multi-tenant environment. In particular, high traffic from one tenant should not adversely affect all other tenants on the network who are using the same shared network medium to communicate. Users entering a multi-tenant environment ought to be able to specify their network needs just as they specify compute and storage needs. VM mobility needs to take into account if sufficient network bandwidth will be available after move. It might also take into account latency.

Tenth, forwarding schemes must be optimized for unicast, broadcast and multicast traffics. In broadcast cases, this might imply broadcast control (if possible, both within and between a dc). In multicast, it implies choosing the most optimal points of packet replication to reduce bandwidth use (access, core, edge, etc). Note that multicast replication points may need to change with VM mobility.

-----------------------

Thanks, Ashish


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Xuxiaohu
Sent: Friday, December 23, 2011 9:42 AM
To: Ashish Dalela (adalela); Ronald Bonica; Thomas Narten; So, Ning
Cc: [e-mail]
Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting)

Hi,

Let me express my opinion on your first point. It's true that installing host route is not scalable in general. However, once the subnet has been extended across multiple data centers for VM mobility, you can 't use subnet for routing any more. Either MAC based forwarding or host route based routing (both of them are in the host granularity), you need to choose one. Using Mobile IP alike approach will stretch the forwarding path and hence will increase the forwarding latency. Once we choose the host route based approach, we can use the map&encap scheme like L3VPN to address the scaling issue on the P routers, and further we can even use the on-demand FIB-installation or on-demand routing announcement to address the FIB/RIB scaling issue on the PE routers. 

Best regards,
Xiaohu
.
> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]] 代表 Ashish
> Dalela (adalela)
> 发送时间: 2011年12月23日 11:25
> 收件人: Ronald Bonica; Thomas Narten; So, Ning
> 抄送: [e-mail]
> 主题: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting)
> 
> 
> Here's my elevator pitch. I'll assume that elevator has to go to the
> 140th floor, with a few stops.
> 
> -------------
> 
> Large virtualized datacenters pose several networking challenges.
> 
> First, native L2 or L3 forwarding technologies do not work. L2 networks
> can't be large due to high number of broadcasts. L3 networks can't be
> used because of VM mobility, since routing uses subnets and the IP
> cannot be moved out of that subnet. Moving IP in a natively L3 network
> requires installing a host route, which is an approach that can't be
> scaled. Hence, a new approach is required.
> 
> Second, datacenters will span across locations, and in the hybrid cloud
> case need to connect private-public domains. VM mobility across these
> sites has the same issues as mobility within a datacenter, although the
> technology to address it must run "over" the L3 Internet.
> 
> Third, the need of a new approach is reinforced by multi-tenancy of
> cloud networks. Native L2 networks are constrained by 4096 VLANs, which
> may be too few segments to distinguish customers in a public cloud.
> Further, when private and public clouds are connected, private VLAN
> identities will get extended into the public domain, causing VLAN
> overlap. Some method of uniquely identifying a customer in the public
> cloud is needed.
> 
> Fourth, given that small, large, huge datacenters will need to be
> interconnected and need to work seamlessly, the technology for the
> datacenter must be agnostic of the architecture used in a specific case.
> Each datacenter may architect the network differently depending on their
> scale. This has been true of past of L2 (e.g. STP) and L3 (e.g. OSPF)
> technologies that are topology agnostic.
> 
> Fifth, networking schemes spanning across these large domains must be
> cognizant of "convergence" issues, especially arising out of VM mobility
> and hardware / software failures, which will be common at a large scale.
> Network convergence on mobility and failure will require control plane
> signaling and forwarding plane churn. This churn needs to be minimized
> in order to keep the network stable.
> 
> Sixth, large cloud datacenters depend on economies of scale, and need to
> reduce equipment cost and energy. This is possible only when the
> technology scales easily both at a hardware and software level, keeping
> the cost and energy consumed low. As an example, technologies that do
> map-encap require per flow hardware entries, and per flow setup
> signaling, which is very expensive at scale.
> 
> Seventh, move into a multi-tenant environment depends upon sufficient
> "controls" for a user (preferably easy to use). Loss of control will
> prevent users from using these facilities (cloud doesn't equal to
> fuzzy). The "control" problem requires a standard interface across
> private-public and public-public domains. This interface should
> facilitate discovery and management of services, including real-time
> debugging and statistics.
> 
> ------------
> 
> Thanks, Ashish
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Ronald Bonica
> Sent: Friday, December 23, 2011 3:40 AM
> To: Thomas Narten; So, Ning
> Cc: [e-mail]
> Subject: [dc] Elevator Pitch (was: Scoping the Interim meeting)
> 
> Folks,
> 
> Amplifying what Thomas said:
> 
> At this point, the most helpful thing that anyone can do is to summarize
> the problem(s) that we are trying to solve in a relatively terse email.
> Once we come to consensus on that brief summary, we can flesh it out
> into very short Internet Draft.
> 
> I look forward to hearing your elevator pitches.
> 
>                                                      Happy
> Holidays,
>                                                         Ron
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Thomas Narten
> > Sent: Wednesday, December 21, 2011 1:31 PM
> > To: So, Ning
> > Cc: Ronald Bonica; [e-mail]
> > Subject: Re: [dc] Scoping the Interim meeting
> >
> > We sure have a lot of volunteers wanting to help. That is fine at one
> > level, but misses the bigger point.
> >
> > The best way to help is to articulate a specific problem or area.
> >
> > Do so on this list in a single message. We don't need yet more
> > documents (at least not yet).
> >
> > 2-4 paragraphs (no more).  Think "elevator pitch"
> > (http://en.wikipedia.org/wiki/Elevator_pitch)
> >
> > You only get a couple of minutes to make your case, and if you can't
> > do so, either you don't understand the problem yourself well enough,
> > or the value-proposition just isn't compelling.
> >
> > So far, I haven't seen discussions of specific problems (or problem
> > areas). What I'm seeing is pointers to lots of drafts, many of which
> > (for those that I've looked at) don't crisply get at a real, tangible
> > problem that I understand and think the IETF can/should work on. Bonus
> > points for showing:
> >
> > 1) an operator (or some other clear customer/consumer technology) that
> >    says "yes, that is what I need, and if it was available today, I'd
> >    use it"
> >
> > 2) a vendor saying "here is what my customers are telling me will
> >    solve a problem of theirs", and we think an IETF standard is
> >    needed.
> >
> > 3) demonstration of a clear technical/protocol gap between what is
> >    available today, and what is needed to address the problem.
> >
> > Thomas
> >
> > _______________________________________________
> > dc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dc
> _______________________________________________
> dc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dc
> _______________________________________________
> dc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dc
_______________________________________________
dc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dc