{fat fingers let previous email got away too soon, ignore}
>>>>> "Stephen" == Stephen Hanna <sha...@juniper.net> 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. Oh, I'll paste it into the ticket too)
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
open question whether when H1 told A about H2, whether it in fact told
A about *all* of the topology that H1 knew about H2, or just about A.
Would traffic from A to D go via H2 after step1, or would traffic to D
continue to go via H1/H2?
This speaks to requirements, because if H1 needs to know where B is,
then we need to have a protocol along trunk1 and trunk2 that permits the
information about where B is to be communicated.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
then sign the petition.
pgp001BO8okTD.pgp
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
