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 protected]; Keshava A K > Cc: [email protected]; [email protected]; [email protected] > 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 protected] [mailto:[email protected]] On Behalf Of > Murari Sridharan > Sent: Tuesday, May 15, 2012 4:29 PM > To: Murari Sridharan; Linda Dunbar; [email protected]; Keshava A K > Cc: [email protected]; [email protected]; [email protected] > 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 protected] [mailto:[email protected]] On Behalf Of > Murari Sridharan > Sent: Tuesday, May 15, 2012 1:12 PM > To: Linda Dunbar; [email protected]; Keshava A K > Cc: [email protected]; [email protected]; [email protected] > 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 protected] [mailto:[email protected]] On Behalf > Of Linda Dunbar > Sent: Tuesday, May 15, 2012 12:41 PM > To: [email protected]; Keshava A K > Cc: [email protected]; [email protected]; [email protected] > 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 protected] [mailto:[email protected]] On Behalf > > Of Robert Raszuk > > Sent: Wednesday, May 09, 2012 2:27 AM > > To: Keshava A K > > Cc: [email protected]; Xuxiaohu; [email protected]; [email protected] > > 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 protected] > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3
