[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Routing Directorate comments on draft-ietf-ccamp-automesh-01
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.
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
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
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>> 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?