Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00"advertise its external facing hosts' IP addresses to external world?

From: Gary Berger <[email-masked]>
Date: Fri, 24 Feb 2012 17:22:37 -0500

> 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.

I wouldn't put such a restriction, vm migration may not be planned.. They
both degenerate into a multi-homing problem.
>  
> Linda
>  
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Vishwas Manral
> Sent: Thursday, September 22, 2011 9:38 PM
> To: Murari Sridharan
> Cc: [email-masked]
> 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 <[email-masked]>
> 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; [email-masked];
> [email-masked]
> 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 <[email-masked]>
> wrote:
> 
> You mean not an Ethernet frame but some IP payload?
>  
> From: Vishwas Manral [mailto:[email-masked]]
> Sent: Thursday, September 22, 2011 4:49 PM
> To: Murari Sridharan
> Cc: Narasimhan Venkataramaiah; Linda Dunbar; [email-masked];
> [email-masked]
> 
> 
> 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 <[email-masked]>
> 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:[email-masked]]
> Sent: Thursday, September 22, 2011 4:19 PM
> 
> 
> To: Narasimhan Venkataramaiah
> Cc: Linda Dunbar; Murari Sridharan; [email-masked]; [email-masked]
> 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
> <[email-masked]> 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:[email-masked]]
> Sent: Thursday, September 22, 2011 4:04 PM
> To: Narasimhan Venkataramaiah
> Cc: Linda Dunbar; Murari Sridharan; [email-masked]; [email-masked]
> 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
> <[email-masked]> 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: [email-masked] [[email-masked]] on behalf of Linda Dunbar
> [[email-masked]]
> Sent: Sunday, September 18, 2011 7:06 AM
> To: Murari Sridharan; [email-masked]; [email-masked]
> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
>> > Murari Sridharan
>> > Sent: Saturday, September 17, 2011 3:02 PM
>> > To: [email-masked]; [email-masked]
>> > 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: [email-masked] [mailto:[email-masked]] On Behalf Of
>> > [email-masked]
>> > Sent: Friday, September 16, 2011 6:14 AM
>> > To: [email-masked]
>> > 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: [email-masked] [mailto:[email-masked]] On Behalf
>>> > > Of Warren Kumari
>>> > > Sent: Wednesday, August 31, 2011 3:16 PM
>>> > > To: Vishwas Manral
>>> > > Cc: [email-masked]
>>> > > 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
>> > <[email-masked]> 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
>> > <[email-masked]> 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
>> > <[email-masked]> 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
>> > <[email-masked]> 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 <[email-masked]>
>> > 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
>> > <[email-masked]> 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 <[email-masked]>
>> > 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
> [email-masked] https://www.ietf.org/mailman/listinfo/armd

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 27 Feb 2012 16:48:46 -0800

Hi Gary,

I guess what Linda was trying to say is that the station moves
autonomously, however there is some entity moving the VM (which can in turn
could move the state on the switch).

An example of this could be VEPA.

Thanks,
Vishwas

On Fri, Feb 24, 2012 at 2:22 PM, Gary Berger <[email-masked]> wrote:

>
>
> 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:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Vishwas Manral
> *Sent:* Thursday, September 22, 2011 9:38 PM
> *To:* Murari Sridharan
> *Cc:* [email-masked]
> *Subject:* Re: [armd] how does "draft-sridharan-virtualization-nvgre-00"
> advertise its external facing hosts' IP addresses to external world?****
>
> ** **
>
> Murari think IP mobility. :)****
>
>  ****
>
> 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; [email-masked];
> [email-masked]
> *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****
>
> wrote:****
> You mean not an Ethernet frame but some IP payload?****
>
>  ****
>
> *From:* Vishwas Manral [mailto:[email-masked]]
> *Sent:* Thursday, September 22, 2011 4:49 PM
> *To:* Murari Sridharan
> *Cc:* Narasimhan Venkataramaiah; Linda Dunbar; [email-masked];
> [email-masked]****
>
>
> *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****
>
> 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:[email-masked]]
> *Sent:* Thursday, September 22, 2011 4:19 PM ****
>
>
> *To:* Narasimhan Venkataramaiah
> *Cc:* Linda Dunbar; Murari Sridharan; [email-masked]; [email-masked]
> *Subject:* Re: [armd] how does "draft-sridharan-virtualization-nvgre-00"
> advertise its external facing hosts' IP addresses to external world?****
>
>  ****
>
> Hi Simha,****
>
>  ****
>
> (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 <
> [email-masked]> 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:[email-masked]]
> *Sent:* Thursday, September 22, 2011 4:04 PM
> *To:* Narasimhan Venkataramaiah
> *Cc:* Linda Dunbar; Murari Sridharan; [email-masked]; [email-masked]
> *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.***
> *
>
>  ****
>
> switches to do hashing to use TNI).****
>
>  ****
>
> different paths?****
>  ****
> Thanks,****
> Vishwas****
> On Sun, Sep 18, 2011 at 11:01 AM, Narasimhan Venkataramaiah <
> [email-masked]> wrote:****
>
> 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: [email-masked] [[email-masked]] on behalf of Linda
> Dunbar [[email-masked]]
> Subject: [armd] how does "draft-sridharan-virtualization-nvgre-00"
> advertise its external facing hosts' IP addresses to external world?****
>
>
> Hi Murari,
>
> 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
>
> > > >****
>  ****
>  ****
> ** **
> ** **

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 28 Feb 2012 21:16:32 +0000

