>>>>> "Stephen" == Stephen Hanna <[email protected]> writes:
Stephen> I think that Michael is asking an important question. There
Stephen> are many ways to solve the P2P VPN problem. One way is to
Stephen> have satellites with little configuration that connect to
Stephen> core gateways with lots of dynamic information. A core
Stephen> gateway (a "hub" in Michael's parlance) can download things
Stephen> to a satellite (maybe a new SPD and PAD, credentials,
Stephen> etc.), thus causing some traffic from the satellite to be
Stephen> sent to a different core gateway or satellite. In that
Stephen> circumstance, I think Michael's question is about whether
Stephen> the core gateway that a satellite initially connects (which
Stephen> I'll call the "initial core gateway") to should be expected
Stephen> to have or obtain all the information needed to configure
Stephen> the satellite or whether the initial core gateway can send
Stephen> the satellite to another core gateway where it can get more
Stephen> information. At least, that's how I understand Michael's
Stephen> question. Perhaps he can affirm or deny this
Stephen> interpretation.
You got my question correctly.
I'm gonna add a diagram so that everyone can agree. (Those of you with
mailers that ignore text/plain; format=fixed, you need to copy this
email to Wordpad/vi, or it will be munged by your RFC-ignorant vendor)
In the requirements document, I think that we need establish some
nomenclature, such as "hub". and "initial hub", or "core", as you wish.
Given that goal of this is to go from hub+spoke (generalized to
trunk+feeder.. In my spare time I'm actually a transit expert. True story)
A B
\ /
\ /
\ /
+----+ trunk1 +------+ trunk2 +-----+
| H1 |==============| H2 |===============| H3 |
+----+ +------+ +-----+
/ \
/ \
C D
Leaf A has traffic of leaf B. It would otherwise go via Hub1(H1), Hub2,
and Hub3.
Thanks to our new Private Elastic Cloud On-Demand (PECOD) protocol,
magic will happen. The question, *AT THE REQUIREMENTS* phase, is
whether a solution such as:
step1, H1 tells A that H2 is closer:
A B
\..................... /
\ \ /
\ \ /
+----+ trunk1 +------+ trunk2 +-----+
| H1 |==============| H2 |===============| H3 |
+----+ +------+ +-----+
/ \
/ \
C D
step2, H2 tells A where B is:
A........................................................B
\..................... /
\ \ /
\ \ /
+----+ trunk1 +------+ trunk2 +-----+
| H1 |==============| H2 |===============| H3 |
+----+ +------+ +-----+
/ \
/ \
C D
pti
Stephen> Personally, I think that this question is premature. It
Stephen> presupposes too much about the eventual solution. That's
Stephen> why I think it should be answered in the solution not
Stephen> included in the problem statement. Apparently, Yaron
Stephen> doesn't agree with me. I'd like to hear more from him on
Stephen> this matter. Does he believe that all solutions to this
Stephen> problem (or at least all the good ones) must necessarily
Stephen> employ the model that I described above? What about a
Stephen> solution that doesn't rely on core gateways to refer
Stephen> satellites but instead has satellites querying for the
Stephen> information that they need? Or one that has some external
Stephen> entity (not the core gateway) configuring the satellites?
Stephen> In my view, there may be many possible P2P VPN
Stephen> solutions. However, I'm not an IPsec expert. Maybe this is
Stephen> the only practical approach. I'd like to hear views from
Stephen> Yaron and from others on this topic.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
