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

From: Ross Callon <[email-masked]>
Date: Tue, 25 Jul 2006 12:54:15 -0400

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: [email-masked]
Date: Tue, 25 Jul 2006 22:50:12 +0200

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 

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") ? 

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

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) 

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

Thanks, Ross