Please let me repeat myself, by asking the DT that WiFi clients with IEEE802.11r (fast BSS transition) are supported in the homenet. The requirement is in RFC 7368.
The DT could say: we have RFC 5415/5416 and someone shall bring in a WLC, or, add an SDN layer in the homenet. This might not happen. The alternative would be MAC layer routing (a.k. bridging). This is brought up several times, by several people. People which IMO understand home WiFi problems and know how to fix them. I do not say I prefer ISIS/TRILL or ISIS/RFC6329/IEEE802.1aq over Babel. What I say is that selection based on number of pages of an RFC, number of lines of code will result in nothing. It is about problems to fix with a good engineering effort. I know this SPB technology seems to be overkill and is less an IP layer routing beast. But a well performing homenet with multiple WiFi APs cannot without. BTW: 802.11r without central controller needs a config distribution protocol. We could provide that. May I ask for having 802.11 experts in the DT? Teco > Op 31 mrt. 2015, om 17:12 heeft Terry Manderson <[email protected]> > het volgende geschreven: > > WG, > > I have reviewed all of the emails on this topic. > > My assessment is that no-one spoke specifically against (nor for!) the > design team to select the mandatory to implement routing protocol for > homenet. There was, however, some constructive discussion about the design > team charter, along with some advice for the design team to consider. > > I have the sense that folks were waiting for charter word-smithing to be > completed prior to accepting/supporting the design team and ultimately its > determination. There simply wasn't enough positive nor negative responses > to gauge consensus. > > > I have updated the charter as follows which folds in the substantive > comments from Lorenzo and Brian. > > =-=-=-=-=-=-=-=- > > Homenet's architecture (RFC 7368) articulates the general features > required. The working group has agreed that a single routing protocol > must be identified as mandatory to implement. The final purpose of > this design team is to select and present a single routing protocol > with a summary of the necessary extensions and work to be the one that > is mandatory to implement. Once the design team has made its > recommendation, the working group will consider any substantial > technical objections (see RFC 7282) as part of gaining consensus. > > For the design team to make this determination, it shall first > understand the use-cases for homenet and derive routing requirements > from those. Then it shall compare these routing requirements to > candidate routing protocols and examine the gaps in each. For each > highly plausible candidate routing protocol, the design team will > estimate the work and actions needed, the resources at hand > or reasonably available, and the associated timeline to get > an acceptable, full, standardized solution using each protocol. > Based upon this information and the perceived market timing > needs of the technology, the design team will make its selection. > The requirements, gaps, and reasoning will be documented. > > This document should be delivered by the July 2015 IETF. > > =-=-=-=-=-=-=-=- > > So with no more emails on the thread, I'm marking the above as the final > design team charter and I now ask the WG to comment by midnight Friday the > 3rd April (UTC) of either accepting the design team, or not. I will judge > consensus at that point, remembering that silence doesn't help. > > > Pending consensus, and at the appropriate time I will direct the design > team to read the advice from Steven, Alexandru, and James posted here for > their consideration. > > > Cheers > Terry > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
