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

[[e-mail]]

hi adrian

sensible imho - comments can be shared 

now i would like to see your opinion on

"> o) the document does introduce a field to facilitate LSP identification 

> (name) as part of the routing extension i am concerned by the 
introduction 
> of a new LSP identification format / mechanism - if no pointer to RFC 
3209 
> is provided;"

per 3209, we have 3 tuples to identify sessions (+ session name in session 
attribute)

per 3209, we have 5 tuples to identify LSPs 

so my interpretation from the text that the "tail-end" field is a TE LSP 
group name
- but is that correct ? -

ps: subsidiary question - is it suitable to exchange LSP names via routing 
? - opinions ?





"Adrian Farrel" <[e-mail]>
29/08/2006 23:42
Please respond to Adrian Farrel
 
        To:     "Acee Lindem" <[e-mail]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Ross Callon <[e-mail]>, 
[e-mail], [e-mail]
        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