Re: [manet-dlep-rg] London meet up?

Teco Boot <teco@inf-net.nl> Thu, 06 March 2014 10:24 UTC

Return-Path: <teco@inf-net.nl>
X-Original-To: manet-dlep-rg@ietfa.amsl.com
Delivered-To: manet-dlep-rg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E4F1A0239 for <manet-dlep-rg@ietfa.amsl.com>; Thu, 6 Mar 2014 02:24:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCCqeybJ36FF for <manet-dlep-rg@ietfa.amsl.com>; Thu, 6 Mar 2014 02:24:54 -0800 (PST)
Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) by ietfa.amsl.com (Postfix) with ESMTP id 549651A01FE for <manet-dlep-rg@ietf.org>; Thu, 6 Mar 2014 02:24:54 -0800 (PST)
Received: by mail-we0-f169.google.com with SMTP id w62so2842132wes.0 for <manet-dlep-rg@ietf.org>; Thu, 06 Mar 2014 02:24:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Ei2CcA6OciHjYoBV0adeAVlNk/bFi44Ap/w+KNgLnzE=; b=Mgw/eiL+JErCM+FvJoQwMnbwzZuwG6Ba0vTDmjnyhvQPPpsz2K5RyAU81rI3C0T+rz xJgjNrsfioXUlEXDGXzZ8VAHVa8x38erRvLPhNWODPMtPHz9k0+iF4GX7R31HJH6Qt6a PsAiP9L1fbkF8v03ivAftEjFJdCPGs3ii2VUjN4mLgujkUMocUMY60G3ooDGzErhX3UJ 8JwXOPtcgLU2ZrkNQGuYxtV/HTCNEc96bjTxEqlNYlhc9qwdHUwgwNXEbPyEqCm/s/tS nbe+exKjWKCo48qnJ7iCujHVtnPLva3Vcqgdej88VBLzL6AN9ij78tvZglTiioND4PBx e+FQ==
X-Gm-Message-State: ALoCoQliT8g1Ha9maWNjhJXA5sXYpj2do3y77wrejXtYqnfVIwE+xwe50INuCPESPcvtKE/Rz+Dg
X-Received: by 10.194.87.163 with SMTP id az3mr8607494wjb.63.1394101489995; Thu, 06 Mar 2014 02:24:49 -0800 (PST)
Received: from dhcp-a727.meeting.ietf.org (dhcp-a727.meeting.ietf.org. [31.133.167.39]) by mx.google.com with ESMTPSA id xt1sm14724100wjb.17.2014.03.06.02.24.47 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 02:24:48 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <CAGnRvupykvOGyYZ7ugaarA=J_qVfcyzU1rDD4NJ80WMce9tr+A@mail.gmail.com>
Date: Thu, 6 Mar 2014 11:24:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E64DFE28-CDF3-4907-A71C-777E40CA794B@inf-net.nl>
References: <38A5475DE83986499AEACD2CFAFC3F98FA6C34C0@tss-server1.home.tropicalstormsoftware.com> <480A632F-CB9E-4A62-ACDA-521C1A899049@inf-net.nl> <CAGnRvuqL8z+P5BJP-duyQo2BnTSpnkv7nDnOEdAQ1RfdXu7r+Q@mail.gmail.com> <38A5475DE83986499AEACD2CFAFC3F98FA6C4B60@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98FA6C56BA@tss-server1.home.tropicalstormsoftware.com> <CAGnRvuotok8UC-=i9RU8RvAv_wcv1DE3ubRLqibWeDLF6KRuDA@mail.gmail.com> <FB821471-E223-41BE-8D38-24C54B2B92C5@cisco.com> <CAGnRvupAoaLtvsHh6TLXvxsBnmrLMtPCZ-VKuxR=gVPxnchWDQ@mail.gmail.com> <67373A27-5AB2-47D3-B543-C0EB72D0AD7C@cisco.com> <CAGnRvuqHknFWoLyv5RjM3OcJ+g4WsRTphMH8d9wLQV+m+J+6uw@mail.gmail.com> <2D5195A7-2E4E-430C-9380-4D8926F13E86@inf-net.nl> <CAGnRvupykvOGyYZ7ugaarA=J_qVfcyzU1rDD4NJ80WMce9tr+A@mail.gmail.com>
To: Henning Rogge <hrogge@gmail.com>, Stan Ratliff <sratliff@cisco.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet-dlep-rg/lhtkK-bHdKZBWoP4dBvrRcD3l4c
Cc: "DLEP Research Group, \(manet-dlep-rg@ietf.org\)" <manet-dlep-rg@ietf.org>, Rick Taylor <rick@tropicalstormsoftware.com>
Subject: Re: [manet-dlep-rg] London meet up?
X-BeenThere: manet-dlep-rg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DLEP Radio Group <manet-dlep-rg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet-dlep-rg>, <mailto:manet-dlep-rg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet-dlep-rg/>
List-Post: <mailto:manet-dlep-rg@ietf.org>
List-Help: <mailto:manet-dlep-rg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet-dlep-rg>, <mailto:manet-dlep-rg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Mar 2014 10:24:57 -0000

