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