Hi Fred, I see draft-detienne¹s view of discovery of tunnel-peer is a routing issue. So DMVPN solution predominantly a routing solution. So, draft-detienne may work good for routing vendors.
But it is not a solution for non-routing vendors. As an example, mobile devices increasingly can do more features like FaceTime/Skype/Hangout, Airdrop. To do these, expecting mobile devices to run BGP protocol, to discover a direct tunnel is not a reasonable expectation. Or for that matter expecting a firewall device to run routing protocol, is not a reasonable expectation either. More comments inline. Thanks, Praveen On 2/5/14, 5:45 AM, "Frederic Detienne (fdetienn)" <fdeti...@cisco.com> wrote: > We can no longer call that a simple solution. There are pieces that meet >some of the requirements but are in contradiction with others. > Similarly, draft-sathyanarayan offers multiple implementation or >deployment systems (policy based or tunnel based) which are not >compatible at protocol level. It means implementations have to cover BOTH >methods to guarantee interoperability. [PRAVEEN] I disagree. How will a spoke running OSPF and other spoke running BGP interop in draft-detienne? Your answer was, (previously in virtual conference) was that it does not matter. Because, as long as Hub supports both routing protocols, there is no issue. The same thing applies here. If you have route based implementation on a SpokeA and Policy based implementation SpokeB, it can still open a direct IPSec tunnel without causing any interoperability. And of course, there is no need of running routing protocol between the spokes, even in our solution. To take a practical example: one domain may initially be rule based, the other tunnel based. What happens when those domains must now cooperate ? Both issues above will prevent proper cross-domain interoperability. In particular, a "policy-based" spoke will not be able to talk to a "tunnel based" hub as per this draftŠ it would take a decision as to which is the fallback mode and a dual implementation on at least one of the devices. [PRAVEEN] No issues here. As long as you support rfc5996, and you exchange TSi and Tsr payloads, you are ready to setup a tunnel and forward the traffic. On route based VPN side, you get TSi and TSr payload that defines the SPD entries. These SPD entries are bound to your tunnel interface. Route that exist before the shortcut tunnel, still points to tunnel interface. As this tunnel-interface is now has dynamic SPD entries, it now knows how to forward all/selective traffic to the shortcut tunnel. And of course the Policy based domain side it is straight forward. Where do you see the issue? Thanks, Praveen _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
