Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt

From: Linda Dunbar <[email-masked]>
Date: Wed, 16 May 2012 22:26:36 +0000

Peter, 

You are absolutely right. I am saying the same thing, i.e. the OverlayBounaryPoint has multiple addresses. So that some VMs can be encapsulated in one SR/DST address and other VMs can be encapsulated with other addresses. 

I agree with Murari that focusing on entropy values is too narrow. You can have all the entropy values, but you still will run into in-balanced distribution because flow of each VM is different. 
 
I have noticed that VMware (in their document) and Microsoft tend to use "host" to indicate "Server" which can support multiple VMs. V.s. in other environment "Host" is referring to "End-Station". 

Linda

> -----Original Message-----
> From: AshwoodsmithPeter
> Sent: Tuesday, May 15, 2012 4:00 PM
> To: Murari Sridharan; Linda Dunbar; [email-masked]; Keshava A K
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN
> traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version
> Notification for draft-xu-mpls-in-udp-00.txt
> 
> 
> Linda, just to clarify, its not the ultimate host addresses (VM) that
> need to be multiple, it's the Hyperisor/Vswitch that needs multiple IP
> addresses. The hash is on this *outer* IP address and is of course
> limited because there are insufficient outer addresses for good entropy.
> 
> You'd use a single IP address for the VM/host but then when
> encapsulating you'd pick one of say 32 or more Vswitch addresses for
> your SA based on your VM IPs and the UDP/TCP ports. Everywhere there
> was a dependency on /32 would have to be made flexible. Not sure if
> that's an issue but its possibly hard coded in some places. Routers ARP
> table for example?
> 
> The number of outer addresses you use dictates how much entropy you get
> when you traverse a LAG which can have quite a few members, but 16 or
> 32 is likely not unreasonable. Also if you go through several hops, the
> number of bits of entropy puts a strict upper bound on the total number
> of different paths you can exercise. So if you have 4 bits you can only
> exercise 16 unique paths *end to end*. Since the number of paths grows
> exponentially in the path length a small number of bits does limit
> spead exponentially quickly.
> 
> This 'trick' is only needed of course if the LAG or ECMP hardware does
> not know to look at an NVGRE header or is not capable of generic hash
> extensions which some ASICs now can do... (even if they don't support
> NVGRE termination/encapsulation) so its likely more a concern between
> DC's than inside the DC.
> 
> Peter
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Murari Sridharan
> Sent: Tuesday, May 15, 2012 4:29 PM
> To: Murari Sridharan; Linda Dunbar; [email-masked]; Keshava A K
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN
> traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version
> Notification for draft-xu-mpls-in-udp-00.txt
> 
> Linda, to clarify the address "assignment" could be setup as a SLAAC
> and hosts can generate address from a given prefix etc.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Murari Sridharan
> Sent: Tuesday, May 15, 2012 1:12 PM
> To: Linda Dunbar; [email-masked]; Keshava A K
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN
> traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version
> Notification for draft-xu-mpls-in-udp-00.txt
> 
> Whichever entity assigns IP addresses to the host can assign one or
> many including 1:1 for every VM in that host. This isn't specific to
> IPv6 or IPv4.
> 
> On a general note, devices/appliances etc that want to participate in
> NV03 will likely want to understand specific tenant information to
> provide richer services. No matter what the encapsulation format is
> devices/appliances will need to update if they want to do something
> interesting with the flow. I have seen several threads where folks seem
> to have a "let's keep switch-ECMP" view of the DC which I think is
> narrow.
> 
> Thanks
> Murari
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Linda Dunbar
> Sent: Tuesday, May 15, 2012 12:41 PM
> To: [email-masked]; Keshava A K
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN
> traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version
> Notification for draft-xu-mpls-in-udp-00.txt
> 
> Robert,
> 
> When GRE encapsulation uses different SRC/DST addresses for different
> flows, it means that same OverlayBoundaryPoint needs multiple addresses.
> Does it also mean an IP prefix can be given to a OverlayBoundaryPoint?
> I guess for IPv6, there shouldn't be any issues, should it? (well I am
> not an IPv6 expert).
> 
> Linda
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Robert Raszuk
> > Sent: Wednesday, May 09, 2012 2:27 AM
> > To: Keshava A K
> > Cc: [email-masked]; Xuxiaohu; [email-masked]; [email-masked]
> > Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN
> > traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New
> Version
> > Notification for draft-xu-mpls-in-udp-00.txt
> >
> >
> > > If switches were to try to distribute GRE flows between two VTEPs
> > > that used a GRE encapsulation, all the traffic would be directed to
> > > use only one link within these Port Channels.
> >
> > Not true. GRE encapsulation is not mandated to use the same src/dst
> > addresses for all flows between given two end points.
> >
> > You do not need to parse deep into packet to enable good load
> > balancing hash across parallel links when you use GRE as an
> > encapsulation technology.
> >
> > And what is nice about IP encapsulation all GRE src/dst addresses can
> > be naturally aggregated so from IGP point of view they still look
> like
> > a single prefix.
> >
> > Regards,
> > R.
> > _______________________________________________
> > nvo3 mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/nvo3
> 
> 
> 
> 
> 
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
> 
> 
> 
> 
> 
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3