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

From: Acee Lindem <[email-masked]>
Date: Mon, 28 Aug 2006 22:45:29 -0400

Hi Dimitri,

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 ;^).

See some comments on your comments inline.

[email-masked] wrote:
> hi ross
>
> i have a couple points on this doc.
>
> 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; 
>
> 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?

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 document mentions that "The TE-MESH-GROUP TLV is OPTIONAL and must 
> at most appear once in a OSPF Router Information LSA or ISIS Router 
> Capability TLV." but for addition/removal it mentions "conversely, if the 
> LSR leaves a mesh-group the corresponding entry will be removed from the 
> TE-MESH-GROUP TLV." what are these "entries" referring to - that there is 
> a top-level TE-MESH-GROUP TLV with multiple sub-TLVs (but the document 
> mentions "No sub-TLV is currently defined for the TE-mesh-group TLV") ? 
>   
I interpret this to mean that a list of mesh groups is packed in a 
single TLV. I agree
that this should be stated explicitly. To the best of my knowledge, it 
has been this
way from the beginning  (although  it may have started with a single 
mesh group).

> o) the document mentions that "Note that both operations can be performed 
> in the context of a single refresh." but this is not a refresh anymore 
> this becomes a trigger/update
>   
I agree that a better term could be used. I'd prefer "LSA origination". 
for OSPF.

> o) it would be valuable to state exact OSPF applicability since the 
> Router_Cap document (used by the present doc) covers both v2 and v3
>
> 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.

Thanks,
Acee

> much thanks,
> - dimitri.
>
>
>
>
>
>
> Ross Callon <[email-masked]>
> 25/07/2006 18:54
>  
>         To:     [email-masked]
>         cc:     [email-masked], [email-masked]
>         Subject:        draft-ietf-ccamp-automesh-01.txt
>
>
> I am looking for one or two routing directorate volunteers to
> review draft-ietf-ccamp-automesh-01.txt,  and/or am looking
> for comments on this document.
>
> To me there seems to be two issues that are worth looking at
> (although of course a reviewer may find other things to comment
> on).
>
> One question involves the advisability of piggybacking information
> on IGPs. One the one hand in this case the information being
> piggybacked is relatively small in volume, and is also quite stable.
> Thus the extra load on the IGP seems minimal. On the other hand,
> piggybacking on IGPs in general seems to have two issues that
> make it more iffy compared to piggybacking on BGP: (i) IGPs have
> very tight timing constraints (if a link goes down you want your IGP
> to respond quickly, and you also want all routers in an area to update
> their routing databases and forwarding tables relatively close to at the
> same time to minimize the persistence of microloops); (ii) If the
> amount of information grows to the point that it is bothersome, with
> BGP the L3VPN framework describes how to partition it into multiple
> instances, each of which is only run between those routers which
> actually need to know the information being distributed, with IGPs
> (OSPF and IS-IS) the same information is flooded to all routers in the
> area, including those that don't need it, and it is not obvious to me
> how to cleanly partition two instances of an IGP in the same network;
> (I have also heard a complaint that IGPs refresh their LSAs periodically,
> and thus the piggybacked information also needs to be refreshed -- I
> however would expect that refreshes would be rare enough, and
> sufficiently spread over time, that this would not be a significant extra
> load).
>
> The other issue that I notice is that the security considerations section
> of this document is null ("No new security issues are raised in this
> document"). While this may be true (I can't think of any new security
> considerations -- if the IGP is compromised then you are in real
> trouble with or without this enhancement), if anyone can think of more
> to say here this might be a good idea. In fact, it might not be a bad
> idea to have a "security considerations with IGPs" document that we
> could just refer to (volunteers to write this one?).
>
> Thanks, Ross
>
>
>
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 29 Aug 2006 22:42:01 +0100

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)

> from section 9, with no "useful" comments ;^).

Oh, is that what the Acknowledgments section is for?

> 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

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

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

---

From: [email-masked]
Date: Wed, 30 Aug 2006 09:32:48 +0200

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 

> 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" <[email-masked]>
29/08/2006 23:42
Please respond to Adrian Farrel
 
        To:     "Acee Lindem" <[email-masked]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Ross Callon <[email-masked]>, 
[email-masked], [email-masked]
        Subject:        Re: draft-ietf-ccamp-automesh-01.txt

Hi Acee and Dimitri,

> Actually, the OSPF theoretical limit is much smaller since the new TLV 
can 
> once and the length of a single TLV is limited to 2^16 bytes. However, 
all 
> had with the authors indicate that deployments will be limited to a 
small 

Hmmm.

> There are several ways these could have been advertised but now that 
we've 

For example: "This mechanism SHOULD NOT be used if LSRs join or leave a 
mesh 

Thoughts?

A