Hi. I think it should be more complicated than this. The suggested solution has a dichotomy of either a full mesh or a start topology. The requirements should cover scenarios such as a mesh within an organization connecting to a hub to gateways outside the organization, or multiple hubs connected among themselves in either a star or a mesh, or even certain "routes" that are manually configured along with all the auto-discovery stuff.
Perhaps we can capture the needed complexity by talking about groups of nodes, where nodes that belong to a single group attempt to create a mesh among them, and packets can travel between nodes that do not belong to the same group through group intersection. I'm not sure if this level of detail is part of the problem statement, but it's more high level than a solution. On May 12, 2012, at 1:11 AM, Vishwas Manral wrote: > Hi, > > I would like to start off by trying to resolve the issue. The notes from the > IETF are attached below. > > Description:Some admins prefer a star topology so they can inspect traffic. > They may not want to use this technology. > > Detail arguments: My take is similar to what Yaron and Yaov seem to state. > There is no reason to exclude star topology at all from the Problem > statement/ requirements document. In fact both the proprietary solutions I > know of allow for such a topology. I however understand that some of the > functionality on the Hub (of the star) could be achieved by using PFP flags > in the SPD entry. > > Suggested Resolution: State in the document that Star topology is not > excluded from the solution. The problem of configuration is however mainly > limited to the Hub. For every spoke added/ deleted/ modified the > configuration on the Hub needs to be changed, which is not desirable. May be > update Section 3.2 with the same too. > > Thanks, > Vishwas > =========================================================== > Notes from meeting minutes: > > # 219 Star topology as an admin choice > People don't need to use this if they don't want to > Say this in the security considerations > Yoav Nir: > Has to be a requirement that any solution > can > implement different policies > Yaron Sheffer: > Agrees with Yoav, maybe becomes a use case > Take this to the list > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
