Re: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03

[Praveen Sathyanarayan <[e-mail]>]

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)" <[e-mail]>
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