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

Michael Demmer <demmer@cs.berkeley.edu> Fri, 10 November 2006 17:15 UTC

Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id kAAHFaY01741 for <dtn-interest@mailman.dtnrg.org>; Fri, 10 Nov 2006 09:15:36 -0800
Received: from [130.129.65.58] (dhcp65-58.ietf67.org [130.129.65.58]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.13.8/8.13.5) with ESMTP id kAAHFXjg018358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 10 Nov 2006 09:15:35 -0800 (PST)
In-Reply-To: <4554A338.7080207@jpl.nasa.gov>
References: <20061105200001.9649.82769.Mailman@webbie.berkeley.intel-research.net> <1163058566.4773.32.camel@lap10-c703.uibk.ac.at> <4554A338.7080207@jpl.nasa.gov>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <713DE2E9-4FE8-4C02-9625-322A546153B6@cs.berkeley.edu>
Cc: dtn-interest@mailman.dtnrg.org
Content-Transfer-Encoding: 7bit
From: Michael Demmer <demmer@cs.berkeley.edu>
Subject: Re: [dtn-interest] Re: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE 30 Oct
X-Applemailsentby: demmer
Date: Fri, 10 Nov 2006 09:15:34 -0800
To: Scott Burleigh <Scott.Burleigh@jpl.nasa.gov>
X-Mailer: Apple Mail (2.752.3)
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/>

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.

-m