Hi, On Wed, 19 Feb 2014 21:57:26 +0100 Daniel Migault <[email protected]> wrote:
> On Thu, Feb 6, 2014 at 11:07 AM, Timo Teras <[email protected]> wrote: > > On Thu, 6 Feb 2014 09:20:08 +0100 > > Daniel Migault <[email protected]> wrote: > > > >> RFC5685 is not limited to client-gateway, the second line of the > >> section 10 you pointed out says: [...] the mechanism can also be > >> used between any two IKEv2 peers. " So no additional specification > >> are required. > > > > You missed the next sentance: > > "However, the mechanism can also be used between any two IKEv2 > > peers. But this protocol is asymmetric, meaning that only the > > original responder can redirect the original initiator to another > > server." > > > > Suppose A establish an IPsec session with node B. B can use a Redirect > not A. If A has not the capacity to handle the communication it should > not initiate it, and let C initiate the communication. This may be a > disadvantage is A and B are "equal", but in that case A and B should > be organized as clusters and redirect may not be the best way. But if A original had the capacity and was intended to establish it, but then later on routing protocol or administrative action made the prefix to be removed from A. A would then need to inform of this somehow. > >> You mention load balancing may be an issue. Can you please specify > >> the issue you see? > > > > Could you specify how in practice I could implement one subnet to be > > load-balanced to spoke nodes? > > > If I correctly understand your scenario, you are looking at load > balancing the traffic of your private network between two spokes. Any > IP-load balancer could split and load balance the traffic between the > two spokes. > On the other hand you might also want to have multiple spokes under a > given IP address. In that case, load balancing is performed according > to the hash of the IP addresses or according to values of the SPI. > Solution like cluster IP load balance the traffic between the two > spokes [1]. > > [1] > http://wiki.strongswan.org/projects/strongswan/wiki/HighAvailability This generally works by requiring single virtual IP that is then later on load-blanced. How about I have two ISP connection with separate public IPs. Haw can I loadbalance over them? This is relatively simple to achieve in DMVPN. > >> One last point to clarify. it seems that you are trying to say > >> ADVPN misses some features provided by routing protocols. In fact > >> ADVPN can take advanatge of ALL of these features as ANY routing > >> protocol can run on the top of ADVPN. This was a MUST requirement > >> of RFC5685. If you see a scenrio that you think does not fit > >> ADVPN, please document it so we can address your specific issue. > > > > I thought the advantage was to _not_ run routing protocol. > > You are right ADVPN does not necessarily need routing protocol. It can > have one or not, it is up to the scenarios you want to address. > > > If running routing protocol is supported, can you please specify > > how a routing protocol is to be integrated with the IKE traffic > > exchange? Yes, it is possible, but non-trivial, thus I would like > > to see some specification mapping how to do that mapping. > > I do not see the issue. Can you point out the issue more specifically. There is a lot of things involved. First question is already explained in this (see above) and the previous mails. What happens when routing protocol withdraws a subnet from one gateway, and it needs to tell everyone that it's no longer available from it, but may be available through other nodes. > > And like someone else asked, how is MPLS routed? > > Maybe you could encapsulates MPLS traffic in GRE/IP. Everything > possible with DMVPN is possible with ADVPN. This is one step closer to dmvpn. But how would the SHORTCUT mechanism work then? 4.1. says protected domain can contain only INTERNAL_IP4_SUBNET (13) and INTERNAL_IP6_SUBNET (15). You'd need to specify additional record types to all possible protocols ever needed to run over GRE. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