Gary,

Can you elaborate why "vm migration may not be planned"?

I thought that VM migration is orchestrated by some entity, like vMotion or VM managers.

Linda

From: Vishwas Manral [mailto:[email-masked]]
Sent: Monday, February 27, 2012 6:49 PM
To: Gary Berger
Cc: Linda Dunbar; Murari Sridharan; [email-masked]
Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00"advertise its external facing hosts' IP addresses to external world?

Hi Gary,

I guess what Linda was trying to say is that the station moves autonomously, however there is some entity moving the VM (which can in turn could move the state on the switch).

Thanks,
Vishwas
On Fri, Feb 24, 2012 at 2:22 PM, Gary Berger <[email-masked]<mailto:[email-masked]>> wrote:

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.

I wouldn't put such a restriction, vm migration may not be planned.. They both degenerate into a multi-homing problem.

Linda

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Vishwas Manral
Sent: Thursday, September 22, 2011 9:38 PM
To: Murari Sridharan
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" advertise its external facing hosts' IP addresses to external world?

On Thu, Sep 22, 2011 at 5:00 PM, Murari Sridharan <[email-masked]<mailto:[email-masked]>> 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; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
You mean not an Ethernet frame but some IP payload?

From: Vishwas Manral [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, September 22, 2011 4:49 PM
To: Murari Sridharan
Cc: Narasimhan Venkataramaiah; Linda Dunbar; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" advertise its external facing hosts' IP addresses to external world?

Murari,

>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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, September 22, 2011 4:19 PM

To: Narasimhan Venkataramaiah
Cc: Linda Dunbar; Murari Sridharan; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, September 22, 2011 4:04 PM
To: Narasimhan Venkataramaiah
Cc: Linda Dunbar; Murari Sridharan; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" advertise its external facing hosts' IP addresses to external world?

Hi Simha,

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 <[email-masked]<mailto:[email-masked]>> 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: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Linda Dunbar [[email-masked]<mailto:[email-masked]>]
Sent: Sunday, September 18, 2011 7:06 AM
To: Murari Sridharan; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [armd] how does "draft-sridharan-virtualization-nvgre-00" advertise its external facing hosts' IP addresses to external world?

Hi Murari,

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

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> Murari Sridharan
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> > Of Warren Kumari
> > Cc: [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>> wrote:
> > >
> > > >>>>
> <[email-masked]<mailto:[email-masked]>> wrote:
> > > Hi Anoop,
> > >
> <[email-masked]<mailto:[email-masked]>> wrote:
> > > Hi Vishwas,
> > >
> <[email-masked]<mailto:[email-masked]>> wrote:
> > > Hi Linda,
> > >
> > > On Tue, Aug 9, 2011 at 11:51 AM, Linda Dunbar <[email-masked]<mailto:[email-masked]>>
> wrote:
> > > Vishwas,
> > >
> <[email-masked]<mailto:[email-masked]>> wrote:
> > > Hi Linda,
> > > On Tue, Aug 9, 2011 at 10:22 AM, Linda Dunbar <[email-masked]<mailto:[email-masked]>>
> wrote:

_______________________________________________ armd mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/armd

---

From: Michael Smith <[email-masked]>
Date: Tue, 28 Feb 2012 13:31:22 -0800

VM migration can be planned or unplanned, either manually or automatically.
In the event of a host failing that is configured for automatic migration,
the VM's on the host will migrate to another host as configured.  There is
some internal intelligence that will allow for best placement of VM's, so
they can move to any one of a number of available hosts.

Mike
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Linda Dunbar
Sent: Tuesday, February 28, 2012 1:17 PM
To: Vishwas Manral; Gary Berger
Cc: [email-masked]
Subject: Re: [armd] how does
"draft-sridharan-virtualization-nvgre-00"advertise its external facing
hosts' IP addresses to external world?
 
Gary, 

I thought that VM migration is orchestrated by some entity, like vMotion or
VM managers. 
 
Linda 
 
From: Vishwas Manral [mailto:[email-masked]] 
Sent: Monday, February 27, 2012 6:49 PM
To: Gary Berger
Cc: Linda Dunbar; Murari Sridharan; [email-masked]
Subject: Re: [armd] how does
"draft-sridharan-virtualization-nvgre-00"advertise its external facing
hosts' IP addresses to external world?
 
Hi Gary,

I guess what Linda was trying to say is that the station moves autonomously,
however there is some entity moving the VM (which can in turn could move the
state on the switch). 

Thanks,
Vishwas

 
Linda

 

  _____  

From: Vishwas Manral
Sent: 9/22/2011 4:55 PM

To: Murari Sridharan
 
Yes that is what I mean.
 
Thanks,
Vishwas

 
Murari,

totally?
 
Thanks,
Vishwas
On Thu, Sep 22, 2011 at 4:43 PM, Murari Sridharan <[email-masked]>
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

 
Hi Simha,

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
<[email-masked]> 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
entropy label.
 
Simha

Hi Simha,

 
 
Thanks,
Vishwas

Simha

Hi Murari,

One question:

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

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 29 Feb 2012 15:31:48 -0800

Hi Michael,

Please forgive my ignorance here. I guess what you are saying is that the
trigger could be some asynchronous event not initiated by the operator.

However isn't the management entity (not manual intervention) involved in
actually moving the VM and any storage/ state associated with it? If it is
the management entity knows of the movement.

Thanks,
Vishwas

On Tue, Feb 28, 2012 at 1:31 PM, Michael Smith <[email-masked]> wrote:

> VM migration can be planned or unplanned, either manually or
> automatically.   In the event of a host failing that is configured for
> automatic migration, the VM’s on the host will migrate to another host as
> configured.  There is some internal intelligence that will allow for best
> placement of VM’s, so they can move to any one of a number of available
> hosts.****
>
>
> Mike****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Linda Dunbar
>
> *Sent:* Tuesday, February 28, 2012 1:17 PM
> *To:* Vishwas Manral; Gary Berger
> *Cc:* [email-masked]
> *Subject:* Re: [armd] how does
> hosts' IP addresses to external world?****
>
> ** **
>
> Gary, ****
>
> ** **
>
> Can you elaborate why “vm migration may not be planned”?****
>
> ** **
>
> I thought that VM migration is orchestrated by some entity, like vMotion
> or VM managers. ****
>
> ** **
>
> Linda ****
>
> ** **
>
> *Sent:* Monday, February 27, 2012 6:49 PM
> *To:* Gary Berger
> *Cc:* Linda Dunbar; Murari Sridharan; [email-masked]
> *Subject:* Re: [armd] how does
> hosts' IP addresses to external world?****
>
> ** **
>
> Hi Gary,
>
> On Fri, Feb 24, 2012 at 2:22 PM, Gary Berger <[email-masked]> wrote:**
> **
>
> ** **
>
> ** **
>
> both degenerate into a multi-homing problem.****
>
>  ****
>
> Linda****
>
>  ****
>
> [email-masked] https://www.ietf.org/mailman/listinfo/armd ****
>
> ** **
>

---

From: "Gary Berger (gaberger)" <[email-masked]>
Date: Wed, 29 Feb 2012 19:24:00 -0500

The keyword here was "planned". If there is a catastrophic failure such as power loss it may be another entity responsible for recovering services i.e heartbeat

You can assume under certain situations your in a critical failure and are willing to lose application state. Of course as pointed out you would need your application data replicated as well. 

The requirements here would be based on a rigid set of constraints such as hardcoded addresses or specific bindings that need to be maintained which is not ideal, but there is a long-tail of poorly designed apps out there. 

I think we are just simply saying that multi-homing should be a native architectural element regardless to which network you attach to. 

G

Sent from my iPhone

On Feb 29, 2012, at 6:31 PM, "Vishwas Manral" <[email-masked]> wrote:

> Hi Michael,
> 
> Please forgive my ignorance here. I guess what you are saying is that the trigger could be some asynchronous event not initiated by the operator.
> 
> However isn't the management entity (not manual intervention) involved in actually moving the VM and any storage/ state associated with it? If it is the management entity knows of the movement.
> 
> Thanks,
> Vishwas
> 
> VM migration can be planned or unplanned, either manually or automatically.   In the event of a host failing that is configured for automatic migration, the VM’s on the host will migrate to another host as configured.  There is some internal intelligence that will allow for best placement of VM’s, so they can move to any one of a number of available hosts.
> 
> 
> Mike
> 
>  
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
> 
> 
> Can you elaborate why “vm migration may not be planned”?
> 
>  
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Vishwas Manral
> On Thu, Sep 22, 2011 at 5:00 PM, Murari Sridharan <[email-masked]> wrote:
> 
> Cc: Narasimhan Venkataramaiah; Linda Dunbar; [email-masked]; [email-masked]
> On Thu, Sep 22, 2011 at 4:50 PM, Murari Sridharan <[email-masked]> wrote:
> 
> Cc: Narasimhan Venkataramaiah; Linda Dunbar; [email-masked]; [email-masked]
> 
> 
> On Thu, Sep 22, 2011 at 4:43 PM, Murari Sridharan <[email-masked]> wrote:
> 
> On Thu, Sep 22, 2011 at 4:11 PM, Narasimhan Venkataramaiah <[email-masked]> wrote:
> 
> On Sun, Sep 18, 2011 at 11:01 AM, Narasimhan Venkataramaiah <[email-masked]> wrote:
> 
> From: [email-masked] [[email-masked]] on behalf of Linda Dunbar [[email-masked]]
> _______________________________________________ armd mailing list [email-masked] https://www.ietf.org/mailman/listinfo/armd
> 
>  
> 
>