Re: draft-ietf-ccamp-automesh-01.txt
"Adrian Farrel" <adrian@olddog.co.uk> Tue, 29 August 2006 21:43 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBN5-0004KU-3a; Tue, 29 Aug 2006 17:43:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBN3-0004ED-Nj for rtg-dir@ietf.org; Tue, 29 Aug 2006 17:43:45 -0400
Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIBN1-0003FG-88 for rtg-dir@ietf.org; Tue, 29 Aug 2006 17:43:45 -0400
Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1GIBN8-0007sj-00 for rtg-dir@ietf.org; Tue, 29 Aug 2006 22:43:50 +0100
Received: from your029b8cecfe ([217.158.132.220] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Aug 2006 22:43:26 +0100
Message-ID: <047701c6cbb4$24e706f0$89849ed9@your029b8cecfe>
From: Adrian Farrel <adrian@olddog.co.uk>
To: Acee Lindem <acee@cisco.com>, Dimitri.Papadimitriou@alcatel.be
References: <OFAC1DC5D9.860F4CE0-ONC12571B6.0064F578-C12571B6.00727649@netfr.alcatel.fr> <44F3AA49.3010704@cisco.com>
Date: Tue, 29 Aug 2006 22:42:01 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="response"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-OriginalArrivalTime: 29 Aug 2006 21:43:27.0102 (UTC) FILETIME=[291DF9E0:01C6CBB4]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: Ross Callon <rcallon@juniper.net>, fenner@research.att.com, rtg-dir@ietf.org
Subject: Re: draft-ietf-ccamp-automesh-01.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
Errors-To: rtg-dir-bounces@ietf.org
Hi Acee and Dimitri, Very much appreciate you reviewing this. We did get a couple of comments from IS-IS so we have something to think about. See in line (suitably snipped) > Since we recently completed a last call of this document in the OSPF WG > and received no additional comments, I decided to take another look. > I've also reviewed this document at least twice previously but, judging > from section 9, with no "useful" comments ;^). Oh, is that what the Acknowledgments section is for? >> o) the document mentions that the number of mesh groups is limited but >> potentially (depending on encoding) provides for binary encoding for >> 2^32-1 groups - how this can be controlled such as to prevent the >> resulting behaviour you have described > Actually, the OSPF theoretical limit is much smaller since the new TLV can > occur at most > once and the length of a single TLV is limited to 2^16 bytes. However, all > discussions I've > had with the authors indicate that deployments will be limited to a small > number of mesh > groups (usually 1 and never more than a handful). Is there any reason to > doubt this? Hmmm. 1. Whenever we say something like that, history proves us wrong. 2. There is a proposal to use mesh groups for P2MP membership discovery. Essentially, each P2MP LSP will behave as a mesh group. (Hint: I want to kill that idea!) > There are several ways these could have been advertised but now that we've > gone this > long down this path, I don't think we should change it unless there is a > very good > reason. > >> o) the term "fairly static" is relative to the OSPF refresh timer ? (i >> would ask to refer to periodicity instead) > I interpreted this as referring to the author's view on how often an LSR > will be > join or leave a mesh group. Yeah, that is my take, too. I really don't like these relativistic statements when they are not quantified. It would be best to state it relative to the OSPF refresh timer. For example: "This mechanism SHOULD NOT be used if LSRs join or leave a mesh group more frequently than the OSPF refresh timer." Thoughts? A
- draft-ietf-ccamp-automesh-01.txt Ross Callon
- Re: draft-ietf-ccamp-automesh-01.txt Dimitri.Papadimitriou
- Re: draft-ietf-ccamp-automesh-01.txt Acee Lindem
- Re: draft-ietf-ccamp-automesh-01.txt Adrian Farrel
- Re: draft-ietf-ccamp-automesh-01.txt Adrian Farrel
- Re: draft-ietf-ccamp-automesh-01.txt Dimitri.Papadimitriou