Because there 802.11s, this provides enough space for addresses.

The tunnel approach has less impact on the driver, so would be more easy to implement.
For full 802.1D, there is a need for a bridge table, with DestAddr to RecvAddr mapping.

BTW, for Stan: The large organization I work for uses Cisco AP’s because they can mesh…. Not 11s, not IBSS, but functional equivalent. 

Teco
 
Op 6 mrt. 2014, om 10:23 heeft Henning Rogge <hrogge@gmail.com>; het volgende geschreven:

> I dont think there is a current wifi driver with 4 address adhoc mode.
> 
> Henning
> 
> On Mar 6, 2014 9:18 AM, "Teco Boot" <teco@inf-net.nl>; wrote:
> My opinion on MAC NAT hack or Dup MAC address: nice but ugly. Breaks 802.1D even more. Let’s not standardize it.
> Ronald fixed 802.11D for MadWiFi in Ad Hoc, 4-addr mode. Others use encap with another MAC header. Both are much cleaner.
> 
> Or I miss something.
> 
> Teco
> 
> Op 5 mrt. 2014, om 22:02 heeft Henning Rogge <hrogge@gmail.com>; het volgende geschreven:
> 
> > One option to allow DLEP with adhoc wifi might be to configure the
> > local MAC address of the routers interface towards the DLEP radio with
> > the same mac address as the local radio.
> >
> > This way you can send them over the wifi link without having to do a
> > nasty MAC-NAT style thing.
> >
> > It would be a help to be able to reconfigure the MAC on the router
> > BEFORE I have to open the TCP session.
> >
> > It might work reconfiguring it afterwards (will trigger new ARP/ICMPv6
> > requests I think).
> >
> > Henning
> >
> > On Wed, Mar 5, 2014 at 8:59 PM, Stan Ratliff (sratliff)
> > <sratliff@cisco.com>; wrote:
> >> What would that MAC address be used for? I don't understand.
> >>
> >> Stan
> >>
> >> On Mar 5, 2014, at 3:21 PM, Henning Rogge <hrogge@gmail.com>; wrote:
> >>
> >>> I wonder if we could allow a MAC address data TLV in the multicast
> >>> discovery peer offer.
> >>>
> >>> It would solve a lot of headaches with DLEP Wifi radios in Adhoc mode.
> >>>
> >>> Henning
> >>>
> >>> On Wed, Mar 5, 2014 at 7:49 PM, Stan Ratliff (sratliff)
> >>> <sratliff@cisco.com>; wrote:
> >>>> Henning,
> >>>>
> >>>> That's true. The data items would be in the "Peer Offer" response to the
> >>>> Multicasted Discovery. Those data items (IP address and Port) will have to
> >>>> move to the discovery message. Also, any a-priori configuration will need to
> >>>> be implemented in the router instead of the modem, but that's really an
> >>>> "implementation detail".
> >>>>
> >>>> Regards,
> >>>> Stan
> >>>> On Mar 5, 2014, at 1:19 PM, Henning Rogge <hrogge@gmail.com>;
> >>>> wrote:
> >>>>
> >>>> I just looked it up, we have no data items in the UDP discovery broadcast at
> >>>> all at the moment.
> >>>>
> >>>> Henning
> >>>>
> >>>> On Mar 5, 2014 5:36 PM, "Rick Taylor" <rick@tropicalstormsoftware.com>;
> >>>> wrote:
> >>>>>
> >>>>> Hi Guys,
> >>>>>
> >>>>> Thank you all very much for a very productive meeting this afternoon.  I
> >>>>> include a write up of my notes, please correct me if I have missed anything
> >>>>> pertinent.
> >>>>>
> >>>>> Stan has committed to updating the session initiation description to place
> >>>>> the TCP server in the modem, so the initial part of the protocol is:  Modem
> >>>>> broadcasts UDP Hello packets containing version, ident and TCP address/port.
> >>>>> Router TCP connects, session initiation occurs via the new TCP connection.
> >>>>>
> >>>>> Credit windowing will stay in the document, but will be clearly marked as
> >>>>> an optional part of the protocol.  There was some concern raised over the
> >>>>> clarity of the current text which will need to be address before last call.
> >>>>>
> >>>>> Vendor extensions will be defined using a new Data Item, containing a OUI
> >>>>> (or something from an existing registry) and space for a payload.  There
> >>>>> will need to be some guidance verbiage to characterise what is a valid
> >>>>> vendor extension and what is not.
> >>>>>
> >>>>> There was clarification of what both ends of a DLEP session must do on
> >>>>> reciept of an unrecognized signal and data item.  For a data item, the
> >>>>> receiver MUST ignore the data item, for a signal the recipient MUST send an
> >>>>> error status signal and terminate the TCP connection.
> >>>>>
> >>>>> There will be no facility in DLEP v1 for vendor extended signals.  Any
> >>>>> extra signals will require an uplift of the verion of the protocol and
> >>>>> require a new draft.
> >>>>>
> >>>>> There will be no such thing as a Peer Characteristic Request.  This will
> >>>>> prevent abuse and misuse of the DLEP protocol to act as a configuration
> >>>>> mechanism.
> >>>>>
> >>>>> There was further discussion concerning multiple QoS flows with seperate
> >>>>> metrics across a single link.  This was agreed to be pushed out to another
> >>>>> draft after DLEP v1, after some analysis that the proposed approach
> >>>>> (heirachial data items) will not break existing DLEP v1 implementations.
> >>>>> Stan agreed to double check that the text specified 16bit length values for
> >>>>> all TLVs (data and signals).
> >>>>>
> >>>>> There was discussion about enumerating error codes, and potential error
> >>>>> text.  The status signal MUST include an error code, 0 being success, others
> >>>>> to be enumerated after close analysis of the protocol, plus and optional
> >>>>> free text field to carry loggable information, capped at 80 bytes, utf8
> >>>>> encoded.
> >>>>>
> >>>>> There was discussion of confidence values for metrics, and this was
> >>>>> rejected as a core DLEP mechanism, and the suggestion was to use an
> >>>>> extension data item TLV instead.
> >>>>>
> >>>>> In light of achieveing their goal of listing the outstanding points that
> >>>>> needed to be reolved before DLEP can make progress to WG last-call, and
> >>>>> actually achieving suitable consensus to resolve the outstanding issues to
> >>>>> the satisafaction of one of the authors present, the DT decided to not apply
> >>>>> for a continuation of their charter, and to instead announce "Mission
> >>>>> Complete"
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Rick Taylor
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> manet-dlep-rg mailing list
> >>>>> manet-dlep-rg@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
> >>>>
> >>>> _______________________________________________
> >>>> manet-dlep-rg mailing list
> >>>> manet-dlep-rg@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
> >>>>
> >>>>
> >>
> >
> > _______________________________________________
> > manet-dlep-rg mailing list
> > manet-dlep-rg@ietf.org
> > https://www.ietf.org/mailman/listinfo/manet-dlep-rg
>