I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.


draft-ietf-mpls-ldp-igp-sync-bcast-04 
LDP IGP Synchronization for broadcast networks

the draft updates RFC 5443 (LDP IGP Synchronization)
It basically proposes the following mechanism: "If an interface is not a
'cut-edge' then the updating of the LSA with that link to the
pseudo-node is postponed until LDP is operational."

The document states that there would be no security considerations
beyond RFC5443.
I am not certain of that. Although the idea behind bcast is good, it
adds a new mechanism beyond 5443.
To make sure the security considerations are accurate, I'd like to raise
two questions for the authors/WG:
1. Which security implications does the WG see for removing a coming up
link from the LSDB?
2. Can there be a gap between the algorithm to determine "cut-edge" and
TTL (e.g. may not qualify for "cut-edge" and thus be removed from LSDB,
but have a large number of links and effectively not be reachable)?

and three minor editorial comments:
- section 3, last paragraph:
s/Since A's cost to reach B not high/Since A's cost to reach B is not high
- Appendix A: Computation of 'cut-edge'
there should be an informative reference for mentioned "Dijkstra's
algorithm"
- abbreviation "SPF" should list the its expanded term (Shortest Path
First) at first mentioning.

Best regards, Tobias