From melinda20102010@gmail.com Wed May 1 18:04:08 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DC521F859D for ; Wed, 1 May 2013 18:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEuKvep5pQJ3 for ; Wed, 1 May 2013 18:04:07 -0700 (PDT) Received: from mail-da0-x231.google.com (mail-da0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD4921F859C for ; Wed, 1 May 2013 18:04:07 -0700 (PDT) Received: by mail-da0-f49.google.com with SMTP id p5so45745dak.8 for ; Wed, 01 May 2013 18:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=eg+ms5I158xrs8u5hLJmlLyCJI/R7XT4s42AXBziiD4=; b=CBweO4Zg4BL5mLR7ZoLkSXqrsCKYDA7gWJu38NTns64tWSOg9TTgeZZkkw5yJkOI6I UfQASbonodhrqXzenjQ3fLCCqSacxR69GGU3+8v9nmJ4hVXoNV5T7yWt5QzWPBD9H6+V 78oyAwsAhopcc2lUpPu6F9mZnyREQM7GGZnQ8Lu1TCYoWzE0+qdrchpf0uAar7u3A4bc CHb30uNZv/KV1LiZIinKAfOcWPfVS3HXu/LIzM/aluNu2myprRZHAsarJE3Umv94gxL2 hYfuxEmOg8eXfMyJ7uajgz0poNXUPqsloZtGU0U1i+w6seWt1MIu2y2miuyDSa39l534 Izqg== X-Received: by 10.66.89.65 with SMTP id bm1mr7246527pab.179.1367456647324; Wed, 01 May 2013 18:04:07 -0700 (PDT) Received: from [10.48.34.54] ([12.130.141.12]) by mx.google.com with ESMTPSA id at4sm4930762pbc.40.2013.05.01.18.04.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 May 2013 18:04:06 -0700 (PDT) Message-ID: <5181BB84.2080705@gmail.com> Date: Wed, 01 May 2013 18:04:04 -0700 From: Melinda User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: routing-discussion@ietf.org Subject: question on link state routing protocols Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 01:05:16 -0000 Dear all: May I ask one simple question in link state routing protocol? Was link state information accumulated and cause the size of signaling message larger and larger? i.e. the path is: a->b->c->d->e->f node a knows b's link state because of 1-hop neighbors, but can node f also know a,b,c,d,e's link states? If so, the information then keeps accumulation, the size of message received at f must be too large,right? Thanks for your answer in advance. Best, Melinda From jnc@mercury.lcs.mit.edu Wed May 1 20:08:01 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE12A21F9A13 for ; Wed, 1 May 2013 20:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtpoPo69w68C for ; Wed, 1 May 2013 20:07:56 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 91B1B21F9A10 for ; Wed, 1 May 2013 20:07:56 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 084FB18C19F; Wed, 1 May 2013 23:07:54 -0400 (EDT) To: melinda20102010@gmail.com, routing-discussion@ietf.org Subject: Re: question on link state routing protocols Message-Id: <20130502030754.084FB18C19F@mercury.lcs.mit.edu> Date: Wed, 1 May 2013 23:07:54 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 03:08:01 -0000 > From: Melinda > May I ask one simple question in link state routing protocol? > Was link state information accumulated and cause the size of signaling > message larger and larger? No. Each update only contains information about the originating node's links to its direct neighbour nodes. (These updates are sent to every node in the network - usually via some sort of 'flooding' mechanism.) The size of each update is determined by the number of direct neighbours of that node. Since most nodes only have a few direct neighbours, that limits the size of the updates. The map database in each router gets larger as the network gets bigger, of course, but that's different. > i.e. the path is: a->b->c->d->e->f > node a knows b's link state because of 1-hop neighbors, but can node f > also know a,b,c,d,e's link states? Node F _has_ to know about the connections (link state) of all the other nodes in the network (as do _all_ the nodes in the network): it has to have that information to create a complete map of the network, which is needed for the path-selection algorithm. Noel From adrian@olddog.co.uk Thu May 2 02:31:51 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB3121F9910 for ; Thu, 2 May 2013 02:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2OL7os7V9ud for ; Thu, 2 May 2013 02:31:47 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id D601E21F9579 for ; Thu, 2 May 2013 02:30:08 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r429U0fH025629; Thu, 2 May 2013 10:30:00 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r429TxbS025575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 May 2013 10:30:00 +0100 From: "Adrian Farrel" To: "'Noel Chiappa'" , References: <20130502030754.084FB18C19F@mercury.lcs.mit.edu> In-Reply-To: <20130502030754.084FB18C19F@mercury.lcs.mit.edu> Subject: RE: question on link state routing protocols Date: Thu, 2 May 2013 10:29:59 +0100 Message-ID: <027a01ce4717$9e6a0050$db3e00f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI0zj9M5cR1W23Bw1G6Cy9RdlCJOpgkkc7A Content-Language: en-gb Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 09:31:51 -0000 I think the real answer is "it depends on the protocol". What is clear is that the amount of link state information in the network increases with network size. The information is not related to "paths" per Melinda's email, but is specific to individual links per Noel's answer. But how the protocol decides to distribute the information can vary according to the protocol. For example, one protocol might distribute it in individual per-link pieces (thus keeping message size small, but increasing the number of messages), while another protocol might decide to batch the information (thus allowing message size to grow, but keeping the number of messages low). There are trade-offs and there is religion. Adrian > -----Original Message----- > From: routing-discussion-bounces@ietf.org [mailto:routing-discussion- > bounces@ietf.org] On Behalf Of Noel Chiappa > Sent: 02 May 2013 04:08 > To: melinda20102010@gmail.com; routing-discussion@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: question on link state routing protocols > > > From: Melinda > > > May I ask one simple question in link state routing protocol? > > Was link state information accumulated and cause the size of signaling > > message larger and larger? > > No. > > Each update only contains information about the originating node's links to > its direct neighbour nodes. (These updates are sent to every node in the > network - usually via some sort of 'flooding' mechanism.) The size of each > update is determined by the number of direct neighbours of that node. Since > most nodes only have a few direct neighbours, that limits the size of the > updates. > > The map database in each router gets larger as the network gets bigger, of > course, but that's different. > > > i.e. the path is: a->b->c->d->e->f > > node a knows b's link state because of 1-hop neighbors, but can node f > > also know a,b,c,d,e's link states? > > Node F _has_ to know about the connections (link state) of all the other > nodes in the network (as do _all_ the nodes in the network): it has to have > that information to create a complete map of the network, which is needed for > the path-selection algorithm. > > Noel > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From abdussalambaryun@gmail.com Thu May 2 03:16:03 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D1C21F9992 for ; Thu, 2 May 2013 03:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VOLGRmgCEYB for ; Thu, 2 May 2013 03:16:02 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 52E1521F9991 for ; Thu, 2 May 2013 03:16:02 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id wy7so270621pbc.10 for ; Thu, 02 May 2013 03:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=U13z3siow0XMl5riP2BbOmX1FT08G103+xSgtxZvid8=; b=Iqq4OiVW+1JqanergZD6Zv4PgVV51Jo8nDm7lo5HwCZ/F1+nYEUymnHCi3gQ+Ag5ny KtW35zoPOeZMkn7nQ/PQN/kIAAMIpDawNa09z9Nd5vS6p6Xj4P6BMrIoAN6f3yyoBznS el/7sl5mxgLkVtVpVN+AnPgXRKv1f+VuVtw8zCa08ENhnT8Gk+EuR4CjQLw1RCO7XN12 6dKnNurf91jgjOoFTLtxYYITpgDW07rLRas6Hh3pMfadGfYnZmwc9vpFWGvXqI8B14p8 itmUCt7aZ6N20v6mQ5J9i8AiY8TqtvdnWaVlSyaekmXh1mQ7+xX/WOT0ClPv4RHWXljA dSDQ== MIME-Version: 1.0 X-Received: by 10.69.12.37 with SMTP id en5mr8177480pbd.93.1367489761012; Thu, 02 May 2013 03:16:01 -0700 (PDT) Received: by 10.68.230.35 with HTTP; Thu, 2 May 2013 03:16:00 -0700 (PDT) In-Reply-To: <5181BB84.2080705@gmail.com> References: <5181BB84.2080705@gmail.com> Date: Thu, 2 May 2013 12:16:00 +0200 Message-ID: Subject: Re: question on link state routing protocols From: Abdussalam Baryun To: Melinda Content-Type: text/plain; charset=ISO-8859-1 Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 10:16:03 -0000 Dear Melinda, For ALL *Link State (LS) Routing Protocols* in the IETF, the protocol design depends on the Applicability Statement, or Use-Case. Users of protocols SHOULD read that section carefully (hope not to be general purpose use-case, which makes me confused in some WGs, and may users be as well). I don't know your use-case and don't know which network technology using that protocol, so answers may vary. my comments below; On 5/2/13, Melinda wrote: > Dear all: > > May I ask one simple question in link state routing protocol? Any question is always important/welcomed as long as related to IETF progress, but few editors may not follow questions from reviewers or users which needs to be fixed. It will be nice if an author of one IETF LS routing protocol I-D/RFC answers your question related to that protocol as example. > > Was link state information accumulated and cause the size of signaling > message larger and larger? IMHO, Yes that could be if the protocol allows that, but I expect that no protocols will let the message become very large compared to the first message LS information transmitted in such network. > > i.e. the path is: a->b->c->d->e->f > > node a knows b's link state because of 1-hop neighbors, but can node f > also know a,b,c,d,e's link states? IMHO, Yes F-router needs to know LSs to find out which route to use, some protocols may use information of neighbor discovery or clustering protocols > If so, the information then keeps accumulation, the size of message > received at f must be too large,right? Yes that is right, but what is the definition of too large, let us let the router to decide what is large or not (as the designer defines these things in the I-D or RFC). > > Thanks for your answer in advance. > No problem, thanks for your discussion. If we don't discuss or comment on every thing in IETF then how can we progress. Best Regards AB From jnc@mercury.lcs.mit.edu Thu May 2 07:56:50 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AE921F84B2 for ; Thu, 2 May 2013 07:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpuomLVWKegT for ; Thu, 2 May 2013 07:56:45 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8E61D21F8E04 for ; Thu, 2 May 2013 07:56:45 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 8D12718C11B; Thu, 2 May 2013 10:56:44 -0400 (EDT) To: melinda20102010@gmail.com, routing-discussion@ietf.org Subject: RE: question on link state routing protocols Message-Id: <20130502145644.8D12718C11B@mercury.lcs.mit.edu> Date: Thu, 2 May 2013 10:56:44 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 14:56:50 -0000 > From: "Adrian Farrel" > But how the protocol decides to distribute the information can vary > according to the protocol. For example, one protocol might distribute it > in individual per-link pieces Per-node, actually - I don't know of any such protocol which sends per-link messages (probably because there is no reason to do so, and good reasons not to). > (thus keeping message size small, but increasing the number of > messages), while another protocol might decide to batch the information > (thus allowing message size to grow, but keeping the number of messages > low). Do you know of any link-state protocol which does this? If not, perhaps there are good reasons not to. I can think of at least two. Noel From crowcroft@gmail.com Thu May 2 08:29:01 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B38621F87D2 for ; Thu, 2 May 2013 08:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1M-7ra9-Q4pg for ; Thu, 2 May 2013 08:29:01 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5F321F85EE for ; Thu, 2 May 2013 08:28:52 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id z16so332515ead.27 for ; Thu, 02 May 2013 08:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QIdz3unD5+lLv8cK6vAr2A4pvTyRf56YcznVdJprEpo=; b=L6Ij4oG0RIVTAmJ1gZpNknBzntIUuht81BbzUCLyyyr5vVWYWvHFJPn4ckkBgW/gd2 sK2IQTiwXqfWsbtale9f6BUmkcqBl2AfbnPfrmMmc/ocdH6ceqY+e6lquNld3+KKAYvy AEi9MaUgb9Bdee/3T1M3/Un4vQd6CtYChfsshSz0HKcPD5Sv2OEqzBTzXq44N8f1yVWc 7KUgKpTzvlxT5QpvHVpsRM2A6AjoXVhU1FuHmr2Nne0Sto/AEnbAK9eGO5q4pFYirTRb mXCCpGpJniaDzM8dx7tBEFlvsOmY9dOa8I6qBOvFaeiG/63hOtMKSZoYsuCBwxsj3coB O2pQ== MIME-Version: 1.0 X-Received: by 10.14.208.132 with SMTP id q4mr12277554eeo.35.1367508523584; Thu, 02 May 2013 08:28:43 -0700 (PDT) Sender: crowcroft@gmail.com Received: by 10.223.144.134 with HTTP; Thu, 2 May 2013 08:28:43 -0700 (PDT) In-Reply-To: <20130502145644.8D12718C11B@mercury.lcs.mit.edu> References: <20130502145644.8D12718C11B@mercury.lcs.mit.edu> Date: Thu, 2 May 2013 16:28:43 +0100 X-Google-Sender-Auth: Dxo9emKx4CU-QaKXJjYhcFHVt84 Message-ID: Subject: Re: question on link state routing protocols From: Jon Crowcroft To: Noel Chiappa Content-Type: multipart/alternative; boundary=047d7b603bf4c6bc0004dbbde352 Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 15:29:01 -0000 --047d7b603bf4c6bc0004dbbde352 Content-Type: text/plain; charset=ISO-8859-1 you could imagine some new protocol/algorithm which carried an accumulated counter of the number of interfaces the predecessor hop that is forwarding the flooded LSA had seen this LSA on - this could be used by some as yet not quite thought-through fast incremental re-computation when you notice a link fail... On Thu, May 2, 2013 at 3:56 PM, Noel Chiappa wrote: > > From: "Adrian Farrel" > > > But how the protocol decides to distribute the information can vary > > according to the protocol. For example, one protocol might > distribute it > > in individual per-link pieces > > Per-node, actually - I don't know of any such protocol which sends per-link > messages (probably because there is no reason to do so, and good reasons > not to). > > > (thus keeping message size small, but increasing the number of > > messages), while another protocol might decide to batch the > information > > (thus allowing message size to grow, but keeping the number of > messages > > low). > > Do you know of any link-state protocol which does this? If not, perhaps > there are good reasons not to. I can think of at least two. > > Noel > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > --047d7b603bf4c6bc0004dbbde352 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
you could imagine some new protocol/algorithm which carrie= d an accumulated counter of the number of interfaces the predecessor hop th= at is forwarding the flooded LSA had seen this LSA on - this could be used = by some as yet not quite thought-through fast incremental re-computation wh= en you notice a link fail...


On Thu, May 2= , 2013 at 3:56 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
=A0 =A0 > From: "Adrian Farrel"= <adrian@olddog.co.uk>

=A0 =A0 > But how the protocol decides to distribute the information can= vary
=A0 =A0 > according to the protocol. For example, one protocol might dis= tribute it
=A0 =A0 > in individual per-link pieces

Per-node, actually - I don't know of any such protocol which send= s per-link
messages (probably because there is no reason to do so, and good reasons not to).

=A0 =A0 > (thus keeping message size small, but increasing the number of=
=A0 =A0 > messages), while another protocol might decide to batch the in= formation
=A0 =A0 > (thus allowing message size to grow, but keeping the number of= messages
=A0 =A0 > low).

Do you know of any link-state protocol which does this? If not, perha= ps
there are good reasons not to. I can think of at least two.

=A0 =A0 =A0 =A0 Noel
_____________________= __________________________
routing-discussion mailing list
routing-discussion@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/routing-discussion

--047d7b603bf4c6bc0004dbbde352-- From jnc@mercury.lcs.mit.edu Thu May 2 09:21:45 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BC421F9058 for ; Thu, 2 May 2013 09:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SY3xL7Xcoo+o for ; Thu, 2 May 2013 09:21:40 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8133521F8FA3 for ; Thu, 2 May 2013 09:21:37 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id AD4AB18C1A6; Thu, 2 May 2013 12:21:35 -0400 (EDT) To: routing-discussion@ietf.org Subject: Re: question on link state routing protocols Message-Id: <20130502162135.AD4AB18C1A6@mercury.lcs.mit.edu> Date: Thu, 2 May 2013 12:21:35 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 16:21:45 -0000 > From: Jon Crowcroft > you could imagine some new protocol/algorithm which carried an > accumulated counter of the number of interfaces the predecessor hop that > is forwarding the flooded LSA had seen this LSA on Umm, maybe I'm misunderstanding your suggestion, because isn't the value of that counter which would be sent on to the neighbours always going to be '1'? (I.e. you only forward an update the _first_ time you see it - additional copies are [basically] ignored?) Yes, the copy in the node will count up, but I'm not sure what use it can be put to. Remember, loop prevention requires that everyone be working off exactly the same page, there are no 'local optimizations'. Noel From jac22@cl.cam.ac.uk Fri May 3 02:04:17 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0416821F84F2 for ; Fri, 3 May 2013 02:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.288 X-Spam-Level: X-Spam-Status: No, score=-4.288 tagged_above=-999 required=5 tests=[AWL=2.311, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqcjiFmXz+4d for ; Fri, 3 May 2013 02:04:10 -0700 (PDT) Received: from mta1.cl.cam.ac.uk (mta1.cl.cam.ac.uk [128.232.25.21]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC2E21F8529 for ; Fri, 3 May 2013 02:04:10 -0700 (PDT) Received: from ramsey.cl.cam.ac.uk ([128.232.1.219] helo=cl.cam.ac.uk) by mta1.cl.cam.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1UYBuS-0004qN-8N; Fri, 03 May 2013 10:04:08 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) Subject: Re: question on link state routing protocols In-reply-to: <20130502162135.AD4AB18C1A6@mercury.lcs.mit.edu> References: <20130502162135.AD4AB18C1A6@mercury.lcs.mit.edu> Comments: In-reply-to jnc@mercury.lcs.mit.edu (Noel Chiappa) message dated "Thu, 02 May 2013 12:21:35 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15369.1367571845.1@cl.cam.ac.uk> Date: Fri, 03 May 2013 10:04:05 +0100 From: Jon Crowcroft Message-Id: Cc: Jon.Crowcroft@cl.cam.ac.uk, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 09:04:17 -0000 In missive <20130502162135.AD4AB18C1A6@mercury.lcs.mit.edu>, Noel Chiappa typed: >> > From: Jon Crowcroft >> >> > you could imagine some new protocol/algorithm which carried an >> > accumulated counter of the number of interfaces the predecessor hop that >> >>Umm, maybe I'm misunderstanding your suggestion, because isn't the value of >>that counter which would be sent on to the neighbours always going to be '1'? >>(I.e. you only forward an update the _first_ time you see it - additional >>copies are [basically] ignored?) flooding is either done by building a spanning tree and sending it on that (viz radia perlman) or by copying a packet from any incoming link on all the interfaces you have NOT seen it - so you can count that and send it on with the LSA... >>Yes, the copy in the node will count up, but I'm not sure what use it can be >>put to. Remember, loop prevention requires that everyone be working off >>exactly the same page, there are no 'local optimizations'. sure - i'm thinking about how you do incremental dijstra in the next epoch when an LSA with my new count comes in cheers jon From jnc@mercury.lcs.mit.edu Fri May 3 07:11:56 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86E821F8D94 for ; Fri, 3 May 2013 07:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fq0soAY56kYT for ; Fri, 3 May 2013 07:11:51 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id B90AB21F86AE for ; Fri, 3 May 2013 07:11:51 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 517E518C08F; Fri, 3 May 2013 10:11:50 -0400 (EDT) To: routing-discussion@ietf.org Subject: Re: question on link state routing protocols Message-Id: <20130503141150.517E518C08F@mercury.lcs.mit.edu> Date: Fri, 3 May 2013 10:11:50 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 14:11:56 -0000 > From: Jon Crowcroft > flooding is either done by building a spanning tree and sending it on > that (viz radia perlman) I guess I need to go read up on Radia's technique, because it seems to me like there'd be a timing glitch there: suppose there's been a topology change that you don't know about yet... But if anyone could make it work, Radia can! :-) > or by copying a packet from any incoming link on all the interfaces you > have NOT seen it - so you can count that and send it on with the LSA... I guess I'm still confused. Pretty much by definition, if the node has N interfaces (which it will give in the update), the count of 'interfaces it has not yet seen update #X on' is always going to be N-1? (Since a node only forwards an update once - the first time it sees it.) Noel From d3e3e3@gmail.com Fri May 3 09:14:44 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C17121F8F43 for ; Fri, 3 May 2013 09:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YECGx5xl5lN for ; Fri, 3 May 2013 09:14:43 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CB30C21F991F for ; Fri, 3 May 2013 08:17:08 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id 6so1488171oba.4 for ; Fri, 03 May 2013 08:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=e4OHVJQygfLT74En7nwNrQ4X5hD1LgMu2a0I1fkPLSM=; b=kFx7wtJ/WM1tWbq6LcVcd3COYRiYZTmMk1AxPOmwbqBxLvesynvzxLp/7qkvLEkcLC CGH91oTanKcVCoVwVz6Ihox9THVxUFkVo7/tsdox+dYrlPhSts+A1SNITKnConLID9az BU5u6yQ6oq4m6UuR9GAqcOd7StSj/V09avaGAESy+B4aqbzu7bmdxEd9rKomxMNlDtsn wL0L2WyBubFaEexW9gF8BA8cTQWSRuVEEfD4ERoGSXhggKx2pe1ir2eT+qgwCUrY+q9m wlTvTKZaTxDqUhgXCzksdrfItuDg+wMUObmvE/k+4zJ323IGeXqg9ev+fvn/S8TdNFtW e9qw== X-Received: by 10.60.23.70 with SMTP id k6mr3113911oef.90.1367594226049; Fri, 03 May 2013 08:17:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.10.8 with HTTP; Fri, 3 May 2013 08:16:45 -0700 (PDT) In-Reply-To: <20130503141150.517E518C08F@mercury.lcs.mit.edu> References: <20130503141150.517E518C08F@mercury.lcs.mit.edu> From: Donald Eastlake Date: Fri, 3 May 2013 11:16:45 -0400 Message-ID: Subject: Re: question on link state routing protocols To: Noel Chiappa Content-Type: text/plain; charset=ISO-8859-1 Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 16:14:45 -0000 Hi, On Fri, May 3, 2013 at 10:11 AM, Noel Chiappa wrote: > > From: Jon Crowcroft > > > flooding is either done by building a spanning tree and sending it on > > that (viz radia perlman) > > I guess I need to go read up on Radia's technique, because it seems to me like > there'd be a timing glitch there: suppose there's been a topology change that > you don't know about yet... But if anyone could make it work, Radia can! :-) I think this was just a reference to Radia's invention of the Spanning Tree protocol. Neither IS-IS nor OSPF use spanning tree for flooding link state information. Spanning Tree is fundamentally a distance vector method so, if there was a link state method that used spanning tree for flooding, there wouldn't necessarily be any routing information interaction between the Spanning Tree protocol and this hypothetical link state protocol. > > or by copying a packet from any incoming link on all the interfaces you > > have NOT seen it - so you can count that and send it on with the LSA... > > I guess I'm still confused. Pretty much by definition, if the node has N > interfaces (which it will give in the update), the count of 'interfaces it has > not yet seen update #X on' is always going to be N-1? (Since a node only > forwards an update once - the first time it sees it.) It's a link state protocol so it remembers the latest version it has of each fragment of link state information. If it receives an older version or the current version it already has, it ignores it. Only if it receives a newer version does it flood it. It might also send that same current fragment it has again if it hears from some participant on a link that that participant has an old version either by that participant transmitting an old version of the fragment or by that participant transmitting meta information on what versions it has of what fragments which meta information reveals that it is out of date. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Noel From jnc@mercury.lcs.mit.edu Fri May 3 10:06:40 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9176221F8FD7 for ; Fri, 3 May 2013 10:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsBhc4VwAVrP for ; Fri, 3 May 2013 10:06:28 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id D81DC21F979E for ; Fri, 3 May 2013 09:31:10 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 06BE618C17F; Fri, 3 May 2013 12:31:10 -0400 (EDT) To: routing-discussion@ietf.org Subject: Re: question on link state routing protocols Message-Id: <20130503163110.06BE618C17F@mercury.lcs.mit.edu> Date: Fri, 3 May 2013 12:31:10 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:06:40 -0000 > From: Donald Eastlake > It's a link state protocol so it remembers the latest version it has of > each fragment of link state information. If it receives an older version > or the current version it already has, it ignores it. Only if it > receives a newer version does it flood it. Yes, yes, I understood that already, thanks. > It might also send that same current fragment it has again if it hears > from some participant on a link that that participant has an old version > either by that participant transmitting an old version of the fragment But that is 'unlikely' to happen (I'll give the scenario for it to happen below). When the node in question ('Ni') first hears the newest update ('UxN') from some node node ('Nx'), it will have sent that update to all its neighbour nodes, including this hypothetical 'node with old update' ('Nu'). Since this update is reliable (at least in all the link-state protocols I know of, which are i) new ARPANET, ii) OSPF, and iii) IS-IS - there aren't very many), i.e. the recipient has to send an ACK, and the source keeps sending the update until it gets that ACK, Ni will have kept sending UxN to Nu, trying to get an acknowledgement from Nu for UxN. Not only that, but _all_ of Nu's _other_ neighbours will _also_ have been sending update UxN to Nu, since all nodes send new updates to _all_ their neighbours (other than they one they got it from), until they get an ack for UxN from Nu. And of course Nu will have been trying to send update UxN-1 to Ni since Nu got that update (because if it had gotten any ack for UxN-1 from Ni, it would not send UxN-1 to Ni again). So for Ni to be able to get a repeated old update UxN-1 from Nu, i) _none_ of Ni's acknowledgement messages for UxN-1 to Nu could have gotten through to Nu, and ii) _none_ of the UxN updates (sent by _all_ of Nu's neighbours) could have gotten through to Nu. This seems to me unlikely - unless all of Nu's interfaces have failed for incoming packets at the same time - which also seems unlikely. Now, if Nu is a 'test' router with only one interface, which has failed for incoming packets, perhaps that could actually produce this symptom - but that's a pretty odd corner case. Or perhaps Nu has a coding error, in which case all bets are off, and you can't trust anything it says anyway... > or by that participant transmitting meta information on what versions it > has of what fragments which meta information reveals that it is out of > date. I think the same analysis as above applies here too, no? Noel From d3e3e3@gmail.com Fri May 3 11:47:33 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FED21F8C33 for ; Fri, 3 May 2013 11:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSgz5w+p+bKO for ; Fri, 3 May 2013 11:47:24 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4FD21F8BDE for ; Fri, 3 May 2013 11:47:11 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id ta14so1682936obb.26 for ; Fri, 03 May 2013 11:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=HIRabtsPYwMog8M+usf/Wx6iIUCOyLu1JY0oPwlibjE=; b=K4nmhifeGygsLGqkkVA8V3n891QVbhS+ZE5b+Tb6PiYXkEGD4T1RwGoDxY1cYi+f6n aocgbQfpVLj2YspKTIuRXpxZkFyTRwVnQ8idYcx1+QhwhBQKvHh8sjpFMQGO17M5kQf2 nzMxH3Q3N5zfLdvlNG6wmJlduPE0XnhfW/3Jq9SMvUqTeVsCMUVb9ZkZvVIacpb6UZns LtQLgDtAawIu3nNInovNth1XO7ixOV0sVGsVwDXDL8RaaWUW8VpX+ofh+8m7ZyFK8PN6 d3YS3DvIcqxUuDEGEq+YxW5NDOCNChIp341G2JxPOr8OmHem4kV7DR+DTJAGIFW5nrVv 5GLQ== X-Received: by 10.182.14.39 with SMTP id m7mr3226962obc.96.1367606830847; Fri, 03 May 2013 11:47:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.10.8 with HTTP; Fri, 3 May 2013 11:46:50 -0700 (PDT) In-Reply-To: <20130503163110.06BE618C17F@mercury.lcs.mit.edu> References: <20130503163110.06BE618C17F@mercury.lcs.mit.edu> From: Donald Eastlake Date: Fri, 3 May 2013 14:46:50 -0400 Message-ID: Subject: Re: question on link state routing protocols To: Noel Chiappa Content-Type: text/plain; charset=ISO-8859-1 Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 18:47:35 -0000 Hi Noel, On Fri, May 3, 2013 at 12:31 PM, Noel Chiappa wrote: > > From: Donald Eastlake > > ... > > > It might also send that same current fragment it has again if it hears > > from some participant on a link that that participant has an old version > > either by that participant transmitting an old version of the fragment > > But that is 'unlikely' to happen (I'll give the scenario for it to happen > below). > > When the node in question ('Ni') first hears the newest update ('UxN') from > some node node ('Nx'), it will have sent that update to all its neighbour > nodes, including this hypothetical 'node with old update' ('Nu'). > > Since this update is reliable (at least in all the link-state protocols I know > of, which are i) new ARPANET, ii) OSPF, and iii) IS-IS - there aren't very > many), i.e. the recipient has to send an ACK, and the source keeps sending the > update until it gets that ACK, Ni will have kept sending UxN to Nu, trying to > get an acknowledgement from Nu for UxN. Well, I think there are things like OLSR and others but let's just use IS-IS. There are lots of people who know more about IS-IS than I do but it is the link state routing protocol that I know the most about. While it is certainly possible that IS-IS routers are connected by a link with link level acknowledgements and re-transmission, such as an 802.11 link, common link technologies such as Ethernet don't do that as I'm sure you know. You seem to be saying that there are IS-IS level acks and retransmission. Could you point out where in ISO/IEC 10589:200 or RFC 1195 or where ever this IS-IS level PDU ack and retransmission is specified? Perhaps I missed it. As far as I know, an IS-IS router just sends updated link state fragments on its various interfaces, other than the one it received it on, and trusts to the CSNP/PSNP mechanism and the like to fix up any problems from lost packets. (It's actually more complex. To avoid storms, in general it just sets a flag associated with the link state fragment and the port. This flag setting may or may not cause the fragment to be sent on that port. If the same fragment is received on that port before the router gets around to sending, the flag gets cleared. It will send it quickly if there hasn't been much link state traffic recently but if there are lots of link state updates going on, it may delay a while before scanning for transmit flags that are still set to avoid update storms.) If I'm all confused about this, hopefully you can set me straight. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Not only that, but _all_ of Nu's _other_ neighbours will _also_ have been > sending update UxN to Nu, since all nodes send new updates to _all_ their > neighbours (other than they one they got it from), until they get an ack for > UxN from Nu. > > And of course Nu will have been trying to send update UxN-1 to Ni since Nu got > that update (because if it had gotten any ack for UxN-1 from Ni, it would not > send UxN-1 to Ni again). > > So for Ni to be able to get a repeated old update UxN-1 from Nu, i) _none_ of > Ni's acknowledgement messages for UxN-1 to Nu could have gotten through to Nu, > and ii) _none_ of the UxN updates (sent by _all_ of Nu's neighbours) could > have gotten through to Nu. This seems to me unlikely - unless all of Nu's > interfaces have failed for incoming packets at the same time - which also > seems unlikely. > > Now, if Nu is a 'test' router with only one interface, which has failed for > incoming packets, perhaps that could actually produce this symptom - but > that's a pretty odd corner case. > > Or perhaps Nu has a coding error, in which case all bets are off, and you can't > trust anything it says anyway... > > > or by that participant transmitting meta information on what versions it > > has of what fragments which meta information reveals that it is out of > > date. > > I think the same analysis as above applies here too, no? > > Noel From fred@cisco.com Fri May 3 12:22:57 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6FD21F8B5F for ; Fri, 3 May 2013 12:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.3 X-Spam-Level: X-Spam-Status: No, score=-109.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRNK+H1TpTqI for ; Fri, 3 May 2013 12:22:52 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D163C21F8B60 for ; Fri, 3 May 2013 12:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=619; q=dns/txt; s=iport; t=1367608971; x=1368818571; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ixADV66GbOK+0G2RPmohkxwp07nW+w3WvgTuOZOH2F4=; b=CJwZFWdSOUkJPu2zyRFPPSN22C1hvtVVPExyjWI7YFJSl5ZBsP0D6o2X DIvPhcIL/o52jVZjatwoIISf6ev8GAuI4QpHhI6vKLnF40AO0gekxRh63 ZWIpK7iHoCySk0iOEqe/jpvSJKQChnI0Hem8NYgiW5s7xdR2uS/cEfCay A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAFABMOhFGtJXG8/2dsb2JhbABQgwc3gnW8PHkWdIIfAQEBAwE6PwULAgEIDhQUECERJQIEDgUIh3IDCQYMuUQNh2QEjFuCIwIxB4JyYQOVSI11hSGDDYIn X-IronPort-AV: E=Sophos;i="4.87,606,1363132800"; d="scan'208";a="206193038" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 03 May 2013 19:22:36 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r43JMasf029815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 May 2013 19:22:36 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Fri, 3 May 2013 14:22:35 -0500 From: "Fred Baker (fred)" To: Donald Eastlake Subject: Re: question on link state routing protocols Thread-Topic: question on link state routing protocols Thread-Index: AQHOSBueFf5ayskne0WRWsdveXN70Zj0IL4AgAAJ+4A= Date: Fri, 3 May 2013 19:22:35 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B843B2D@xmb-rcd-x09.cisco.com> References: <20130503163110.06BE618C17F@mercury.lcs.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: text/plain; charset="us-ascii" Content-ID: <62515CF45B154847BC51734100135360@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Noel Chiappa , "" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 19:22:57 -0000 On May 3, 2013, at 11:46 AM, Donald Eastlake wrote: > You seem to be saying that there are IS-IS level > acks and retransmission. Could you point out where in ISO/IEC > 10589:200 or RFC 1195 or where ever this IS-IS level PDU ack and > retransmission is specified? Perhaps I missed it. yes, there are such acks and retransmission. You might look at https://tool= s.ietf.org/html/rfc1142 (which reflects the 1990 spec, not the 1992 spec, a= nd so will have some differences from current reality, but is publicly acce= ssible without money) and specifically sections 7.3.14 and 7.3.17.= From jnc@mercury.lcs.mit.edu Fri May 3 13:32:19 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C97221F8681 for ; Fri, 3 May 2013 13:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.3 X-Spam-Level: X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfEYviK7lT6t for ; Fri, 3 May 2013 13:32:14 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 888A521F84B2 for ; Fri, 3 May 2013 13:32:14 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id ADAC918C116; Fri, 3 May 2013 16:32:13 -0400 (EDT) To: routing-discussion@ietf.org Subject: Re: question on link state routing protocols Message-Id: <20130503203213.ADAC918C116@mercury.lcs.mit.edu> Date: Fri, 3 May 2013 16:32:13 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 20:32:19 -0000 > From: Donald Eastlake > You seem to be saying that there are IS-IS level acks and > retransmission. ... As far as I know, an IS-IS router just sends updated > link state fragments on its various interfaces, other than the one it > received it on, and trusts to the CSNP/PSNP mechanism and the like to > fix up any problems from lost packets. Oh, right you are - I'd forgotten that IS-IS only uses reliable flooding on point-point links, not broadcast links. (It's been a long while since I looked at IS-IS - sorry!) I'm curious as to why they went that route; if the maps are not synchronized, routing loops can occur. Presumably (I don't remember any more, although I remember talking to John Moy a lot about OSPF) that's why when John did OSPF he didn't copy that aspect of IS-IS (the spec doesn't say, alas); I know he looked heavily at IS-IS and did use other ideas from it. Noel From d3e3e3@gmail.com Fri May 3 13:46:46 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A8521F8A00 for ; Fri, 3 May 2013 13:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.1 X-Spam-Level: X-Spam-Status: No, score=-103.1 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdTNbwTyMaIN for ; Fri, 3 May 2013 13:46:42 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id 21FCB21F882A for ; Fri, 3 May 2013 13:46:42 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id j1so2042197oag.27 for ; Fri, 03 May 2013 13:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=zevPFIA/Uz3Jf6M8ZzadZ7aQzZvIUVitZC5ErkGRmxI=; b=TYC9e6FOHeJzmwFaddENe2Bld6vfj7n/Lbm+DBOGOWwTIIAqHG4uP4nJdUBo19OuRP 8P3GtG/1XHsBo+pasSFLxtcVUuQFwS0rVDI0Hz6ShDqlPoWZAqtm3oofOm7Z+cSFHq4i 2mN8XaaDjoLjcCiKArg4hGMmZIuwKjUEUXFgy12bZbbBj7bfUfSdIh+e75WFCd7yWzGr 090J373Qjaq7jat0Cd6Yi00m9WGs1QdUERETRcXqV63rQbpL4LiJ+GT4Q0+5jPRA28xB Jqz6FE9EBrU+qWe+kvzupZRpvvZBzmqGbW8S26rLEHN0aVMMNVei95v3SvGmzpRPqutb zFow== X-Received: by 10.60.56.168 with SMTP id b8mr3336753oeq.5.1367614001731; Fri, 03 May 2013 13:46:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.10.8 with HTTP; Fri, 3 May 2013 13:46:21 -0700 (PDT) In-Reply-To: <8C48B86A895913448548E6D15DA7553B843B2D@xmb-rcd-x09.cisco.com> References: <20130503163110.06BE618C17F@mercury.lcs.mit.edu> <8C48B86A895913448548E6D15DA7553B843B2D@xmb-rcd-x09.cisco.com> From: Donald Eastlake Date: Fri, 3 May 2013 16:46:21 -0400 Message-ID: Subject: Re: question on link state routing protocols To: "Fred Baker (fred)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Noel Chiappa , "" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 20:46:46 -0000 OK. What I was saying was correct for broadcast links, as Noel said. I understand my thinking may be different from how others think, but I consider broadcast links to be the general case and p2p links a configured special case. So unless someone says they are talking about p2p links, I tend to think about the broadcast link case. In any case, I don't think even on a p2p link there is a very tightly coupled protocol where an immediate acknowledgement is always sent and sub-second timeout always causes retransmission if an acknowledgement hasn't been received. The receipt of a link state fragment on a p2p link just sets a flag to request that an PSNP be eventually sent as an acknowledgment. There are various timers with multi-second defaults. Of course, for the flooding to be reliable (and it isn't much use if it isn't reliable), you have to have some mechanism that will eventually force retransmission/synchronization. But it seems to me that the mechanisms in IS-IS can be orders of magnitude slower than a tightly coupled link retransmission protocol would be. So, depending on how reliable and consistent the links are and how richly interconnected the routers are and how rapidly topological changes are happening, I think there is room for things to occur such as receiving an old update from an adjacent router. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Fri, May 3, 2013 at 3:22 PM, Fred Baker (fred) wrote: > > On May 3, 2013, at 11:46 AM, Donald Eastlake wrote: > >> You seem to be saying that there are IS-IS level >> acks and retransmission. Could you point out where in ISO/IEC >> 10589:200 or RFC 1195 or where ever this IS-IS level PDU ack and >> retransmission is specified? Perhaps I missed it. > > yes, there are such acks and retransmission. You might look at https://to= ols.ietf.org/html/rfc1142 (which reflects the 1990 spec, not the 1992 spec,= and so will have some differences from current reality, but is publicly ac= cessible without money) and specifically sections 7.3.14 and 7.3.17. From fred@cisco.com Fri May 3 14:19:28 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C56A21F8696 for ; Fri, 3 May 2013 14:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.949 X-Spam-Level: X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7A6jNnk18BC for ; Fri, 3 May 2013 14:19:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BA88B21F84B2 for ; Fri, 3 May 2013 14:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1692; q=dns/txt; s=iport; t=1367615962; x=1368825562; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yJBo8RM0nItnMgwzmxhHZ56nKbnF8GLbodDG2PerL3E=; b=BwKkQzt3ymh46YjDfUE0RQ0dM9YxwUL1XQI4NZPRKFSwZcx1rkaj4Plu HToW+Zyvg+tTdzd0amM6dbxv7xO02Eou9IcnYP04GSWkxQ5LQo5qAiOMd PYE8Q1D/5YcqOpqKvfW1SCPbvXmifydny/3+xCCY7nzcp1veVekwynMq1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAKgohFGtJV2d/2dsb2JhbABQgwe/anoWdIIfAQEBAwE6PwULAgEIDgoKFBAhESUCBA4FCIdyAwkGuVUNh2iMW4IjAjEHgnJhA5NdgWuNdYUhgw2CJw X-IronPort-AV: E=Sophos;i="4.87,607,1363132800"; d="scan'208";a="206346025" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 03 May 2013 21:19:22 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r43LJMVZ012295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 May 2013 21:19:22 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Fri, 3 May 2013 16:19:22 -0500 From: "Fred Baker (fred)" To: Donald Eastlake Subject: Re: question on link state routing protocols Thread-Topic: question on link state routing protocols Thread-Index: AQHOSBueFf5ayskne0WRWsdveXN70Zj0IL4AgAAJ+4CAABdqgIAACTcA Date: Fri, 3 May 2013 21:19:21 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B843D80@xmb-rcd-x09.cisco.com> References: <20130503163110.06BE618C17F@mercury.lcs.mit.edu> <8C48B86A895913448548E6D15DA7553B843B2D@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: text/plain; charset="us-ascii" Content-ID: <6BAAA472AE679E44837B7D3776A222F0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Noel Chiappa , "" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 21:19:28 -0000 On May 3, 2013, at 1:46 PM, Donald Eastlake wrote: > In any case, I don't think even on a p2p link there is a very tightly > coupled protocol where an immediate acknowledgement is always sent and > sub-second timeout always causes retransmission if an acknowledgement > hasn't been received. Sub-second timeout doesn't case a retransmission. There is a timeout, and i= t causes retransmission. > it seems to me > that the mechanisms in IS-IS can be orders of magnitude slower than a > tightly coupled link retransmission protocol would be.=20 Well, OK. We could discuss LAPB or IEEE 802.2's equivalent. My first though= t would be to say "haven't we been there before?" My second thought would be to wonder what the causes of loss and eventual t= imeout are. We could, for example, mention forward error correction on your= favorite link layer. A part of me wonders if there would be value in an im= plementation setting a very short "first" timeout, perhaps on the order of = a small multiple of the propagation delay of the link (tens to hundreds of = milliseconds) and resending the PDU if an ack hasn't been received by that = time. Or, whatever, just send every message twice on the assumption that th= e peer knows how to drop duplicates. How probable is the event, and what is= the cost/benefit ratio of addressing it? If we think that links have a BER on the order of 1e-11 or better, and that= the primary source of non-congestive loss is bit errors (there are ways to= prevent congestive loss), it seems to me that we are dealing with a high c= ost for the error rate if we're doing a lot more than my "first" timeout.= From tony.li@tony.li Fri May 3 14:51:14 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AAB21F90C1 for ; Fri, 3 May 2013 14:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecbQ1o-Yv6ly for ; Fri, 3 May 2013 14:51:07 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3F521F90EA for ; Fri, 3 May 2013 14:51:07 -0700 (PDT) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta01.emeryville.ca.mail.comcast.net with comcast id XQ7L1l00B0vp7WLA1Zr4lE; Fri, 03 May 2013 21:51:04 +0000 Received: from [192.168.2.111] ([98.248.36.188]) by omta05.emeryville.ca.mail.comcast.net with comcast id XZr21l01F43ZcXW8RZr3xS; Fri, 03 May 2013 21:51:04 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: question on link state routing protocols From: Tony Li In-Reply-To: <8C48B86A895913448548E6D15DA7553B843D80@xmb-rcd-x09.cisco.com> Date: Fri, 3 May 2013 14:51:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7179AD84-7FAF-4EBA-A0AF-2AFA6A379BDC@tony.li> References: <20130503163110.06BE618C17F@mercury.lcs.mit.edu> <8C48B86A895913448548E6D15DA7553B843B2D@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B843D80@xmb-rcd-x09.cisco.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1503) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367617864; bh=NAV9G+cmcDhKHae/JDD37htJNvb5zcxz42prOYZ2A3Q=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=CLh4nKWV83gT89M355jjmku7muVtfwguAcckQJNNgGAhpMcG6qR3LWyh2A678TqrO HafLRRc8FPbhvTsfXSdVdcAhYB7z/D02xBbH1sC4gFhG6HjnIgnu2yyBx8Y1KPPS5u Y1GrR7UYAA/DEmvau2iGWuwXhAJYmuKttfay7But9bG4jCSB3yX7Cb5z1eGXYqZWIJ 3gYucLOB/MVVbyrDzons7Siug6GZsHjZN7ym+n316UaI56CsfIsQumrRfWy14zLd3m zbpYWakdxuZLzi6Z3cXlem0mJFOCtXkYnMqsycfRIdMtz0erS+DsEywt5XeYqbjIzx eVH/SQmt4XhHQ== Cc: Noel Chiappa , "" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 21:51:15 -0000 On May 3, 2013, at 2:19 PM, "Fred Baker (fred)" wrote: >>=20 >> it seems to me >> that the mechanisms in IS-IS can be orders of magnitude slower than a >> tightly coupled link retransmission protocol would be.=20 >=20 > Well, OK. We could discuss LAPB or IEEE 802.2's equivalent. My first = thought would be to say "haven't we been there before?" >=20 > My second thought would be to wonder what the causes of loss and = eventual timeout are. We could, for example, mention forward error = correction on your favorite link layer. A part of me wonders if there = would be value in an implementation setting a very short "first" = timeout, perhaps on the order of a small multiple of the propagation = delay of the link (tens to hundreds of milliseconds) and resending the = PDU if an ack hasn't been received by that time. Or, whatever, just send = every message twice on the assumption that the peer knows how to drop = duplicates. How probable is the event, and what is the cost/benefit = ratio of addressing it? In my humble experience, the most frequent cause of lost protocol = packets is indigestion on the receiver side, and it's bizarrely rare to = boot. =20 Why would we worry about optimizing for a 10-sigma outlier, and even if = we did that, wouldn't we want to send less, not more? Tony From ginsberg@cisco.com Fri May 3 16:49:49 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F3821F8EA4 for ; Fri, 3 May 2013 16:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgDfFmtttItq for ; Fri, 3 May 2013 16:49:44 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 982F221F8C33 for ; Fri, 3 May 2013 16:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1402; q=dns/txt; s=iport; t=1367624984; x=1368834584; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fnsFb0wMXXvdU8R6aka3hcF0ie9yquRdp5UbKVqZZ6Y=; b=KZVo0bKeV7wgMDwh2/NMZufjmDLWemB0fHUXAfWZPsUVpkKZo7tD7F8N 7+HV7CrtBw3GX8Yy7ouHxjn6rAwzX1AgW77dlypiCUOZoM9dGJ1ucgs1L LCXDhtZVDchDpzkBcoOWgQBAFEzjiFx30Uq9375D21oQuSZyHirZ48VIu 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFACxMhFGtJV2Y/2dsb2JhbABQgwc3vzZ7FnSCHwEBAQQBAQE3NAsMBAIBCBEEAQEBChQJByEGCxQJCAIEAQ0FCIdyAw8MuVANiAiMW4IlMQIFBoJsYQOVSIMKimuFIYMNgic X-IronPort-AV: E=Sophos;i="4.87,607,1363132800"; d="scan'208";a="206299772" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 03 May 2013 23:49:44 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r43NnhNE029214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 May 2013 23:49:43 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Fri, 3 May 2013 18:49:43 -0500 From: "Les Ginsberg (ginsberg)" To: "Fred Baker (fred)" , Donald Eastlake Subject: RE: question on link state routing protocols Thread-Topic: question on link state routing protocols Thread-Index: AQHOSBueXfZHWxueIUi+cLE/sDsnrZj0IL4AgAAJ/oD///YWwA== Date: Fri, 3 May 2013 23:49:43 +0000 Message-ID: References: <20130503163110.06BE618C17F@mercury.lcs.mit.edu> <8C48B86A895913448548E6D15DA7553B843B2D@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B843B2D@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.99.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Noel Chiappa , "" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 23:49:49 -0000 ISO 10589:2002 (THE REAL STANDARD) is freely available here: http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html Please let's not refer to RFC1142 which I thought we had successfully burie= d years ago. :-) Les > -----Original Message----- > From: routing-discussion-bounces@ietf.org [mailto:routing-discussion- > bounces@ietf.org] On Behalf Of Fred Baker (fred) > Sent: Friday, May 03, 2013 12:23 PM > To: Donald Eastlake > Cc: Noel Chiappa; > Subject: Re: question on link state routing protocols >=20 >=20 > On May 3, 2013, at 11:46 AM, Donald Eastlake wrote: >=20 > > You seem to be saying that there are IS-IS level > > acks and retransmission. Could you point out where in ISO/IEC > > 10589:200 or RFC 1195 or where ever this IS-IS level PDU ack and > > retransmission is specified? Perhaps I missed it. >=20 > yes, there are such acks and retransmission. You might look at > https://tools.ietf.org/html/rfc1142 (which reflects the 1990 spec, not th= e > 1992 spec, and so will have some differences from current reality, but is > publicly accessible without money) and specifically sections 7.3.14 and > 7.3.17. > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From sratliff@cisco.com Fri May 3 17:58:23 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21D521F8BE9 for ; Fri, 3 May 2013 17:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9xeM+HhkZ2g for ; Fri, 3 May 2013 17:58:18 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1E31821F86AE for ; Fri, 3 May 2013 17:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2302; q=dns/txt; s=iport; t=1367629098; x=1368838698; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oFOIwqs/cK+23m25OpS4yGChmmrjZHbax2pCkST8glI=; b=e8EUBHejIJQKbn9v3BThZl2d3ka6RbPSsFBjjWsn+7QWBwaUr4w5n43v 1jF9aavYEcqnqDt9ZO+SCDD/BO8UOr9jEROr83IgV6PVZAgNKlj6FqbYq 2ZLKbNAX89VBnIrfdF502UbBjkd9gilaU4k/TgtfjoCPA3pCELJh720/W Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAKZchFGtJV2b/2dsb2JhbABQgwc3vzZ7FnSCHwEBAQMBAQEBawsQAgEIGAokJwslAgQOBQiHfgYMwWMEjn4CMQeCcmEDk12VAYMNgWkHNw X-IronPort-AV: E=Sophos;i="4.87,607,1363132800"; d="scan'208";a="206103133" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 04 May 2013 00:58:17 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r440wHjG007497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 4 May 2013 00:58:17 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.159]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 3 May 2013 19:58:17 -0500 From: "Stan Ratliff (sratliff)" To: Tony Li Subject: Re: question on link state routing protocols Thread-Topic: question on link state routing protocols Thread-Index: AQHOSBueSgQInNJy0EqfI2gBAB9QNpj0IL4AgAAJ+4CAABdqgIAACTiAgAAI2gCAADRQAA== Date: Sat, 4 May 2013 00:58:16 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C100E30EA@xmb-aln-x03.cisco.com> References: <20130503163110.06BE618C17F@mercury.lcs.mit.edu> <8C48B86A895913448548E6D15DA7553B843B2D@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B843D80@xmb-rcd-x09.cisco.com> <7179AD84-7FAF-4EBA-A0AF-2AFA6A379BDC@tony.li> In-Reply-To: <7179AD84-7FAF-4EBA-A0AF-2AFA6A379BDC@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.213] Content-Type: text/plain; charset="Windows-1252" Content-ID: <16FE2E5DE1883D448A94A01D7CEF3F67@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Fred Baker \(fred\)" , "" , Noel Chiappa X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 00:58:23 -0000 On May 3, 2013, at 5:51 PM, Tony Li wrote: >=20 > On May 3, 2013, at 2:19 PM, "Fred Baker (fred)" wrote: >=20 >>>=20 >>> it seems to me >>> that the mechanisms in IS-IS can be orders of magnitude slower than a >>> tightly coupled link retransmission protocol would be.=20 >>=20 >> Well, OK. We could discuss LAPB or IEEE 802.2's equivalent. My first tho= ught would be to say "haven't we been there before?" >>=20 >> My second thought would be to wonder what the causes of loss and eventua= l timeout are. We could, for example, mention forward error correction on y= our favorite link layer. A part of me wonders if there would be value in an= implementation setting a very short "first" timeout, perhaps on the order = of a small multiple of the propagation delay of the link (tens to hundreds = of milliseconds) and resending the PDU if an ack hasn't been received by th= at time. Or, whatever, just send every message twice on the assumption that= the peer knows how to drop duplicates. How probable is the event, and what= is the cost/benefit ratio of addressing it? >=20 >=20 > In my humble experience, the most frequent cause of lost protocol packets= is indigestion on the receiver side, and it's bizarrely rare to boot. =20 Not for wireless nets. ;-) With more and more mobile wireless popping up, a= nd the need for those devices to participate in routing (instead of being a= nd end-user device), the problem will get worse, IMO. >=20 > Why would we worry about optimizing for a 10-sigma outlier, and even if w= e did that, wouldn't we want to send less, not more? I completely agree that sending less is preferable, especially on "disadvan= taged" links like RF. But from what I've seen, users *want* to deploy on th= e order of thousands of routing nodes in a network (think of a brigade of s= oldiers, each with 3 or 4 intelligent devices of some sort), do it wireless= ly, *and* stream HD video all over the place=85 (Note that I said users *wa= nt* to do this, not that it's actually possible). ;-) Regards, Stan >=20 > Tony >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From tony.li@tony.li Fri May 3 19:42:43 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE2A21F8F2F for ; Fri, 3 May 2013 19:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ijy7qJcsn+Ou for ; Fri, 3 May 2013 19:42:36 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by ietfa.amsl.com (Postfix) with ESMTP id 95CB821F8F1E for ; Fri, 3 May 2013 19:42:36 -0700 (PDT) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta09.emeryville.ca.mail.comcast.net with comcast id XeWV1l0041vN32cA9eicS4; Sat, 04 May 2013 02:42:36 +0000 Received: from [192.168.2.111] ([98.248.36.188]) by omta22.emeryville.ca.mail.comcast.net with comcast id Xeia1l00Y43ZcXW8ieibnz; Sat, 04 May 2013 02:42:36 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: question on link state routing protocols From: Tony Li In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C100E30EA@xmb-aln-x03.cisco.com> Date: Fri, 3 May 2013 19:42:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <302778D7-F766-48EF-8097-0600DDE8B77A@tony.li> References: <20130503163110.06BE618C17F@mercury.lcs.mit.edu> <8C48B86A895913448548E6D15DA7553B843B2D@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B843D80@xmb-rcd-x09.cisco.com> <7179AD84-7FAF-4EBA-A0AF-2AFA6A379BDC@tony.li> <2ED1D3801ACAAB459FDB4EAC9EAD090C100E30EA@xmb-aln-x03.cisco.com> To: "Stan Ratliff (sratliff)" X-Mailer: Apple Mail (2.1503) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367635356; bh=sS7oSAvIDMtk2VNccKGiduj89Ed8jsgey5c+ItIKtUI=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=QGb/tovqLYmcZfknFB0bKviiwikrLoJCxi61pq23+3hGb6GZCE2u7LYL5dqOIYetp Vae5s3Xg1ZAJJx4FwhLFNmoKl+vajCHsodxCJs9a3WsoCdgi+NfEHdcrUP6OZTDhhb 5V0OTtoqlaClTs9tUqlKZMW1ku5gzxisVIPqAV5jB59YvQ+veb0hyP9Qyf2Gm1T4EH 1fi6y+2fSXFshge+IqCtOxXilYdm9b/FmW56P3hRZ70cNkYzsE3gkViwocM8EKNpj+ ICJ1RQvqD3HgKDsKeH5Jz4NgfHIBzKSEYqW3gKDKzSmn3qburCsJ+vsXdzonmLCPbC slS4p9Ka59yuQ== Cc: "Fred Baker \(fred\)" , "" , Noel Chiappa X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 02:42:43 -0000 On May 3, 2013, at 5:58 PM, "Stan Ratliff (sratliff)" = wrote: > Not for wireless nets. ;-) With more and more mobile wireless popping = up, and the need for those devices to participate in routing (instead of = being and end-user device), the problem will get worse, IMO. Fair, but this is exactly why 802.11 has a built-in link layer = mechanism. No need to replicate it at a higher layer. >> Why would we worry about optimizing for a 10-sigma outlier, and even = if we did that, wouldn't we want to send less, not more? >=20 > I completely agree that sending less is preferable, especially on = "disadvantaged" links like RF. But from what I've seen, users *want* to = deploy on the order of thousands of routing nodes in a network (think of = a brigade of soldiers, each with 3 or 4 intelligent devices of some = sort), do it wirelessly, *and* stream HD video all over the place=85 = (Note that I said users *want* to do this, not that it's actually = possible). ;-) Good, so how about we focus on what's possible instead? T From sratliff@cisco.com Mon May 6 07:50:50 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA51321F93E6 for ; Mon, 6 May 2013 07:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMI1zMECOMts for ; Mon, 6 May 2013 07:50:44 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D597721F93D8 for ; Mon, 6 May 2013 07:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1774; q=dns/txt; s=iport; t=1367851841; x=1369061441; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QonmMJfz1SzGf70c/vl81BtVhfAAO05HlGF0uC31b00=; b=jS4QQR7oVTEgyGIyX7ktDZuSbbo7cP4XniZQo7gJOiXrD4BrLeISHUuy x+wJykYod1VO9s3Jj1OHJzwfdKHmz0HjL26+aaEfufaSK8kKQ5j3L53Al vBcIfr/YE6d5EolKJwIcCg3UkCw0MR1odzrzXH2/zEUOSOqIklVCcTdgM Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAHzCh1GtJXG//2dsb2JhbABQgwe/M4ECFnSCHwEBAQMBeRACAQgYCiQyJQIEDgUIh34GwACOfgIxB4JyYQOTX5UDgw2BaQc3 X-IronPort-AV: E=Sophos;i="4.87,622,1363132800"; d="scan'208";a="206910611" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 06 May 2013 14:50:38 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r46EocuO005743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 May 2013 14:50:38 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.159]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 6 May 2013 09:50:38 -0500 From: "Stan Ratliff (sratliff)" To: Tony Li Subject: Re: question on link state routing protocols Thread-Topic: question on link state routing protocols Thread-Index: AQHOSBueSgQInNJy0EqfI2gBAB9QNpj0IL4AgAAJ+4CAABdqgIAACTiAgAAI2gCAADRQAIAAHSUAgAPwHgA= Date: Mon, 6 May 2013 14:50:37 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C100E759C@xmb-aln-x03.cisco.com> References: <20130503163110.06BE618C17F@mercury.lcs.mit.edu> <8C48B86A895913448548E6D15DA7553B843B2D@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B843D80@xmb-rcd-x09.cisco.com> <7179AD84-7FAF-4EBA-A0AF-2AFA6A379BDC@tony.li> <2ED1D3801ACAAB459FDB4EAC9EAD090C100E30EA@xmb-aln-x03.cisco.com> <302778D7-F766-48EF-8097-0600DDE8B77A@tony.li> In-Reply-To: <302778D7-F766-48EF-8097-0600DDE8B77A@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.118] Content-Type: text/plain; charset="Windows-1252" Content-ID: <50745299F8249242AC151086DADF2F23@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Fred Baker \(fred\)" , "" , Noel Chiappa X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 14:50:50 -0000 On May 3, 2013, at 10:42 PM, Tony Li wrote: >=20 > On May 3, 2013, at 5:58 PM, "Stan Ratliff (sratliff)" wrote: >=20 >> Not for wireless nets. ;-) With more and more mobile wireless popping up= , and the need for those devices to participate in routing (instead of bein= g and end-user device), the problem will get worse, IMO. >=20 >=20 > Fair, but this is exactly why 802.11 has a built-in link layer mechanism.= No need to replicate it at a higher layer. The inefficiencies in 802.11 make it (IMO) good for the last hop to an end-= user, but lousy for transit. Add the problems of mobility in, and it become= s unusable in a routing context.=20 >=20 >=20 >>> Why would we worry about optimizing for a 10-sigma outlier, and even if= we did that, wouldn't we want to send less, not more? >>=20 >> I completely agree that sending less is preferable, especially on "disad= vantaged" links like RF. But from what I've seen, users *want* to deploy on= the order of thousands of routing nodes in a network (think of a brigade o= f soldiers, each with 3 or 4 intelligent devices of some sort), do it wirel= essly, *and* stream HD video all over the place=85 (Note that I said users = *want* to do this, not that it's actually possible). ;-) >=20 >=20 > Good, so how about we focus on what's possible instead? I'd love to see some focus on routing protocols deployed in greater numbers= (e.g. hundreds, up to a thousand routers), running efficiently on lower ba= ndwidth links like wireless. I think we'd get commercially viable product w= ell before the defense-oriented use case I described above. This just seeme= d like a good opportunity to bring the topic up.=20 Regards, Stan >=20 > T >=20 From fred@cisco.com Mon May 6 10:26:20 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B18B21F931F for ; Mon, 6 May 2013 10:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.486 X-Spam-Level: X-Spam-Status: No, score=-110.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBGTNIUSWSiP for ; Mon, 6 May 2013 10:26:14 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B176521F930C for ; Mon, 6 May 2013 10:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3147; q=dns/txt; s=iport; t=1367861174; x=1369070774; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3XmmA3NM+UYyqY0ALlCfPPihDOJjPfbfZCb91KvocrM=; b=bTG3EgYDoe+v9GUB0sjx3Qosb2VOWYKevX51z7NaqVyZd+RE0M6GbvfB j5HcMr88AX4s7GcMTn94aj1lrLoHqQODahVNjUgshdOoWYYGCEdNCeeHJ wuANV/wiz4lsFOTezJrH7WVCzPOlJWWr2OHx+WgxpNDbB5xeH9xSnbNbo w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAE/nh1GtJV2Z/2dsb2JhbABQgwe/M4EDFnSCHwEBAQMBeQULAgEIIiQyJQIEDgUIE4drBsAwjgB+AjEHgnJhA5NflQODDYIn X-IronPort-AV: E=Sophos;i="4.87,623,1363132800"; d="scan'208";a="207004449" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 06 May 2013 17:26:14 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r46HQEda021566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 May 2013 17:26:14 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.125]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Mon, 6 May 2013 12:26:13 -0500 From: "Fred Baker (fred)" To: "Stan Ratliff (sratliff)" Subject: Re: question on link state routing protocols Thread-Topic: question on link state routing protocols Thread-Index: AQHOSBueFf5ayskne0WRWsdveXN70Zj0IL4AgAAJ+4CAABdqgIAACTcAgAAI2wCAADRQAIAEOJOA Date: Mon, 6 May 2013 17:26:13 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B851440@xmb-rcd-x09.cisco.com> References: <20130503163110.06BE618C17F@mercury.lcs.mit.edu> <8C48B86A895913448548E6D15DA7553B843B2D@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B843D80@xmb-rcd-x09.cisco.com> <7179AD84-7FAF-4EBA-A0AF-2AFA6A379BDC@tony.li> <2ED1D3801ACAAB459FDB4EAC9EAD090C100E30EA@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C100E30EA@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Noel Chiappa , "" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 17:26:20 -0000 On May 3, 2013, at 5:58 PM, Stan Ratliff (sratliff) wr= ote: > I completely agree that sending less is preferable, especially on "disadv= antaged" links like RF. But from what I've seen, users *want* to deploy on = the order of thousands of routing nodes in a network (think of a brigade of= soldiers, each with 3 or 4 intelligent devices of some sort), do it wirele= ssly, *and* stream HD video all over the place=85 (Note that I said users *= want* to do this, not that it's actually possible). ;-) >From my perspective, that's the argument for solutions like TRILL and manet= , which use layer 3 concepts on what I would consider a layer 3 network, ju= st the sub-layer below IP.=20 As to streaming HD video among a brigade of soldiers, I tend to think the r= equirements get overstated. Aerial platforms and other theatre assets can h= elp a lot with the individual connectivity. In the US's 21st century wars, = patrol actions have far outnumbered battalion or brigade level actions, eve= n in places like the battle for Marjeh in 2009 when several battalions took= positions to oust a well-deployed insurgency. When one is driving or walki= ng somewhere and wondering "where might I find an IED" or "a sniper", what = has usually happened is that a photo was taken on each of several reconnais= sance flights, sophisticated algorithms have identified that someone walked= through a field and perhaps spent some time at a specific place between ph= oto shoots, and the patrol can be given a photograph with a circle around a= place rather than a live feed, or a one-frame-per-second feed, getting the= same operational results. Their return is likely to be the same, and more = about "am I looking at the same place you are" than "let me give you more d= etail on that." The places where one hears a lot about large scale sensor networks are simi= larly not usually everyone-streaming-HD-to-a-certain-place. Deborah Estrin = published several papers in the late 1990's about tracking California wildf= ires, for example. Her model was to distribute a large number of styrofoam = "golf balls" with the intelligence and power resources one might find in a = wristwatch, which would communicate back to a central location about what t= hey found. She started from IP, but pretty quickly discovered that what was= really needed in the application was something more akin to an isobar or i= sotherm map, and the best way to deliver it was to summarize information fr= om sensor to sensor rather than having sensors relay datagrams for each oth= er - a concept that I suspect fed into the CCN space. Putting that into a m= ilitary context, one could imagine a field of sensors distributing data abo= ut the amount of motion in their areas, which would quickly settle down int= o "there's a lot of noise in this general field" that might relate to dust = or plants, and "there is a solid object moving at a certain rate in the vic= inity of a certain set of sensors". As seems to always be the case, what users want may have no bearing on what= they actually need.= From adrian@olddog.co.uk Wed May 8 03:14:23 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875B821F90EB for ; Wed, 8 May 2013 03:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKxKLgLztU9L for ; Wed, 8 May 2013 03:14:17 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 7724B21F90D2 for ; Wed, 8 May 2013 03:14:17 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r48AEFkA011853 for ; Wed, 8 May 2013 11:14:15 +0100 Received: from 950129200 ([193.1.64.8]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r48AEEuG011821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 8 May 2013 11:14:15 +0100 From: "Adrian Farrel" To: Subject: Status of mentoring program Date: Wed, 8 May 2013 11:14:12 +0100 Message-ID: <00ee01ce4bd4$c9999a80$5ccccf80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5L1IKIG+Dmvgw7SWKS7ZVtooE1Jg== Content-Language: en-gb X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 10:14:23 -0000 Hi, In Orlando at the Routing Area meeting Stewart and I promised to put together a plan for mentoring in the Routing Area. Some of you were immediately kind enough to offer yourselves as mentors. Our ideas have been over-taken by events: the IAB and IESG are putting together an IETF-wide mentoring scheme. Look for an announcement soon and in any case before Berlin. Thanks, Adrian and Stewart From jnc@mercury.lcs.mit.edu Wed May 8 12:15:09 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B6B21F8EBF for ; Wed, 8 May 2013 12:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4BJaB4Q2yDo for ; Wed, 8 May 2013 12:15:05 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 4670D21F8F24 for ; Wed, 8 May 2013 12:15:05 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 140B018C192; Wed, 8 May 2013 15:15:04 -0400 (EDT) To: routing-discussion@ietf.org Subject: Re: question on link state routing protocols Message-Id: <20130508191504.140B018C192@mercury.lcs.mit.edu> Date: Wed, 8 May 2013 15:15:04 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 19:15:09 -0000 > From: Tony Li > Fair, but this is exactly why 802.11 has a built-in link layer > mechanism. No need to replicate it at a higher layer. I guess I still don't understand why IS-IS doesn't have the most robust possible update flooding mechanism, though - the potential consequences of out-of-sync maps (forwarding loops) are so severe. There must be something I'm missing (especially since they include the robust mechanism on point-point links). And it can't be because they didn't want to fuss with N^2, or having a DR to avoid that - IS-IS does have a DR. I guess the right thing to do is ask the people who designed it. (Which I guess would be Radia, Ross and Dave Oran?) Noel From rcallon@juniper.net Wed May 8 13:09:54 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BFC21F8EFC for ; Wed, 8 May 2013 13:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrDwBRSqSSSH for ; Wed, 8 May 2013 13:09:49 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0DE21F8AE2 for ; Wed, 8 May 2013 13:09:49 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUYqxDNSMlcXaneXYaeowLA0bviiKdUS3@postini.com; Wed, 08 May 2013 13:09:49 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 8 May 2013 13:07:11 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 8 May 2013 13:07:10 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.189) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 May 2013 13:18:09 -0700 Received: from mail37-co1-R.bigfish.com (10.243.78.227) by CO1EHSOBE025.bigfish.com (10.243.66.88) with Microsoft SMTP Server id 14.1.225.23; Wed, 8 May 2013 20:07:09 +0000 Received: from mail37-co1 (localhost [127.0.0.1]) by mail37-co1-R.bigfish.com (Postfix) with ESMTP id 6E68DB007AF for ; Wed, 8 May 2013 20:07:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -23 X-BigFish: PS-23(zz9371I542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1155h) Received: from mail37-co1 (localhost.localdomain [127.0.0.1]) by mail37-co1 (MessageSwitch) id 1368043583612057_9839; Wed, 8 May 2013 20:06:23 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.238]) by mail37-co1.bigfish.com (Postfix) with ESMTP id 937BF6A0193; Wed, 8 May 2013 20:06:23 +0000 (UTC) Received: from CH1PRD0510HT004.namprd05.prod.outlook.com (157.56.244.213) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 8 May 2013 20:06:21 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.207]) by CH1PRD0510HT004.namprd05.prod.outlook.com ([10.255.150.39]) with mapi id 14.16.0305.001; Wed, 8 May 2013 20:06:14 +0000 From: Ross Callon To: Noel Chiappa , "routing-discussion@ietf.org" Subject: RE: question on link state routing protocols Thread-Topic: question on link state routing protocols Thread-Index: AQHOTCBYXLDidisEB0ylQhX2fcZYQpj7ti2A Date: Wed, 8 May 2013 20:06:14 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD316C452F5@CH1PRD0510MB355.namprd05.prod.outlook.com> References: <20130508191504.140B018C192@mercury.lcs.mit.edu> In-Reply-To: <20130508191504.140B018C192@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.110.54.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%MERCURY.LCS.MIT.EDU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 20:09:54 -0000 I am hoping that Radia or Dave Oran will speak up. I *used* to know the ans= wer to this question, but have forgotten the details.=20 Ross -----Original Message----- From: routing-discussion-bounces@ietf.org [mailto:routing-discussion-bounce= s@ietf.org] On Behalf Of Noel Chiappa Sent: Wednesday, May 08, 2013 3:15 PM To: routing-discussion@ietf.org Cc: jnc@mercury.lcs.mit.edu Subject: Re: question on link state routing protocols > From: Tony Li > Fair, but this is exactly why 802.11 has a built-in link layer > mechanism. No need to replicate it at a higher layer. I guess I still don't understand why IS-IS doesn't have the most robust possible update flooding mechanism, though - the potential consequences of out-of-sync maps (forwarding loops) are so severe. There must be something I'm missing (especially since they include the robu= st mechanism on point-point links). And it can't be because they didn't want to fuss with N^2, or having a DR to avoid that - IS-IS does have a DR. I guess the right thing to do is ask the people who designed it. (Which I guess would be Radia, Ross and Dave Oran?) Noel _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From tony.li@tony.li Wed May 8 14:09:27 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6793D21F9113 for ; Wed, 8 May 2013 14:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5fHx+ekKka6 for ; Wed, 8 May 2013 14:09:21 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by ietfa.amsl.com (Postfix) with ESMTP id A1F6A21F90F3 for ; Wed, 8 May 2013 14:09:21 -0700 (PDT) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta09.emeryville.ca.mail.comcast.net with comcast id ZRzh1l0010EPchoA9Z9My7; Wed, 08 May 2013 21:09:21 +0000 Received: from [10.66.230.177] ([64.236.139.254]) by omta01.emeryville.ca.mail.comcast.net with comcast id ZZ791l00k5VXD0o8MZ7CpV; Wed, 08 May 2013 21:07:18 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: question on link state routing protocols From: Tony Li In-Reply-To: <20130508191504.140B018C192@mercury.lcs.mit.edu> Date: Wed, 8 May 2013 14:07:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130508191504.140B018C192@mercury.lcs.mit.edu> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.1503) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368047361; bh=5RWAtOrGIH1lWNzDA2OI3ysyfaPAZoISKc23vIkvBrg=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=fxi/4ab4s4/8QXR0JNujJHl8uOhCdLRgTLzNQ90k86RT7wSwAlo+h1PpDrlAx97Hk 2jpFTz/z9bi6onLO3zAyLoRBKIa+VqiqDNmX9xiiTZW5VWIEWCLnhPY0Uj69XLy4cW WAVVlUt+QroLFXBvv9o501LgIw+wOLU/2XLvnHyoJFtoXI1Bx64GKQxlmtBqvhSSHU XI4kRUUaHllPKBm5G1MLQ5PHul1RbNtNUalflHeRcRqKf58iRU2RFrdXhKl4wGYl0M V79OFoiwZgCwz5WYfPSnMtVpX+PMUUmJ7uJO7HG8nbXTxVkAn38ijkACGFd3v1Oh8z RjkLrPRbqSdOA== Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 21:09:27 -0000 Noel, >> Fair, but this is exactly why 802.11 has a built-in link layer >> mechanism. No need to replicate it at a higher layer. >=20 > I guess I still don't understand why IS-IS doesn't have the most = robust > possible update flooding mechanism, though - the potential = consequences of > out-of-sync maps (forwarding loops) are so severe. With all due respect, you have it backwards. The CSNP mechanism is FAR = more robust than a LSP-by-LSP acknowledgement. It is a continuing and = ongoing cross-checksum between adjacencies. With IS-IS, if an LSP is = lost in flight, then it is caught in the next CSNP cycle and = retransmitted. Further, if something happens in memory on either system = and LSPs are lost, then they get retransmitted. And there's only one = mechanism to take care of both. Tony From jnc@mercury.lcs.mit.edu Wed May 8 14:35:05 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159B221F8F25 for ; Wed, 8 May 2013 14:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnHdfydzuYBH for ; Wed, 8 May 2013 14:35:00 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id B599421F8EE1 for ; Wed, 8 May 2013 14:35:00 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 5049118C1A0; Wed, 8 May 2013 17:34:59 -0400 (EDT) To: routing-discussion@ietf.org Subject: Re: question on link state routing protocols Message-Id: <20130508213459.5049118C1A0@mercury.lcs.mit.edu> Date: Wed, 8 May 2013 17:34:59 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 21:35:05 -0000 > From: Tony Li > The CSNP mechanism is FAR more robust than a LSP-by-LSP > acknowledgement. It is a continuing and ongoing cross-checksum between > adjacencies. With IS-IS, if an LSP is lost in flight, then it is caught > in the next CSNP cycle and retransmitted. Perhaps "robust" was poor word choice on my part. Let's substitute "timely". A lost LSP is not caught until the next CSNP cycle, right? Why is it OK to wait until then? Noel From tony.li@tony.li Wed May 8 14:55:33 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E0F21F9130 for ; Wed, 8 May 2013 14:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbzEw1uXslTm for ; Wed, 8 May 2013 14:55:19 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by ietfa.amsl.com (Postfix) with ESMTP id 23F4121F9104 for ; Wed, 8 May 2013 14:55:19 -0700 (PDT) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta13.emeryville.ca.mail.comcast.net with comcast id ZZdi1l0040QkzPwADZvKCU; Wed, 08 May 2013 21:55:19 +0000 Received: from [10.66.230.177] ([64.236.139.254]) by omta02.emeryville.ca.mail.comcast.net with comcast id ZZt81l00i5VXD0o8NZtAg2; Wed, 08 May 2013 21:53:17 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: question on link state routing protocols From: Tony Li In-Reply-To: <20130508213459.5049118C1A0@mercury.lcs.mit.edu> Date: Wed, 8 May 2013 14:53:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <875A7D4B-588A-44BA-9C5E-93B5B79235F3@tony.li> References: <20130508213459.5049118C1A0@mercury.lcs.mit.edu> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.1503) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368050119; bh=1Wbljy1KQHz+SoZOylAobidG6Qg4JNr+/wuVaRQfC/U=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=a707feqFuYtqVxJev3QKSc6Zh8HKPjBHF7G+Glr1Gjufb9sGoQbZr62i5OB4nJcrp t1tUeMhYUBnm4uChlBBgDwdXO4pkktgpMhUKQJeH7YBvIOKfHkX0ZxLo2fXBYKsyAS v/J0zpeFKTb2ZxDEmp+HFwelO+SSyuVL8aRnA6ynZ6PLR7IM8CcLch+dBlt2pKoLxf uVbMBrFAYVP9otkZR6tyLyabscLEp/mFaGXdrbSYVovOzUZnjjdc6kZKOiVc9OP1pB h5pJmD4v62CmL+N8ZO1k6y45KLV1O4DsY8ABXasu+gGmQlvr6dUMhpSE+LVkrW5fe6 OD+n+NmDe9jfA== Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 21:55:34 -0000 On May 8, 2013, at 2:34 PM, jnc@mercury.lcs.mit.edu (Noel Chiappa) = wrote: >> The CSNP mechanism is FAR more robust than a LSP-by-LSP >> acknowledgement. It is a continuing and ongoing cross-checksum = between >> adjacencies. With IS-IS, if an LSP is lost in flight, then it is = caught >> in the next CSNP cycle and retransmitted. >=20 > Perhaps "robust" was poor word choice on my part. Let's substitute = "timely". >=20 > A lost LSP is not caught until the next CSNP cycle, right? Why is it = OK to > wait until then? P[packet loss] ~=3D 10^-18 Doing more would be over-design. Tony From oran@cisco.com Wed May 8 14:57:32 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0C621F8BB7 for ; Wed, 8 May 2013 14:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWzf5d30GNZs for ; Wed, 8 May 2013 14:57:27 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8350321F86C1 for ; Wed, 8 May 2013 14:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1257; q=dns/txt; s=iport; t=1368050247; x=1369259847; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AM5DcV7vIXeejAsW8Dx5AcqXO+p1IEqLcqsXzyBO1YY=; b=Q0Gz/bXULz6sJrCBe7E/Ze+GIbXYY+RAEbvYITGpvrU9oS6FjPuB7iOP FchXNe7K4/oz0+DqldiRD9pUYPnpZV3XcNTLQNmuG6gQH2PV4wyclzMHj GUTH5Ucm/dACfyhgAOKs2GTrZSzCzSmSNkXZY69be+24EKtF1VPk6IXCt A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFABrJilGtJXG8/2dsb2JhbABSDoJ5N78XehZ0gh8BAQEDAQEBATc0CwULAgEIDgcNFBAnCyUCBA4FCBKHbAYMwVQEjnUCMQeCdGEDqGGCUD+CJw X-IronPort-AV: E=Sophos;i="4.87,636,1363132800"; d="scan'208";a="207873827" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 08 May 2013 21:57:25 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r48LvPk4004059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 May 2013 21:57:25 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.79]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 8 May 2013 16:57:25 -0500 From: "Dave Oran (oran)" To: Noel Chiappa Subject: Re: question on link state routing protocols Thread-Topic: question on link state routing protocols Thread-Index: AQHOTDPjTbMsVpPnUkKwmc/xCoS2rpj8KXiA Date: Wed, 8 May 2013 21:57:24 +0000 Message-ID: <61A34E1FA77BE74E886859A389603E7F4293E070@xmb-rcd-x01.cisco.com> References: <20130508213459.5049118C1A0@mercury.lcs.mit.edu> In-Reply-To: <20130508213459.5049118C1A0@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.69.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <44D1929C0A22384BB0CE553E918BC7C2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 21:57:33 -0000 On May 8, 2013, at 5:34 PM, Noel Chiappa wrote: >> From: Tony Li >=20 >> The CSNP mechanism is FAR more robust than a LSP-by-LSP >> acknowledgement. It is a continuing and ongoing cross-checksum between >> adjacencies. With IS-IS, if an LSP is lost in flight, then it is caught >> in the next CSNP cycle and retransmitted. >=20 > Perhaps "robust" was poor word choice on my part. Let's substitute "timel= y". >=20 > A lost LSP is not caught until the next CSNP cycle, right? Why is it OK t= o > wait until then? >=20 Because a timeout is a timeout is a timeout. If you want faster responsiven= ess you can crank down the CSNP interval. CSNPs aren't that big (compared t= o actual LSPs) and are multicast so they don't use O(numberofroutersonthe l= ink) of bandwidth. If you want to be especially clever you can use differen= t CSNP intervals for bad news and good news. Transitive closure on LANs is pretty important, so just comparing the 2-par= ty responsiveness doesn't tell the whole story. > Noel > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From imc.shand@gmail.com Mon May 13 10:38:57 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07C721F93EF for ; Mon, 13 May 2013 10:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl8BWdVhPinx for ; Mon, 13 May 2013 10:38:53 -0700 (PDT) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id 2C53821F93EE for ; Mon, 13 May 2013 10:38:53 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id e49so1872501eek.33 for ; Mon, 13 May 2013 10:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ze4iyDl1+2JZpEWMNEaQzdquAZeyIguVSgAm2XHEBEA=; b=pT+hjWuwWoap8AISHDjKoB4rSzGjAWoinMrtlh0dEy1eTo8hqz59sR0M5DB4urXGsS HpMPbFK3Jyuv2MuAXuYgXDFDy8lgR9GN0kJwzcp1TPCOM9vdBlRDCuw7Cq5UiEA7vic0 WKb/504Zy3k7GRTetWOGooPc0eSSwQHtKFAeTZIyKsrdGbBgfXtLzq5KaSXE+Krj+dwS 6Rm1JAfW7lToQfXHBIJR8VMd7RZO3zPwdBS6VCM8ow3l4FboaPsuI0BucNYCDHCz6ngw YaTJQgdyFUsx9rJKfmyneRoiDPyb1DI3yyHYWOPytBaIskX1V9Ed1aXui5tCEA8DwbqA A1yQ== X-Received: by 10.14.211.69 with SMTP id v45mr7211628eeo.45.1368466731934; Mon, 13 May 2013 10:38:51 -0700 (PDT) Received: from [192.168.2.183] (46-65-61-13.zone16.bethere.co.uk. [46.65.61.13]) by mx.google.com with ESMTPSA id c42sm3961907eeb.10.2013.05.13.10.38.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 May 2013 10:38:51 -0700 (PDT) Message-ID: <5191252A.6010208@gmail.com> Date: Mon, 13 May 2013 18:38:50 +0100 From: Mike Shand User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: routing-discussion@ietf.org Subject: Re: question on link state routing protocols References: <20130508213459.5049118C1A0@mercury.lcs.mit.edu> <61A34E1FA77BE74E886859A389603E7F4293E070@xmb-rcd-x01.cisco.com> In-Reply-To: <61A34E1FA77BE74E886859A389603E7F4293E070@xmb-rcd-x01.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 17:38:57 -0000 What is important here is that for correctness the databases MUST eventually be synchronized. However, as has been pointed out, LSP loss is actually a low probability event (mostly due to overloading receivers with too much information... certainly in the old days, when this was designed), and timeliness of retransmission is not particularly important, since in most cases, there will be multiple paths for the LSPs to arrive over, so temporary loss of a single LSP is rarely an issue. In particular, in the cases were there IS only a single path on which it can be received, it tends to indicate that the temporary mis-synchronization is even less important, since there is probably not much you could do about it, even if you DID get the timely information. As Tony says, there is a danger of over-engineering here. Mike On 08/05/2013 22:57, Dave Oran (oran) wrote: > On May 8, 2013, at 5:34 PM, Noel Chiappa > wrote: > >>> From: Tony Li >>> The CSNP mechanism is FAR more robust than a LSP-by-LSP >>> acknowledgement. It is a continuing and ongoing cross-checksum between >>> adjacencies. With IS-IS, if an LSP is lost in flight, then it is caught >>> in the next CSNP cycle and retransmitted. >> Perhaps "robust" was poor word choice on my part. Let's substitute "timely". >> >> A lost LSP is not caught until the next CSNP cycle, right? Why is it OK to >> wait until then? >> > Because a timeout is a timeout is a timeout. If you want faster responsiveness you can crank down the CSNP interval. CSNPs aren't that big (compared to actual LSPs) and are multicast so they don't use O(numberofroutersonthe link) of bandwidth. If you want to be especially clever you can use different CSNP intervals for bad news and good news. > > Transitive closure on LANs is pretty important, so just comparing the 2-party responsiveness doesn't tell the whole story. > >> Noel >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion