Le 2012-08-24 11:39, Wojciech Dec a écrit :
    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).

Looks like my idea wasn't well understood. Let me try again...

RFC A: defines MAP as we know it.
RFC B: defines a hub-and-spoke only subset of MAP. refers to A.

My assumption is that RFC B would look very much like LW4o6.

An ISP needing only hub-and-spoke would cite RFC B in an RFP. The vendor would be free to implement RFC B without full support for A. A full implementation of RFC A would also implicitly be an implementation of B.

Just an idea, trying to find a way forward...

Simon
--
DTN made easy, lean, and smart --> 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

Reply via email to