Routing Directorate comments on draft-ietf-ccamp-automesh-01

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

We held an additional last call for this draft in the IGP working groups and 
received some further comments that JP has just addressed in a new revision.

We have also received some comments from a review in the Routing Directorate 
that I am précising below. JP, authors: please look through these and let us 
know your proposals for dealing with them.

Thanks,
Adrian

===

1) The Tail-end name field facilitates LSP identification. Is this a new 
form of LSP identification?
If it is not new, then there should be a reference to RFC3209 and a 
statement of which RFC3209 fields are mapped to this IGP field.
If it is not new then there is a significant concern that a new 
identification is being introduced when it is not needed.

2) 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 (although this might be constrained by OSPF's limit of a TLV 
size to 2^16 bytes.
The document (and the authors) state that scaling of these extensions is not 
an issue because only a small number of mesh groups are likely to be in 
existence in a network, and any one router is unlikely to participate in 
more than a very few.
There are two concerns:
a) Whenever we say that something in the Internet is limited, history 
usually proves us wrong. Indeed, there is already a
proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a similar 
mechanism for a problem that would have far more groups.
b) The I-D does not itself impose any reasonable limits on the number of 
groups with the potential for a single router (by misconfiguration, design, 
or malice) advertising a very large number of groups.
Thus, it appears that the scaling concerns are not properly addressed in 
this I-D.

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

AF>> My comment on this is that the definition of the TLVs seems unclear.
AF>> From figure 2, it appears that some additional information can be
AF>> present in the TLV after the fields listed, and (reading between the
AF>> lines) it would appear that this additional information is a series of
AF>> repeats of the set of fields to define multiple mesh groups.
AF>> This could usefully be clarified considerably.
AF>>
AF>> But it is now unclear to me whether a single router can be a member
AF>> of IPv4 an IPv6 mesh groups. It would seem that these cannot be
AF>> mixed within a single TLV, and multiple TLVs (one IPv4 and one
AF>> IPv6) are prohibited.

4) Small terminology issue in section 5.1 it says: "Note that both 
operations can be performed in the context of a single refresh."
This is not a refresh. It is a trigger/update. A better term for OSPF would 
be "LSA origination".

5) Please state the applicability to OSPF v2 and or v3. Note that the 
Router_Cap document covers both v2 and v3

6) The term "fairly static" at the end of section 5.1 is meaningless without 
some relative context.
Presumably this relates to the number times an LSR joins or leaves a mesh 
group over time.
Is it intended to be relative to the IGP refresh period?
Please clarify in an objective rather than a subjective way.

7) The security section (section 8) is inadequate and will undoubtedly be 
rejected by the security ADs. At the very least, the I-D needs a paragraph 
(i.e. more than one or two lines) explaining why there are no new security 
considerations. But what would be the impact of adding false mesh groups to 
a TLV? Is there anything (dangerous) that can be learned about the network 
by inspecting mesh group TLVs?