Re: [dtn-interest] Re: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE 30 Oct

Scott Burleigh <Scott.Burleigh@jpl.nasa.gov> Mon, 13 November 2006 14:56 UTC

Received: from nmta1.jpl.nasa.gov (nmta1.jpl.nasa.gov [137.78.160.214]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id kADEuSY07819 for <dtn-interest@mailman.dtnrg.org>; Mon, 13 Nov 2006 06:56:28 -0800
Received: from xmta2.jpl.nasa.gov (xmta2.jpl.nasa.gov [137.78.160.56]) by nmta1.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id kADEuNJb020867 for <dtn-interest@mailman.dtnrg.org>; Mon, 13 Nov 2006 06:56:23 -0800
Received: from [127.0.0.1] (vpn-149-246-044.jpl.nasa.gov [128.149.246.44]) by xmta2.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id kADEuFPq029763 for <dtn-interest@mailman.dtnrg.org>; Mon, 13 Nov 2006 06:56:23 -0800
Message-ID: <4558878D.1090307@jpl.nasa.gov>
Date: Mon, 13 Nov 2006 06:56:13 -0800
From: Scott Burleigh <Scott.Burleigh@jpl.nasa.gov>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: dtn-interest@mailman.dtnrg.org
Subject: Re: [dtn-interest] Re: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE 30 Oct
References: <20061105200001.9649.82769.Mailman@webbie.berkeley.intel-research.net> <1163058566.4773.32.camel@lap10-c703.uibk.ac.at> <4554A338.7080207@jpl.nasa.gov> <713DE2E9-4FE8-4C02-9625-322A546153B6@cs.berkeley.edu>
In-Reply-To: <713DE2E9-4FE8-4C02-9625-322A546153B6@cs.berkeley.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Source-IP: vpn-149-246-044.jpl.nasa.gov [128.149.246.44]
X-Source-Sender: Scott.Burleigh@jpl.nasa.gov
X-AUTH: Authorized
Sender: dtn-interest-admin@mailman.dtnrg.org
Errors-To: dtn-interest-admin@mailman.dtnrg.org
X-BeenThere: dtn-interest@mailman.dtnrg.org
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@mailman.dtnrg.org?subject=unsubscribe>
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>
List-Post: <mailto:dtn-interest@mailman.dtnrg.org>
List-Help: <mailto:dtn-interest-request@mailman.dtnrg.org?subject=help>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@mailman.dtnrg.org?subject=subscribe>
List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-interest/>

Michael Demmer wrote:
>
> On Nov 10, 2006, at 8:05 AM, Scott Burleigh wrote:
>> Having selected, potentially hazardous BRLs time out and expire 
>> sounds fine to me.  We absolutely do want to minimize the potential 
>> for production of destructive traffic.
>>
>> I'm not quite so comfortable with the concept of pre-placing BRLs 
>> along a path, in part because discovery of the path might be part of 
>> the reason to establish the BRLs.  I can certainly see how one 
>> wouldn't want BRLs for traffic-tracing BSRs installed at every node 
>> in the network, and I wouldn't argue for that.  My notion is that the 
>> subset of nodes at which we'd install some set of 
>> mutually-referencing BRLs would be selected by whoever "owned" and/or 
>> was responsible for network management at those nodes and was 
>> interested in getting specific kinds of traffic handling information 
>> from them.  Membership in the subset would be more a function of 
>> administrative interest than of topology.
>
> It seems to me that the BRL is one of potentially several ways to 
> limit the network impact of BSRs. And even with BRLs in place along 
> the entire path, a node still cannot infer definitively that failure 
> to receive a BSR means that the conditions requisite to generate the 
> BSR did not occur, as the BSR may simply have been lost by the network 
> en route to the report-to EID.
>
> I therefore propose that we change the architecture document to say 
> that nodes "should" (not "must") generate BSRs in response to the 
> specified conditions, and add a sentence or two explaining that 
> various mechanisms to rate limit or suppress unwanted BSR generation 
> may be in place at the node.
>
> Then the BRL mechanism can be individually specified in a separate 
> draft as one of these mechanisms. In addition to specifying the format 
> of the BRL and rules for the operation of the protocol, it could 
> specify that a node which conforms to the BRL spec MUST generate a BSR 
> when it has an appropriate BRL, thereby providing the additional 
> assurance that the BSR was actually created.
This seems fine to me.

Scott