Re: [armd] how does "draft-sridharan-virtualization-nvgre-00"advertise its external facing hosts' IP addresses to external world?
Benson Schliesser <bschlies@cisco.com> Sat, 24 September 2011 18:22 UTC
Return-Path: <bschlies@cisco.com>
X-Original-To: armd@ietfa.amsl.com
Delivered-To: armd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9976721F8713 for <armd@ietfa.amsl.com>; Sat, 24 Sep 2011 11:22:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.296
X-Spam-Level:
X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-I9Y9AvuuuF for <armd@ietfa.amsl.com>; Sat, 24 Sep 2011 11:22:21 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A07BA21F86A1 for <armd@ietf.org>; Sat, 24 Sep 2011 11:22:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=54712; q=dns/txt; s=iport; t=1316888698; x=1318098298; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=a1qYHR7DVg0EzhytaggkHgLQ738aoq4qpLoKGWlusFk=; b=jT4gMSdwBqXfyHmALouP1+WafhbBVnhbn6a0rr0VdH+8NJiB1LFmnxrx 5AmzX0xauQo+XZ35WTVzwXoGVNsRpseGn/WQvJSzsBqx7WzEpUijAfKx8 bJDsUueK7WJeuHdH6VrgLWb8naPIUQQYAx2zFqxDnEcV44Uxkx6CLgrWn Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArwAAL8ffk6tJXG+/2dsb2JhbABCgk2WU4deAYR9djxueIFTAQEBAQIBAQEBDwEHASIxBAcFBwYBCA4DBAEBASABAgQoBh8JCAIEAQ0FCRIEA4dWBppOAZ0YhwsEh0Iwi2CFK4Rshzo
X-IronPort-AV: E=Sophos; i="4.68,435,1312156800"; d="scan'208,217"; a="23788451"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 24 Sep 2011 18:24:56 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8OIOuUn000455; Sat, 24 Sep 2011 18:24:56 GMT
Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Sep 2011 13:24:56 -0500
Received: from 10.21.72.138 ([10.21.72.138]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; Sat, 24 Sep 2011 18:24:55 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Sat, 24 Sep 2011 13:24:50 -0500
From: Benson Schliesser <bschlies@cisco.com>
To: Narasimhan Venkataramaiah <narave@microsoft.com>, Linda Dunbar <linda.dunbar@huawei.com>, Vishwas Manral <vishwas.ietf@gmail.com>, Murari Sridharan <muraris@microsoft.com>
Message-ID: <CAA38AA2.15970%bschlies@cisco.com>
Thread-Topic: [armd] how does "draft-sridharan-virtualization-nvgre-00"advertise its external facing hosts' IP addresses to external world?
Thread-Index: AQHMdgwxzKQpmaafWkqNIE83xQq6KJVTbCHGgAcU1gD//4sFsIAAeWoAgAAGy4CAAAFnAIAAAHwAgAAA1ACAAAHwAIAAK/SAgAJKO4D//81YUIAADgaw
In-Reply-To: <65755BEBE02F7C41BD4F137AED91DA5E2FD3872E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3399715491_61616018"
X-OriginalArrivalTime: 24 Sep 2011 18:24:56.0132 (UTC) FILETIME=[42A93040:01CC7AE7]
Cc: "armd@ietf.org" <armd@ietf.org>
Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00"advertise its external facing hosts' IP addresses to external world?
X-BeenThere: armd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." <armd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/armd>, <mailto:armd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/armd>
List-Post: <mailto:armd@ietf.org>
List-Help: <mailto:armd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/armd>, <mailto:armd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Sep 2011 18:22:26 -0000
Thanks, Simha. Leaving aside your comments about support for non-IP payloads, etc, and focusing strictly on address resolution: Would carrying IP in the overlay inherently localize the address resolution functions (ARP, ND)? Conversely, does carrying L2 frames in the overlay suggest the extension or enlargement of ARP/ND domains? Or would you propose an ARP/ND proxy in the MAC overlay? It seems to me that scale of the address resolution function will be affected by the way it¹s distributed (or not) throughout the overlay network. Likewise, this may have impact on the forwarding efficiency of traffic (i.e. when there are multiple inbound/outbound paths attached to the overlay). Cheers, -Benson On 9/24/11 12:36 PM, "Narasimhan Venkataramaiah" <narave@microsoft.com> wrote: > Posting back some offline emails > > From: Narasimhan Venkataramaiah > Sent: Thursday, September 22, 2011 9:49 PM > To: 'Vishwas Manral' > Cc: Murari Sridharan; Linda Dunbar; david.black@emc.com; Benson Schliesser > Subject: RE: [armd] how does "draft-sridharan-virtualization-nvgre-00" > advertise its external facing hosts' IP addresses to external world? > > In some cases the it may be more efficient to just send IP but given MAC in > GRE is a superset, its simpler to just always do MAC in GRE from an > engineering point of view for various hardware devices that parse the packets > to provide added functionality in the path. They have to deal with one type of > packets. We would need MAC in GRE to stretch L2 to non NV-GRE subnets or to > carry non IP payload. > > Simha > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Thursday, September 22, 2011 9:43 PM > To: Narasimhan Venkataramaiah > Cc: Murari Sridharan; Linda Dunbar; david.black@emc.com; Benson Schliesser > Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" > advertise its external facing hosts' IP addresses to external world? > > I agree PMIP may not directly work here. In such cases the Layer-2 header > however is still of no use. > > -Vishwas > On Thu, Sep 22, 2011 at 9:07 PM, Narasimhan Venkataramaiah > <narave@microsoft.com> wrote: > Right with NVGRE L2 mobility happens automatically however if you were to > achieve it without NVGRE in a multitenant environment you would need some VLAN > reconfiguration. NVGRE achieves that with Tenant IDs. > PMIP is not multi-tenancy aware in the sense that the proxy won¹t be able to > distinguish between multiple tenants using same IP address space in the > virtual network. > Simha > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Thursday, September 22, 2011 8:51 PM > To: Narasimhan Venkataramaiah > Cc: Murari Sridharan; Linda Dunbar; david.black@emc.com; Benson Schliesser > > Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" > advertise its external facing hosts' IP addresses to external world? > > Hi Simha, > With that aspect there is little difference in the functionality, though > L3-in-L3 can use PMIP and other mobility work already done. > Also it begs the question why you even need L2 mobility in this case > Moving off the list as Benson feels the replies are not substantial. > Thanks, > Vishwas > On Thu, Sep 22, 2011 at 8:34 PM, Narasimhan Venkataramaiah > <narave@microsoft.com> wrote: > Say you have a virtual subnet that spans 2 physical subnets. A VM in a virtual > subnet moving to another host within the same physical subnet is L2 mobility > and a VM moving to another host on another in a different physical subnet is > L3 mobility. These 2 cases are the same for NV-GRE in terms of encapsulation > as the resulting packets are the same. What does IP in GRE achieve that MAC in > GRE does not? > Simha > > > > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Linda > Dunbar > Sent: Saturday, September 24, 2011 6:36 AM > To: Vishwas Manral; Murari Sridharan > Cc: armd@ietf.org > Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" > advertise its external facing hosts' IP addresses to external world? > > Protocols have been developed for IP mobility between Home Gateway and Remote > Gateway. The question is if we want similar protocols among TORs or among > vSwitches. Handset mobility is random, but VM migration is planned. > > Linda > > > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Vishwas Manral > Sent: Thursday, September 22, 2011 9:38 PM > To: Murari Sridharan > Cc: armd@ietf.org > Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" > advertise its external facing hosts' IP addresses to external world? > > > Murari think IP mobility. :) > > > > On Thu, Sep 22, 2011 at 5:00 PM, Murari Sridharan <muraris@microsoft.com> > wrote: > > Do you have a scenario in mind? > > > From: Vishwas Manral > Sent: 9/22/2011 4:55 PM > > > To: Murari Sridharan > Cc: Narasimhan Venkataramaiah; Linda Dunbar; david.black@emc.com; > armd@ietf.org > Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" > advertise its external facing hosts' IP addresses to external world? > > Hi Murari, > > > > Yes that is what I mean. > > > > Thanks, > > Vishwas > > On Thu, Sep 22, 2011 at 4:50 PM, Murari Sridharan <muraris@microsoft.com> > wrote: > > You mean not an Ethernet frame but some IP payload? > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Thursday, September 22, 2011 4:49 PM > To: Murari Sridharan > Cc: Narasimhan Venkataramaiah; Linda Dunbar; david.black@emc.com; > armd@ietf.org > > > Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" > advertise its external facing hosts' IP addresses to external world? > > > > Murari, > > > > What I am saying is the inner header should be allowed to be L3. > > > > From the diagram you have that does not seem to be the case. Am I missing it > totally? > > > > Thanks, > > Vishwas > > On Thu, Sep 22, 2011 at 4:43 PM, Murari Sridharan <muraris@microsoft.com> > wrote: > > Vishwas, Thanks for the feedback we will definitely consider adding that. I am > not sure what you mean by doing L3 instead of L2. We allow any arbitrary > virtual topology including L3. > > Thanks > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Thursday, September 22, 2011 4:19 PM > > > To: Narasimhan Venkataramaiah > Cc: Linda Dunbar; Murari Sridharan; david.black@emc.com; armd@ietf.org > Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" > advertise its external facing hosts' IP addresses to external world? > > > > Hi Simha, > > > > I see this as the only difference between VXLAN and the NVGRE solution > (besides ofcourse that TNI needs to be parsed in the intermediate device for > hashing and using lesser number of bytes). > > > > I would think you should add it to your draft immediately. With tunneling you > consolidate the addresses visible to the core and by providing a hash > mechanism, you are providing some level of randomness. > > > > The other thing you should look at is L3 (IPv4/ IPv6) over NVGRE instead of L2 > alone. I guess it would be the same comment for the VXLAN proposal too. > > > > Thanks, > > Vishwas > > On Thu, Sep 22, 2011 at 4:11 PM, Narasimhan Venkataramaiah > <narave@microsoft.com> wrote: > > The draft mentions exactly this as one use of the reserved 8 bits in Section > 4. An NVGRE endpoint could use the 8 bits to further distribute flows > belonging to a particular TNI and the switches use all 32 bits to get entropy. > One step further would be for the switches to get full entropy from the inner > Ethernet frame. I take it that your comment would be to make it explicit in > the draft. Right? > > One > such example could be to use the upper 8 bits of the Key field to > add flow based entropy and tag all the packets from a flow with an entropy > label. > > Simha > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Thursday, September 22, 2011 4:04 PM > To: Narasimhan Venkataramaiah > Cc: Linda Dunbar; Murari Sridharan; david.black@emc.com; armd@ietf.org > Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" > advertise its external facing hosts' IP addresses to external world? > > > > Hi Simha, > > > > The main (Standards Track) change in your draft is the addition of TNI. > > > > A question I have is a TNI identifies a particular tenant and all flows > from/to a tenant will be hashed to the same path (even with the changes in > switches to do hashing to use TNI). > > > > Why do you not use the last 8 bits which you have kept as reserved for > providing the randomization for hashing flows between same to/from on > different paths? > > > > Thanks, > > Vishwas > > On Sun, Sep 18, 2011 at 11:01 AM, Narasimhan Venkataramaiah > <narave@microsoft.com> wrote: > The easiest from the point of view of configuration would be to route > everything back through the enterprise - not necessarily the optimal from the > enterprise point of view. Are you referring to a scenario where the VMs subnet > is split between the cloud and the enterprise? Otherwise I don't see the > implication on virtualization as its no different than getting the traffic > routed to the enterprise in the first case. > > Simha > > ________________________________________ > From: armd-bounces@ietf.org [armd-bounces@ietf.org] on behalf of Linda Dunbar > [linda.dunbar@huawei.com] > Sent: Sunday, September 18, 2011 7:06 AM > To: Murari Sridharan; david.black@emc.com; armd@ietf.org > Subject: [armd] how does "draft-sridharan-virtualization-nvgre-00" advertise > its external facing hosts' IP addresses to external world? > > > Hi Murari, > > Thank you very much for sharing the presentation. > > One question: > > For a host within an Enterprise site which needs to communicate with external > peers, the host either uses public IP address which is visible to external > peers or uses private IP address which is translated to public address at the > Enterprise site's gateway. > > When this host is moved to "Cloud data center", will the "Cloud Data center" > advertise this host address to external peers? Or will all external peers go > through enterprise's gateway to reach this host which is no longer residing in > the enterprise site? > > Thanks, Linda > >> > -----Original Message----- >> > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of >> > Murari Sridharan >> > Sent: Saturday, September 17, 2011 3:02 PM >> > To: david.black@emc.com; armd@ietf.org >> > Subject: Re: [armd] soliciting typical network designs for ARMD >> > >> > FYI, here is a talk that I gave last week in relation to the nvgre >> > draft below. >> > http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-442T >> > >> > Thanks >> > Murari >> > >> > -----Original Message----- >> > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of >> > david.black@emc.com >> > Sent: Friday, September 16, 2011 6:14 AM >> > To: armd@ietf.org >> > Subject: Re: [armd] soliciting typical network designs for ARMD >> > >> > And two more drafts on this topic: >> > >> > http://www.ietf.org/id/draft-mahalingam-dutt-dcops-vxlan-00.txt >> > http://www.ietf.org/id/draft-sridharan-virtualization-nvgre-00.txt >> > >> > The edge switches could be the software switches in hypervisors. >> > >> > Thanks, >> > --David >> > >> > >>> > > -----Original Message----- >>> > > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf >>> > > Of Warren Kumari >>> > > Sent: Wednesday, August 31, 2011 3:16 PM >>> > > To: Vishwas Manral >>> > > Cc: armd@ietf.org >>> > > Subject: Re: [armd] soliciting typical network designs for ARMD >>> > > >>> > > >>> > > On Aug 11, 2011, at 11:40 PM, Vishwas Manral wrote: >>> > > >>>> > > > Hi Linda/ Anoop, >>>> > > > >>>> > > > Here is the example of the design I was talking about, as defined >> > by google. >>> > > >>> > > Just a clarification -- s/as defined by google/as described by >> > someone >>> > > who happens to work for google/ >>> > > >>> > > W >>> > > >>>> > > > http://www.ietf.org/id/draft-wkumari-dcops-l3-vmmobility-00.txt >>>> > > > >>>> > > > Thanks, >>>> > > > Vishwas >>>> > > > On Tue, Aug 9, 2011 at 2:50 PM, Anoop Ghanwani >> > <anoop@alumni.duke.edu> wrote: >>>> > > > >>>>>>>> > > > >>>> >>>> > > > (though I think if there was a standard way to map Multicast MAC to >>>> > > > Multicast IP, they could >>> > > probably use such a standard mechanisms). >>>>>>>> > > > >>>> >>>> > > > >>>> > > > They can do that, but then this imposes requirements on the >>>> > > > equipment to be able to do multicast forwarding, and even if does, >>>> > > > because of pruning requirements the number of groups would be very >>>> > > > large. The average data center switch probably won't handle that >>>> > > > many groups. >>>> > > > >>>> > > > On Tue, Aug 9, 2011 at 2:41 PM, Vishwas Manral >> > <vishwas.ietf@gmail.com> wrote: >>>> > > > Hi Anoop, >>>> > > > >>>> > > > From what I know they do not use Multicast GRE (I hear the extra 4 >>>> > > > bytes in the GRE header is a >>> > > proprietery extension). >>>> > > > >>>> > > > I think a directory based mechanism is what is used (though I think >>>> > > > if there was a standard way to >>> > > map Multicast MAC to Multicast IP, they could probably use such a >> > standard mechanisms). >>>> > > > >>>> > > > Thanks, >>>> > > > Vishwas >>>> > > > On Tue, Aug 9, 2011 at 2:03 PM, Anoop Ghanwani >> > <anoop@alumni.duke.edu> wrote: >>>> > > > Hi Vishwas, >>>> > > > >>>> > > > How do they get multicast through the network in that case? >>>> > > > Are they planning to use multicast GRE, or just use directory based >>>> > > > lookups and not worry about multicast applications for now? >>>> > > > >>>> > > > Anoop >>>> > > > >>>> > > > On Tue, Aug 9, 2011 at 1:27 PM, Vishwas Manral >> > <vishwas.ietf@gmail.com> wrote: >>>> > > > Hi Linda, >>>> > > > >>>> > > > The data packets can be tunnelled at the ToR over say a GRE packet >>>> > > > and the core is a Layer-3 core >>> > > (except for the downstream ports). So we could have encapsulation/ >>> > > decapsulation of L2 over GRE at the ToR. >>>> > > > >>>> > > > The very same thing can be done at the hypervisor layer too, in >>>> > > > which case the entire DC network >>> > > would look like a Layer-3 flat network including the ToR to server >>> > > link and the hypervisor would do the tunneling. >>>> > > > >>>> > > > I am not sure if you got the points above or not. I know cloud OS >>>> > > > companies that provide the service >>> > > and have big announced customers. >>>> > > > >>>> > > > Thanks, >>>> > > > Vishwas >>>> > > > On Tue, Aug 9, 2011 at 11:51 AM, Linda Dunbar <dunbar.ll@gmail.com> >> > wrote: >>>> > > > Vishwas, >>>> > > > >>>> > > > In my mind the bullet 1) in the list refers to ToR switches >>>> > > > downstream ports (facing servers) >>> > > running Layer 2 and ToR uplinks ports run IP Layer 3. >>>> > > > >>>> > > > Have you seen data center networks with ToR switches downstream >>>> > > > ports (i.e. facing servers) enabling >>> > > IP routing, even though the physical links are Ethernet? >>>> > > > If yes, we should definitely include it in the ARMD draft. >>>> > > > >>>> > > > Thanks, >>>> > > > Linda >>>> > > > On Tue, Aug 9, 2011 at 12:58 PM, Vishwas Manral >> > <vishwas.ietf@gmail.com> wrote: >>>> > > > Hi Linda, >>>> > > > I am unsure what you mean by this, but: >>>> > > > * layer 3 all the way to TOR (Top of Rack switches), We can also >>>> > > > have a heirarchical network, with the core totally Layer-3 (and >>>> > > > having seperate >>> > > routing), from the hosts still in a large Layer-3 subnet. Another >>> > > aspect could be to have a totally >>> > > Layer-3 network. >>>> > > > >>>> > > > The difference between them is the link between the servers and the >> > ToR. >>>> > > > >>>> > > > Thanks, >>>> > > > Vishwas >>>> > > > On Tue, Aug 9, 2011 at 10:22 AM, Linda Dunbar <dunbar.ll@gmail.com> >> > wrote: >>>> > > > During the 81st IETF ARMD WG discussion, it was suggested that it >> > is >>>> > > > necessary to document typical >>> > > data center network designs so that address resolution scaling issues >>> > > can be properly described. Many data center operators have expressed >> > that they can't openly reveal their detailed network designs. >>> > > Therefore, we only want to document anonymous designs without too >> > much >>> > > detail. During the journey of establishing ARMD, we have come across >> > the following typical data center network designs: >>>> > > > * layer 3 all the way to TOR (Top of Rack switches), >>>> > > > * large layer 2 with hundreds (or thousands) of ToRs being >>>> > > > interconnected by Layer 2. This >>> > > design will have thousands of hosts under the L2/L3 boundary router >>> > > (s) >>>> > > > * CLOS design with thousands of switches. This design will have >>>> > > > thousands of hosts under the >>> > > L2/L3 boundary router(s) >>>> > > > We have heard that each of the designs above has its own problems. >>>> > > > ARMD problem statements might >>> > > need to document DC problems under each typical design. >>>> > > > Please send feedback to us (either to the armd email list or to >> > the >>>> > > > ARMD chair Benson & Linda) to >>> > > indicate if we have missed any typical Data Center network designs. >>>> > > > >>>> > > > Your contribution can greatly accelerate the progress of ARMD WG. >>>> > > > >>>> > > > Thank you very much. >>>> > > > >>>> > > > Linda & Benson >>>> > > > > > > > > > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd
- [armd] soliciting typical network designs for ARMD Linda Dunbar
- Re: [armd] soliciting typical network designs for… Vishwas Manral
- Re: [armd] soliciting typical network designs for… Linda Dunbar
- Re: [armd] soliciting typical network designs for… Vishwas Manral
- Re: [armd] soliciting typical network designs for… Vishwas Manral
- Re: [armd] soliciting typical network designs for… Anoop Ghanwani
- Re: [armd] soliciting typical network designs for… Anoop Ghanwani
- Re: [armd] soliciting typical network designs for… Vishwas Manral
- Re: [armd] soliciting typical network designs for… Warren Kumari
- Re: [armd] soliciting typical network designs for… Linda Dunbar
- Re: [armd] soliciting typical network designs for… david.black
- Re: [armd] soliciting typical network designs for… Murari Sridharan
- [armd] how does "draft-sridharan-virtualization-n… Linda Dunbar
- Re: [armd] how does "draft-sridharan-virtualizati… Narasimhan Venkataramaiah
- Re: [armd] soliciting typical network designs for… Balus, Florin Stelian (Florin)
- Re: [armd] how does "draft-sridharan-virtualizati… Linda Dunbar
- Re: [armd] soliciting typical network designs for… Joel M. Halpern
- Re: [armd] how does "draft-sridharan-virtualizati… Narasimhan Venkataramaiah
- Re: [armd] how does "draft-sridharan-virtualizati… Vishwas Manral
- Re: [armd] how does "draft-sridharan-virtualizati… Narasimhan Venkataramaiah
- Re: [armd] how does "draft-sridharan-virtualizati… Vishwas Manral
- Re: [armd] how does "draft-sridharan-virtualizati… Murari Sridharan
- Re: [armd] how does "draft-sridharan-virtualizati… Vishwas Manral
- Re: [armd] how does "draft-sridharan-virtualizati… Murari Sridharan
- Re: [armd] how does "draft-sridharan-virtualizati… Vishwas Manral
- Re: [armd] how does "draft-sridharan-virtualizati… Murari Sridharan
- Re: [armd] how does "draft-sridharan-virtualizati… Vishwas Manral
- Re: [armd] how does "draft-sridharan-virtualizati… Murari Sridharan
- Re: [armd] how does "draft-sridharan-virtualizati… Vishwas Manral
- Re: [armd] how does "draft-sridharan-virtualizati… Narasimhan Venkataramaiah
- Re: [armd] how does "draft-sridharan-virtualizati… Vishwas Manral
- Re: [armd] how does "draft-sridharan-virtualizati… Narasimhan Venkataramaiah
- Re: [armd] how does "draft-sridharan-virtualizati… Gary Berger
- Re: [armd] soliciting typical network designs for… Warren Kumari
- Re: [armd] how does "draft-sridharan-virtualizati… Linda Dunbar
- Re: [armd] how does "draft-sridharan-virtualizati… Narasimhan Venkataramaiah
- Re: [armd] how does "draft-sridharan-virtualizati… Benson Schliesser
- Re: [armd] how does "draft-sridharan-virtualizati… Narasimhan Venkataramaiah
- Re: [armd] how does "draft-sridharan-virtualizati… Gary Berger
- Re: [armd] how does "draft-sridharan-virtualizati… Vishwas Manral
- Re: [armd] how does "draft-sridharan-virtualizati… Linda Dunbar
- Re: [armd] how does "draft-sridharan-virtualizati… Michael Smith
- Re: [armd] how does "draft-sridharan-virtualizati… Vishwas Manral
- Re: [armd] how does "draft-sridharan-virtualizati… Gary Berger (gaberger)
- [armd] Multi-homing in data center Linda Dunbar
- Re: [armd] Multi-homing in data center Gary Berger
- Re: [armd] how does "draft-sridharan-virtualizati… Michael Smith
- Re: [armd] how does "draft-sridharan-virtualizati… david.black