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
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to