Simon, On 16 August 2012 15:19, Simon Perreault <[email protected]>wrote:
> Le 2012-08-16 00:58, Maoke a écrit : > > same view. some operator would like to deploy things only with >> hub&spokes mode, it is fine. but for those who want to have mesh and >> hub&spokes simultaneously, there is no reason that we need two solutions >> especially when MAP has supported both. there is no need to limit MAP's >> scope with "focusing on mesh". >> > > The elephant in the room is that a provider that only needs hub-and-spoke > doesn't want to pay for the needless (subjectively) complexity of MAP. > > Here's an idea: a restricted "profile" of MAP-E that would only allow > hub-and-spoke, described in a separate RFC, would look exactly like LW4o6, > right? And it could be implemented stand-alone, without all the mesh code. > And it could be listed on an RFP. > MAP already supports hub& spoke, as documented, and no it doesn't look like LW4o6, since MAP allows the: 1. Ability to optimize the amount of configuration/rules required. Eg 1 rule can cover millions of end points. 2. Ability to optimize traffic forwarding (which gets referred to as mesh mode). -Woj. > Simon > -- > DTN made easy, lean, and smart --> > http://postellation.viagenie.**ca<http://postellation.viagenie.ca> > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > ______________________________**_________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/**listinfo/softwires<https://www.ietf.org/mailman/listinfo/softwires> >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
