On Aug 24, 2012, at 5:50 PM, Simon Perreault wrote: > 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. We cannot have a standards track protocol RFC coming out of softwires for every manner in which a technology might show up in an RFP. This simply does not scale. What we can have is as many informational use-case documents as v6ops is willing to shepherd. So, I suggest we let softwires produce as few standards-track alternatives as possible for base technology that can be used to meet the needs of as many operators as possible. If an operator wants to share how that technology is used in a specific manner, tradeoffs made, specific topologies and configuration, etc. via a BCP, Informational or Experimental document in the operations area, fantastic! We need real world feedback on how the technology is and is not being used. If an ISP wants to reference said operations document as advice for how they intend to use the softwires protocol in an RFP, that's fine too, but let's try and keep *this* group focused on as few base technologies (read: fewer standards track RFCs) as possible. - Mark > > 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
