Re: draft-ietf-ccamp-automesh-01.txt

["Adrian Farrel" <[e-mail]>]

Oh, one other thing: can we get these comments out into the CCAMP WG?
They can be anonymised through me or Ross, if you like.

A
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: "Acee Lindem" <[e-mail]>; <[e-mail]>
Cc: "Ross Callon" <[e-mail]>; <[e-mail]>; 
<[e-mail]>
Sent: Tuesday, August 29, 2006 10:42 PM
Subject: Re: draft-ietf-ccamp-automesh-01.txt


> 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