Hi Michael,
I am working on updating the text of the draft. I had a few doubts.
> I think the focus on "movement" and "mobility" is wrong.
> Instead, focus on connectivity.
>
> Tero (and I) asked the question about a device which was, from a
> topological point of view, originally connected to "outside" (on the
> public Internet, effectively), and had built up a mesh.
>
> Are you talking of a case where the device had Public internet
connectivity and has now roamed to a place where it is inside the network,
so the IPsec tunnel is not required. You are probably looking at a way to
gracefully tear down the IPsec tunnel and use the native connectivity. Is
the understanding of the usecase you had in mind correct?
> There is a connectivity change (let's not worry about how, why, but I
> can describe a dozen ways if you like, and not all of them involve 3G or
> 802.11), and the device is now connected behind a gateway which is also
> part of the mesh.
>
> Let's assume a multiple star topology situation. (We draw these on
> napkins in Paris. I promise to re-read the problem statment to learn if
> this scenario has been named)
>
> Let's say that said device ("A") previously was part of VPN-Concentrator X.
> (It was perhaps part of that star via NAT-T transport). Packets flowed
> from A to device B. Device B is located on network B-location, and is
> served by B-gateway, and these packets flowed via VPN-Concentrator X.
>
> X attempts to ask A to connect directly to B-gateway so that packets
> from A<->B take the shortcut. A presently has connectivity *on*
> "network B-location". That is, A and B are in fact, co-located (but
> might not be on the same link).
>
> 1) Is there a requirement that B-gateway must be able to make a bypass
> connection to another spoke, from *behind* B?
>
> Let me see if I understood the question. We are talking of a gateway-B
which is on the path between 2 spokes (A and B) which are talking via a VPN
concentrator (X). You are asking if we allow the Gateway-B to allow for a
bypass and if so can we allow for a "clear" bypass connectivity. Is my
understanding correct?
I agree there is a use case for this optimization, but do we want to tackle
the use case as part of the base solution or as an extension once the base
solution is created (so a future use case).
Thanks,
Vishwas
2) Many would feel that actually there should be *no* IPsec tunnel
> between A and B, as they are presently co-located.
> Do we have a requirement that the policy between two spokes
> (a "bypass") could in fact be "clear"?
>
>
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/
>
>
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
