This is an early review with a specific request to review the Security Considerations section.

The draft adds a bunch of TLVs to be sent from routers regarding the link state of the link used for IGP. The draft references RFC 7752 which defined earlier TLVs used to carry NLRI (reachability) information.

What I found difficult about both 7752 and this draft is the vagueness about who the consumer of this information is. The abstract of 7752 begins like this: "In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information."
There is also a diagram with information flowing to a "consumer" and that's it. Is it an SDN controller? Some kind of application?

OK. On to the Security Considerations section. It begins with a statement that this does not affect the security model of BGP.  Although that is just claimed and not supported in text, it seems reasonable. I should note that this paragraph is copied from 7752.

The second (and last) paragraph in the security considerations section talks about the new attributes. It mentions that security and authentication are assumed to be used just as in RFCs 7810 and 7471. With proper authentication this information is not sent except to the proper consumer. However, there is an important difference that I think needs to be addressed. 7810 and 7471 are about IS-IS and OSPF respectively. There routing protocols are typically used in closed environments, and the Security Considerations of 7810 state that explicitly. BGP (the subject of this document) is different in that it is typically used all over the Internet. Without further clarity about who and where the "consumer" is, it has to be assumed that the information might at least leak out.

Another issue I have with this section is that the draft specifies how to send new information (the link state TLVs) from one node to another. This is information that was not sent before. When a change like that is made, I think the Security Considerations section should justify why it is OK to distribute this information. Typically you need to justify that leaking this information (to the intended recipient or to the rest of the world) does not (1) make it easier to attack some part of the system, or (2) distributes privacy-sensitive information, or (3) undermines some other confidentiality interest. I think it's fairly easy to make the argument that the information in these TLVs does not do any of the above, but the argument should be made.  The last paragraph in the Security Considerations section of RFC 7752 has just such an argument.