Re: [manet] draft-sratliff-dlep-00

"Charles E. Perkins" <charles.perkins@earthlink.net> Thu, 05 August 2010 20:30 UTC

Return-Path: <charles.perkins@earthlink.net>
X-Original-To: manet@core3.amsl.com
Delivered-To: manet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ABE93A6881 for <manet@core3.amsl.com>; Thu, 5 Aug 2010 13:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.153
X-Spam-Level:
X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tn1CQ0ypFJzR for <manet@core3.amsl.com>; Thu, 5 Aug 2010 13:30:17 -0700 (PDT)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 3DE953A6974 for <manet@ietf.org>; Thu, 5 Aug 2010 13:30:17 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=S7QQNufyRPg7GyZsdg+OgtIOxQan6YuDmzXz2rYjg51o/dkzgKUIuhUzOAPXYR31; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [12.204.153.98] (helo=[10.166.254.158]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1Oh75T-00028W-9K; Thu, 05 Aug 2010 16:30:47 -0400
Message-ID: <4C5B1F73.4090002@earthlink.net>
Date: Thu, 05 Aug 2010 13:30:43 -0700
From: "Charles E. Perkins" <charles.perkins@earthlink.net>
Organization: Wichorus Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6
MIME-Version: 1.0
To: Stan Ratliff <sratliff@cisco.com>
References: <AANLkTim2KguoikQd3Uc+T375JoCm80bHvQdxO35zqXGP@mail.gmail.com><ABE739C5ADAC9A41ACCC72DF366B719D0349584B@GLKMS2100.GREENLNK.NET> <4F60AEF7-6E5B-4418-B73D-68EDFD0C9BEF@cisco.com>
In-Reply-To: <4F60AEF7-6E5B-4418-B73D-68EDFD0C9BEF@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52743eab96d0df951819ce63b55f313d5e350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 12.204.153.98
Cc: MANET IETF <manet@ietf.org>
Subject: Re: [manet] draft-sratliff-dlep-00
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Aug 2010 20:30:22 -0000

Hello Stan,

I've read the draft.  I have some minor editorial
nits I'll send separately.  Some comments/questions:

- My reading is that a "session" is between
   a router and a modem, and that a "neighbor" is
   some node reachable on the "other side" of the
   modem.   I reckon that "neighbors" do not have
   sessions with the router.  Is this correct?

- Presumably it's better for DLEP to enable bridging
   to neighbors, but it would be almost the same if
   DLEP established modems as next hops towards the
   neighbors.  Then, would DLEP count as a
   "mini routing protocol"?  Could you explain
   why that would be a bad idea?

- I reckon the Bandwidth Request Message field
   descriptions are wrong.  What is "Request DR"?

- Does the distinction between a client and a client
   proxy have any effect on the protocol?  Is it the
   case that _all_ "remote clients" are associated
   with a client proxy?

- Is N*2 really long enough in noisy environments
   for the heartbeat timeout?

- It's not clear why the session model is important
   for the operation of the protocol.  What state is
   established for the maintenance of the session?
   Does it just mean that a heartbeat should be
   expected?

- In the introduction:

>             Fluctuations in speed and quality of these links can
>    occur    ...    on a
>    moment-to-moment basis, due to physical phenomena like multipath
>    interference, obstructions, rain fade, etc.

    Is it intended that DLEP should deal with such
    fluctuations?  I guess it's "best effort", but in
    some cases I could imagine bursts of control traffic
    when data is struggling to be transmitted correctly.

Regards,
Charlie P.



On 8/4/2010 10:28 AM, Stan Ratliff wrote:
> Was submitted on Aug 2 and is on the ietf site at
> https://datatracker.ietf.org/doc/draft-sratliff-dlep/
>
> One difference from what was presented in Maastricht: Authentication has
> been removed from the draft. There was an off-list discussion about
> handling authentication within the context of the packetbb-sec draft;
> that seems like a better approach than handling it inside of DLEP.
>
> Regards,
> Stan
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>