<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">KY9K de AE7SJ<br>
      <br>
      Awaiting your response, but I'll address Gerard's comments here
      since he's waited quite a while.<br>
      <br>
      <br>
      On 3/14/2013 12:01 AM, Gerard Hickey wrote:<br>
    </div>
    <blockquote
      cite="mid:D0BE1DDC-5B7D-4BCA-9C85-E210B9195F8D@kinetic-compute.com"
      type="cite"><br>
      <div>First of all, (Bart I am not trying to start a fight, just
        making an observation)</div>
    </blockquote>
    <br>
    No one is trying to start a fight, but we do have inherently
    contentious issues to discuss.  So let's keep a cool head and keep
    the communication going for the good of the community.<br>
    <br>
    <blockquote
      cite="mid:D0BE1DDC-5B7D-4BCA-9C85-E210B9195F8D@kinetic-compute.com"
      type="cite">
      <div>HamWAN is not a mesh network. It is an architected network
        with links (both real and planned) spread out throughout the
        region.</div>
    </blockquote>
    <br>
    This is where we hit the inevitable confusion over the phrase "mesh
    network" which I addressed at the top of my first response so there
    wouldn't be any such confusion.  Let me find it ... <br>
    <br>
    <tt>-=[ QUOTE ]=-<br>
      First, let's speak the same language.</tt><tt><br>
    </tt><tt> </tt><tt><br>
    </tt><tt> There's a lot of confusion around the word "MESH".  I'm
      also not sure why it's always capitalized.  It's not an acronym as
      far as I know.  The term "mesh network" describes nothing more
      than the logical topology of a network.  There's a really good
      write-up on this at the </tt><tt><a
        href="http://en.wikipedia.org/wiki/Mesh_networking">wikipedia
        page</a></tt><tt>.  I'm pretty sure that when you (and others on
      this email) use the phrase "mesh network" it is not the wikipedia
      definition you're intending.  It means something different,
      including:</tt><tt><br>
    </tt><tt> </tt><tt><br>
    </tt><tt> 1) Using a common RF channel</tt><tt><br>
    </tt><tt> 2) Promiscuous neighbor discovery + association</tt><tt><br>
    </tt><tt> 3) Automatic IP configuration based on MAC</tt><tt><br>
    </tt><tt> 4) Nearly open node authentication</tt><tt><br>
    </tt><tt> 5) Omnidirectional operation</tt><tt><br>
    </tt><tt> 6) </tt><tt><a
        href="http://en.wikipedia.org/wiki/Wireless_distribution_system">WDS</a></tt><tt>-style

      operation</tt><tt><br>
    </tt><tt> </tt><tt><br>
    </tt><tt> These are the typical traits of a </tt><tt><a
        href="http://seattlewireless.net/">SeattleWireless</a></tt><tt>
      style mesh network (which, BTW, has been attempting to bootstrap
      itself for the last 13 years).  This type of definition of "mesh
      network" is quite a different animal from the canonical mesh
      network definition (wikipedia's, derived from network theory).</tt><tt><br>
    </tt><tt> </tt><tt><br>
    </tt><tt> The reason I want to make the distinction clear is that
      nearly all large networks in the world are indeed mesh networks,
      but nearly none of them possess the qualities of 1-6.  So when I
      say something like "</tt><tt><a
        href="https://www.hamwan.org/t/tiki-index.php">HamWAN</a></tt><tt>
      is a mesh network", I want it to be clear that I'm referring to
      the network topology only (the wikipedia definition).  I'm not
      sure what is the right word to describe the other type of network;
      perhaps capitalizing all the letters is a good differentiator
      after all.  :)</tt><tt><br>
      -=[ /QUOTE ]=-<br>
    </tt><br>
    <br>
    <blockquote
      cite="mid:D0BE1DDC-5B7D-4BCA-9C85-E210B9195F8D@kinetic-compute.com"
      type="cite">
      <div> Two of the qualities of a mesh network is self-healing and
        zero configuration.</div>
    </blockquote>
    <br>
    So, admittedly I did pull the list of the above 6 properties out of
    my butt.  It's my best guess.  Is there actually a formal list
    somewhere?  Please provide it.  I don't think there's actually any
    clear divide between MESH or not, it's more like a spectrum of
    features that are there or not.<br>
    <br>
    I would argue the "zero configuration" claim is not actually true. 
    There's configuration in MESH nodes, it's just stored in the node
    router, much as it will be in HamWAN client routers.  You set things
    like frequency, bandwidth, SSID.  In fact, as I understand it,
    there's usually a custom firmware that's uploaded which comes with I
    don't know how many settings that I'm guessing are set "just right"
    so that things work nicely.  So here, we're not so different, as
    both client router devices will have a config set.<br>
    <br>
    The other way I can interpret this is that once you get your fully
    configured client router device, you simply attach it to an antenna
    and it finds and connects to the wireless network.  This is exactly
    the scenario we're enabling for HamWAN as well, it's not unique to
    NW-MESH.  OK, maybe one slight difference: in the HamWAN case there
    will be user credentials you enter into the router for it to
    authenticate onto the network.  But isn't there some OLSR key in
    NW-MESH?  I'm really not up to speed on that as much as I should be.<br>
    <br>
    <blockquote
      cite="mid:D0BE1DDC-5B7D-4BCA-9C85-E210B9195F8D@kinetic-compute.com"
      type="cite">
      <div> Yes, HamWAN does have self-healing properties but it is an
        engineered healing mechanism rather than a intrinsic part of the
        technology.</div>
    </blockquote>
    <br>
    I'm failing to understand the difference between "engineered" and
    "intrinsic" here.  If we require that HamWAN run OSPF, this becomes
    an intrinsic property of HamWAN.  OLSR is REALLY close to OSPF.  I
    would say in the self-healing aspects, the networks are not very
    different at all.<br>
    <br>
    <blockquote
      cite="mid:D0BE1DDC-5B7D-4BCA-9C85-E210B9195F8D@kinetic-compute.com"
      type="cite">
      <div> I also can not just by the same hardware that HamWAN is
        using, turn it on and point it to a HamWAN point of presence and
        have it work. There are specific network and routing parameters
        that need to be set in order to come up on the network.</div>
    </blockquote>
    <br>
    I addressed this "zero config" claim above, but do correct me if I'm
    wrong.<br>
    <br>
    <blockquote
      cite="mid:D0BE1DDC-5B7D-4BCA-9C85-E210B9195F8D@kinetic-compute.com"
      type="cite">
      <div> Just the same as if I have a configured HamWAN installation,
        I could not move it to another part of the region, point it to
        another point of presence and be back on the network (actually
        there is one or two ways, but it makes the routing butt ugly). <br>
      </div>
    </blockquote>
    <br>
    This is actually one of the scenarios we're definitely enabling.  If
    you have a static IP or subnet, it will follow you around on the
    network no matter what sector you connect to.  In one of my previous
    replies I also described how that static (and publicly routable!)
    address(es) can follow you to partner networks as well through use
    of VPN peering.  Nice, ya? :)  This is why we're using beefy
    routers, cuz we expect the routing tables to be large.<br>
    <br>
    <blockquote
      cite="mid:D0BE1DDC-5B7D-4BCA-9C85-E210B9195F8D@kinetic-compute.com"
      type="cite">
      <div><br>
      </div>
      <div>With these statements, I am just trying to provide a clearer
        distinction that Bart started in the second or third email of
        this thread. By no means am I trying to elevate one technology
        or the other as a superior technology. I think that there is
        plenty of room for every one to experiment and play with the
        various technologies. <br>
      </div>
    </blockquote>
    <br>
    I whole-heartedly encourage any activity which gets hams playing
    with more modern digital stuff.  The whole concept of "superior" or
    "best" is relative to your goals.  That's why I'm trying to get some
    sense out of the NW-MESH crowd of what the goals really are.  A
    mission statement or something.  Like I've said, I think our goals
    are actually pretty close in most areas, and it's the differences
    I'd like to explore to see if we can minimize them or respect them
    and work on a peering model.  If we develop a clear understanding of
    each others' goals, only then we can begin the technical work
    necessary to align the networks together.<br>
    <br>
    <blockquote
      cite="mid:D0BE1DDC-5B7D-4BCA-9C85-E210B9195F8D@kinetic-compute.com"
      type="cite">
      <div><br>
      </div>
      <div>I have stated since I first heard Bart speak about the HamWAN
        project last year at Summer Gathering that it works very well as
        a backbone technology. I think it compliments the NW-MESH work
        very well in the sense that it can tie together various NW-MESH
        networks and provide the backbone between them. And NW-MESH
        provides an economical way for hams to participate in a
        community network. <br>
      </div>
    </blockquote>
    <br>
    The economics of onboarding to HamWAN (~$200) vs. NW-MESH (~$30) is
    a fair point.  I can envision a neighborhood cluster of $30 nodes
    sharing a $200 uplink.  But for this to become reality, we must
    agree on how to align.  I'm starting to sound like a broken record. 
    :)  The initial thinking of "just give us a tunnel" is a raw deal
    for HamWAN, so we must work harder to strike a better balance.  I'd
    like HamWAN clients and MESH clients to be mutually directly
    addressable, for one.  I have other concerns about route injection
    into HamWAN, client authentication on NW-MESH and potential
    collisions with people's RFC1918 space networks since HamWAN does
    intend to announce routes into people's home networks.  I'd also
    like to understand the QoS, default gateway, DNS, IPsec and IPv6
    stories.  There's a LOT of work to sort out.  Let's not waste time
    in jumping to it.<br>
    <br>
    <blockquote
      cite="mid:D0BE1DDC-5B7D-4BCA-9C85-E210B9195F8D@kinetic-compute.com"
      type="cite">
      <div><br>
      </div>
      <div>
        <blockquote type="cite"> Do you have a favorite low-noise public
          meeting location with power + wifi?  Starbucks is sounding
          likely.</blockquote>
      </div>
      <div><br>
      </div>
      <div>I have never seen a Starbucks be low-noise. Anyone of them I
        have ever been is has always been fairly loud with all the sound
        reverberating of every flat surface (I swear that every
        Starbucks employee is taught to bang pots on every surface
        behind the counter). I am sure that I can be proven wrong as I
        am not a coffee drinker and do not visit Starbucks that often. </div>
      <div><br>
      </div>
      <div>What I will offer is conference rooms at ebay in Redmond. We
        have plenty of white boards and projectors / 60 monitors for
        presenting so that everyone does not have to crowd around one
        laptop. We can meet pretty much most nights or weekends except
        for Tuesdays and the 2nd and 4th Monday of the month. This
        Friday and Saturday is also out since I will be at the Cascadia
        IT conference. I will also be in California the week of 3/25.
        Beyond that I think I can pretty much make anything else work. <br>
      </div>
    </blockquote>
    <br>
    I'm game.  Since I work in Redmond, I can be available there any
    weekday (after work), and am willing to make weekend trips whenever
    others can do likewise.  Let's get the ball rolling here.  During
    the first meeting(s) whoever is attending should be prepared to
    discuss their goals and philosophy about these networks.<br>
    <br>
    --Bart<br>
    <br>
    <br>
    <blockquote
      cite="mid:D0BE1DDC-5B7D-4BCA-9C85-E210B9195F8D@kinetic-compute.com"
      type="cite">
      <div><br>
      </div>
      <div>73.<br>
        <div>
          <span class="Apple-style-span" style="border-collapse:
            separate; color: rgb(0, 0, 0); font-family: Helvetica;
            font-style: normal; font-variant: normal; font-weight:
            normal; letter-spacing: normal; line-height: normal;
            orphans: 2; text-align: -webkit-auto; text-indent: 0px;
            text-transform: none; white-space: normal; widows: 2;
            word-spacing: 0px; -webkit-border-horizontal-spacing: 0px;
            -webkit-border-vertical-spacing: 0px;
            -webkit-text-decorations-in-effect: none;
            -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
            0px; font-size: medium; ">
            <div>--<br>
              Gerard Hickey / WTØF   IRLP:3067/Echolink:529661<br>
              <a moz-do-not-send="true"
                href="mailto:hickey@kinetic-compute.com">hickey@kinetic-compute.com</a><br>
              425-395-4554</div>
          </span>
        </div>
        <br>
        <div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>