Simon - 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?
I believe the 'F-flag' defined in section 4.2 of draft-ietf (MAP_DHCP, ver.-00 or -01, https://datatracker.ietf.org/doc/draft-ietf-softwire-map-dhcp/?include_text=1 ) already make MAP to support H&S mode. If the BMR is set with F-flag=0, that does mean H&S for MAP, because BMR will not be used for the packet forwarding... Best Regards, Leaf -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Simon Perreault Sent: Thursday, August 16, 2012 9:19 PM To: [email protected] Subject: Re: [Softwires] Hub&Spoke of MAP-E 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. 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
